A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)
Extracted elements (22)
An optimization for inter-AS TE allows ASBRs to flood TE information for inter-ASBR links even when no IGP adjacency exists over those links. This allows ingress ASBRs to make better route selections and reduces call setup failure due to unsatisfied constraints on inter-ASBR links.
Certain TE constraints like resource affinity, color, and metric may need to be translated at domain boundaries via local policy mapping. This is particularly applicable to inter-AS TE, similar to inter-AS TE agreement enforcement policies.
For stitched or nested inter-domain TE LSPs, reoptimization is treated as a local matter per domain because the inter-domain TE LSP is a different LSP (different RSVP session) from the intra-domain S-LSP or H-LSP. This makes reoptimization transparent to the Head-end LSR.
No topology or resource information needs to be distributed between domains, which is critical to preserve IGP/BGP scalability and confidentiality for TE LSPs spanning multiple routing domains. This is mandated by RFC 4105 and RFC 4216.
Per-domain path computation cannot guarantee end-to-end path optimality and may fail to find diverse paths due to the 'trapping' problem. For example, with a serialized per-domain approach, selecting A-B-C-D first may prevent finding the two diverse paths A-C-D and A-B-D that actually exist.
The per-domain path computation mechanisms are applicable regardless of the nature of the inter-domain TE LSP (contiguous, stitched, or nested), and equally apply to both OSPF-based (inter-area) and IS-IS-based (multi-level) networks.
The per-domain path computation technique is applicable to any node (not just boundary nodes) that receives a Path message with an ERO containing a loose hop or non-simple abstract node. When a strict node is present in the ERO, procedures from RFC 3209 apply with no further action needed.
When an AS is composed of multiple IGP areas (e.g., BGP confederations), the per-domain path computation technique applies recursively. Each sub-domain is treated as a domain in its own right.
A manual trigger for reoptimization at the Head-end LSR SHOULD force a reoptimization by signaling a new path for the same LSP using the Make-Before-Break procedure.
For a contiguous TE LSP, unless disallowed by policy, the boundary LSR processing the ERO SHOULD perform ERO expansion — computing the constrained path to the next loose hop and inserting the computed hops as strict nodes in the ERO. If no satisfying path exists, an RSVP PathErr SHOULD be sent.
For a stitched or nested TE LSP, if the boundary LSR supports nesting/stitching and no suitable H-LSP/S-LSP exists to the next-hop boundary LSR, it SHOULD signal a new H-LSP/S-LSP. If dynamic H-LSP/S-LSP setup fails, this SHOULD be treated as a path computation and signaling failure and an RSVP PathErr SHOULD be sent upstream.
If crankback is not allowed for an inter-area TE LSP or if the ABR is configured not to perform crankback, then the ABR MUST stop the signaling process and MUST forward a PathErr to the Head-end LSR without trying to select another ABR.
If the next hop is not present in the TED, the boundary LSR SHOULD check if the next-hop boundary LSR has IP reachability (via IGP or BGP) when the next-hop address is outside the current domain and the next-hop domain is PSC with in-band control channel. If the next hop is not reachable, a signaling failure occurs and the LSR SHOULD send an RSVP PathErr with error code=24.
When a boundary LSR (ABR/ASBR) receives a Path message with an ERO containing a loose hop or a non-simple abstract node, it MUST follow the procedures specified in RFC 5151.
When an operator does not desire local reoptimization of certain inter-domain LSPs, procedures from RFC 4736 MUST be used, and any reoptimization event within the domain MUST be reported to the Head-end node. This SHOULD be a configurable policy.
Auto-discovery is the process of determining the domain boundary exit point (next-hop ABR or ASBR) based on routing information (IGP, BGP, or policy routing) as the TE LSP is being signaled. Without auto-discovery, the domain exit points must be statically configured or signaled as loose hops in the ERO.
Per-domain path computation is a technique for establishing inter-domain TE LSPs where each node responsible for computing a section of the path is always along the path itself. It applies when the full end-to-end path cannot be or is not determined at the ingress node, and is not signaled across domain boundaries.
The ERO (Explicit Route Object) in an RSVP-TE Path message specifies the inter-domain TE LSP path as a set of loose and/or strict hops. Hops may identify: the complete strict path end-to-end, strict path in the source domain followed by boundary LSRs, the complete list of boundary LSRs, or just the current boundary LSR and destination.
Boundary nodes performing ERO expansion on inter-domain TE LSPs may be exposed to various attacks. It is RECOMMENDED to support policy decisions to reject ERO expansion if not allowed by policy, and operators SHOULD be provided mechanisms to enforce policies and filters at domain borders, rate-limit LSP setup requests, and perform policy-based outbound RSVP message processing.
The per-domain path computation process does not increase the information exchanged between ASs and preserves topology confidentiality, in compliance with RFC 4105 and RFC 4216. No summarized TE information is leaked between ASs.
When signaling inter-domain RSVP-TE LSPs, operators may use RSVP-TE security features (RFC 3209), requiring domain coordination to share cryptographic keys (RFC 2747, RFC 3097) with sufficiently frequent key changes. Fast Reroute protection (RFC 4090) requires additional synchronization since the Merge Point and PLR must also share keys.
ERO expansion at a boundary LSR transitions through: (1) determine next-hop boundary LSR (from ERO or auto-discovery), (2) compute constrained path to next loose hop, (3) insert computed hops as strict nodes in ERO and forward Path message, or (4) on failure, send PathErr upstream and optionally trigger crankback to select an alternate boundary LSR.