MPLS Transport Profile Data Plane Architecture
updated by
- rfc-7274 — Allocating and Retiring Special-Purpose MPLS Labels
Extracted elements (30)
ECMP is prohibited on MPLS-TP LSPs because MPLS-TP transport paths require deterministic, stable routing for OAM correlation and protection/restoration to function correctly; load-balancing in the server layer is permitted only if transparent to MPLS-TP.
PHP is disabled by default on MPLS-TP LSPs because transport networks require the penultimate LSR to forward the packet with its LSP label intact, enabling end-to-end OAM and consistent TTL/label-stack semantics at the egress LER.
Pipe and Short Pipe Diffserv tunneling models are required (not just permitted) for typical transport use because transport networks are designed so the server layer topology and QoS are independent of the client layer, making Uniform model inappropriate.
MPLS-TP includes the data plane architectures for both single-segment pseudowires (RFC 3985) and multi-segment pseudowires (RFC 5659) without modification or extension to pseudowire data plane architectures or protocols.
The S-bit behavior in MPLS-TP differs slightly from RFC 3032: RFC 3032 uses the S bit to signal the transition from MPLS to network-layer processing, but MPLS-TP requires exactly one S=1 entry even when the payload is itself an MPLS-labeled packet (e.g., a PW or nested LSP).
A section MUST provide a means of identifying the type of payload it carries; link-specific mechanisms, the LSP label, the S bit, or additional labels MAY be used.
Client layers that wish to secure data carried over MPLS-TP transport entities are REQUIRED to apply their own security mechanisms, as the MPLS-TP data plane provides none.
Data plane implementations MUST provide adequate context (such as receiving interface or received label stack) to the application that is to process a G-ACh packet; the required context definition MUST be part of the application's specification.
Encapsulation and forwarding of packets traversing MPLS-TP LSPs MUST follow standard MPLS packet encapsulation and forwarding as defined in RFC 3031, RFC 3032, RFC 5331, and RFC 5332, except as explicitly stated otherwise.
Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed on an MPLS-TP LSP. If the server layer supports load-balancing, it MUST operate transparently to MPLS-TP.
In order for two LSRs to exchange non-IP MPLS-TP control packets over a section, the G-ACh Label (GAL) MUST appear at the bottom of the label stack.
MPLS-TP packet encapsulation and forwarding SHALL operate according to the MPLS data plane architecture described in RFC 3031 and RFC 3032 and to the data plane architectures for single-segment and multi-segment pseudowires, except as noted otherwise.
Penultimate Hop Popping (PHP) MUST be disabled by default on MPLS-TP LSPs.
Point-to-point unidirectional LSPs are REQUIRED to function in the same manner in the MPLS-TP data plane as in the basic MPLS architecture (RFC 3031), except as explicitly stated otherwise.
Support for Internet Protocol (IP) host and router data plane functionality by MPLS-TP interfaces and in MPLS-TP networks is OPTIONAL, in contrast to general MPLS (RFC 3031 Section 3.10).
Support for the Pipe or Short Pipe Diffserv tunneling and TTL processing models is REQUIRED for typical transport applications in which the topology and QoS characteristics of the MPLS-TP server layer are independent of the client layer.
The G-ACh MUST NOT be used to transport client layer network traffic in MPLS-TP networks; it is reserved for control, management, and OAM traffic.
The Traffic Class field (formerly EXP field) of an MPLS label follows the definition of RFC 5462 and RFC 3270 and MUST be processed according to the rules specified in those documents.
When the payload of an MPLS-TP LSP itself contains an MPLS label stack, exactly one LSE in the contiguous stack SHALL have the S (Bottom of Stack) bit set to 1.
A co-routed bidirectional LSP is an associated bidirectional LSP with the additional constraint that its two unidirectional component LSPs follow the same path (nodes and links), causing them to share fate.
A point-to-multipoint LSP differs from point-to-point in that an LSR may have more than one (egress interface, outgoing label) pair, transmitting each packet out all associated egress interfaces, as described in RFC 4875 and RFC 5332.
A point-to-point associated bidirectional LSP consists of two unidirectional LSPs (A→B and B→A) treated as a pair forming a single logical bidirectional transport path.
An MPLS-TP section at layer n is the connectivity between two topologically adjacent LSRs at that layer; the label stack for a layer-n section has n labels in the absence of stack optimization.
MPLS-TP defines four LSP types: point-to-point unidirectional, point-to-point associated bidirectional, point-to-point co-routed bidirectional, and point-to-multipoint unidirectional.
MPLS-TP defines three data plane transport entities: Label Switched Paths (LSPs), sections, and pseudowires (PWs). These form the layered transport hierarchy of an MPLS-TP network.
The Associated Channel Header (ACH) is the 32-bit structure following the bottom-of-stack label; it acts as a discriminator for the type of G-ACh traffic. For PWs, it is identified by a first nibble value of '1' following the PW label.
The G-ACh Label (GAL) is a reserved label with value 13 placed at the bottom of the label stack to indicate that the payload begins with an Associated Channel Header (ACH) for sections and LSPs.
The Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with MPLS-TP sections, LSPs, and PWs, primarily for OAM, control, and management traffic, as specified in RFC 5586.
The MPLS-TP data plane does not provide any inherent security mechanisms; client layers must apply their own. Management and control plane protocols used to establish transport paths carry their own security features that operators should leverage.
Where enhanced security is desirable, an LSR MAY implement a packet-discard policy: accept an MPLS packet only if a processed label was distributed by the receiving LSR to that neighbor, or was distributed to a peer known to be reachable via that neighbor.