GMPLS RSVP-TE Extensions for Lock Instruct and Loopback
Extracted elements (23)
Rather than defining a new RSVP-TE object, this document reuses the existing Administratively down (A) bit in the ADMIN_STATUS Object for Lock Instruct, providing a unified GMPLS control-plane approach for LI and LB across TDM, WDM, and packet-switching technologies without adding new signaling overhead.
The loopback mechanism uses RFC7570 ERO Hop Attributes subobjects to address loopback requests to a specific intermediate node, enabling on-demand OAM targeting without requiring new RSVP-TE object types. This complements RFC7487's proactive OAM configuration.
For networks supporting MPLS-TP, the GMPLS RSVP-TE LI and LB mechanisms defined in this document are complementary to RFC6435 (MPLS-TP Lock Instruct and Loopback Functions), which provides OAM-layer mechanisms for the same functions.
If a label subobject (RFC3473) immediately precedes the ERO Hop Attributes subobject, the loopback SHOULD be enabled for the direction indicated by the U bit of the label subobject.
If a node successfully enters loopback mode, it MUST set the Loopback Attribute Flag in any RRO Hop Attributes subobject it adds per RFC7570, and the A bit MUST be kept set. If loopback cannot be enabled, the node MUST send a PathErr with Error Code 'OAM Problem' and Error Value 'Loopback Failure'.
If the egress node locks the LSP successfully, it MUST send a Resv message with the A bit in the ADMIN_STATUS Object set. Otherwise, it MUST send a PathErr with Error Code 'OAM Problem' and Error Value 'Lock Failure', and subsequent Resv messages MUST have the A bit cleared.
On receipt of a loopback Path message, the target node MUST check that the A bit is set (LSP in lock mode); if not, the loopback request MUST be ignored. The node MUST also verify the desired loopback entity is identified by the ERO subobject preceding the ERO Hop Attributes subobject.
The ERO subobject type preceding the ERO Hop Attributes subobject MUST be less than 32 (to identify a specific loopback entity). For type 1 (IPv4 prefix) the prefix length MUST be 32, and for type 2 (IPv6 prefix) it MUST be 128. If the loopback entity is not explicitly identified, the request MUST be ignored and a 'Bad EXPLICIT_ROUTE object' error SHOULD be generated.
The ingress node MUST ensure that the LSP is in lock mode (A bit set) before requesting that a particular node enter loopback mode. Loopback can only be applied to a locked LSP.
The ingress node MUST NOT request to exit lock mode while the LSP is still in loopback mode. The egress node MUST ignore such a request when the LSP is still in loopback mode.
When an ingress node intends to put an LSP into lock mode, it MUST send a Path message with the Administratively down (A) bit set and the Reflect (R) bit in the ADMIN_STATUS Object set.
When an LSP is put in lock mode, subsequent Path and Resv messages MUST keep the A bit in the ADMIN_STATUS Object set. When taken out of lock mode, subsequent messages MUST keep the A bit cleared.
When requesting loopback, the ingress MUST send a Path message with the Loopback Attribute Flag set, and MUST ensure the loopback entity is explicitly identified by the immediately preceding subobject of the ERO Hop Attributes subobject (per RFC7570). The A bit MUST remain set.
When the ingress intends to exit loopback mode, it MUST send a Path message with the Loopback Attribute Flag cleared. The A bit MUST remain set. If the node exits loopback successfully it MUST clear the Loopback flag in the RRO Hop Attributes subobject; on failure it MUST send PathErr with Error Value 'Exit Loopback Failure'.
When the ingress node intends to take the LSP out of lock mode, it MUST send a Path message with the A bit in the ADMIN_STATUS Object cleared. On successful unlock the egress MUST send Resv with A bit cleared; otherwise MUST send PathErr with Error Value 'Unlock Failure' and subsequent Resv MUST keep A bit set.
Reporting loopback status via the RRO may reveal details about network nodes that the operator wishes to keep confidential. The privacy considerations in paragraph 3 of Section 5 of RFC7570 apply to this document.
A new Loopback flag is defined as bit number 13 in the Attribute Flags TLV (RFC5420). It is carried in Path messages and RRO Attributes subobjects, but not in Resv messages. It indicates that a particular node on the LSP is required to enter loopback mode.
Lock Instruct (LI) uses the Administratively down (A) bit in the ADMIN_STATUS Object (RFC3471, RFC3473) to indicate the lock/unlock status of an LSP. An LSP in lock mode is prevented from carrying user data traffic.
IANA assigned four new Error Value sub-codes under the 'OAM Problem' Error Code in the RSVP 'Error Codes and Globally-Defined Error Value Sub-Codes' registry: 26 (Lock Failure), 27 (Unlock Failure), 28 (Loopback Failure), 29 (Exit Loopback Failure).
IANA assigned Loopback as bit number 13 in the 'Attribute Flags' sub-registry of 'RSVP-TE Parameters'. The flag is carried in Path messages and RRO (Yes), but not in Resv messages (No); it is valid in ERO (Yes).
IANA updated the allocation rule for ERO subobject types in the range 5-31 (0x05-0x1F) in the RSVP 'Class Names, Class Numbers, and Class Types' registry to label them 'Unassigned (For explicit resource identification)', reserving this range for identifying specific entities where loopback can occur.
This document does not introduce new security issues beyond those in RFC3209, RFC3473, and RFC7570. For comprehensive GMPLS security and attack mitigation, RFC5920 ('Security Framework for MPLS and GMPLS Networks') applies.
An LSP progresses through: normal service → locked (triggered by ingress Path with A bit set and R bit set, confirmed by egress Resv with A bit set) → loopback (triggered by ingress Path with Loopback flag set while locked, confirmed by RRO with Loopback flag set) → locked (Loopback flag cleared) → normal service (A bit cleared). Transitions from loopback directly to unlocked are prohibited.