Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)
Extracted elements (25)
There is no forwarding adjacency between end points of an S-LSP TE link, unlike H-LSP TE links. Consequently, any label exchanged between S-LSP end points for the e2e LSP has no significance in the data plane and must not be processed by the recipients.
Unlike LSP hierarchy where multiple LSPs can be nested into a single H-LSP using distinct labels, LSP stitching dedicates one S-LSP to exactly one e2e LSP. This is because an S-LSP provides a data link to other LSPs in the same layer (not a higher layer), so no label separation between nested LSPs is possible.
An e2e LSP traversing an S-LSP SHOULD record in the RRO an identifier corresponding to the S-LSP TE link; intermediate links or nodes traversed by the S-LSP itself SHOULD NOT be recorded in the RRO for the e2e LSP over the S-LSP hop.
S-LSP teardown follows standard procedures defined in RFC 3209 and RFC 3473. Teardown of the S-LSP SHOULD be treated as a failure event for the associated e2e LSP, and corresponding teardown or recovery procedures SHOULD be triggered for the e2e LSP.
An ingress node requesting LSP stitching MUST examine the RRO Attributes subobject Flags for the egress node and MUST NOT use the S-LSP for stitching if the 'LSP segment stitching ready' bit is cleared.
An S-LSP MUST NOT admit more than one e2e LSP into it. If an S-LSP is allocated to an e2e LSP, the unreserved bandwidth SHOULD be set to zero to prevent further e2e LSPs from being admitted.
For bidirectional e2e TE LSPs, an Upstream Label MUST be signaled in the Path message over the S-LSP hop; however, since there is no forwarding adjacency, the label value is meaningless and the egress node MUST ignore the Upstream Label in the Path message over the S-LSP hop.
If an egress node of the S-LSP recognizes the 'LSP stitching desired' bit but cannot support the requested stitching behavior, it MUST send back a PathErr message with error code 'Routing Problem' (24) and error value 'Stitching unsupported' (30).
If the egress node of an S-LSP recognizes the 'LSP stitching desired' bit and supports stitching, it MUST allocate a non-NULL label for that S-LSP in the corresponding Resv message and MUST set the 'LSP segment stitching ready' bit in the RRO Attributes subobject.
In order to signal an e2e LSP over an LSP segment, signaling procedures described in Section 8.1.1 of RFC 4206 MUST be used. The RSVP-TE signaling extensions described in Section 5.1 MUST be used for stitching an e2e packet or non-packet GMPLS LSP to an S-LSP.
It is RECOMMENDED that a delay of 30 seconds be introduced before tearing down a dynamically created S-LSP after e2e LSP teardown is complete, to reduce simultaneous generation of RSVP errors and teardown messages due to multiple events.
The ingress node stitching an e2e TE LSP to an S-LSP MUST ignore the Label object received in the Resv for the e2e TE LSP over the S-LSP hop. Recipients of Label/Upstream Label in the stitching case MUST NOT process these labels.
The region-boundary crossing trigger defined in RFC 4206 for dynamic FA-LSP creation MUST NOT be used for creation of an S-LSP for LSP stitching. For stitching, switching capabilities of the previous hop and next hop TE links MUST be the same, and local policies SHOULD be used for dynamic S-LSP creation.
The switching capability of an S-LSP TE link MUST be equal to the switching type of the underlying S-LSP, since an S-LSP TE link provides a data link to other LSPs in the same layer and no hierarchy is possible.
When a PathTear arrives at the GMPLS stitching node for e2e LSP teardown, the PathTear MUST be IP routed to the LSP segment egress node with the destination IP address set to the address of the S-LSP end node. Router Alert MUST be off and RSVP TTL check MUST be disabled on the receiving node.
When stitching an e2e LSP to an S-LSP, the switching type in the Generalized Label Request of the e2e LSP MUST be equal to the switching type of the S-LSP. The GMPLS node MUST use RFC 4206 signaling procedures to send the Path message to the S-LSP end point, identifying the S-LSP in the RSVP_HOP.
When tearing down an e2e LSP from the tail end, the egress of the S-LSP MUST propagate the ResvTear/PathErr upstream and MUST use IP addressing to target the ingress of the LSP segment.
When the egress node of a packet S-LSP is also the egress of the e2e LSP and PHP is required, the node MUST send back a Resv trigger message for the S-LSP with the Implicit or Explicit NULL Label. These steps MUST NOT be used for non-packet LSPs or packet LSPs where PHP is not desired.
A new 'LSP segment stitching ready' bit (Bit Number 5) is defined in the Flags field of the RRO Attributes subobject. The egress node of an S-LSP MUST set this bit in the Resv to confirm it can support stitching, enabling the head end to know that correct stitching actions will be carried out.
A new 'LSP stitching desired' bit (Bit Number 5) is defined in the Attributes Flags TLV of the LSP_ATTRIBUTES object (RFC 4420). This bit SHOULD be set in the Path message for the S-LSP by its head end to signal the desire for stitching, and MUST NOT be modified by any other nodes.
LSP stitching combines several GMPLS LSP segments (S-LSPs) such that a single end-to-end LSP is realized in the data plane, with the key constraint that a constituent S-LSP not be allocated to more than one e2e LSP. The entire bandwidth of an S-LSP is dedicated to the single e2e LSP stitched to it.
IANA allocated Bit Number 5 ('LSP stitching desired') in the Attributes Flags sub-registry of the 'RSVP TE Parameters' registry, for use in the LSP_ATTRIBUTES object. This bit is used on Path messages and the corresponding RRO Attributes subobject.
IANA assigned error sub-code 30 ('Stitching unsupported') under RSVP error-code 'Routing Problem' (24) in the 'Error Codes and Globally-Defined Error Value Sub-Codes' sub-registry of 'Resource ReSerVation Protocol (RSVP) Parameters'. This error code is used only in a PathErr message.
Because RSVP messages for LSP stitching may be sent/received on control interfaces different from the data interfaces, security associations MUST be bound to communicating neighbors themselves (identified by IP address) rather than to interfaces. Per RFC 2747, 'sending interface' should be replaced with 'receiver's IP address' for security association selection.
LSP stitching allows the IP destination address of Path and PathTear messages to be the IP address of a next-hop node rather than the RSVP session destination address. This makes IPsec AH (previously ruled out in RFC 2747 for RSVP) now applicable, and standard IPsec procedures can be used to secure message exchanges.