rfc-7965

LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels

M. Chen, W. Cao, A. Takacs, P. Pan
date2016-08 streamIETF areartg wgpals statusPROPOSED STANDARD pages16 canonicalhttps://www.rfc-editor.org/rfc/rfc7965 doi10.17487/RFC7965
Many transport services require that user traffic, in the form of Pseudowires (PWs), be delivered via either a single co-routed bidirectional tunnel or two unidirectional tunnels that share the same routes. This document defines an optional extension to the Label Distribution Protocol (LDP) that enables the binding between PWs and the underlying Traffic Engineering (TE) tunnels. The extension applies to both single-segment and multi-segment PWs.

Extracted elements (25)

design-rationale §7 RECOMMENDED

Co-routed bidirectional LSPs are RECOMMENDED over two unidirectional LSPs with the same route because the latter cannot guarantee route consistency over time, particularly when Fast ReRoute (FRR) is deployed and link/node failure may cause the two LSPs to diverge.

mpls, routing

design-rationale §4

The extension uses active/passive PE roles (from RFC 6073) to resolve collisions when both PEs simultaneously initiate PSN Binding to the same PW over different tunnels. Node ID comparison (unsigned integer) deterministically selects which PE's binding request wins.

mpls, routing

design-rationale §3.1

The T-bit is introduced to support MPLS protection operations where the LSP Number fields may be ignored; when set, only tunnel-level identification is used rather than specific LSP identification, accommodating protection switchover scenarios.

mpls, routing

interoperability-note §5

For unidirectional LSPs in co-routed binding, the PSN Tunnel Binding TLV may contain only Source IDs/Numbers with Destination IDs/Numbers set to zero, leaving the remote PE (PE2) to complete the Destination fields in its response.

mpls, routing

interoperability-note §3

The PSN Tunnel Binding TLV extension applies to both FEC 128 and FEC 129 based PWs (single-segment and multi-segment), but MS-PW uses FEC 129 exclusively. The extension is backward compatible: unknown receivers silently ignore the optional TLV due to the U-bit being set to 1.

mpls, routing

normative-requirement §5 MUST

After a PW is established, if the underlying PSN tunnel breaks or operators move PWs to other tunnels, a new Label Mapping message MUST be sent to notify the remote PE. If the new message contains no PSN Tunnel Binding TLV, it declares removal of co-routed/strict constraints.

mpls, routing

normative-requirement §3.1.1 MUST

Each PSN Tunnel Binding TLV MUST contain only one PSN Tunnel Sub-TLV. When sending, only one sub-TLV MUST be carried. When received, if more than one sub-TLV is present, only the first MUST be used and the rest MUST be ignored.

mpls, routing

normative-requirement §3.1 MUST

Either the C-bit or the S-bit MUST be set in the PSN Tunnel Binding TLV; they are mutually exclusive and cannot both be set or both be cleared. If a message with both set or both cleared is received, a Label Release with status code 0x0000003C MUST be sent and the PW will not be established.

mpls, routing

normative-requirement §6 MUST

For MS-PW co-routed binding, the initiating T-PE MUST set the C-bit and reset the S-bit. Each S-PE may select an alternative tunnel/LSP for the reverse direction only if it is co-routed with the forward tunnel/LSP.

mpls, routing

normative-requirement §6 MUST

For MS-PW, when an active T-PE starts signaling, a PSN Tunnel Binding TLV MUST be carried in the Label Mapping message to the adjacent S-PE. If an S-PE cannot accept the binding request, it MUST reply with a Label Release with status code 0x0000003B to the upstream PE.

mpls, routing

normative-requirement §5 MUST

For SS-PW strict binding, when two PEs both initiate PSN Binding, the receiving PE MUST compare its own Node ID against the received Source Node ID as unsigned integers. If the received Source Node ID is larger, the PE confirms the binding; otherwise, it MUST reply with a Label Release with status code 0x0000003B.

mpls, routing

normative-requirement §5 MUST

If the received PSN tunnel/LSP endpoints do not match the PW endpoints, the receiving PE MUST reply with a Label Release message with status code 0x0000003B ('Reject - unable to use the suggested tunnel/LSPs'), and the received PSN Tunnel Binding TLV MUST also be carried.

mpls, routing

normative-requirement §3.1 MUST

The PSN Tunnel Binding TLV MUST be carried in the LDP Label Mapping message if PW-to-LSP binding is required. The U-bit MUST be set to 1 so that unknown receivers silently ignore it; the F-bit MUST be set to 0 to prevent forwarding when unknown.

mpls, routing

normative-requirement §6 SHOULD

When a tunnel/LSP changes in an established MS-PW, the PE that detects the change SHOULD select an alternative tunnel/LSP for temporary use while renegotiating with other PEs.

mpls, routing

protocol-element §4

PEs are categorized as active (initiates tunnel/LSP selection and informs remote PE) or passive (obeys the active PE's suggestion). For SS-PW both PEs may assume active roles; for MS-PW one PE is active and the other passive.

mpls, routing

protocol-element §3.1

The PSN Tunnel Binding TLV (type 0x0973) is a new optional TLV carried in LDP Label Mapping messages to communicate tunnel/LSP selection and binding requests between PEs. It contains a Flags field (C, S, T bits) and a PSN Tunnel Sub-TLV specifying the tunnel/LSP to bind.

mpls, routing

protocol-element §3.1

The T (Tunnel Representation) bit in the PSN Tunnel Binding TLV indicates whether the tunnel is identified by tunnel information only (T=1, LSP Number fields MUST be zero) or by both tunnel and LSP information (T=0, LSP Number fields carry actual LSP IDs).

mpls, routing

protocol-element §3

Two binding modes are defined: strict binding (S-bit set), where the receiving PE MUST use the specified tunnel/LSP or the PW fails to establish; and co-routed binding (C-bit set), where the receiving PE SHOULD select a co-routed LSP but may choose an alternative.

mpls, routing

registry §9.1

IANA assigned TLV type value 0x0973 from the 'LDP TLV Type Name Space' registry for the new PSN Tunnel Binding TLV defined in this document.

registry, mpls

registry §9.2

IANA assigned two new LDP status codes from the 'LDP Status Code Name Space' registry: 'Reject - unable to use the suggested tunnel/LSPs' (0x0000003B) and 'The C-bit or S-bit unknown' (0x0000003C), both with E-bit set to 1.

registry, mpls

registry §9.1.1

IANA created a new PWE3 subregistry 'PSN Tunnel Sub-TLV Name Space' with IPv4 PSN Tunnel sub-TLV assigned type 1 and IPv6 PSN Tunnel sub-TLV assigned type 2. Values 0 and 255 are reserved; values 1-254 are allocated by IETF Review.

registry, mpls

security-consideration §8 RECOMMENDED

The ability to control which LSP carries PW traffic is a potential security risk for denial of service and traffic interception. It is RECOMMENDED that PEs not accept LSPs identified in the PSN Tunnel Binding TLV unless the LSP endpoints match the PW or PW segment endpoints, and that PEs implement LDP security mechanisms from RFC 5036 and RFC 5920.

security, mpls, routing

wire-format §3.1.1

The IPv4 PSN Tunnel Sub-TLV (Type 1) carries: 1-byte Type, 1-byte Length, 2-byte Reserved, 4-byte Source Global ID, 4-byte Source Node ID, 2-byte Source Tunnel Number, 2-byte Source LSP Number, 4-byte Destination Global ID, 4-byte Destination Node ID, 2-byte Destination Tunnel Number, 2-byte Destination LSP Number.

mpls, routing, ip

wire-format §3.1.1

The IPv6 PSN Tunnel Sub-TLV (Type 2) has the same structure as the IPv4 variant but uses 16-byte IPv6 addresses for the Source Node ID and Destination Node ID fields instead of 4-byte IPv4 addresses.

mpls, routing, ip

wire-format §3.1

The PSN Tunnel Binding TLV has a 2-octet U/F/type field (0x0973), a 2-octet Length field, a 2-octet Flags field (C, S, T bits plus unallocated flags), a 2-octet Reserved field, and a variable-length PSN Tunnel Sub-TLV.

mpls, routing