Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions
updates
Extracted elements (28)
For failure of a border node when stitching or nesting is in use, the PLR must be the upstream domain entry point and the MP must be the downstream domain exit point, because the failed node is the start or end of a stitching segment or H-LSP. For contiguous LSPs, normal PLR and MP selection applies without these constraints.
Per-domain reoptimization using nesting or stitching is limited to preserving domain entry and exit points, whereas end-to-end reoptimization can select new domain border LSRs. This locality principle means stitching or nesting better supports local reoptimization, while contiguous LSPs give the ingress maximal end-to-end control.
Replacing Notify recipients at domain border nodes allows domains to handle notifiable events locally (e.g., enabling protection switching within a domain), but introduces the cost of processing and forwarding Notify messages at domain borders, a cost that increases linearly with the number of domains.
The three signaling methods (contiguous, nested, stitched) are per-domain transit options, not end-to-end choices. This allows each domain operator to choose the method that best suits their administrative and technical requirements, enabling, for example, an ingress that wants maximal control to request contiguous signaling while a transit domain operator who wants per-domain reoptimization control may permit only stitching.
Domain border LSRs must be upgraded before inter-domain TE LSPs are allowed across a domain border due to the need to establish policy, administrative, and security controls. Legacy domain border LSRs need not be considered since they will block inter-domain LSPs.
The document is backward compatible: transit non-border LSRs that receive a Path message without the 'Contiguous LSP' bit or the LSP_Attributes object pass it unmodified per RFC 2205 rules. Back-level ingress LSRs can still initiate inter-domain LSPs since the default behavior is to allow all modes.
A domain border node MUST NOT suppress the propagation of a PathErr message except to attempt crankback rerouting. If a subsequent rerouting attempt is successful, the held PathErr MUST be discarded; if all subsequent attempts are unsuccessful, the PathErr MUST be sent upstream toward the ingress.
A domain border router MUST NOT mask its own presence and MUST include itself in the RRO, even when filtering internal topology information for confidentiality.
An ERO with a loose hop as the next hop MUST be expanded to determine the path to the next hop using path computation. In the absence of any ERO subobjects beyond the local domain border node, the LSP egress MUST be considered as the next loose hop.
An intermediate node that recognizes the 'Contiguous LSP' bit but cannot support contiguous TE LSPs MUST send a PathErr with error code 'Routing Problem'/'Contiguous LSP type not supported' upon receiving a Path message with this bit set.
Before deploying inter-domain RSVP-TE signaling, administrators of neighboring domains MUST satisfy themselves as to the existence of a suitable trust relationship. In the absence of such a relationship, administrators SHOULD decide not to deploy inter-domain signaling and SHOULD disable RSVP-TE on inter-domain interfaces.
ERO procedures from Section 8.2 of RFC 4206 MUST be followed for nesting or stitching of inter-domain TE LSPs, including adjusting the ERO before sending the Path message to the next hop.
For reoptimization of a contiguous inter-domain TE LSP, the make-before-break signaling MUST be initiated by the ingress node as defined in RFC 3209. The RFC 4736 mechanisms SHOULD be used for reoptimization of contiguous inter-domain TE LSPs.
If an ERO subobject identifies a TE link formed by the advertisement of an H-LSP or LSP segment, contiguous signaling MUST NOT be used; the domain border node MUST use either nesting or stitching according to LSP capabilities, Path message parameters, and local policy.
If the ingress node of an inter-domain TE LSP has specified restrictions on signaling methods via the Path message, the domain border node MUST adhere to those restrictions. If no allowed signaling method is available, the domain border node MUST send a PathErr.
Suitable configuration MUST be provided in an RSVP-TE implementation to enable operators to control optional protocol features that may be considered a security risk across domain boundaries, such as restart information exchange.
The 'Contiguous LSP' bit MUST NOT be modified by any transit node. Domain border LSRs MUST support and act on the setting of the 'Contiguous LSP' flag.
The procedures in Sections 3 and 4 MUST be applied to all inter-domain TE LSPs, including bypass tunnels, detour LSPs (RFC 4090), and segment recovery LSPs (RFC 4873).
When a domain border LSR receives a Path message with the 'Contiguous LSP' bit set to one, the node MUST NOT perform stitching or nesting for the inter-domain TE LSP. When the bit is clear, the domain border LSR MAY perform stitching or nesting according to local policy.
When a domain border node receives an RSVP Path message for an inter-domain TE LSP setup, it MUST apply domain policies, determine the signaling method, carry out ERO procedures, and perform path computation before forwarding the Path message.
A new 'Contiguous LSP' bit (bit number 4) is defined in the Attributes Flags TLV of the LSP_Attributes object (RFC 4420). When set by the ingress node in a Path message, it restricts all domain border nodes from performing stitching or nesting for the inter-domain TE LSP.
RFC 5151 defines three signaling options for inter-domain RSVP-TE LSPs: contiguous (single end-to-end LSP per RFC 3209/3473), nested (LSP carried inside an H-LSP per RFC 4206), and stitched (concatenated LSP segments per RFC 5150). Any combination of these options may be used across the domains traversed by a single end-to-end LSP.
A new bit (bit number 4, 'Contiguous LSP') has been allocated from the 'Attributes Flags' sub-registry of the 'RSVP TE Parameters' registry. It is valid in the Attributes Flags Path and RRO, but not in the Attributes Flags Resv.
Two new error values were registered under the existing 'Policy control failure' error code (value 2): 103 = 'Inter-domain policy failure' and 104 = 'Inter-domain explicit route rejected'. Two new error values were registered under 'Routing Problem' (value 24): 28 = 'Contiguous LSP type not supported' and 29 = 'ERO conflicts with inter-domain signaling method'.
In the event of a path computation failure, an operator may configure the border node to silently discard the Path message instead of returning a PathErr, because a PathErr provides information about network capabilities and policies that could be used for network probing.
Operators SHOULD be provided with mechanisms to enforce policies and filters at domain borders for incoming inter-domain TE LSP setup requests, to rate-limit LSP setup requests or error notifications from a particular domain, and to apply policy-based outbound RSVP message processing.
RSVP does not currently provide automated key management. When using RSVP-TE security features across domains, key sharing is required between domains (RFC 2747, RFC 3097), and keys must be changed sufficiently frequently. If domain border nodes are protected with FRR, the MP and PLR must also share the key.
To preserve confidentiality of network topology, an operator may disallow recording of internal hops in the RRO, may filter out certain recorded RRO addresses at the domain border node, and may require the border node to modify the addresses in PathErr or Notify messages originating from within the domain.