Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths
Extracted elements (19)
Non-PHP behavior is required for OOB mapping because an egress LSR cannot make correct forwarding decisions until OOB mapping information (e.g., via BGP) is received. To identify the incoming LSP on which traffic arrives, the egress LSR must receive a non-NULL label rather than having it popped by the penultimate hop.
MPLS OAM mechanisms such as LSP ping and traceroute (RFC 4379, RFC 6425) are expected to work independently of the OOB mapping learning process, even though the egress LSR has not yet installed forwarding state for the LSP.
The Non-PHP behavior flag and OOB mapping flag can appear and be processed independently of each other. However, in the application context of this document, OOB mapping requires non-PHP behavior; an ingress LSR requesting OOB mapping MAY also set the Non-PHP behavior flag.
An egress LSR MAY implement a cleanup timer for triggering the Path Error when OOB mapping is not received; the timeout is a local decision with a RECOMMENDED default value of 60 seconds.
An ingress LSR requesting non-PHP behavior SHOULD examine the Non-PHP behavior flag in the RRO Attributes subobject and MAY send a Path Tear to an egress that has not set the flag or that assigns a NULL label value.
An ingress LSR sets the Non-PHP behavior flag to signal that egress LSRs SHOULD assign a non-NULL label for the LSP being signaled. This flag MUST NOT be modified by any other LSRs in the network.
If an egress LSR receiving the Path message supports the LSP Attributes object, the Attributes Flags TLV, and recognizes the Non-PHP behavior flag, it MUST allocate a non-NULL local label and MUST set the Non-PHP behavior flag in the RRO Attributes subobject.
If the egress LSR receives payload information from OOB mapping, it MUST ignore the L3PID (Layer 3 Protocol ID) in the Label Request Object (RFC 3209), as the OOB mapping supersedes the in-band payload information.
The OOB mapping flag MUST NOT be modified by any LSRs other than the egress; LSRs other than egress LSRs SHOULD ignore this flag.
To avoid unnecessary resource use and possible black-holing of traffic, an egress LSR MAY send a Path Error message with error code/sub-code 'Notify Error / no OOB mapping received' if OOB mapping information is not received within a reasonable time.
When an egress LSR that supports the OOB mapping flag receives a Path message with that flag set, it MUST set the OOB mapping flag in the RRO Attributes subobject and MUST NOT set up forwarding state for the LSP before receiving the OOB mapping.
When signaling a P2MP LSP where individual per-leaf responses to the Non-PHP behavior flag are needed, the source node MUST use a separate Path message for each leaf in networks where RFC 6510 is not supported.
When signaling a P2MP LSP where per-leaf responses to the OOB mapping flag are needed, the source node MUST use a separate Path message for each leaf in networks where RFC 6510 is not supported; with RFC 6510 deployed, single or multiple leaves per Path message MAY be used.
A new flag 'Non-PHP behavior flag' is defined as Bit Number 7 in the Attributes Flags TLV of the LSP Attributes object (RFC 5420). It is carried in Path messages and in the RRO Attributes subobject, but not in Resv messages.
A new flag 'OOB mapping flag' is defined as Bit Number 8 in the Attributes Flags TLV of the LSP Attributes object. It is carried in Path messages and in the RRO Attributes subobject, but not in Resv messages.
A new RSVP error sub-code 'No OOB mapping received' with value 12 is defined under Error Code 25 'Notify Error' (RFC 3209), to be sent by an egress LSR that has not received the required OOB mapping within a reasonable time.
A new RSVP error sub-code value 12 ('No OOB mapping received') is registered under Error Code 25 'Notify Error' in the RSVP-TE Parameters registry.
Two new flags are registered in the 'Attribute Flags for LSP Attributes Object' registry: Bit Number 7 (Non-PHP behavior flag) and Bit Number 8 (OOB mapping flag). Both are carried in Path and RRO messages but not in Resv messages.
The addition of non-PHP behavior introduces attacks on the label assigned by the egress node, since a change in the egress label value reported in the RRO can cause the LSP to be torn down. Additional security measures for protecting egress-assigned labels are required, referencing RFC 5920, RFC 2205, RFC 3209, RFC 3473, RFC 5420, and RFC 4875.