RFC 4726
A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering
A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering 🦋
okay bestie, let's do the vibe check first 💅 This is RFC 4726, and it's Informational, so it's giving "here's some good info" and not "you MUST do this" 🌸 It was published in November 2006 by A. Farrel (Old Dog Consulting), J.-P. Vasseur (Cisco Systems, Inc.), and A. Ayyangar (Nuova Systems). Its header doesn't list anything it obsoletes or updates, so it's a solo main character doc 🙈
Status of This Memo ✨
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice 💜
Copyright (C) The IETF Trust (2006).
Abstract 🎀
This document gives you a framework for setting up and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Paths (LSPs) across multi-domain networks 🧚
Quick definition moment: for this doc, a domain is any collection of network elements that share a common sphere of address management or path computational responsibility. Examples are Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes) 🍓
Table of Contents 📑
1. Introduction ....................................................3
1.1. Nested Domains .............................................3
2. Signaling Options ...............................................4
2.1. LSP Nesting ................................................4
2.2. Contiguous LSP .............................................5
2.3. LSP Stitching ..............................................5
2.4. Hybrid Methods .............................................6
2.5. Control of Downstream Choice of Signaling Method ...........6
3. Path Computation Techniques .....................................6
3.1. Management Configuration ...................................7
3.2. Head-End Computation .......................................7
3.2.1. Multi-Domain Visibility Computation .................7
3.2.2. Partial Visibility Computation ......................7
3.2.3. Local Domain Visibility Computation .................8
3.3. Domain Boundary Computation ................................8
3.4. Path Computation Element ...................................9
3.4.1. Multi-Domain Visibility Computation ................10
3.4.2. Path Computation Use of PCE When Preserving
Confidentiality ....................................10
3.4.3. Per-Domain Computation Elements ....................10
3.5. Optimal Path Computation ..................................11
4. Distributing Reachability and TE Information ...................11
5. Comments on Advanced Functions .................................12
5.1. LSP Re-Optimization .......................................12
5.2. LSP Setup Failure .........................................13
5.3. LSP Repair ................................................14
5.4. Fast Reroute ..............................................14
5.5. Comments on Path Diversity ................................15
5.6. Domain-Specific Constraints ...............................16
5.7. Policy Control ............................................17
5.8. Inter-Domain Operations and Management (OAM) ..............17
5.9. Point-to-Multipoint .......................................17
5.10. Applicability to Non-Packet Technologies .................17
6. Security Considerations ........................................18
7. Acknowledgements ...............................................19
8. Normative References ...........................................19
9. Informative References .........................................201. Introduction ✨
okay so the Traffic Engineering Working Group already wrote up the requirements for inter-area and inter-AS MPLS Traffic Engineering in [RFC4105] and [RFC4216] 📋
Since then, people have come up with plenty of proposals to meet some or all of those requirements. They do it by extending the Resource Reservation Protocol Traffic Engineering extensions (RSVP-TE) and the Interior Gateway Protocols (IGPs), meaning Intermediate System to Intermediate System (IS-IS) and OSPF 💅
This document introduces the techniques for setting up Traffic Engineered (TE) Label Switched Paths (LSPs) across multiple domains. In this context, and for the rest of the document, we look at all source-based and constraint-based routed LSPs, and we call them "TE LSPs" or "LSPs" interchangeably 🦋
The functional pieces of these techniques are split up into three jobs: discovering reachability and TE information, computing the paths of LSPs, and signaling the LSPs. Note that this document isn't trying to detail each technique. Those are covered in separate documents, which the sections introducing each technique reference. The real goal here is to propose a framework for inter-domain MPLS Traffic Engineering 🌸
Also, for the rest of the document, "MPLS Traffic Engineering" applies equally to MPLS and Generalized MPLS (GMPLS) traffic. Specific GMPLS issues in inter-domain environments are covered in separate documents such as [GMPLS-AS]. One example is the policy implications of using the Link Management Protocol [RFC4204] on inter-domain links 🧚
For this document, a domain is any collection of network elements that share a common sphere of address management or path computational responsibility. Examples include IGP areas and Autonomous Systems. Wholly or partially overlapping domains (for example, path computation sub-domains of areas or ASes) are not within the scope of this document 🙈
1.1. Nested Domains 🪆
Nested domains are outside the scope of this document. Some domains that are nested administratively, or for the purposes of address space management, can be treated as adjacent domains for this document. However, the fact that the domains are nested is then immaterial 💖
In the context of MPLS TE, domain A is considered to be nested within domain B if domain A is wholly contained in domain B, and domain B is fully or partially aware of the TE characteristics and topology of domain A ✨
2. Signaling Options 🎀
Three distinct options for signaling TE LSPs across multiple domains have been identified. The option you pick may be influenced by the path computation technique you use (see section 3), although some path computation techniques can apply to multiple signaling options. The choice may also depend on the application the TE LSPs are for, and on the nature, topology, and switching capabilities of the network 👑
A comparison of the usages of the different signaling options is beyond the scope of this document, and should be the subject of a separate applicability statement 💅
2.1. LSP Nesting 🪺
Hierarchical LSPs are a fundamental part of MPLS [RFC3031] and are discussed in more detail in [RFC4206]. Hierarchical LSPs may optionally be advertised as TE links. Note that a hierarchical LSP that spans multiple domains can't be advertised this way, because there is no concept of TE information that spans domains 🙈
Hierarchical LSPs can support inter-domain TE LSPs. In particular, a hierarchical LSP may be used to get connectivity between any pair of Label Switching Routers (LSRs) within a domain. The ingress and egress of the hierarchical LSP could be the edge nodes of the domain, in which case connectivity spans the entire domain. Or they could be any other pair of LSRs in the domain 🍓
Carrying one TE LSP inside another is called LSP nesting. A hierarchical LSP can provide a TE LSP tunnel that transports (that is, nests) multiple TE LSPs along a common part of their paths. Alternatively, a TE LSP may carry (that is, nest) a single LSP in a one-to-one mapping 🫶
The signaling trigger for setting up a hierarchical LSP can be the receipt of a signaling request for the TE LSP it will carry. It can also be a management action to "pre-engineer" a domain that TE LSPs will cross, so those TE LSPs can use hierarchical LSPs as the traffic traverses the domain. The mapping (inheritance rules) between attributes of the nested and the hierarchical LSPs, including bandwidth, may be statically pre-configured. For on-demand hierarchical LSPs, the mapping may instead be dynamic, depending on the properties of the nested LSPs. Even in the dynamic case, inheritance from the properties of the nested LSP(s) can be complemented by local or domain-wide policy rules 😭
Note that a hierarchical LSP may be built to span multiple domains or parts of domains. However, such an LSP can't be advertised as a TE link that spans domains. The end points of a hierarchical LSP aren't necessarily on domain boundaries, so nesting isn't limited to domain boundaries 💜
Also, the Interior/Exterior Gateway Protocol (IGP/EGP) routing topology stays unaffected by the LSP connectivity and TE links introduced by hierarchical LSPs, even if they're advertised as TE links. In other words, the routing protocols don't exchange messages over the hierarchical LSPs, and LSPs aren't used to create routing adjacencies between routers 🌈
While you're setting up a nested LSP that uses a hierarchical LSP, the SENDER_TEMPLATE and SESSION objects stay unchanged along the entire length of the nested LSP. So do all other objects that have end-to-end significance 🔥
2.2. Contiguous LSP 🧵
A single contiguous LSP is set up from ingress to egress in one signaling exchange. No further LSPs need to be established to support it, so hierarchical or stitched LSPs aren't needed 💅
A contiguous LSP uses the same Session/LSP ID along its whole path (that is, at each LSR). The notions of "splicing" different LSPs together, or of "shuffling" Session or LSP identifiers, aren't considered here 🙈
2.3. LSP Stitching 🪡
LSP Stitching is described in [STITCH]. In the LSP stitching model, separate LSPs (called TE LSP segments) are set up and "stitched" together in the data plane, so a single end-to-end Label Switched Path is achieved. The difference is that the component LSP segments are signaled as distinct TE LSPs in the control plane. Each signaled TE LSP segment has a different source and destination 🦋
LSP stitching can support inter-domain TE LSPs. In particular, an LSP segment may be used to get connectivity between any pair of LSRs within a domain. The ingress and egress of the LSP segment could be the edge nodes of the domain, in which case connectivity spans the entire domain. Or they could be any other pair of LSRs in the domain 💖
The signaling trigger for setting up a TE LSP segment can be the establishment of the previous TE LSP segment. It can also be the receipt of a setup request for a TE LSP that it plans to stitch to a local TE LSP segment, or a management action ✨
LSP segments may be managed and advertised as TE links 🎀
2.4. Hybrid Methods ✨
okay so nothing stops you from mixing and matching the signaling methods we just went over when you set up a single end-to-end inter-domain TE LSP 💅 full mix-and-match energy. In that case it may be nice for the choice of each method to get reported along the path, maybe through the Record Route Object (RRO) 🦋
If there's a desire to restrict which methods get used, that has to be signaled the way the next section explains 🫶
2.5. Control of Downstream Choice of Signaling Method 💖
okay so even though the previous section sets the vibe, an ingress LSR might want to restrict the signaling methods applied to a particular LSP at domain boundaries across the network 👑 Such control, where it's needed, can be done by defining new flags in the SESSION-ATTRIBUTE object or the Attributes Flags TLV of the LSP_ATTRIBUTES object [RFC4420]. Before anyone builds a mechanism for this level of control, the functional requirement to control how the network delivers a service has to be established first 🧠 Also, due consideration must be given to interoperability, because new mechanisms must be backwards compatible 🥺 and care must be taken so that standards-conformant implementations don't each support a different functional subset in a way where they can't establish LSPs. that would be a whole disaster 😭
3. Path Computation Techniques 🧚
the path computation stuff in this document is pretty limited, lowkey on purpose 🌸 It only covers where computation may take place and which components of the full path may be determined.
The techniques used are closely tied to the signaling methodologies from the previous section, because certain computation techniques may require particular signaling approaches and vice versa 🔗
Whether a particular path computation technique is appropriate in any given circumstance is beyond the scope of this document. That kind of discussion should be described in a separate applicability statement 📝
Path computation algorithms are firmly out of the scope of this document. not me saying "firmly" 🙈
3.1. Management Configuration 🎀
Path computation may be performed by offline tools or by a network planner 🧮 The resultant path may be supplied to the ingress LSR as part of the TE LSP or service request, and then the ingress LSR encodes it as an Explicit Route Object (ERO) on the Path message that gets sent out 📨
There's no reason the path the operator gives you shouldn't span multiple domains, as long as the relevant information is available to the planner or the offline tool 🌈 What information is needed to do this, and how that information gets gathered, is outside the scope of this document 🤷♀️
3.2. Head-End Computation 🍓
The head-end, or ingress, LSR may take on responsibility for path computation when the operator supplies part or none of the explicit path 💅 Either way, the operator must supply at least the destination address (egress) of the LSP 🎯
3.2.1. Multi-Domain Visibility Computation 👑
If the ingress has enough visibility into the topology and TE information for all of the domains it'll route the LSP across to reach its destination, then it may compute and provide the entire path 🗺️ The quality of that path (aka its optimality, as discussed in section 3.5) can be better if the ingress has full visibility into all relevant domains, rather than just enough visibility to find some path to the destination 🔥
Extreme caution must be exercised when thinking about how the requisite TE information gets distributed. See section 4 💀
3.2.2. Partial Visibility Computation 🦋
It may be that the ingress doesn't have full visibility of the topology of all domains, but it does know how the domains are connected and what TE resources are available across them 🧩 In this case the ingress can't provide a fully specified strict explicit path from ingress to egress. However, the ingress might supply an explicit path that looks something like:
- explicit hops from ingress to the local domain boundary
- loose hops representing the domain entry points across the network
- a loose hop identifying the egress
Or the explicit path might be expressed as:
- explicit hops from ingress to the local domain boundary
- strict hops giving abstract nodes representing each domain in turn
- a loose hop identifying the egress
These two explicit path formats could be mixed depending on the information available, which gives you different combos of loose hops and abstract nodes 🌸
This form of explicit path relies on some further computation technique being applied at the domain boundaries. See section 3.3 ✨
Same as with the multi-domain visibility option, extreme caution must be exercised when thinking about how the requisite TE information gets distributed. See section 4 😭
3.2.3. Local Domain Visibility Computation 🌙
One last option for ingress-based computation is when the ingress LSR only has visibility within its own domain, plus connectivity info just far enough to figure out one or more domain exit points that might be suitable for carrying the LSP to its egress 🚪
In this case, the ingress builds an explicit path that comprises just:
- explicit hops from ingress to the local domain boundary
- a loose hop identifying the egress
3.3. Domain Boundary Computation 🧠
If the partial explicit path methods from sections 3.2.2 or 3.2.3 are applied, then the LSR at each domain boundary is responsible for making sure there's enough path information added to the Path message to carry it at least to the next domain boundary (aka out of the new domain) 🛤️
If the LSR at the domain boundary has full visibility to the egress, it can supply the entire explicit path. Note, however, that the ERO processing rules of [RFC3209] state that it should only update the ERO as far as the next specified hop (that is, the next domain boundary if one was supplied in the original ERO). And of course, it must not insert ERO subobjects immediately before a strict hop 🙅♀️
If the LSR at the domain boundary only has partial visibility (using the definitions from section 3.2.2), it'll fill in the path as far as the next domain boundary, and it'll supply further domain/domain boundary information if it isn't already in the ERO 💅
If the LSR at the domain boundary only has local visibility into the immediate domain, it'll just add info to the ERO to carry the Path message as far as the next domain boundary 📦
Domain boundary path computations are performed independently of each other. Domain boundary LSRs may have different computation capabilities, run different path computation algorithms, apply different sets of constraints and optimization criteria, and so forth. That can make the path segment quality unpredictable to the ingress LSR and totally out of its control 😵💫 One way to fix this is to enhance the information signaled during LSP setup so it includes a larger set of constraints and the paths of related LSPs (like diverse protected LSPs), as described in [GMPLS-E2E] 🫶
It's also the case that paths generated on domain boundaries may produce loops. Specifically, the computed paths may loop back into a domain that the LSP has already crossed. This may or may not be a problem, and it might even be desirable, but it could also give rise to real loops 🔁 This can be avoided by using the recorded route (RRO) to provide exclusions within the path computation algorithm. But if there's a lack of trust between domains, the RRO may need to indicate the previously visited domains. Even this solution isn't available where the RRO isn't available on a Path message 🥲 Note that when an RRO is used to provide exclusions, and a loop-free path is found to not be available by the computation at a downstream border node, crankback [CRANKBACK] may enable an upstream border node to select an alternate path 🔙
3.4. Path Computation Element 👩💻
The computation techniques in sections 3.2 and 3.3 rely on topology and TE information being distributed to the ingress LSR and the LSRs at domain boundaries. These LSRs are responsible for computing paths. There may be scaling concerns with distributing the required information, so see section 4 📊
An alternative technique puts the responsibility for path computation on a Path Computation Element (PCE) [RFC4655] 🧚 There may be a centralized PCE, or multiple PCEs (each with local visibility, collaborating in a distributed way to compute an end-to-end path) across the entire network and even within any one domain. The PCE may collect topology and TE information from the same sources the LSRs in the previous paragraph would use, or through other means 🌐
Each LSR called upon to do path computation (and even the offline management tools from section 3.1) may hand the task off to a PCE of its choice. The selection of PCE(s) may be driven by static configuration or by dynamic discovery 🔍
3.4.1. Multi-Domain Visibility Computation 🌈
A PCE may have full visibility, perhaps through connectivity to multiple domains. In this case, it's able to supply a full explicit path as in section 3.2.1 👑
3.4.2. Path Computation Use of PCE When Preserving Confidentiality 🤫
Here's the tea: although a centralized PCE or multiple collaborative PCEs may have full visibility into one or more domains, it may be desirable (e.g., to preserve topology confidentiality) that the full path not get handed to the ingress LSR. Instead, a partial path is supplied (as in section 3.2.2 or 3.2.3), and the LSRs at each domain boundary are required to make further requests for each successive segment of the path 🔐
This way, an end-to-end path can be computed using the full network capabilities, while confidentiality between domains is still preserved 💜 Optionally, the PCE(s) may compute the entire path at the first request and hold it in storage for subsequent requests. Or they may recompute each leg of the path on each request, or at regular intervals, until the LSRs establishing the LSP request it 🔄
It may be the case that the centralized PCE or the collaboration between PCEs defines a trust relationship greater than what's normally operational between domains 🤝
3.4.3. Per-Domain Computation Elements 🏡
A third way PCEs may be used is to simply have one (or more) per domain. Each LSR within a domain that wants to derive a path across the domain may consult its local PCE 🧚♀️
This mechanism could be used for all path computations within the domain, or it could be specifically limited to computations for LSPs that will leave the domain. In that case, external connectivity information can be restricted to just the PCE 🫧
3.5. Optimal Path Computation ✨
okay so "optimal" is a whole vibe 💅 because there are SO many definitions, and they depend on which constraints you slap onto the path computation. In a multi-domain setup it gets even messier, since an optimal route could mean "the route you'd get if domain boundaries didn't exist" 🙈 Or you could add a constraint that just tries to limit how many domains the LSP crosses. Choose your fighter, bestie 🥊
It's super easy to build examples showing that chopping a network into domains, and losing or aggregating routing info along the way, can lead to routes that aren't optimal 😭 Basically, it is impossible to guarantee optimal routing once routing info gets aggregated, abstracted, or summarized. No magic wand here 🪄
This doc is NOT going to define what an optimum path is for an inter-domain TE LSP 🙃 That debate has been handed off to requirements documents and applicability statements for specific deployment scenarios. Also, heads up: what a computation metric means can differ between domains (see section 5.6) 👀
4. Distributing Reachability and TE Information 🦋
Traffic Engineering information gets collected into a TE Database (TED) 📚, and path computation algorithms work on it either directly or after building a network graph.
The path computation techniques from the last section put some demands on how reachability info gets distributed, on the TE capabilities of nodes and links within domains, and on the TE connectivity across domains 🧠
Right now, TE info is distributed within domains by adding stuff to IGPs [RFC3630], [RFC3784].
When two domains are interconnected by one or more links (aka the domain boundary falls on a link instead of a node), there should be a mechanism to distribute the TE information associated with the inter-domain links to the corresponding domains. This would help path computation and cut down on TE-related crankbacks on these links 🙌
Where a domain is a subset of an IGP area, filtering of TE information may be applied at the domain boundary. This filtering may be one way or two way 🔀
Where info needs to reach a PCE that spans multiple domains, the PCE may snoop on the IGP traffic in each domain, or play an active part as an IGP-capable node in each domain. The PCE might also receive TED updates from a proxy within the domain 🧚
An LSR doing path computation (like an ingress LSR) might get the topology and TE info of not just its own domain, but other domains too 👀 That info may be subject to filtering by the advertising domain (for example, it might be limited to Forwarding Adjacencies (FAs) across other domains, or it might be aggregated or abstracted).
Before anyone starts work on protocols or protocol extensions for cross-domain reachability and TE advertisement in support of inter-domain TE, the requirements and benefits must be clearly established 🛑 This has not been done to date. Where any cross-domain reachability and TE info needs to be advertised, consideration must be given to TE extensions to existing protocols such as BGP, and to how the advertised info may be fed to the IGPs. It must be noted that any extensions that cause a significant increase in processing (such as aggregation computation) at domain boundaries, or a significant increase in the amount of info flooded (such as detailed TE info), need to be treated with extreme caution and compared carefully with the scaling requirements expressed in [RFC4105] and [RFC4216] 😬
5. Comments on Advanced Functions ✨
This section gives some non-definitive comments on the constraints that inter-domain MPLS places on advanced MPLS TE functions 💅 It does NOT try to state the implications of using one inter-domain technique or another. That material is deferred to appropriate applicability statements, where statements about what existing or future signaling, routing, and computation techniques can deliver for the listed functions should be made.
5.1. LSP Re-Optimization 🔄
Re-optimization is the process of moving a TE LSP from one path to another, more preferable path (no attempt is made in this document to define "preferable", since no attempt was made to define "optimal") 🙃 Make-before-break techniques are usually applied so traffic gets disrupted as little as possible 💖 The Shared Explicit style is usually used to avoid double booking of network resources.
Re-optimization may be available within a single domain. Alternatively, it may involve a change in route across several domains, or might involve a choice of different transit domains 🗺️
Re-optimization requires that all or part of the path of the LSP be re-computed. The techniques used may be selected as described in section 3, and this will influence whether the whole or part of the path is re-optimized.
The trigger for path computation and re-optimization may be an operator request, a timer, information about a change in availability of network resources, or a change in operational parameters (for example, bandwidth) of an LSP ⏰ This trigger must be applied to the point in the network that requests re-computation and controls re-optimization, and may require additional signaling.
Note also that where multiple mutually-diverse paths are applied end-to-end (i.e., not simply within protection domains; see section 5.5), the point of calculation for re-optimization (whether it is PCE, ingress, or domain entry point) needs to know all such paths before attempting re-optimization of any one path. Mutual diversity here means that a set of computed paths has no commonality. Such diversity might be link, node, Shared Risk Link Group (SRLG), or even domain disjointedness according to circumstances and the service being delivered 🧩
It may be the case that re-optimization is best achieved by recomputing the paths of multiple LSPs at once. Indeed, this can be shown to be most efficient when the paths of all LSPs are known, not simply those LSPs that originate at a particular ingress. While this problem is inherited from single domain re-optimization and is out of scope within this document, it should be noted that the problem grows in complexity when LSPs wholly within one domain affect the re-optimization path calculations performed in another domain 🌀
5.2. LSP Setup Failure 💔
When an inter-domain LSP setup fails in some domain other than the first, various options are available for reporting and retrying the LSP.
In the first instance, a retry may be attempted within the domain that contains the failure. That retry may be attempted by nodes wholly within the domain, or the failure may be referred back to the LSR at the domain boundary.
If the failure cannot be bypassed within the domain where the failure occurred (perhaps there is no suitable alternate route, perhaps rerouting is not allowed by domain policy, or perhaps the Path message specifically bans such action), the error must be reported back to the previous or head-end domain 🚨
Subsequent repair attempts may be made by domains further upstream, but will only be properly effective if sufficient information about the failure and other failed repair attempts is also passed back upstream [CRANKBACK]. Note that there is a tension between this requirement and that of topology confidentiality, although crankback aggregation may be applicable at domain boundaries 🫣
Further attempts to signal the failed LSP may apply the information about the failures as constraints to path computation, or may signal them as specific path exclusions [EXCLUDE].
When requested by signaling, the failure may also be systematically reported to the head-end LSR.
5.3. LSP Repair 🛠️
An LSP that fails after it has been established may be repaired dynamically by re-routing. The behavior in this case is either like that for re-optimization, or like that for handling setup failures (see previous two sections). Fast Reroute may also be used (see below).
5.4. Fast Reroute ⚡
MPLS Traffic Engineering Fast Reroute ([RFC4090]) defines local protection schemes intended to provide fast recovery (in 10s of msecs) of fast-reroutable packet-based TE LSPs upon link/SRLG/Node failure. A backup TE LSP is configured and signaled at each hop, and activated upon detecting or being informed of a network element failure. The node immediately upstream of the failure (called the PLR, or Point of Local Repair) reroutes the set of protected TE LSPs onto the appropriate backup tunnel(s) and around the failed resource.
In the context of inter-domain TE, there are several different failure scenarios that must be analyzed. Provision of suitable solutions may be further complicated by the fact that [RFC4090] specifies two distinct modes of operation, referred to as the "one to one mode" and the "facility back-up mode" 🧐
The failure scenarios specific to inter-domain TE are as follows:
- Failure of a domain edge node that is present in both domains. There are two sub-cases:
- The Point of Local Repair (PLR) and the Merge Point (MP) are in the same domain.
- The PLR and the MP are in different domains.
- Failure of a domain edge node that is only present in one of the domains.
- Failure of an inter-domain link.
Although it may be possible to apply the same techniques for Fast Reroute (FRR) to the different methods of signaling inter-domain LSPs described in section 2, the results of protection may be different when it is the boundary nodes that need to be protected, and when they are the ingress and egress of a hierarchical LSP or stitched LSP segment. In particular, the choice of PLR and MP may be different, and the length of the protection path may be greater. These uses of FRR techniques should be explained further in applicability statements or, in the case of a change in base behavior, in implementation guidelines specific to the signaling techniques 📝
Note that after local repair has been performed, it may be desirable to re-optimize the LSP (see section 5.1). If the point of re-optimization (for example, the ingress LSR) lies in a different domain to the failure, it may rely on the delivery of a PathErr or Notify message to inform it of the local repair event 📬
It is important to note that Fast Reroute techniques are only applicable to packet switching networks, because other network technologies cannot apply label stacking within the same switching type. Segment protection [GMPLS-SEG] provides a suitable alternative that is applicable to packet and non-packet networks 🦋
5.5. Comments on Path Diversity 💅
Okay so, diverse paths might be needed for load sharing and/or protection 🫶. Those paths might have to be node diverse, link diverse, fully path diverse (meaning link AND node diverse), or SRLG diverse 🦋.
Diverse path computation is a classic problem, the kind every graph theory major has suffered through 😭. It gets messier when there's "private knowledge" going around, like when domains don't share topology information 💀. The problem can be solved more efficiently (e.g., avoiding the "trap problem") when mutually resource disjoint paths can be computed "simultaneously" on the fullest set of information ✨.
That being said, there are various techniques (out of the scope of this document) that exist to ensure end-to-end path diversity across multiple domains 🌈.
Lots of network technologies use "protection domains" because they fit really well with what the tech can do, so a bunch of domains end up operated as protection domains. In this model, protection paths converge at domain boundaries 🎀.
Note that the question of SRLG identification is not yet fully answered 🙈. There are two classes of SRLG:
- those that indicate resources that are all contained within one domain
- those that span domains
The first kind might be identified using a combo of a globally scoped domain ID and an SRLG ID that the domain administers 🍓. The second kind needs a global scope for the SRLG ID. So both schemes need external administration 🫠. The first one can leverage existing domain ID administration (for example, area and AS numbers), but the second would need a brand new administrative policy 👀.
5.6. Domain-Specific Constraints 🌸
So bandwidth is pretty chill and can be assumed to mean the same thing across different domains 💜. But other TE constraints (like resource affinity, color, metric, priority, etc.) might mean different things in different domains, and that can affect the ability to support Diffserv-aware MPLS or to manage preemption 😤.
To get consistent meaning and LSP establishment, this fact has to be considered when doing constraint-based path computation or when signaling across domain boundaries ✨.
A mapping function can be derived for most constraints based on policy agreements between the domain administrators 🤝. The details of that mapping function are outside the scope of this document, but it's really important to note that the default behavior must either be that a constant mapping is applied, or that any requirement to apply these constraints across a domain boundary must fail in the absence of explicit mapping rules 🚫.
5.7. Policy Control 🧚
Domain boundaries are natural points for policy control, and honestly there's not a ton to add here 💅. Just note that a TE LSP that can't be established on a path through one domain because of a policy applied at the domain boundary may be totally fine using a path that avoids the demurring domain 🦋. Either way, when a TE LSP signaling attempt gets rejected because it doesn't comply with some policy constraint, this should be reflected back to the ingress LSR 📣.
5.8. Inter-Domain Operations and Management (OAM) 🔧
Some OAM stuff may be intentionally confined within a domain 🏠. Others (like end-to-end liveness and connectivity testing) clearly need to span the entire multi-domain TE LSP 🌍. When topology confidentiality is a big deal, collaboration between PCEs or domain boundary nodes might be required to provide end-to-end OAM. A significant issue to sort out is making sure the end-points support the various OAM capabilities 🥺.
The different signaling mechanisms described above may need refinements to [RFC4379], [BFD-MPLS], etc., to get full end-to-end visibility ✨. These protocols should, however, be considered in light of topology confidentiality requirements 🔒.
Route recording is a commonly used signaling feature that gives OAM info about the path of an established LSP 🗺️. When an LSP crosses a domain boundary, the border node may remove or aggregate some of that recorded info for topology confidentiality or other policy reasons 🫣.
5.9. Point-to-Multipoint 🌷
Inter-domain point-to-multipoint (P2MP) requirements are explicitly out of scope for this document 🙅. They may be covered by other documents, depending on the details of MPLS TE P2MP solutions 📚.
5.10. Applicability to Non-Packet Technologies 📡
Non-packet switching technologies can present particular issues for inter-domain LSPs 😬. Packet switching networks may use control planes built on MPLS or GMPLS, but non-packet networks are limited to GMPLS 💫.
On the other hand, some problems, like Fast Reroute on domain boundaries (see section 5.4), may be handled by the GMPLS technique of segment protection [GMPLS-SEG], which works for both packet and non-packet switching technologies 🙌.
The specific architectural considerations and requirements for inter-domain LSP setup in non-packet networks are covered in a separate document [GMPLS-AS] 📖.
6. Security Considerations 🔐
Requirements for security within domains are unchanged from [RFC3209] and [RFC3473], and from [RFC3630] and [RFC3784]. So basically, all the security procedures for existing protocols in the MPLS context keep applying for intra-domain cases 🛡️.
Inter-domain security may be considered a more important and more sensitive issue than intra-domain security 😱, since in inter-domain traffic engineering, control and information may be passed across administrative boundaries. The most obvious and most sensitive case is inter-AS TE 🚨.
All of the intra-domain security measures for the signaling and routing protocols are equally applicable in the inter-domain case 🔑. There is, however, a greater likelihood of them being applied in the inter-domain case 💅.
Security for inter-domain MPLS TE is the subject of a separate document that analyzes the security deployment models and risks 📝. That separate document must be completed before inter-domain MPLS TE solution documents can be advanced 🚧.
Similarly, the PCE procedures [RFC4655] are subject to security measures for the exchange of computation information between PCEs, and for LSRs that request path computations from a PCE. The requirements for this security (set out in [RFC4657]) apply whether the LSR and PCE (or the cooperating PCEs) are in the same domain or lie across domain boundaries 🫶.
It should be noted, however, that techniques used for (for example) authentication require coordination of secrets, keys, or passwords between sender and receiver 🚨. Where sender and receiver lie within a single administrative domain, this process may be simple. But where they lie in different administrative domains, cross-domain coordination between network administrators will be required in order to provide adequate security. At this stage, it is not proposed that this coordination be provided through an automatic process or through the use of a protocol. Human-to-human coordination is more likely to provide the required level of confidence in inter-domain security 🤝.
One new security concept is introduced by inter-domain MPLS TE 🌟. This is the preservation of confidentiality of topology information. That is, one domain may wish to keep secret the way its network is constructed and the availability (or otherwise) of end-to-end network resources 🕵️♀️. This issue is discussed in sections 3.4.2, 5.2, and 5.8 of this document. When there's a requirement to preserve inter-domain topology confidentiality, policy filters must be applied at the domain boundaries to avoid distributing such information 🛑. This is the responsibility of the domain that distributes the information, and it may be adequately addressed by aggregating information as described in the referenced sections 💖.
Applicability statements for particular combinations of signaling, routing, and path computation techniques that provide inter-domain MPLS TE solutions are expected to contain detailed security sections 📋.
7. Acknowledgements 🎀
The authors would like to extend their warmest thanks to Kireeti Kompella for convincing them to expend effort on this document 🥰.
Grateful thanks to Dimitri Papadimitriou, Tomohiro Otani, and Igor Bryskin for their review and suggestions on the text 🙏.
Thanks to Jari Arkko, Gonzalo Camarillo, Brian Carpenter, Lisa Dusseault, Sam Hartman, Russ Housley, and Dan Romascanu for the final review of the text 👑.
8. Normative References 📚
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031,
January 2001.
[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.
[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.9. Informative References ✨
Okay bestie, this is the reading list 📚💅 These are the docs the spec leans on for background, not the ones it's strictly built on. Every single entry is here with all its details, no cap 🫶
- [BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", Work in Progress, June 2006.
- [CRANKBACK] Farrel, A., et al., "Crankback Signaling Extensions for MPLS Signaling", Work in Progress, May 2005.
- [EXCLUDE] Lee, CY., Farrel, A., and DeCnodder, "Exclude Routes - Extension to RSVP-TE", Work in Progress, August 2005.
- [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. 🦋
- [GMPLS-AS] Otani, T., Kumaki, K., Okamoto, S., and W. Imajuku, "GMPLS Inter-domain Traffic Engineering Requirements", Work in Progress, August 2006.
- [GMPLS-E2E] Lang, J.P., Rekhter, Y., and D. Papadimitriou, Editors, "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery", Work in Progress, April 2005.
- [GMPLS-SEG] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Based Segment Recovery", Work in Progress, May 2005.
- [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 🌸
- [RFC4105] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
- [RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204, October 2005.
- [RFC4216] Zhang, R. and J.-P. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
- [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 🔥
- [RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J.-P., and A. Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006.
- [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. 👑
- [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
- [STITCH] Ayyangar, A. and J.-P. Vasseur, "LSP Stitching with Generalized MPLS TE", Work in Progress, September 2005.
Authors' Addresses 🎀
Meet the squad who wrote this thing 🧚 Here's how to reach each of them:
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk
Jean-Philippe Vasseur
Cisco Systems, Inc
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
EMail: jpv@cisco.com
Arthi Ayyangar
Nuova Systems
EMail: arthi@nuovasystems.comFull Copyright Statement 💜
Copyright (C) The IETF Trust (2006).
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 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.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. ✨
📦 where this page comes from
- ietf: rfc4726 2006-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms