RFC 5152
A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)
RFC 5152: A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs) 🎀
Authors: JP. Vasseur, Ed. (Cisco Systems, Inc.), A. Ayyangar, Ed. (Juniper Networks), R. Zhang (BT) 💜 Working Group: Networking Working Group Category: Standards Track 🦋 Date: February 2008 🌸 Obsoletes/Updates: the title block doesn't list anything it obsoletes or updates ✨
1. Introduction ....................................................2
2. Terminology .....................................................3
2.1. Requirements Language ......................................4
3. General Assumptions .............................................4
3.1. Common Assumptions .........................................4
3.2. Example of Topology for the Inter-Area TE Case .............6
3.3. Example of Topology for the Inter-AS TE Case ...............7
4. Per-Domain Path Computation Procedures ..........................8
4.1. Example with an Inter-Area TE LSP .........................11
4.1.1. Case 1: T0 Is a Contiguous TE LSP ..................11
4.1.2. Case 2: T0 Is a Stitched or Nested TE LSP ..........12
4.2. Example with an Inter-AS TE LSP ...........................13
4.2.1. Case 1: T1 Is a Contiguous TE LSP ..................13
4.2.2. Case 2: T1 Is a Stitched or Nested TE LSP ..........14
5. Path Optimality/Diversity ......................................14
6. Reoptimization of an Inter-Domain TE LSP .......................15
6.1. Contiguous TE LSPs ........................................15
6.2. Stitched or Nested (non-contiguous) TE LSPs ...............16
6.3. Path Characteristics after Reoptimization .................17
7. Security Considerations ........................................17
8. Acknowledgements ...............................................18
9. References .....................................................18
9.1. Normative References ......................................18
9.2. Informative References ....................................18Status of This Memo 📜
okay so this doc is a Internet standards track protocol spec for the whole Internet community, and it's literally asking everyone for discussion and suggestions to make it better 🫶 For the current standardization state and status of this protocol, check the latest edition of the "Internet Official Protocol Standards" (STD 1). And the good news: distribution of this memo is unlimited, so share away 💅
Abstract ✨
this doc spells out a per-domain path computation technique for setting up inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs) 🧚 A "domain" here just means a group of network elements that share a common sphere of address management or path computation responsibility. Think Interior Gateway Protocol (IGP) areas and Autonomous Systems 🌈
per-domain computation kicks in when the full path of an inter-domain TE LSP can't be figured out, or isn't figured out, at the ingress node of that LSP. The path also isn't signaled across domain boundaries. This mostly happens because of TE visibility limitations 👀 The signaling message only tells you the destination and the nodes up to the next domain boundary. It might also mention further domain boundaries or domain identifiers. The path through each domain, including which exit point it picks (if that's part of the decision), must be determined within that domain 💖
1. Introduction 🌸
okay the requirements for inter-domain Traffic Engineering (inter-area and inter-AS TE) came out of the Traffic Engineering Working Group, and they're written up in [RFC4105] and [RFC4216] 🎀 The framework for inter-domain MPLS Traffic Engineering lives in [RFC4726] 🦋
some of the mechanisms used to set up and maintain inter-domain TE LSPs are specified in [RFC5151] and [RFC5150] ✨
this doc is all about the path computation side of things, and it defines a way to set up inter-domain TE LSPs where every node in charge of computing a section of the path is always on the path of that TE LSP 🧠
when the Head-end LSR (the LSR that started the TE LSP) doesn't have visibility into an end-to-end complete path that spans multiple domains, one approach in this doc is to use a per-domain path computation technique during LSP setup. That way the inter-domain TE LSP gets figured out as it moves through each domain 🚀
the mechanisms in this doc also work for MPLS TE domains other than IGP areas and ASs 🌈
the solution here doesn't try to address every single requirement in [RFC4105] and [RFC4216]. That's totally fine according to [RFC4216], which says a solution can be built for one specific deployment scenario and might therefore not meet all the requirements for other scenarios 💅
it's super important to know that the inter-domain path computation technique in this doc is just one of many options. Picking the right one has to be driven by the set of requirements for the path attributes, and by how well a given technique fits the deployment scenario 🧐 For example, if you need an end-to-end constraint-based shortest path across multiple domains, a mechanism using one or more distributed PCEs could compute that shortest path across the different domains (see [RFC4655]) 🔥 Other off-line mechanisms for path computation aren't ruled out either. Also, a Service Provider may choose to use different inter-domain path computation techniques for different TE LSP types 🫶
2. Terminology 📚
here's the vocab we're using in this doc:
- AS: Autonomous System.
- ABR: Area Border Router, a router used to connect two IGP areas (areas in OSPF or levels in Intermediate System to Intermediate System (IS-IS)).
- ASBR: Autonomous System Border Router, a router used to connect together ASs of a different or the same Service Provider via one or more inter-AS links.
- Boundary LSR: a boundary LSR is either an ABR in the context of inter-area TE or an ASBR in the context of inter-AS TE.
- ERO: Explicit Route Object.
- IGP: Interior Gateway Protocol.
- Inter-AS TE LSP: a TE LSP that crosses an AS boundary.
- Inter-area TE LSP: a TE LSP that crosses an IGP area.
- LSR: Label Switching Router.
- LSP: Label Switched Path.
- TE LSP: Traffic Engineering Label Switched Path.
- PCE: Path Computation Element, an entity (component, application, or network node) that can compute a network path or route based on a network graph and apply computational constraints.
- TED: Traffic Engineering Database.
the notions of contiguous, stitched, and nested TE LSPs are defined in [RFC4726], so we're not repeating them here 🙈
2.1. Requirements Language 💜
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in RFC 2119 [RFC2119]. so yeah, those caps words are the official ones 😭
3. General Assumptions 🧚
3.1. Common Assumptions 🎀
- Each domain in all the examples below is assumed to be capable of doing Traffic Engineering (i.e., running OSPF-TE or ISIS-TE and RSVP-TE (Resource Reservation Protocol Traffic Engineering)). A domain may itself comprise multiple other domains. For example, an AS may itself be composed of several other sub-ASs (BGP confederations) or areas/levels. In this case, the path computation technique described for inter-area and inter-AS MPLS Traffic Engineering applies recursively 🌀
- the inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209] and [RFC3473]) 🚀
- the path for an inter-domain TE LSP (specified by an ERO (Explicit Route Object) in an RSVP-TE Path message) may be signaled as a set of (loose and/or strict) hops 🦋
- the hops may identify:
- the complete strict path end-to-end across different domains
- the complete strict path in the source domain, followed by boundary LSRs (or domain identifiers, e.g., AS numbers)
- the complete list of boundary LSRs along the path
- the current boundary LSR and the LSP destination
the set of (loose or strict) hops can be either statically configured on the Head-end LSR or dynamically computed 🔥 This doc defines a per-domain path computation method with an optional auto-discovery mechanism (for example, one based on IGP, BGP, or policy routing information). That mechanism yields the next-hop boundary node, which is the domain exit point such as an Area Border Router (ABR) or an Autonomous System Border Router (ASBR), along the path while the TE LSP is being signaled. Potential crankback mechanisms come along for the ride too 💅 Or, the domain exit points can be statically configured on the Head-end LSR. In that case, next-hop boundary node auto-discovery wouldn't be required 🌸
- boundary LSRs are assumed to be capable of performing local path computation to expand a loose next hop in the signaled ERO, if the path isn't signaled by the Head-end LSR as a set of strict hops, or if the strict hop is an abstract node (e.g., an AS). In any case, no topology or resource information needs to be distributed between domains (as mandated per [RFC4105] and [RFC4216]). That's critical for keeping IGP/BGP scalability and confidentiality intact when TE LSPs span multiple routing domains 🫶
- the paths for the intra-domain Hierarchical LSP (H-LSP) or Stitched LSP (S-LSP), or for a contiguous TE LSP within the domain, may be pre-configured or computed dynamically based on the arriving inter-domain LSP setup request (depending on the requirements of the transit domain). This capability is explicitly specified as a requirement in [RFC4216] 👑 When the paths for the H-LSP/S-LSP are pre-configured, the constraints as well as other parameters, like a local protection scheme for the intra-domain H-LSP/S-LSP, are also pre-configured 🧠
- while certain constraints like bandwidth can be used across different domains, other TE constraints like resource affinity, color, metric, etc. (as listed in [RFC2702]) may need to be translated at domain boundaries. If that's required, it's assumed that the domain boundary LSRs have some sort of local mapping, based on a policy agreement, to translate those constraints across the boundaries. This assumption is expected to particularly apply to inter-AS TE. For example, the local mapping would be similar to the inter-AS TE agreement enforcement policies stated in [RFC4216] 🌈
- the procedures defined in this doc apply to any node (not just a boundary node) that receives a Path message with an ERO that constrains a loose hop, or an abstract node that isn't a simple abstract node (that is, an abstract node that identifies more than one LSR) ✨
bestie, that's the first chunk of RFC 5152 done 💖
3.2. Example of Topology for the Inter-Area TE Case
okay so this is the example we're using for the inter-area TE case in this doc, and it's giving main character energy 🦋✨
<-area 1-><-- area 0 --><--- area 2 --->
------ABR1------------ABR3-------
| / | | \ |
R0--X1 | | X2---X3--R1
| | | / |
------ABR2-----------ABR4--------
<=========== Inter-area TE LSP =======>Figure 1 - Example of topology for the inter-area TE case 💜
Description of Figure 1 (bestie, read this part, it's the map):
- ABR1, ABR2, ABR3, and ABR4 are ABRs. 🌸
- X1 is an LSR in area 1. 🍓
- X2 and X3 are LSRs in area 2. 🧚
- An inter-area TE LSP T0 originated at R0 in area 1 and terminated at R1 in area 2. 👑
Notes, because I'm not letting you miss any of these 🙈:
- The terminology used in the example above corresponds to OSPF, but the path computation technique proposed in this document equally applies to the case of an IS-IS multi-level network. ✨
- Just a few routers in each area are depicted in the diagram above for the sake of simplicity. 🫶
- The example depicted in Figure 1 shows the case where the Head-end and Tail-end areas are connected by means of area 0. The case of an inter-area TE LSP between two IGP areas that does not transit through area 0 is not precluded. 💅 so area 0 isn't the only vibe, it just happens to be the one drawn here 🦋
3.3. Example of Topology for the Inter-AS TE Case
now we go big. this one is the superset of everything in [RFC4216], so it's basically the whole group chat 🌈💀
<-- AS1 ----> <------- AS2 ------><--- AS3 ----->
<---BGP---> <---BGP-->
CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6
|\ \ | / | / | / | | |
| \ ASBR2---/ ASBR5 | -- | | |
| \ | | |/ | | |
R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2
<======= Inter-AS TE LSP (LSR to LSR)===========>
or
<======== Inter-AS TE LSP (CE to ASBR) =>
or
<================= Inter-AS TE LSP (CE to CE)===============>Figure 2 - Example of topology for the inter-AS TE case 💜
The diagram in Figure 2 covers all the inter-AS TE deployment cases described in [RFC4216], so if you're wondering whether your setup is in there, it probably is 👀✨
Description of Figure 2 (the tea ☕):
- Three interconnected ASs, respectively AS1, AS2, and AS3. Note that in some scenarios described in [RFC4216] AS1=AS3. 🎀 wild, right? the first and last AS can be the same one
- The ASBRs in different ASs are BGP peers. There is usually no IGP running on the single hop links interconnecting the ASBRs and also referred to as inter-ASBR links. 🔗 no IGP on those inter-ASBR links, they're just BGP buddies
- Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE extensions (see [RFC3630], [RFC3784], [RFC4203] and [RFC4205]). In other words, the ASs are TE enabled. 🧠⚡ so every AS is TE-ready, no excuses
- CE: Customer Edge router. 🏠
- Each AS can be made of several IGP areas. The path computation technique described in this document applies to the case of a single AS made of multiple IGP areas, multiple ASs made of a single IGP area, or any combination of the above. For the sake of simplicity, each routing domain will be considered as a single area in this document. The case of an inter-AS TE LSP spanning multiple ASs where some of those ASs are themselves made of multiple IGP areas can be easily derived from the examples above: the per-domain path computation technique described in this document is applied recursively in this case. 🪄 it's all just layers of the same trick, honestly iconic
- An inter-AS TE LSP T1 originated at R0 in AS1 and terminated at R6 in AS3. 🦋 R0 to R6, the whole journey, we're so back 💖
4. Per-Domain Path Computation Procedures ✨
okay bestie, so the inter-domain TE LSP computation stuff in this doc works no matter what kind of inter-domain TE LSP you're dealing with 🦋 (contiguous, stitched, or nested). it's giving flexibility 💅
Note that any path can be defined as a set of loose and strict hops. so sometimes it makes sense to let dynamic path computation handle some domains, and keep strict control over the path in other domains (by defining strict hops) 🎀
When an LSR that is a boundary node such as an ABR/ASBR receives a Path message with an ERO that contains a strict node, the procedures specified in [RFC3209] apply and no further action is needed ✨
When an LSR that is a boundary node such as an ABR/ASBR receives a Path message with an ERO that contains a loose hop, or an abstract node that is not a simple abstract node (that is, an abstract node that identifies more than one LSR), then it MUST follow the procedures as described in [RFC5151] 🔥
ok and in addition, these are the path computation procedures that the LSR SHOULD carry out 💖
- If the next hop is not present in the TED, the two following conditions MUST be checked 🙈:
- Whether the IP address of the next-hop boundary LSR is outside of the current domain
- Whether the next-hop domain is PSC (Packet Switch Capable) and uses in-band control channel
If the two conditions above are satisfied, then the boundary LSR SHOULD check if the next hop has IP reachability (via IGP or BGP). If the next hop is not reachable, then a signaling failure occurs and the LSR SHOULD send back an RSVP PathErr message upstream with error code=24 ("Routing Problem") and error subcode as described in section 4.3.4 of [RFC3209]. If the available routing information indicates that next hop is reachable, the selected route will be expected to pass through a domain boundary via a domain boundary LSR. The determination of domain boundary point based on routing information is what we term as "auto-discovery" in this document. In the absence of such an auto-discovery mechanism, a) the ABR in the case of inter-area TE or the ASBR in the next-hop AS in the case of inter-AS TE should be the signaled loose next hop in the ERO and hence should be accessible via the TED, or b) there needs to be an alternate scheme that provides the domain exit points. Otherwise, the path computation for the inter-domain TE LSP will fail 💀
An implementation MAY support the ability to disable such an IP reachability fall-back option should the next-hop boundary LSR not be present in the TED. In other words, an implementation MAY support the possibility to trigger a signaling failure whenever the next hop is not present in the TED 🌸
- Once the next-hop boundary LSR has been determined (according to the procedure described in 1)) or if the next-hop boundary is present in the TED:
- Case of a contiguous TE LSP. Unless not allowed by policy, the boundary LSR that processes the ERO SHOULD perform an ERO expansion (a process consisting of computing the constrained path up to the next loose hop and adding the list of hops as strict nodes in the ERO). If no path satisfying the set of constraints can be found, then this is treated as a path computation and signaling failure and an RSVP PathErr message SHOULD be sent for the inter-domain TE LSP based on section 4.3.4 of [RFC3209] 🧚
- Case of a stitched or nested TE LSP
- If the boundary LSR is a candidate LSR for intra-area H-LSP/S-LSP setup (the boundary has local policy for nesting or stitching), the TE LSP is a candidate for hierarchy/nesting (the "Contiguous LSP" bit defined in [RFC5151] is not set), and if there is no H-LSP/S-LSP from this LSR to the next-hop boundary LSR that satisfies the constraints, it SHOULD signal an H-LSP/S-LSP to the next-hop boundary LSR. If a pre-configured H-LSP(s) or S-LSP(s) already exists, then it will try to select from among those intra-domain LSPs. Depending on local policy, it MAY signal a new H-LSP/S-LSP if this selection fails. If the H-LSP/S-LSP is successfully signaled or selected, it propagates the inter-domain Path message to the next hop following the procedures described in [RFC5151]. If for some reason the dynamic H-LSP/S-LSP setup to the next-hop boundary LSR fails, then this SHOULD be treated as a path computation and signaling failure and an RSVP PathErr message SHOULD be sent upstream for the inter-domain LSP. Similarly, if selection of a pre-configured H-LSP/S-LSP fails and local policy prevents dynamic H-LSP/S, this SHOULD be treated as a path computation and signaling failure and an RSVP PathErr message SHOULD be sent upstream for the inter-domain TE LSP. In both of these cases, procedures described in section 4.3.4 of [RFC3209] SHOULD be followed to handle the failure 😭
- If, however, the boundary LSR is not a candidate for intra-domain H-LSP/S-LSP (the boundary LSR does not have local policy for nesting or stitching) or the TE LSP is not a candidate for hierarchy/nesting (the "Contiguous LSP" bit defined in [RFC5151] is set), then it SHOULD apply the same procedure as for the contiguous case 🍓
The ERO of an inter-domain TE LSP may comprise abstract nodes such as ASs. In such a case, upon receiving the ERO whose next hop is an AS, the boundary LSR has to determine the next-hop boundary LSR, which may be determined based on the auto-discovery process mentioned above. If multiple ASBR candidates exist, the boundary LSR may apply some policies based on peering contracts that may have been pre-negotiated. Once the next-hop boundary LSR has been determined, a similar procedure as the one described above is followed 🫶
Note the following related to the inter-AS TE case:
In terms of computation of an inter-AS TE LSP path, an interesting optimization technique consists of allowing the ASBRs to flood the TE information related to the inter-ASBR link(s) although no IGP TE is enabled over those links (and so there is no IGP adjacency over the inter-ASBR links). This of course implies that the inter-ASBR links be TE-enabled although no IGP is running on those links. this is so clever, I'm obsessed 😍
<-- AS1 ----> <------- AS2 ------><--- AS3 ----->
<---BGP---> <---BGP-->
CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6
|\ \ | / | / | / | | |
| \ ASBR2---/ ASBR5 | -- | | |
| \ | | |/ | | |
R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2
Figure 3 - Flooding of the TE-related information for
the inter-ASBR linksReferring to Figure 3, ASBR1 for example would advertise in its OSPF Link State Advertisement (LSA)/IS-IS LSP the Traffic Engineering TLVs related to the link ASBR1-ASBR4. 🦋
This allows an LSR (could be the entry ASBR) in the previous AS to make a more appropriate route selection up to the entry ASBR in the immediately downstream AS, taking into account the constraints associated with the inter-ASBR links. This reduces the risk of call setup failure due to inter-ASBR links not satisfying the inter-AS TE LSP set of constraints. Note that the TE information is only related to the inter-ASBR links: the TE LSA/LSP flooded by the ASBR includes not only the TE-enabled links contained in the AS but also the inter-ASBR links. 💅
Note that no summarized TE information is leaked between ASs, which is compliant with the requirements listed in [RFC4105] and [RFC4216]. the privacy is valid 🔒
For example, consider the diagram depicted in Figure 2: when ASBR1 floods its IGP TE LSA ((opaque LSA for OSPF)/LSP (TLV 22 for IS-IS)) in its routing domain, it reflects the reservation states and TE properties of the following links: X1-ASBR1, ASBR1-ASBR2, and ASBR1-ASBR4. ✨
Thanks to such an optimization, the inter-ASBR TE link information corresponding to the links originated by the ASBR is made available in the TED of other LSRs in the same domain to which the ASBR belongs. Consequently, the path computation for an inter-AS TE LSP path can also take into account the inter-ASBR link(s). This will improve the chance of successful signaling along the next AS in case of resource shortage or unsatisfied constraints on inter-ASBR links, and it potentially reduces one level of crankback. Note that no topology information is flooded, and these links are not used in IGP SPF computations. Only the TE information for the outgoing links directly connected to the ASBR is advertised. 🌈
Note that an operator may decide to operate a stitched segment or 1-hop hierarchical LSP for the inter-ASBR link. 🧚
4.1. Example with an Inter-Area TE LSP
The following example uses Figure 1 as a reference. 🎀
4.1.1. Case 1: T0 Is a Contiguous TE LSP
The Head-end LSR (R0) first determines the next-hop ABR (which could be manually configured by the user or dynamically determined by using the auto-discovery mechanism). R0 then computes the path to reach the selected next-hop ABR (ABR1) and signals the Path message. When the Path message reaches ABR1, it first determines the next-hop ABR from its area 0 along the LSP path (say, ABR3), either directly from the ERO (if for example the next-hop ABR is specified as a loose hop in the ERO) or by using the auto-discovery mechanism specified above. 🫶
- Example 1 (set of loose hops):
R0-ABR1(loose)-ABR3(loose)-R1(loose) - Example 2 (mix of strict and loose hops):
R0-X1-ABR1-ABR3(loose)-X2-X3-R1
Note that a set of paths can be configured on the Head-end LSR, ordered by priority. Each priority path can be associated with a different set of constraints. It may be desirable to systematically have a last-resort option with no constraint to ensure that the inter-area TE LSP could always be set up if at least a TE path exists between the inter-area TE LSP source and destination. In case of setup failure or when an RSVP PathErr is received indicating that the TE LSP has suffered a failure, an implementation might support the possibility of retrying a particular path option a configurable amount of times (optionally with dynamic intervals between each trial) before trying a lower-priority path option. 💜
Once it has computed the path up to the next-hop ABR (ABR3), ABR1 sends the Path message along the computed path. Upon receiving the Path message, ABR3 then repeats a similar procedure. If ABR3 cannot find a path obeying the set of constraints for the inter-area TE LSP, the signaling process stops and ABR3 sends a PathErr message to ABR1. Then ABR1 can in turn trigger a new path computation by selecting another egress boundary LSR (ABR4 in the example above) if crankback is allowed for this inter-area TE LSP (see [RFC4920]). If crankback is not allowed for that inter-area TE LSP or if ABR1 has been configured not to perform crankback, then ABR1 MUST stop the signaling process and MUST forward a PathErr up to the Head-end LSR (R0) without trying to select another ABR. 👑
4.1.2. Case 2: T0 Is a Stitched or Nested TE LSP ✨
Okay so the Head-end LSR (R0) goes first and figures out its next-hop ABR. That can be manually configured by the user, or it can be found dynamically with the auto-discovery mechanism 🔍. R0 then computes the path to that selected next-hop ABR and sends the Path message. When the Path message reaches ABR1, ABR1 first works out the next-hop ABR from its area 0 along the LSP path (say ABR3) 💅. It can get that either straight from the ERO, for example if the next-hop ABR is listed as a loose hop in the ERO, or through the auto-discovery mechanism we talked about above.
ABR1 then checks whether it already has an H-LSP or S-LSP to ABR3 that matches the constraints in the inter-area TE LSP Path message. If it doesn't, ABR1 computes a path for an H-LSP or S-LSP from ABR1 to ABR3 that satisfies the constraint and sets it up 🛠️. Also, that H-LSP or S-LSP could have been pre-configured. Just saying 🙈
Once ABR1 picks the H-LSP/S-LSP for the inter-area LSP, it uses the signaling procedures from [RFC5151] and sends the Path message for the inter-area TE LSP to ABR3 🦋. Here's the important bit: whether ABR1 does nesting or stitching, the Path message for the inter-area TE LSP always gets forwarded to ABR3, no exceptions. ABR3 then does the exact same procedures 🔁. If ABR3 can't find a path that obeys the set of constraints for the inter-area TE LSP, it sends a PathErr message back to ABR1 😭. Then ABR1 has options. It can pick another H-LSP/S-LSP to ABR3 if one exists, or it can select another egress boundary LSR (ABR4 in the example above) if crankback is allowed for this inter-area TE LSP (see [RFC4920]). If crankback is not allowed for that inter-area TE LSP, or if ABR1 has been configured not to do crankback, then ABR1 just forwards the PathErr up to the inter-area Head-end LSR (R0) and doesn't try selecting another egress LSR 🚫.
4.2. Example with an Inter-AS TE LSP
Let's use Figure 2 as our reference 👑.
Setting up an inter-AS TE LSP is super similar to the inter-area TE LSP we just went through. The big difference is the inter-ASBR link(s) 🌈.
4.2.1. Case 1: T1 Is a Contiguous TE LSP
The inter-AS TE path can be configured on the Head-end LSR as a set of strict hops, loose hops, or a mix of both 🎀.
- Example 1 (set of loose hops):
ASBR4(loose)-ASBR9(loose)-R6(loose) - Example 2 (mix of strict and loose hops):
R2-ASBR3-ASBR2-ASBR1-ASBR4-ASBR10(loose)-ASBR9-R6
Okay, in Example 1 above, path computation happens per AS. R0 handles AS1, ASBR4 handles AS2, and ASBR9 handles AS3 🧩. Also, when an LSR has to do ERO expansion, the next hop either has to belong to the same AS or has to be the ASBR directly connected to the next hop AS. In that second case, the ASBR reachability gets announced in the IGP TE LSA/LSP that its neighboring ASBR originates 📣. So in Example 1, the TE LSP path is ASBR4(loose)-ASBR9(loose)-R6(loose). That means R0 has to compute the path from R0 to ASBR4, which is why R0 needs to know the TE reservation state for the ASBR1-ASBR4 link (flooded in AS1 by ASBR1) 👀. On top of that, ASBR1 also has to announce the IP address of ASBR4 that's specified in T1's path configuration 💌.
Once ASBR1 has computed the path up to the next-hop ASBR, it sends the Path message for the inter-area TE LSP to ASBR4 (assuming ASBR4 is the selected next-hop ASBR) 💖. ASBR4 then repeats the exact same procedures. If ASBR4 can't find a path that obeys the set of constraints for the inter-AS TE LSP, it sends a PathErr message to ASBR1 😬. ASBR1 can then either select another ASBR (ASBR5 in the example above) if crankback is allowed for this inter-AS TE LSP (see [RFC4920]). If crankback is not allowed for that inter-AS TE LSP, or ASBR1 has been configured not to do crankback, then ABR1 stops the signaling process and forwards a PathErr up to the Head-end LSR (R0) without trying to select another egress LSR. In that case, the Head-end LSR can select another sequence of loose hops, if it's configured with one 🔄. Or the Head-end LSR can decide to retry the same path. That can be useful when a setup failure happens because of an outdated IGP TE database in some downstream AS 🧠. Another option is for the Head-end LSR to retry the same sequence of loose hops after relaxing some constraint(s) ✨.
4.2.2. Case 2: T1 Is a Stitched or Nested TE LSP
The path computation procedures are very similar to the inter-area LSP setup case we covered earlier. The only real twist is that in this case, the H-LSPs or S-LSPs get originated by the ASBRs at the entry to the AS 🍓.
5. Path Optimality/Diversity 💜
Since the inter-domain TE LSP is computed on a per-domain (area, AS) basis, you can't guarantee that the optimal inter-domain path will be found 😩.
Also, computing two diverse paths with a per-domain path computation approach may not be possible in some topologies. This is because of the well-known "trapping" problem 🪤.
Here's a simple topology to show what I mean:
+-------+
/ \
A----B-----C------D
\ /
+---------+
Figure 4 - Example of the "trapping" problemIn the simple topology in Figure 4, if you use a serialized approach with the per-domain path computation technique specified in this document, a first TE LSP might get computed along the path A-B-C-D. In that case, no diverse path can be found, even though two diverse paths actually exist: A-C-D and A-B-D 🙃. The point of this simple example (which can easily be extended to the inter-domain case) is to show the potential problem: you might not be able to find diverse paths with the per-domain approach even when they do exist.
As already mentioned, the Service Provider can choose the required path computation method on a per-LSP basis 🎯.
If the per-domain path computation technique doesn't meet the set of requirements for a particular TE LSP (for example, path optimality, or requirements for a set of diversely routed TE LSPs), then other techniques, such as PCE-based path computation techniques, may be used (see [RFC4655]) 🧚♀️.
6. Reoptimization of an Inter-Domain TE LSP 🦄
As stated in [RFC4216] and [RFC4105], being able to reoptimize an already established inter-domain TE LSP is a requirement 📋. How the reoptimization process goes depends a lot on the nature of the TE LSP and the mechanism used to compute it.
The following mechanisms can be used for reoptimization, and which one fits depends on the nature of the inter-domain TE LSP 🔑.
6.1. Contiguous TE LSPs
After an inter-domain TE LSP has been set up, a better route might show up within any traversed domain 👀. In that case, it's desirable to be able to reroute the inter-domain TE LSP in a non-disruptive way (using the so-called Make-Before-Break procedure) so it follows the better path ✨. This is known as a TE LSP reoptimization procedure.
[RFC4736] proposes a mechanism that lets the Head-end LSR find out that a more optimal path exists in a downstream domain 🛰️. The Head-end LSR can then decide to gracefully reroute the TE LSP using the Make-Before-Break procedure. For a contiguous LSP, the reoptimization process is strictly controlled by the Head-end LSR that triggers the Make-Before-Break procedure defined in [RFC3209], no matter where the better path is 👑.
6.2. Stitched or Nested (non-contiguous) TE LSPs
With a stitched or nested inter-domain TE LSP, reoptimization is treated as a local matter for any domain 🏠. The main reason is that the inter-domain TE LSP is a different LSP (and therefore a different RSVP session) from the intra-domain S-LSP or H-LSP in an area or an AS. So reoptimization in a domain is done by locally reoptimizing the intra-domain H-LSP or S-LSP 🔧. Since the inter-domain TE LSPs are carried over S-LSPs or H-LSPs across each domain, the optimality of the inter-domain TE LSP in a domain depends on the optimality of the matching S-LSP or H-LSP 🧵. If a more optimal path shows up within a domain after an inter-domain LSP is set up, the matching S-LSP or H-LSP gets reoptimized using the Make-Before-Break techniques from [RFC3209]. Reoptimizing the H-LSP or S-LSP automatically reoptimizes the inter-domain TE LSPs it carries 🪄. Reoptimization settings, like how often it happens and the criteria for it (such as metric or bandwidth availability), can differ from one domain to another. They can be configured as needed, per intra-domain TE S-LSP or H-LSP if it's pre-configured, or based on some global policy inside the domain 🎛️.
So in this scheme, each domain takes care of reoptimizing its own S-LSPs or H-LSPs, and therefore the matching inter-domain TE LSPs. That means Make-Before-Break can happen locally and isn't triggered by the Head-end LSR for the inter-domain LSP 💫. No extra RSVP signaling is needed for LSP reoptimization, and reoptimization stays transparent to the Head-end LSR of the inter-domain TE LSP 🫶.
If, however, an operator wants to manually trigger reoptimization at the Head-end LSR for the inter-domain TE LSP, this solution doesn't stop that 🕹️. A manual trigger for reoptimization at the Head-end LSR SHOULD force a reoptimization, which signals a "new" path for the same LSP (along the more optimal path) using the Make-Before-Break procedure ⚡. In response to this new setup request, the boundary LSR may either start a new S-LSP setup (if the inter-domain TE LSP is being stitched to the intra-domain S-LSP), or select an existing or new H-LSP (in case of nesting). When the LSP setup along the current path is complete, the Head-end LSR should switch the traffic over to that path, and the old path is eventually torn down 🧹. Note that the Head-end LSR doesn't know a priori whether a more optimal path exists 🤷♀️. That said, a manual trigger like this from the Head-end LSR of the inter-domain TE LSP is not considered a frequent occurrence 😌.
Procedures described in [RFC4736] MUST be used if the operator does not want local reoptimization of certain inter-domain LSPs 🚨. In that case, any reoptimization event within the domain MUST be reported to the Head-end node. This SHOULD be a configurable policy 🎀.
6.3. Path Characteristics after Reoptimization
Heads up, this one's a bit subtle 🧐. With loose hop reoptimization of a contiguous inter-domain TE LSP, or local reoptimization of a stitched/nested S-LSP where the boundary LSRs are specified as loose hops, the TE LSP may follow a preferable path within one or more domains. But it still traverses the same set of boundary LSRs 🧭. In contrast, with PCE-based path computation techniques, the end-to-end optimal path is computed, so reoptimization may lead to a completely different inter-domain path (including a different set of boundary LSRs) 🌍.
7. Security Considerations 🔐
Okay bestie, this part is serious, so let's be extra careful 🥺. Signaling inter-domain TE LSPs brings up security issues, which are discussed in section 7 of [RFC5151].
[RFC4726] gives an overview of the security requirements for an MPLS-TE or GMPLS multi-domain environment 💜. When you signal an inter-domain RSVP-TE LSP, an operator may use the security features that are already defined for RSVP-TE ([RFC3209]). This may take some coordination between the domains to share the keys (see [RFC2747] and [RFC3097]), and you've gotta make sure the keys get changed often enough 🔑. Also note that this may need extra synchronization if the domain border nodes are protected with Fast Reroute ([RFC4090]), because the Merge Point (MP) and Point of Local Repair (PLR) should also share the key 🫶.
For an inter-domain TE LSP, especially one that crosses different administrative or trust domains, the following mechanisms SHOULD be provided to an operator (also see [RFC4216]):
- A way to enforce policies and filters at the domain borders so they can process incoming inter-domain TE LSP setup requests (Path messages) based on agreed trust and service levels or contracts between domains. Things like bandwidth, priority, and so on could be part of that contract 📜.
- A way for the operator to rate-limit LSP setup requests or error notifications coming from a particular domain 🚦.
- A mechanism that allows policy-based outbound RSVP message processing at the domain border node. This may involve filtering or modifying certain addresses in RSVP objects and messages 🎀.
This document is all about inter-domain path computation 🗺️. The process for establishing paths described here does not increase the information exchanged between ASs, and it preserves topology confidentiality, in compliance with [RFC4105] and [RFC4216]. That being said, signaling an inter-domain TE LSP using the procedure in this document requires path computation on boundary nodes, and those boundary nodes may be exposed to various attacks 💀. Thus, it is RECOMMENDED to support policy decisions that reject the ERO expansion of an inter-domain TE LSP if it isn't allowed 🛡️.
8. Acknowledgements 💖
We would like to acknowledge input and helpful comments from Adrian Farrel, Jean-Louis Le Roux, Dimitri Papadimitriou, and Faisal Aslam. Iconic squad 👑.
9. References 📚
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.9.2. Informative References
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita,
N., and G. Ash, "Crankback Signaling Extensions for MPLS
and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-
Domain MPLS and GMPLS Traffic Engineering -- Resource
Reservation Protocol-Traffic Engineering (RSVP-TE)
Extensions", RFC 5151, February 2008.
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
"Label Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering (GMPLS
TE)", RFC 5150, February 2008.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097,
April 2001.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle,
Ed., "Requirements for Inter-Area MPLS Traffic
Engineering", RFC 4105, June 2005.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005.
[RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate
System to Intermediate System (IS-IS) Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4205, October 2005.
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-
Autonomous System (AS) Traffic Engineering (TE)
Requirements", RFC 4216, November 2005.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework
for Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006.
[RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang,
"Reoptimization of Multiprotocol Label Switching (MPLS)
Traffic Engineering (TE) Loosely Routed Label Switched
Path (LSP)", RFC 4736, November 2006.Authors' Addresses 💌
JP Vasseur (editor)
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
EMail: jpv@cisco.com
Arthi Ayyangar (editor)
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
USA
EMail: arthi@juniper.net
Raymond Zhang
BT
2160 E. Grand Ave.
El Segundo, CA 90025
USA
EMail: raymond.zhang@bt.comFull Copyright Statement ©️
The legal bits, verbatim so nothing gets lost 🧾:
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property 🧠
The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the technology in this document, or on whether any license under those rights might be available. It also doesn't claim to have made any independent effort to find such rights. Info on the procedures for rights in RFC documents is in BCP 78 and BCP 79. The verbatim text:
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.📦 where this page comes from
- ietf: rfc5152 2008-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms