RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)
Extracted elements (25)
Applying RFC 4736 P2P mechanisms directly to P2MP-TE LSP tree reoptimization leads to scaling issues: midpoint LSRs must accumulate path re-evaluation requests for all S2L sub-LSPs and use heuristic timers, while ingress nodes may prematurely reoptimize a subset rather than the full tree. This motivated a new tree-level re-evaluation flag and PathErr sub-code.
Semantic fragmentation of RSVP messages carrying large S2L sub-LSP descriptor lists results in out-of-order fragment arrival with no way for the receiver to determine beginning and end of the list. The fragment identifier (S2L_SUB_LSP_FRAG) was introduced specifically to allow unambiguous reassembly without requiring in-order delivery.
The LSP_ATTRIBUTES object and S2L_SUB_LSP_FRAG object are both defined with class numbers in the form 11bbbbbb, ensuring that nodes not supporting these extensions will ignore and forward them without modification, per RFC 2205.
A midpoint LSR MAY send an unsolicited PathErr with Notify error code and 'Preferable P2MP-TE Tree Exists' sub-code to the ingress node. The LSR SHOULD consider how frequently it sends such PathErrs, accounting for potential message loss and the possibility that the ingress may choose not to reoptimize.
A midpoint LSR SHOULD NOT propagate the 'P2MP-TE Tree Re-evaluation Request' flag in subsequent Path messages sent downstream after finding a preferable P2MP-TE LSP tree and sending the appropriate PathErr.
A midpoint LSR SHOULD wait to accumulate all S2L sub-LSPs before attempting to re-evaluate a preferable path when a Path message for 'Path Re-evaluation Request' is received with the S2L_SUB_LSP_FRAG object.
A midpoint LSR that expands loose next hop(s) and receives a Path message with the 'P2MP-TE Tree Re-evaluation Request' flag set MUST check for a preferable P2MP-TE LSP tree by re-evaluating all S2L sub-LSPs that are expanded paths of the loose next hops.
An ingress node MAY send a Path message with the 'P2MP-TE Tree Re-evaluation Request' flag set, selecting one S2L sub-LSP transiting a midpoint LSR to trigger the re-evaluation request. The ingress node MAY send a re-evaluation request to each border LSR on the path of the LSP tree.
An ingress node SHOULD wait to accumulate all S2L sub-LSPs before triggering reoptimization when a PathErr with Notify error code and 'Preferable Path Exists' sub-code is received with an S2L_SUB_LSP_FRAG object. If fragments are not all received within a configurable time interval, it SHOULD trigger reoptimization of all S2L sub-LSPs transiting the midpoint node that sent the PathErr. The ingress MUST receive at least one fragment to trigger this.
If a midpoint LSR does not receive all fragments within a configurable time interval, it SHOULD trigger re-evaluation of all S2L sub-LSPs of the P2MP-TE LSP transiting on the node, but MUST receive at least one fragment to trigger this behavior.
If a preferable P2MP-TE LSP tree is found, the midpoint LSR MUST send a PathErr with Notify error code 25 and sub-code 13 ('Preferable P2MP-TE Tree Exists') to the ingress node.
If no preferable tree can be found, the midpoint LSR that expands loose next hop(s) MUST propagate the 'P2MP-TE Tree Re-evaluation Request' flag downstream by setting it in the LSP_ATTRIBUTES object of the RSVP Path message.
The Fragments Total field value MUST be the same in all fragmented RSVP messages sharing a common Fragment ID.
Upon receiving a PathErr with Notify error code and 'Preferable P2MP-TE Tree Exists' sub-code, the ingress node SHOULD trigger reoptimization of the LSP using the Make-Before-Break (MBB) method with a different LSP-ID.
When a Path message is not large enough to fit all S2L sub-LSPs and semantic fragmentation is needed, an LSR MUST add the S2L_SUB_LSP_FRAG object for each fragment in the S2L sub-LSP descriptor.
The Fragment ID is a 16-bit integer (1-65535) incremented for each new RSVP message requiring semantic fragmentation, reset to 1 at wraparound. Its scope is limited to a single RSVP message type; Fragment IDs are not correlated across different message types (e.g., Path vs. PathErr).
The 'P2MP-TE Tree Re-evaluation Request' flag is defined as bit number 14 in the Attribute Flags TLV of the LSP_ATTRIBUTES object. It is set by the ingress node in a Path message to trigger tree re-evaluation at midpoint LSRs that expand loose next hops.
The 'Preferable P2MP-TE Tree Exists' notification is defined as sub-code 13 in PathErr messages with Notify error code 25. It is sent by a midpoint LSR (solicited or unsolicited) to inform the ingress node that a better P2MP-TE LSP tree exists.
The S2L sub-LSP descriptor message format is defined as: [ <S2L_SUB_LSP_FRAG> ] <S2L_SUB_LSP> [ <P2MP SECONDARY_EXPLICIT_ROUTE> ]. The S2L_SUB_LSP_FRAG object is placed before the S2L_SUB_LSP object in semantically fragmented RSVP messages.
IANA registered bit number 14 ('P2MP-TE Tree Re-evaluation Request') in the 'Attribute Flags' registry under 'RSVP-TE Parameters'. The flag is valid in Attribute Flags Path but not Resv, RRO, or ERO.
IANA registered Class Number 204 (S2L_SUB_LSP_FRAG) in the 'Class Names, Class Numbers, and Class Types' registry, and created a new 'Class Types or C-Types - 204 S2L_SUB_LSP_FRAG' registry with value 1 assigned.
IANA registered sub-code 13 ('Preferable P2MP-TE Tree Exists') under the 'Sub-Codes - 25 Notify Error' sub-registry of the RSVP Parameters 'Error Codes and Globally-Defined Error Value Sub-Codes' registry.
For P2MP-TE LSP S2L sub-LSPs spanning multiple domains, it may be desirable for a midpoint LSR to modify the RSVP PathErr message to preserve confidentiality across domains, as per the approach described in RFC 4736.
The introduction of the S2L_SUB_LSP_FRAG fragment identifier introduces no additional information to signaling and therefore does not itself introduce new security concerns. General MPLS/GMPLS security considerations are covered by RFC 5920.
The S2L_SUB_LSP_FRAG object (Class Number 204, C-Type 1) is 8 bytes long. It contains a 16-bit Fragment ID (1-65535), an 8-bit Fragments Total (1-255), and an 8-bit Fragment Number (1-255), enabling unambiguous reconstruction of fragmented S2L sub-LSP descriptor lists.