RFC 8184: Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires
In plain English — editorial summary, not part of the RFC
This document describes a framework and several scenarios for a pseudowire (PW) dual-homing local protection mechanism that avoids unnecessary switchovers and does not depend on whether a control plane is used. A Dual-Node Interconnection (DNI) PW is used to carry traffic between the dual-homing Provider Edge (PE) nodes when a failure occurs in one of the Attachment Circuits (AC) or PWs. This PW dual-homing local protection mechanism is complementary to existing PW protection mechanisms.
Document record
- Document ID
- RFC8184
- Published
- June 2017
- Authors
- W. Cheng; L. Wang; H. Li; S. Davari; J. Dong
- Status
- INFORMATIONAL
- Stream
- IETF
- Area
- rtg
- Pages
- 11
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 8185Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires ProtectionCurrent
June 2017
- RFC 8256Requirements for Hitless MPLS Path Segment MonitoringCurrent
October 2017
- RFC 7759Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) PingCurrent
February 2016
- RFC 7487Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TECurrent
March 2015
- RFC 7325MPLS Forwarding Compliance and Performance RequirementsCurrent
August 2014
- RFC 7190Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP)Current
March 2014
- RFC 7167A Framework for Point-to-Multipoint MPLS in Transport NetworksCurrent
April 2014
- RFC 8169Residence Time Measurement in MPLS NetworksCurrent
May 2017
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?