rfc-8320

LDP Extensions to Support Maximally Redundant Trees

A. Atlas, K. Tiruveedhula, C. Bowers, J. Tantsura, IJ. Wijnands
date2018-02 streamIETF areartg wgmpls statusPROPOSED STANDARD pages21 canonicalhttps://www.rfc-editor.org/rfc/rfc8320 doi10.17487/RFC8320
This document specifies extensions to the Label Distribution Protocol (LDP) to support the creation of Label Switched Paths (LSPs) for Maximally Redundant Trees (MRTs). A prime use of MRTs is for unicast and multicast IP/LDP Fast Reroute, which we will refer to as "MRT-FRR". The sole protocol extension to LDP is simply the ability to advertise an MRT Capability. This document describes that extension and the associated behavior expected for Label Switching Routers (LSRs) and Label Edge Routers (LERs) advertising the MRT Capability. MRT-FRR uses LDP multi-topology extensions, so three multi-topology IDs have been allocated from the MPLS MT-ID space.

Extracted elements (25)

design-rationale §7

MPLS MT-ID values for MRT (3945-3947) were assigned within the range 1-4095 to align with PIM MT-ID values (RFC 6420 limits PIM MT-ID to 1-4095). This allows the same numerical value to be used for PIM MT-ID and MPLS MT-ID for the same MRT Profile, reducing management overhead and simplifying troubleshooting for multicast use cases.

mpls, routing, multicast

design-rationale §4.4

MRT-related LDP advertisements do not affect the MRT topology or MRT-Red/Blue next-hop computations; those rely solely on IGP advertisements. Missing LDP label exchanges on a link only produce missing MPLS forwarding entries, analogous to how normal LDP advertisement gaps do not alter IGP-computed shortest paths.

mpls, routing

design-rationale §5.2.1

The 'LDP Peer' concept from RFC 5036 is restricted in the MRT context to mean only LDP peers for which the LDP MRT Capability has been negotiated (called 'MRT LDP peers'). This scoping ensures that MRT FEC label distribution procedures only apply between MRT-capable nodes.

mpls, routing

design-rationale §4.1.2

The MRT Capability Advertisement does not distinguish between IPv4 and IPv6 address families; an LSR advertising MRT LDP Capability is expected to advertise MRT-related FEC-label bindings for the same address families as its shortest-path FEC-label bindings. Advertising MRT bindings for only one address family when both are supported is not supported.

mpls, routing

interoperability-note §5.2.2

In the MRT context, the 'next hop' concept from RFC 5036 is reinterpreted: for red(blue) FECs, the next hop is based on the MRT-Red(Blue) forwarding tree rather than the shortest-path forwarding tree. This affects ordered-control label distribution, label mapping propagation, and next-hop-change response procedures.

mpls, routing

interoperability-note §5.2.3

The egress LSR conditions from RFC 5036 Section 2.6.1.2 are modified for MRT FECs. An LSR may be egress for a red(blue) FEC if: (1) the prefix refers to the LSR itself, (2) the LSR is the red(blue) proxy-node attachment router, or (3) the LSR is an ABR and the MRT LDP peer requires non-best-area behavior. Notably, condition 3 scopes egress status to a particular peer.

mpls, routing

normative-requirement §5.2.4 SHOULD NOT

A label mapping for a Rainbow FEC satisfies the label mapping existence requirement for the corresponding red and blue FECs. The modified condition is: 'Has LSR previously received and retained a label mapping for the red(blue) FEC (or the corresponding Rainbow FEC) from the red(blue) next hop?'

mpls, routing

normative-requirement §5.2.7 MUST NOT

A neighbor of an ABR that receives a label mapping for the Rainbow FEC MUST NOT propagate a label mapping for that Rainbow FEC; Rainbow FEC label mappings should only be originated by an ABR.

mpls, routing

normative-requirement §5.1.2 MUST

A red proxy-node attachment router for a given prefix MUST originate a label mapping for the red FEC for that prefix; a blue proxy-node attachment router MUST originate a label mapping for the blue FEC. If the proxy-node attachment router is an IBR, it MUST forward packets with the red(blue) FEC label to the Island Neighbor and MUST swap the incoming label for the outgoing label corresponding to the shortest-path FEC; if the IN does not support LDP, the IBR MUST pop the incoming label.

mpls, routing

normative-requirement §5.1.1 MUST

An LSR advertising MRT Capability MUST recognize the Rainbow MRT MT-ID and associate the advertised label for a specific prefix with the MRT-Red and MRT-Blue MT-IDs associated with all MRT Profiles that advertise LDP as the forwarding mechanism.

mpls, routing

normative-requirement §4.1.1 MUST

An LSR advertising the LDP MRT Capability MUST also advertise the LDP Multi-Topology (MT) Capability. If MRT Capability is negotiated without MT Capability, the LSR MUST behave as if MRT Capability was not negotiated and respond with the 'MRT Capability negotiated without MT Capability' status code.

mpls, routing

normative-requirement §4.1 MUST NOT

If a router advertises the LDP MRT Capability to its peer but the peer has not advertised the MRT Capability, the router MUST NOT advertise MRT-related FEC-label bindings to that peer.

mpls, routing

normative-requirement §5.1.1 MUST

If an LSR receives a label mapping for a Rainbow FEC while retaining a label mapping for the corresponding red or blue FEC, it MUST continue to use the red or blue FEC mapping and MUST send a Label Release message for the Rainbow FEC. Conversely, if it receives a red or blue FEC mapping while retaining a Rainbow FEC mapping, it MUST continue to use the Rainbow FEC mapping and MUST send a Label Release for the red or blue FEC.

mpls, routing

normative-requirement §5.1.2 MUST

If the proxy-node attachment router is not an IBR, the packet MUST be removed from the MRT forwarding topology and sent along the interface(s) that caused the router to advertise the prefix.

mpls, routing

normative-requirement §5 MUST

The same Label Distribution Control Mode, Label Retention Mode, and Label Advertisement Mode MUST be used for both shortest-path FECs and MRT FECs.

mpls, routing

normative-requirement §5.1.1 MUST

When an ABR requires best-area behavior for a red(blue) FEC, it MUST withdraw any existing Rainbow FEC label mapping advertisements and advertise label mappings for the red(blue) FEC. When non-best-area behavior is required, it MUST withdraw existing red and blue FEC label mappings and advertise the corresponding Rainbow FEC label binding.

mpls, routing

normative-requirement §4.1.1 SHOULD NOT

When MRT Capability is negotiated without MT Capability, the LDP session SHOULD NOT be terminated; the notification E-bit should be set to 0 to indicate an Advisory Notification.

mpls, routing

protocol-element §4.3

MRT-Blue and MRT-Red FECs use the MT Prefix FEC element defined in RFC 7307, with MPLS MT-IDs 3947 (MRT-Blue) and 3946 (MRT-Red) allocated for the Default MRT Profile. These are used without alteration for advertising label mappings.

mpls, routing

protocol-element §4.1

The MRT Capability Parameter TLV (type 0x050E) is a new LDP Capability TLV with U-bit=1, F-bit=0, length=1, and a single S-bit field. It is advertised to signal support for MRT-Blue and MRT-Red LSP establishment procedures.

mpls, routing

protocol-element §4.2

The Rainbow MRT MT-ID (value 3945) refers to multiple MRT forwarding topologies and the default forwarding topology simultaneously. It allows an LSR to advertise a single label to all peers for the same (MT-ID, Prefix), reducing signaling overhead. IMPLICIT_NULL or EXPLICIT_NULL labeled with Rainbow MT-ID applies to all three FEC types (shortest path, red, and blue).

mpls, routing

registry §8

IANA allocated LDP Capability TLV type 0x050E ('MRT Capability TLV') from the 'Label Distribution Protocol (LDP) Parameters' registry under 'TLV Type Name Space'.

mpls, routing, registry

registry §8

IANA allocated LDP Status Code 0x00000034 ('MRT Capability negotiated without MT Capability', E-bit=0) from the 'Label Distribution Protocol (LDP) Parameters' registry under 'Status Code Name Space'.

mpls, routing, registry

registry §8

This document allocates three values in the 'MPLS Multi-Topology Identifiers' registry (RFC 7307): 3945 (Rainbow MRT MPLS MT-ID), 3946 (Default Profile MRT-Red MPLS MT-ID), and 3947 (Default Profile MRT-Blue MPLS MT-ID). It also redesignates the range 3948-3995 as 'Unassigned (for future MRT-related values)' with Standards Action registration procedure.

mpls, routing, registry

security-consideration §6

MRT extensions create additional forwarding paths that do not follow shortest-path routes. A malicious packet with an appropriate MRT label injected from a compromised location would be forwarded along a non-shortest path. Network security designs MUST NOT rely on assumptions that potentially malicious traffic only follows shortest paths when MRT is deployed.

mpls, routing, security

wire-format §4.1

The MRT Capability TLV is 5 octets total: a 2-octet type field (0x050E) with U-bit and F-bit, a 2-octet length field (value=1), and a 1-octet value field containing the S-bit (bit 0) and 7 reserved bits.

mpls, routing