rfc-8400

Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection

H. Chen, A. Liu, T. Saad, F. Xu, L. Huang
date2018-06 streamIETF areartg wgteas statusPROPOSED STANDARD pages21 canonicalhttps://www.rfc-editor.org/rfc/rfc8400 doi10.17487/RFC8400 errataview
This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the egress node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP).

Extracted elements (25)

design-rationale §6.1

Egress local protection (PLR is the direct upstream node of the egress) provides faster failure detection than ingress-based protection because the PLR is closer to the failed egress node, allowing it to detect and react to egress failure more quickly and reliably than a multi-hop BFD session from the ingress.

routing, mpls

design-rationale §5.3

The backup egress node uses the backup LSP label as a context label and the service label as a UA label (per RFC 5331) to maintain per-primary-egress forwarding tables, enabling the backup to deliver traffic to the same destinations as the failed primary without requiring changes at the ingress.

routing, mpls

design-rationale §5.4

When a backup egress node is not explicitly configured, the primary and backup egress nodes SHOULD share the same local address (acting as a 'virtual node'), with the cost to that address on the backup being much higher than on the primary, enabling transparent failover without changes to the ingress VRF routing.

routing, mpls

interoperability-note §5.4.2

For facility protection, multiple primary P2P LSPs going through the same PLR to the same primary egress node MAY share a single backup LSP from the PLR to the designated backup egress node, reducing resource consumption.

routing, mpls

interoperability-note §5.1

The decision to instantiate a backup egress node for protecting the primary egress node can be initiated by either the ingress node or the primary egress node, but not both simultaneously; mutual exclusivity is enforced by requiring configuration on one side only.

routing, mpls

normative-requirement §5.2 MUST

A backup egress node MUST be configured on the primary egress node of the LSP to protect it if and only if the backup egress node is not configured on the ingress node; if so, the primary egress node MUST send its upstream node a Resv message with an SERO for protecting the primary egress node.

routing, mpls

normative-requirement §5.4.4 MUST

During local repair, the PLR MUST let the upstream part of the primary LSP stay alive after the primary egress node fails by sending Resv messages upstream; when a bypass LSP protects the primary egress node, the PLR MUST NOT send any Path message for the primary LSP through the bypass LSP to the backup egress node.

routing, mpls

normative-requirement §5.4.2 MUST

For facility protection, the PLR records that the backup LSP is used to protect the primary LSP and MUST include an SERO object in the Path message for the primary LSP; the object MUST contain the backup LSP ID.

routing, mpls

normative-requirement §5.4.3 MUST

For S2L sub-LSP protection, the PLR MUST determine to protect a primary egress node via S2L sub-LSP protection when it receives a Path message with the 'S2L sub-LSP backup desired' flag set, and MUST set up the backup S2L sub-LSP to the backup egress node.

routing, mpls

normative-requirement §5.4 MUST

If a transit node receives the Path message with SEROs and is not a branch node (upstream of any primary egress), it MUST forward the SEROs unchanged.

routing, mpls

normative-requirement §5.1 MUST

If one-to-one backup or facility backup is desired to protect a primary egress node, the ingress node MUST include a FAST_REROUTE object and set the corresponding flag ('one-to-one backup desired' or 'facility backup desired').

routing, mpls

normative-requirement §5.1 MUST

The ingress node MUST send a Path message for the LSP with the required objects and SEROs for protecting egress nodes; for each primary egress node to be protected, the ingress node MUST add an SERO object into the Path message.

routing, mpls

normative-requirement §5.4 MUST

The PLR MUST extract the backup egress node from the respective SERO object in either a Path or Resv message; if no matching SERO is found, the PLR tries to find the backup egress node by matching the destination IP address of the LSP.

routing, mpls

normative-requirement §5.4 MUST

The PLR MUST provide one-to-one backup protection if the 'one-to-one backup desired' flag is set; otherwise, it MUST provide facility backup protection if the 'facility backup desired' flag is set.

routing, mpls

normative-requirement §5.4 MUST

The PLR MUST set the protection flags in the RRO subobject for the primary egress node in the Resv message according to the status of the primary egress node and the backup LSP protecting it.

routing, mpls

normative-requirement §5.1 MUST

To protect a primary egress node of an LSP, the ingress node MUST set the 'label recording desired' flag and the 'node protection desired' flag in the SESSION_ATTRIBUTE object.

routing, mpls

protocol-element §4.1

The Egress Protection subobject is a PROTECTION object with a new C-Type (3), embedded as the second subobject in an SERO. It contains E-Flags indicating 'egress local protection' (bit 31) and 'S2L sub-LSP backup desired' (bit 30), plus optional primary egress and P2P LSP ID subobjects.

routing, mpls

protocol-element §4.1

The SERO used for egress protection contains exactly three subobjects: (1) the branch node address, (2) an Egress Protection subobject (PROTECTION C-Type 3), and (3) the backup egress node address.

routing, mpls

registry §8

IANA assigned C-Type 3 ('Egress Protection') under the PROTECTION object class (Class Number 37) in the 'Class Names, Class Numbers, and Class Types' registry under RSVP Parameters.

registry, routing, mpls

registry §8

IANA created a new registry for subobject types under PROTECTION object Class Number 37, C-Type 3 (Egress Protection), with initial values: 0=Reserved, 1=IPv4_PRIMARY_EGRESS, 2=IPv6_PRIMARY_EGRESS, 3=IPv4_P2P_LSP_ID, 4=IPv6_P2P_LSP_ID, 5-127=Unassigned, 128-255=Reserved. Future assignments via IETF Review.

registry, routing, mpls

security-consideration §7

Protecting a primary egress node requires out-of-band communication between the primary and backup egress nodes to convey service labels (as UA labels) and related forwarding information. It is important to verify that identifiers used to identify primary and backup egress nodes in the LSP match those used in the out-of-band protocol (such as BGP).

security, routing, mpls

state-machine §5.4.3

For S2L sub-LSP protection, the PLR creates a forwarding entry with an 'inactive' state after receiving the backup LSP Resv message. On detecting primary egress node failure, the PLR transitions the forwarding entry to 'active', causing traffic to be forwarded through the backup LSP.

routing, mpls

wire-format §4.1

The Egress Protection subobject (PROTECTION C-Type 3) is a 32-bit header (L, Type, Length, Reserved, C-Type fields) followed by a 32-bit word with Reserved bits and 2-bit E-Flags, followed by optional subobjects.

routing, mpls

wire-format §4.1.2

The IPv4 P2P LSP ID subobject (Type=3) contains a 4-byte P2P LSP Tunnel Egress IPv4 Address, a 16-bit Reserved field (MUST be zero), a 16-bit Tunnel ID, and a 4-byte Extended Tunnel ID. The IPv6 variant (Type=4) uses 16-byte addresses for both the egress address and Extended Tunnel ID.

routing, mpls

wire-format §4.1.1

The IPv4 Primary Egress subobject (Type=1) body contains a 4-byte IPv4 address of the primary egress node. The IPv6 variant (Type=2) contains a 16-byte IPv6 address.

routing, mpls