RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)
updated by
- rfc-8537 — Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs)
Extracted elements (27)
An associated bidirectional LSP consists of two reverse unidirectional LSPs set up in opposite directions between a pair of nodes. This design satisfies MPLS-TP requirements (RFC 5654) that the endpoints be aware of the pairing relationship and that independent provisioning and protection of each direction be supported.
Two provisioning models are defined: single-sided (TE tunnel configured on one endpoint only, which triggers reverse LSP creation at the far end via REVERSE_LSP Object) and double-sided (two tunnels configured independently at each endpoint using matching ASSOCIATION Objects). The split exists to support both management-plane-driven and operator-symmetric deployment scenarios.
When no REVERSE_LSP subobject overrides the SESSION/SENDER_TEMPLATE, the egress node SHOULD swap the IP addresses: the reverse LSP's SESSION Object gets the forward LSP's SENDER_TEMPLATE address, and vice versa. This reflects the natural reversal of source and destination for a bidirectional pair.
An egress node that does not support the new Association Types will return a PathErr with Error Code 'Admission Control Failure' (1) and Sub-code 'Bad Association Type' (5) per RFC 4872. The REVERSE_LSP Object likewise uses the 11bbbbbb class number range, so non-supporting transit nodes will ignore and forward it without modification.
LSP recovery as defined in RFC 4872 and RFC 4873 is not impacted by this document because recovery uses different Association Type values. Multiple ASSOCIATION Objects can coexist in the same Path message, allowing recovery and bidirectional-association signaling simultaneously.
The ASSOCIATION and Extended ASSOCIATION Objects use class numbers in the 11bbbbbb form, ensuring that non-supporting nodes ignore the objects but forward them unchanged per RFC 2205. Operators wishing to act on an Association Type SHOULD ensure all nodes expected to act on the association support that type.
A transit node receiving a valid Path message containing a REVERSE_LSP Object MUST forward the REVERSE_LSP Object unchanged in the outgoing Path message.
An egress node receiving a Path message with a REVERSE_LSP Object MUST verify that the message also contains an ASSOCIATION or Extended ASSOCIATION Object with Association Type 'Single-Sided Associated Bidirectional LSP'. If not, the Path message MUST NOT trigger a reverse LSP; the failure SHOULD be logged locally but SHOULD NOT trigger any RSVP message.
An ingress node MUST insert an (Extended) ASSOCIATION Object into the Path message of each unidirectional LSP that forms part of an associated bidirectional LSP. If Global Association Source or Extended Association Address is required, an Extended ASSOCIATION Object MUST be used; otherwise an ASSOCIATION Object MAY be used.
Association ID MUST be set to a value assigned by the node that originates the association. Association Source MUST be set to an address selected by that same originating node.
Changes in the forward LSP's Path message, including its REVERSE_LSP Object, MUST result in corresponding changes in the reverse LSP. Objects copied during initial reverse LSP creation MUST be updated when modified in the forward LSP, and the resulting trigger Path message MUST be processed.
(Extended) ASSOCIATION Objects carrying both single-sided and double-sided Association Types MUST NOT be added or sent in the same Path message.
In the Extended ASSOCIATION Object, Global Association Source MUST be set to the Global_ID (RFC 6370) of the originating node when used, and Extended Association ID MUST be set to a value selected by the originating node when used.
Once validated, the egress node MUST create an LSP in the reverse direction or reject the Path message. If creation fails, the egress node MUST return a PathErr with Error Code 'Admission Control Failure' (1) and Sub-code 'Reverse LSP Failure' (6).
The Association Types defined in this document are only to be interpreted in Path messages. These types SHOULD NOT be used in ASSOCIATION Objects carried in Resv messages and SHOULD be ignored if present, because bidirectional LSP association is always upstream-initiated.
The egress node MUST use the subobjects in the REVERSE_LSP Object when initiating the reverse LSP. When a subobject is absent, the egress node SHOULD copy SESSION_ATTRIBUTE, CLASS_TYPE, LABEL_REQUEST, ASSOCIATION, ADMIN_STATUS, and PROTECTION from the forward LSP's Path message.
To bind two reverse unidirectional LSPs into an associated bidirectional LSP, the Association Type in the (Extended) ASSOCIATION Object MUST be set to indicate either single-sided (value 4) or double-sided (value 3).
When a node initiates setup using a Path message with Association Type set to 'Single-Sided Associated Bidirectional LSP', the Path message MUST carry the REVERSE_LSP Object to trigger creation of a reverse LSP on the egress node.
When an LSP carrying an (Extended) ASSOCIATION Object with an Association Type defined in this document is torn down, the processing node SHALL remove the binding of that LSP to any previously identified associated bidirectional LSP.
When the egress node receives a PathTear for the forward LSP or the forward LSP is torn down for any reason, the node MUST remove the associated reverse LSP using standard PathTear processing. Independent teardown of the reverse LSP SHOULD NOT trigger removal of the initiating LSP, but SHOULD cause the egress node to send a PathErr with Sub-code 'Reverse LSP Failure' (6).
REVERSE_LSP subobjects can include SENDER_TSPEC, ERO, SESSION_ATTRIBUTE, ADMIN_STATUS, LSP_REQUIRED_ATTRIBUTES, and PROTECTION Objects. These override default values that the egress node would otherwise copy from the forward LSP's Path message when creating the reverse LSP.
Two new Association Types are defined for use in ASSOCIATION and Extended ASSOCIATION Objects: value 3 'Double-Sided Associated Bidirectional LSP (D)' and value 4 'Single-Sided Associated Bidirectional LSP (A)'. These distinguish the provisioning model and are placed in Path messages only.
IANA assigned Class Number 203 with name REVERSE_LSP (C-type=1) in the 'Class Names, Class Numbers, and Class Types' subregistry of the RSVP Parameters registry, in the 11bbbbbb range.
IANA extended the 'Error Codes and Globally-Defined Error Value Sub-Codes' subregistry under Error Code 1 ('Admission Control Failure') with Sub-code 6 = 'Reverse LSP Failure', used when egress-initiated reverse LSP creation fails.
IANA updated the 'Association Type' subregistry in the GMPLS Signaling Parameters registry with two new values: 3 = 'Double-Sided Associated Bidirectional LSP (D)' and 4 = 'Single-Sided Associated Bidirectional LSP (A)', both referencing Section 4.2 of this document.
The two new Association Types for the (Extended) ASSOCIATION Object introduce no additional information to signaling beyond what RFC 6780 already covers; the related security considerations from RFC 6780 apply. The REVERSE_LSP Object can convey additional reverse-LSP parameters, but this information is not fundamentally different from what is already carried in bidirectional LSP messages, and its processing is subject to existing local policy and MPLS/GMPLS security framework (RFC 5920).
The REVERSE_LSP Object uses Class_Num=203, C_Type=1. Its payload is zero or more variable-length subobjects in the same format as RSVP Objects (RFC 2205 Section 3.1.2). Any object that may appear in a Path message MAY be carried as a subobject, and subobject ordering MUST follow Path message object ordering requirements.