Explicit Path Routing for Dynamic Multi-Segment Pseudowires
Extracted elements (21)
Explicit path routing of dynamic MS-PWs is introduced to support 1:1 protection with diverse primary and backup paths through distinct Switching Provider Edges (S-PEs), avoiding single points of failure at the PW level. It also enables controlled (strict or loose) signaling for special MS-PWs and network resource management.
In many deployments the ST-PE will not have a view of the topology of S-PEs, so the explicit route must be supplied from a management application. How that management application determines the explicit route is outside the scope of this document.
The ER-TLV format is taken directly from Section 4.1 of RFC 3212 (Constraint-Based LSP Setup using LDP), and the ER-Hop TLV format from Section 4.2 of RFC 3212. IPv4 Prefix and IPv6 Prefix ER-Hop semantics also remain as defined in RFC 3212 Sections 4.7.1 and 4.7.2 respectively.
The L2 PW Address carried in the new ER-Hop TLV is derived from the Generalized PWid FEC AII Type 2 structure as defined in RFC 5003; all fields (AII Type, Length, Global ID, Prefix, AC ID) are set and interpreted per Section 3.2 of RFC 5003.
Each node MUST determine a loop-free path if it is to signal the MS-PW. RFC 6073 Section 7.6 provides a mechanism by which a node can check that the path taken by an MS-PW does not include loops.
Each S-PE MUST be assigned an address as specified in Section 3.2 of RFC 7267. An S-PE capable of dynamic MS-PW signaling that has not been assigned an S-PE address and receives a Label Mapping message for a dynamic MS-PW MUST follow the procedures in Section 3.2 of RFC 7267.
If a Label Mapping message with no ER-TLV is received, it MUST be processed as per RFC 7267, preserving backwards compatibility with non-explicit-route MS-PW signaling.
If a loop-free path cannot be found by an ST-PE or S-PE, the node MUST NOT attempt to signal the MS-PW. For an S-PE, if it cannot determine a loop-free path, the received Label Mapping message MUST be released with a status code of 'PW Loop Detected' per Section 4.2.3 of RFC 7267.
If no path exists from the current node to a strict second ER-Hop, the node MUST return a Label Release message to the upstream node with a 'Bad Strict Node Error' (0x04000002) status code.
If no path exists within the MPLS domain to a loose second ER-Hop, the node MUST return a Label Release message to the upstream node with a 'Bad Loose Node Error' (0x04000003) status code.
If there is no ER-Hop TLV contained in the ER-TLV, the message is in error and the node SHOULD return a 'Bad Explicit Routing TLV Error' (0x04000001) status code in a Label Release message sent to the upstream node.
The node receiving the Label Mapping message MUST evaluate the first ER-Hop. If the L bit is not set and the node is not part of the abstract node described by the first ER-Hop, it MUST reply with a Label Release message carrying a 'Bad Initial ER-Hop Error' (0x04000004) status code.
The U and F bits in the L2 PW Address ER-Hop TLV MUST be set to zero, and the procedures of RFC 5036 MUST be followed when the TLV is not known to the receiving node.
When inserting a series of ER Hops before the first ER-Hop (because the node is a member of the first abstract node), each inserted ER Hop MUST denote an abstract node that is a subset of the current abstract node.
When there are no further ER-Hop TLVs following the first ER-Hop (indicating the end of the explicit route), the Explicit Route TLV MUST be removed from the Label Mapping message before forwarding.
The Explicit Route Hop TLV (ER-Hop TLV) identifies an abstract node representing one hop along the MS-PW path. This document defines a new ER-Hop TLV Type, value 0x0805, for the 'L2 PW Address of Switching Point', in addition to the IPv4 Prefix, IPv6 Prefix, AS Number, and LSP-ID types inherited from RFC 3212.
The Explicit Route TLV (ER-TLV) specifies the path to be taken by the MS-PW being established, encoding an ordered list of abstract nodes (groups of one or more S-PEs identified by IPv4, IPv6, or S-PE address). Its format follows Section 4.1 of RFC 3212 and contains one or more ER-Hop TLVs.
IANA assigned TLV type value 0x0805 labeled 'L2 PW Address of Switching Point' from the IETF consensus portion of the LDP 'TLV Type Name Space' registry defined in RFC 5036.
This document introduces no new security considerations beyond those discussed in RFC 5036, RFC 4447, and RFC 7267. The path selection mechanism enables automatic selection of S-PEs for forwarding; operators SHOULD use tools such as VCCV trace (RFC 6073) to verify the path taken by the MS-PW and confirm it does not represent an additional security risk.
Next-hop selection at each node proceeds through seven ordered steps: (1) validate the first ER-Hop against node identity; (2) if no further hops, remove ER-TLV; (3) if node also matches second ER-Hop, delete first and repeat; (4) if topologically adjacent to second ER-Hop's abstract node, select and delete first; (5) otherwise route within first abstract node toward second, returning error if no path; (6) replace first ER-Hop with one denoting the selected next hop; (7) forward Label Mapping to next hop.
The L2 PW Address ER-Hop TLV (Type 0x0805) is 18 bytes in length. It contains U/F bits, a 14-bit Type field, a Length field (=18), an L bit indicating loose (set) or strict (cleared) hop, Reserved bits, a PreLen field (prefix length 1–96), and AII Type 2 fields (AII Type, Length, Global ID, Prefix, AC ID) as defined in RFC 5003.