RFC 5298
Analysis of Inter-Domain Label Switched Path (LSP) Recovery
RFC 5298: Analysis of Inter-Domain Label Switched Path (LSP) Recovery 💖
Okay bestie, let's talk about RFC 5298 🦋. It's an Informational doc from the Network Working Group, published in August 2008, so it's not a standard, just really good info for the Internet community. The editors are T. Takeda (NTT) and A. Farrel (Old Dog Consulting), with Y. Ikejiri (NTT Communications) and JP. Vasseur (Cisco Systems, Inc.) as co-authors. The header doesn't list any Obsoletes or Updates, so it's not replacing or changing anything else. Its title is giving "Analysis of Inter-Domain Label Switched Path (LSP) Recovery" and honestly it's iconic 👑
Network Working Group T. Takeda, Ed.
Request for Comments: 5298 NTT
Category: Informational A. Farrel, Ed.
Old Dog Consulting
Y. Ikejiri
NTT Communications
JP. Vasseur
Cisco Systems, Inc.
August 2008Status of This Memo ✨
Okay so this memo is only here to share information with the Internet community 🌸 It's not an Internet standard of any kind, so don't go treating it like one. Distribution is unlimited, which means share it with everyone you know 💅
Abstract 🧚
Protection and recovery are a huge deal in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks, because they're what makes services feel reliable ✨ And these networks are slowly leveling up from single-domain scope to multi-domain environments, which is giving big main character energy 👑
There are already a bunch of schemes and processes for setting up Label Switched Paths (LSPs) across multiple domains. The big overview of those lives in RFC 4726: "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering" 📚
This document analyzes how those techniques apply to protection and recovery across multi-domain networks 🔍 The main focus is on setting up end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks, and yes, it's the part that's lowkey the most interesting 🦋
Table of Contents 🎀
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Domain .....................................................4
1.3. Document Scope .............................................5
1.4. Note on Other Recovery Techniques ..........................6
1.5. Signaling Options ..........................................6
2. Diversity in Multi-Domain Networks ..............................6
2.1. Multi-Domain Network Topology ..............................7
2.2. Note on Domain Diversity ...................................8
3. Factors to Consider .............................................9
3.1. Scalability versus Optimality ..............................9
3.2. Key Concepts ..............................................10
4. Diverse LSP Setup Schemes without Confidentiality ..............12
4.1. Management Configuration ..................................12
4.2. Head-End Path Computation (with Multi-Domain Visibility) ..12
4.3. Per-Domain Path Computation ...............................12
4.3.1. Sequential Path Computation ........................13
4.3.2. Simultaneous Path Computation ......................14
4.4. Inter-Domain Collaborative Path Computation ...............15
4.4.1. Sequential Path Computation ........................15
4.4.2. Simultaneous Path Computation ......................15
5. Diverse LSP Setup Schemes with Confidentiality .................16
5.1. Management Configuration ..................................17
5.2. Head-End Path Computation (with Multi-Domain Visibility) ..17
5.3. Per-Domain Path Computation ...............................17
5.3.1. Sequential Path Computation ........................18
5.3.2. Simultaneous Path Computation ......................19
5.4. Inter-Domain Collaborative Path Computation ...............20
5.4.1. Sequential Path Computation ........................20
5.4.2. Simultaneous Path Computation ......................20
6. Network Topology Specific Considerations .......................20
7. Addressing Considerations ......................................21
8. Note on SRLG Diversity .........................................21
9. Security Considerations ........................................21
10. References ....................................................22
10.1. Normative References .....................................22
10.2. Informative References ...................................22
11. Acknowledgements ..............................................251. Introduction ✨
Protection and recovery in MPLS and GMPLS networks are covered in [RFC4428]. They're a really big deal for delivering services on these networks 💖
MPLS and GMPLS networks started out limited to single-domain environments, but now people are looking at multi-domain MPLS and GMPLS networks too 🌈 Here, a domain is any collection of network elements that sit within a common sphere of address management or path computational responsibility. Examples include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes) 🧠
[RFC4726] gives a framework for inter-domain MPLS and GMPLS traffic engineering. It brings in the various schemes and processes for setting up Label Switched Paths (LSPs) across multi-domain environments 🦋
Okay but here's the tea 🫖 Protection and recovery add extra complexity to LSP establishment. Protection LSPs generally need to be path diverse from the working LSPs they protect. That's the hard part in multi-domain environments, because no single path computation or planning point can work out path diversity for both paths from one end to the other 😭
This document analyzes various schemes for realizing MPLS and GMPLS LSP recovery in multi-domain networks. The main focus is on setting up end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks 💅
1.1. Terminology 📖
The reader is assumed to already know the terminology for LSP recovery from [RFC4427], plus the terms introduced in [RFC4726], which provides a framework for inter-domain Label Switched Path (LSP) setup. Key terminology may also be found in [RFC4216], which sets out requirements for inter-AS MPLS traffic engineering 🎀
These key terms from those sources get used in this document:
- Domain: See [RFC4726]. A domain is any collection of network elements within a common sphere of address management or path computational responsibility. Nested domains are still out of scope, so don't go there 🙈 Section 1.2 has more details.
- Working LSP: See [RFC4427]. The working LSP carries normal user traffic. The term LSP and TE LSP get used interchangeably here, so don't be confused when you see both ✨
- Recovery LSP: See [RFC4427]. The recovery LSP carries normal user traffic when the working LSP fails. It can also carry user traffic even while the working LSP is working fine and carrying the traffic (for example, 1+1 protection). It's sometimes called a protecting LSP 🛡️
- Diversity: See [RFC4726]. Diversity is the relationship between multiple LSPs where they don't share some specific type of resource, like a link, a node, or a shared risk link group (SRLG). It's also called disjointness 🦋
Diverse LSPs can be used for different things, like load-balancing and recovery. In this document, we're focused on the recovery side of diversity, specifically the end-to-end diversity of two traffic engineering (TE) LSPs 💜 The two diverse LSPs are called the working LSP and the recovery LSP.
- Confidentiality: See [RFC4216]. Confidentiality means protecting information about one domain's topology and resources from being seen by people or applications outside that domain 🔒
1.2. Domain 🌍
To really get the issues this document covers, we have to define and scope the term "domain" carefully 🧐
As [RFC4726] defines it, a domain is any collection of network elements within a common sphere of address management or path computational responsibility. Examples include IGP areas and Autonomous Systems. Networks accessed over the GMPLS User-to-Network Interface (UNI) [RFC4208] and Layer One Virtual Private Networks (L1VPNs) [RFC4847] are special cases of multi-domain networks 🌸
People use more than one domain for reasons like administrative separation, scalability, and building domains to provide protection. These latter "protection domains" offer edge-to-edge protection facilities for spans or segments of end-to-end LSPs 🛡️
As described in [RFC4726], there could be TE parameters (such as color and priority) whose meanings are specific to each domain. So if you're setting up inter-domain LSPs, you might need mapping functions to transform those TE parameters, based on policy agreements between domain administrators 🤝
1.3. Document Scope 🎯
This document analyzes various schemes for realizing MPLS and GMPLS LSP recovery in multi-domain networks. It's based on the existing framework for multi-domain LSP setup [RFC4726]. This document doesn't stop anyone from developing additional techniques where appropriate (in addition to the ones described here). In other words, this document shows how the existing techniques can be applied 🦋
There are various recovery techniques for LSPs. For TE LSPs, the major ones are end-to-end recovery [RFC4872], local protection such as Fast Reroute (FRR) [RFC4090] (in packet switching environments), and segment recovery [RFC4873] (in GMPLS) ✨
The main focus of this document is analyzing diverse TE LSP setup schemes that can be used for end-to-end recovery. The method is to show different combinations of functional elements, like path computation and signaling techniques 💅
[RFC4105] and [RFC4216] describe requirements for diverse LSPs. There are various types of diversity, and this document focuses on node, link, and shared risk link group (SRLG) diversity 🌈
Recovery LSPs may be used for 1+1 protection, 1:1 protection, or shared mesh restoration. However, the requirements for path diversity, the ways to compute diverse paths, and the signaling of these TE LSPs are common across all uses. These topics are the main scope of this document 🫶
Diverse LSPs can also be used for other purposes besides recovery. One example is load-balancing, which limits the traffic disruption to a portion of the traffic flow if there's a single node failure. This document doesn't rule out using diverse LSP setup schemes for those other purposes 💖
The following are beyond the scope of this document:
- Analysis of recovery techniques other than the use of link, node, or SRLG diverse LSPs (see Section 1.4). 🙅♀️
- Details of maintenance of diverse LSPs, such as re-optimization and Operations and Maintenance (OAM). 🛠️
- Comparative evaluation of LSP setup schemes. ⚖️
1.4. Note on Other Recovery Techniques
okay so Fast Reroute and segment recovery in multi-domain networks get covered in Section 5.4 of [RFC4726] 🌸, and there's a deeper dive in Section 5 of [RFC5151] 📚. this doc does NOT go any further on Fast Reroute and segment recovery in multi-domain networks, so no spoilers here, bestie 🙈
the recovery type of an LSP or service can change at a domain boundary 🦋 like, it could stay the same inside one domain but be totally different in the next domain, or on the links between domains. that can happen because of what each domain is capable of, admin policies, or topology limits, and it's giving "every domain doing its own thing" 💅 for example, protection at the domain boundary could be link protection on the inter-domain links, while protection inside each domain is done with segment recovery. this mix of protection techniques is beyond the scope of this document ✨
domain diversity (that's picking paths that only have the ingress and egress domains in common) can be seen as one form of diversity in multi-domain networks 🧚, but it's out of scope here (see Section 2.2) 💜
1.5. Signaling Options
there are three signaling options for setting up inter-domain TE LSPs: nesting, contiguous LSPs, and stitching [RFC4726] 🎀 the way this document describes diverse LSP setup is agnostic about which signaling option you use, unless it says otherwise ✨
also, signaling option considerations for Fast Reroute and segment recovery are in [RFC5151] 🔥
2. Diversity in Multi-Domain Networks ✨
this section lays out some assumptions about getting path diversity in multi-domain networks 🫶
2.1. Multi-Domain Network Topology
Figures 1 and 2 show examples of multi-domain network topologies 🗺️ In Figure 1, domains are connected in a linear topology 🍓 There are multiple paths between nodes A and L, but all of them cross domain#1-domain#2-domain#3 in that order, no exceptions 😭
+--Domain#1--+ +--Domain#2--+ +--Domain#3--+
| | | | | |
| B------+---+---D-----E--+---+------J |
| / | | \ / | | \ |
| / | | \ / | | \ |
| A | | H | | L |
| \ | | / \ | | / |
| \ | | / \ | | / |
| C------+---+---F-----G--+---+------K |
| | | | | |
+------------+ +------------+ +------------+Figure 1: Linear Domain Connectivity
+-----Domain#2-----+
| |
| E--------------F |
| | | |
| | | |
+-+--------------+-+
| |
| |
+--Domain#1-+--+ +-------+------+
| | | | | |
| | | | | |
| A----B--+---+--C----D |
| | | | | |
| | | | | |
+------+-------+ +--+-Domain#4--+
| |
+-+--------------+-+
| | | |
| | | |
| G--------------H |
| |
+-----Domain#3-----+Figure 2: Meshed Domain Connectivity
In Figure 2, domains are connected in a mesh topology 🕸️ There are multiple paths between nodes A and D, and these paths do not cross the same domains (main character energy for sure 👑). If inter-domain connectivity forms a mesh, domain-level routing is required (even for the unprotected case) 💀 This is tightly coupled with the next-hop domain resolution/discovery mechanisms used in IP networks 🧩
in this document, we assume that domain-level routing is given via configuration, policy, or some external mechanism 🎀 and that this isn't part of the path computation process we talk about later in this document ✨
domain-level routing can also allow "domain re-entry", where a path re-enters a domain it already exited (e.g., domain#X-domain#Y-domain#X) 🌀 this needs special handling when confidentiality (described in Section 3.2) is required, and it's beyond the scope of this document 🙈
also, the working LSP and the recovery LSP may or may not go through the same set of domains in the same order 👀 in this document, we assume they DO follow the same set of domains in the same order (via configuration, policy or some external mechanism) 💅 so basically, we assume the domain mesh topology gets reduced to a linear domain topology for each pair of working and recovery LSPs 🦋
in summary,
- there's no assumption about the multi-domain network topology ✨ for example, there could be more than two domain boundary nodes or inter-domain links (links connecting a pair of domain boundary nodes that belong to different domains) 🌈
- in a multi-domain topology, it's assumed that the sequence of domains that the working LSP and the recovery LSP follow must be the same and is pre-configured 🔒
- domain re-entry is out of scope and isn't considered further 🚫
2.2. Note on Domain Diversity
as Section 1.4 described, domain diversity means picking paths that only have the ingress and egress domains in common 💖 this can give you enhanced resilience against failures, and it's a way to make sure the path is diverse for most of the LSP 🫧
in Section 2.1, we assumed the working LSP and the recovery LSP follow the same set of domains in the same order 🥺 under that assumption, domain diversity can't be achieved 😭 BUT (iykyk) by relaxing that assumption, domain diversity could be achieved, e.g., by either of the following schemes ✨
- consider domain diversity as a special case of SRLG diversity (i.e., assign an SRLG ID to each domain) 🎯
- configure domain-level routing to provide domain-diverse paths (e.g., by means of AS_PATH in BGP) 🌸
further details of how domain diversity works are beyond the scope of this document 💜
3. Factors to Consider ✨
3.1. Scalability versus Optimality
as [RFC4726] points out, scalability and optimality are two conflicting objectives 🥀 the meaning of optimality changes depending on each network operation, which is very much a vibe 🌈 some examples of optimality in the context of diverse LSPs are:
- minimizing the sum of their cost while maintaining diversity 💰
- restricting the difference of their costs (for example, so as to minimize the delay difference after switch-over) while maintaining diversity ⏱️
by restricting TE information distribution to only within each domain (and not across domain boundaries), as required by [RFC4105] and [RFC4216], it may not be possible to compute an optimal path. as such, it might not be possible to compute diverse paths, even if they exist 😭
BUT (and this is the good part 🎉) if we assume domain-level routing is given (as discussed in Section 2), it would be possible to compute diverse paths using specific computation schemes, if such paths exist ✨ this is discussed further in Section 4 🦋
3.2. Key Concepts
three key concepts for classifying the different diverse LSP computation and setup schemes are presented below 🧠
- with or without confidentiality
- without confidentiality
it's possible to specify a path across multiple domains in signaling (using the Resource Reservation Protocol-TE (RSVP-TE) Explicit Route Object (ERO)) and to get a record of the inter-domain path used (using the RSVP-TE Record Route Object (RRO)) 📝 in this case it's clear that one domain controls the path followed in another domain, and the path actually used in one domain is visible from inside another domain 👀
examples of this configuration are multi-area networks and some forms of multi-AS networks (especially within the same provider) 🏠 in these cases, there's no requirement for confidentiality 🫶
- with confidentiality
when confidentiality of domain topology and operational policy is required, it's not possible to specify or obtain a full path across other domains 🔐 partial paths may be specified and reported using domain identifiers or the addresses of domain border routers in the EROs and RROs 🧩
examples of this configuration are some forms of multi-AS networks (especially inter-provider networks), GMPLS-UNI networks, and L1VPNs 🌐
- multi-domain path computation, per-domain path computation, and inter-domain collaborative path computation
- multi-domain path computation
if a single network element can see the topology of all domains along the path, it's able to compute a full end-to-end path 🗺️ obviously, this only works where confidentiality isn't required 💅
such a network element might be the head-end Label Switching Router (LSR), a Path Computation Element (PCE) [RFC4655], or a Network Management System (NMS) 🧚 this mode of path computation is discussed in Sections 4 and 5 ✨
- per-domain path computation
the path of an LSP may be computed domain-by-domain as LSP signaling progresses through the network 🚂 this scheme requires ERO expansion in each domain to build the next segment of the path toward the destination 🛤️ setting up unprotected LSPs this way is covered in [RFC5152] 🎀
- inter-domain collaborative path computation
in this scheme, path computation is typically done before signaling and uses communication between cooperating PCEs 🤝 an example of such a scheme is Backward Recursive Path Computation (BRPC) [BRPC] 💜
it's possible to combine multiple path computation techniques (including using a different technique for the working and recovery LSPs), but the details are beyond the scope of this document 🌈
- sequential path computation or simultaneous path computation
- sequential path computation
the path of the working LSP is computed without considering the recovery LSP, and then the path of the recovery LSP is computed 🔁 this scheme is applicable when the recovery LSP is added later as a change to the service grade, but it may also be used when both the working and recovery LSPs are set up from the start 🌱
with this approach, it may not be possible to find diverse paths for the LSPs in "trap" topologies 🪤 furthermore, sequential path computation approaches reduce the likelihood of selecting an "optimal" solution with regards to a specific objective function 📉
- simultaneous path computation
the path of the working LSP and the path of the recovery LSP are computed simultaneously 🙌 in this scheme, it's possible to avoid trap conditions, and it may be more possible to achieve an optimal result 🏆
note that LSP setup, with or without confidentiality, depends on per-domain configuration 🛠️ the choice between per-domain path computation and inter-domain collaborative path computation, and the choice between sequential path computation and simultaneous path computation, can be determined for each individual pair of working/recovery LSPs 💖
the analysis of the various diverse LSP setup schemes is described in Sections 4 and 5, based on the concepts set out above 📖
some other considerations, such as network topology-specific considerations, addressing considerations, and SRLG diversity, are described in Sections 6, 7, and 8 🌟
4. Diverse LSP Setup Schemes without Confidentiality ✨
okay so this section looks at ways to set up diverse LSPs using different path computation techniques, and it assumes there's no need for domain confidentiality 🫶 Section 5 does the same kind of look-through for the schemes where confidentiality is required, so you've got that to look forward to 💅
4.1. Management Configuration 🎀
[RFC4726] describes this technique, where a management application at the head-end specifies the full explicit paths for the working and recovery LSPs. Nothing else needs computing or signaling, so it's giving very simple energy 🌸
4.2. Head-End Path Computation (with Multi-Domain Visibility) 🦋
Section 3.2.1 [RFC4726] describes this one. The full explicit paths for the working and recovery LSPs get computed at the head-end, either by the head-end itself or by a PCE. Either way, the computing entity has full TE visibility across multiple domains, and no further computation or signaling is needed. Main character energy for sure 👑
4.3. Per-Domain Path Computation 🧚
Sections 3.2.2, 3.2.3, and 3.3 of [RFC4726] describe this technique, and [RFC5152] has the more detailed procedures 💜
In this scheme, the explicit paths of the working and recovery LSPs are written as complete strict paths through the source domain, followed by one of these:
- The complete list of boundary LSRs or domain identifiers (e.g., AS numbers) along the paths.
- The LSP destination.
So to get through each domain, the path has to be expanded at every domain boundary, which is why it's called per-domain 🍓 That computation gets done by the boundary LSR, or by a PCE acting on its behalf.
There are two schemes for setting up diverse LSPs with per-domain computation, and they're covered in Sections 4.3.1 and 4.3.2 ✨
4.3.1. Sequential Path Computation 🌈
As mentioned before, the big issue with sequential path computation is that diverse paths can't be guaranteed 😭 When per-domain computation is in use, the computation of the second path needs to know about the path the first one used, so that diversity can even be attempted.
The RSVP-TE EXCLUDE_ROUTE Object (XRO) [RFC4874] can be used when the second path is signaled, to report the details of the first path. Also, the PRIMARY_PATH_ROUTE Object defined in [RFC4872] is meant for end-to-end protection, not path exclusion, so it should not be used for this purpose 🙅♀️
The process for sequential path computation goes like this:
- The working LSP is set up using per-domain path computation, as described in [RFC5152]. Since domain confidentiality isn't required, the path of the working LSP is available at the head-end through the RSVP-TE RRO.
- The path of the recovery LSP across the first domain is computed while excluding the resources the working LSP uses within that domain. If a PCE is involved, the resources to avoid can be passed to it using the Exclude Route Object (XRO) extensions to the PCE Protocol [PCEP-XRO], [PCEP].
- The recovery LSP is then signaled across the first domain as usual, but the working LSP's path also gets sent along in an RSVP-TE XRO. This XRO lists the nodes, links, and SRLGs the LSP being signaled must avoid, and its contents are copied from the working LSP's RRO.
- At each later domain boundary, a segment of the recovery LSP's path can be computed across the new domain, excluding the resources listed in the RSVP-TE XRO.
Honestly, this scheme can't guarantee diverse LSPs even when they could exist, because the working LSP gets set up without thinking about the diverse recovery LSP it needs 💀 If the recovery LSP's setup is blocked, or some resources turn out to be shared, the working LSP's path can be changed using the crankback techniques in [RFC4920].
Also, even when a solution is found, it might not be maximally optimal. The set of diverse TE LSPs may be a bit meh 🙈
4.3.2. Simultaneous Path Computation 💖
Simultaneous path computation gives a much better shot at finding a pair of diverse paths, because the diversity requirement is part of the computation itself. With per-domain mechanisms there are a few things to think about 🤍
Simultaneous path computation means the paths for the working and recovery LSPs are computed at the same time. Since we're talking per-domain, both paths have to be computed at each domain boundary 🫧
The process goes like this:
- The ingress LSR (or a PCE) computes a pair of diverse paths across the first domain. If a PCE is used, PCEP lets you request disjoint paths ✨
- The working LSP is signaled across the first domain as usual, but it also has to carry the requirement for a disjoint recovery LSP, plus the info about the recovery LSP's path already computed across the first domain. In particular, the domain boundary node used by the recovery LSP has to be reported 📍
- Each domain boundary router, in turn, computes a pair of disjoint paths across the next domain. The working LSP is signaled as usual, and the computed recovery LSP path gets collected in the signaling messages 🦋
- Once the working LSP is set up, the full path of the recovery LSP is sent back to the head-end LSR in the signaling messages for the working LSP. That lets the head-end signal the recovery LSP using a full path, with no more path computation needed 👑
Now, the signaling protocol mechanisms to collect the recovery LSP's path during the working LSP's signaling don't exist yet 🙃 Defining those protocol mechanisms is out of scope for this document, but it's believed they would be simple to define and implement.
Heads up: this mechanism still can't guarantee finding diverse paths even when they exist. When domains are interconnected in multiple ways, the end-to-end diverse paths might depend on picking the right inter-domain links. Crankback [RFC4920] can also be combined with this scheme to improve the odds 🥺
Again, even when a solution is found, it might not be maximal in optimality (the set of diverse TE LSPs) 💅
4.4. Inter-Domain Collaborative Path Computation 🤝
Collaborative path computation needs the PCEs responsible for different domains to cooperate. This approach is described in Section 3.4 of [RFC4726]. Backward recursive path computation (BRPC) [BRPC] is a collaborative technique where the paths of the LSPs are completely figured out through PCE-to-PCE communication before the LSPs are set up. Two ways to use BRPC for diverse LSPs are covered in the next sections 🌸
4.4.1. Sequential Path Computation 🧩
With sequential path computation, the working LSP's path is computed using BRPC as described in [BRPC]. The recovery LSP's path is then computed, also using BRPC, with the extra detail that the working LSP's path is explicitly excluded using the XRO route exclusion techniques from [PCEP-XRO].
In this case, the working LSP could be set up either before or after the recovery LSP's path gets computed. If it's after, the actual working LSP path reported in the RSVP-TE RRO should be used when computing the recovery LSP's path 🎀
This scheme can't guarantee diverse LSPs (even when they exist), because the working LSP might block the recovery LSP. If that happens, re-optimizing the working and recovery LSPs may be used to get fully diverse paths 💫
4.4.2. Simultaneous Path Computation 🦄
With simultaneous path computation, the PCEs work together to compute the paths for both the working and the recovery LSPs at the same time. Both LSPs are computed in a single pass, so they can be signaled simultaneously or sequentially, depending on what the head-end LSR prefers 🔥
Collaborative simultaneous path computation is done using the Synchronization Vector (SVEC) object in the PCE Protocol [PCEP]. This object lets two computation requests get associated and made dependent on each other ✨ Coordinating several computation requests inside the BRPC mechanism isn't described in [BRPC]. It's believed that procedures for that coordination could be specified, but developing new procedures is outside the scope of this document 🙈
This scheme can guarantee diverse LSPs wherever they're possible, assuming domain-level routing is predetermined as described in Section 2. On top of that, the computed set of TE LSPs can be guaranteed to be optimal with respect to some objective functions. Iconic. 👑💅
5. Diverse LSP Setup Schemes with Confidentiality ✨
okay so in this section, confidentiality means keeping the topology and resources inside one domain hidden from people and applications outside that domain 🫣 That includes things like recording LSP routes and advertising TE info. It does NOT cover user traffic, which is a totally different thing 💅
Diverse LSP setup schemes with confidentiality are basically the same as the ones without it, but you need some extra tricks to keep the secrets safe 🧚 Here are the main ones:
- Path key: a path key stands in for a segment of an LSP's path whenever the LSP is signaled, whenever its path gets reported in signaling, or whenever a PCE generates its path 🔑 Those hidden bits, called "confidential path segments" (CPSs), get swapped out for path keys so the exact route stays private 🤫
[PCE-PATH-KEY] explains how PCEs can use path keys to keep paths confidential, and [RSVP-PATH-KEY] explains how path keys work in signaling. Heads up: if path keys show up in RSVP-TE EROs, they have to be expanded so the signaling can keep going. That expansion usually happens when the first node in the CPS is reached. The PCE that made the key is normally the one that expands it, which is why the path key carries an identifier for that PCE (the PCE-ID) 🪪
- LSP segment: LSP segments can be pre-established across domains based on some management policy 🌉 They can be used to build end-to-end LSPs as hierarchical LSPs [RFC4206] or as LSP stitching segments [RFC5150].
The end-to-end LSPs are signaled with just the list of domains or domain border routers. When an LSP enters each domain, an existing trans-domain LSP gets picked and used to carry the end-to-end LSP through that domain 🚂
Even though these LSP segments are described as pre-established, they could also be set up on demand, right when the request for the end-to-end LSP shows up at the domain border ⚡
It's also worth knowing that in schemes that end up with one single contiguous end-to-end LSP (no LSP tunneling or stitching), the same LSP segment idea may still apply, as long as ERO expansion happens at domain boundaries and the LSP's path isn't reported in the RSVP-TE RRO 🦋
These techniques might be used directly, or they might need protocol extensions depending on which diverse LSP setup scheme you're using, which is covered below 🌈 Quick note: in the schemes below, the paths of the working and recovery LSPs are NOT affected by the confidentiality requirements 🙌
5.1. Management Configuration
Okay, so management systems might exist that can figure out end-to-end paths even when domain confidentiality is in place 🤓 But the full paths can't be handed to the head-end LSR for LSP signaling, because that would totally break the confidentiality requirements 💀
So for LSPs configured through management applications, the end-to-end path has to either be built out of LSP segments that cross the domains, or be communicated to the head-end LSR using path keys 🔑✨
5.2. Head-End Path Computation (with Multi-Domain Visibility)
It's just not possible for the head-end LSR to compute the full end-to-end path of an inter-domain LSP when domain confidentiality is in use 😭 Why? Because the LSR won't have any TE information about the other domains. No map, no route 🗺️
5.3. Per-Domain Path Computation
Per-domain path computation for working and recovery LSPs is practical even with domain confidentiality 🙌 Same as when there are no confidentiality restrictions, we can split things into the sequential case and the simultaneous case 💜
5.3.1. Sequential Path Computation
In sequential path computation, we can assume the working LSP already has its path computed and gets set up with the normal per-domain technique described in [RFC5152] 🛤️ BUT, because of confidentiality, the full path of the working LSP doesn't come back in the signaling messages, and the head-end LSR can't see it 🫠
To compute a disjoint path for the recovery LSP, each domain border node needs to know the working LSP's path within the domain it's entering 🧠 This part is easy for the ingress LSR, since it has access to the RSVP-TE RRO within the first domain 👑 For the later domains, the working LSP's path has to be made available to the domain border router somehow while the recovery LSP is being signaled. Also, the working and recovery LSPs don't use the same border routers if they're node or SRLG diverse 🍓
There are several ways to make this happen 🌸
- Path keys could go in the RRO for the working LSP. As the signaling messages travel back toward the head-end LSR, each domain border router swaps the segment of the working LSP's path in its domain for a path key 🔁 So the RRO the head-end LSR receives is the path within the initial domain, followed by a series of path keys.
When the recovery LSP is signaled, those path keys can go in the ERO as exclusions. Each domain border router can then expand the path key for its own domain and figure out which resources it has to avoid 🚫 PCEP provides a protocol for asking for that path key expansion, either from the domain border router used by the working LSP or from some third party like a PCE 📞
- Instead of path keys, each confidential path segment in the RRO of the working LSP could be encrypted by the domain border routers 🔐 Those encrypted segments would show up as exclusions in the ERO for the recovery LSP, and the domain border routers could decrypt them 🗝️
No mechanism currently exists in RSVP-TE for this, which would probably assume a domain-wide encryption key 🤷♀️
- The identity of the working LSP could go in the XRO of the recovery LSP, to say "hey, find a disjoint path" 💅
This option could need a simple extension to the current XRO specification [RFC4874] so LSP identifiers can be included 🧩 It could also use the Association Object [RFC4872] to identify the working LSP 🎀
This scheme would also need a way for a domain border router to find the path of an LSP within its own domain 🔍 One efficient way would be to also include the domain border router used by the working LSP in the recovery LSP's signaling, but other schemes based on management applications or stateful PCEs might get developed too 🧚
Clearly, the details of this alternative have NOT been specified yet 🙈
5.3.2. Simultaneous Path Computation
In per-domain simultaneous path computation, the path of the recovery LSP gets computed at the same time as the working LSP (basically, as the working LSP is being signaled) ⚡ The computed recovery path gets passed back to the head-end LSR as part of the working LSP's signaling. But confidentiality has to be maintained, so the full path can't be returned 🫶 There are two options:
- LSP segment: As the working LSP's signaling moves along and the recovery LSP's path is computed domain by domain, trans-domain LSPs can be set up for the recovery LSP to use 🌉 When the recovery LSP is signaled, it picks up these LSP segments and uses them for tunneling or stitching 🪡
This mechanism needs coordination through the management plane between domain border routers, so a router on the working path can request an LSP segment for the protection path 📋 This could be done through the TE MIB modules [RFC3812], [RFC4802] 📊
Also, when the recovery LSP gets signaled, it has to make sure it picks up the correct LSP segment 🎯 So some form of LSP segment identifier needs to be reported in the working LSP's signaling and passed along in the recovery LSP's signaling. Mechanisms for this don't exist yet, but they'd be relatively simple to build 🛠️
Alternatively, the LSP segments could be marked as providing protection for the working LSP. In that case, the recovery LSP can be signaled with the working LSP's identifier using the Association Object [RFC4872], which lets the right LSP segments get selected 💖
- Path key: The path of the recovery LSP can be determined and returned to the head-end LSR just like we described in Section 4.4.2, but each CPS gets replaced by a path key 🔑 When the recovery path is signaled, each path key gets expanded domain by domain to get the correct path 🧩 This requires that the entity computing the recovery LSP's path (a domain border LSR or a PCE) is stateful 🧠
5.4 Inter-Domain Collaborative Path Computation
Cooperative collaboration between PCEs also applies when domain confidentiality is required 🤝✨
5.4.1. Sequential Path Computation
In sequential cooperative path computation, the working LSP's path gets determined first, using a mechanism such as BRPC 🛤️ Since domain confidentiality is in use, the returned path may contain path keys 🔑
When the recovery LSP's path gets computed (which can happen before or after the working LSP is signaled), the path exclusions supplied to the PCE and exchanged between PCEs have to use path keys, as described in [PCEP-XRO] 🚫
5.4.2. Simultaneous Path Computation
As described in Section 4.4.2, diverse path computation can be requested using the PCEP SVEC Object [PCEP], and BRPC could be extended for inter-domain diverse path computation 🌈 But, to conform to domain confidentiality requirements, path keys MUST NOT... sorry, path keys must be used in the paths returned by the PCEs and signaled by RSVP-TE 🔐
Note that the LSP segment approach may not be applicable here, because a path can't be determined until the BRPC procedures are completed ⏳
6. Network Topology Specific Considerations
In some specific network topologies, the schemes for setting up diverse LSPs could be significantly simplified 🦋
For example, consider the L1VPN or GMPLS UNI case. This can be seen as a linear sequence of three domains, where the first and last domains each contain only a single node 🧁 In a scenario like this, no BRPC procedures are needed, because there's no need for path computation in the first and last domains, even if the source and destination nodes are multi-homed 💅
7. Addressing Considerations 🏡
All of the schemes described in this document are applicable when a single address space is used across all domains 🌍
There may also be cases where private address spaces are used within some of the domains 🙈 This problem is pretty similar to domain confidentiality, since the ERO and RRO are meaningless outside a domain even if they're available to you, and the same techniques can solve it 🫶
<<<RFC
8. Note on SRLG Diversity ✨
okay so the schemes in this doc work great when the nodes and links in different domains are in different SRLGs, which is normally the case 💅
BUT it's possible for nodes or links in different domains to be in the same SRLG. An SRLG can span domain boundaries, and that's where things get messy 😭 To get SRLG diverse LSPs in that situation, you need a few things:
- Record the SRLGs used by the working LSP.
- Indicate a set of SRLGs to exclude when computing the recovery LSP's path.
Here's the tea: domain confidentiality and SRLG diversity can clash. If you want both, something has to give, so one of the requirements must be compromised 🫠
And it gets worse 🙈 SRLG IDs can be assigned independently in each domain, so they might not mean the same thing globally. You'd need some mapping functions for that, similar to how other TE parameters get mapped in Section 1.2. Iconic? Not really. Necessary? Absolutely 🎀
9. Security Considerations 🔐
Okay, bestie, this one's serious, so let's do it properly 💜
The core protocols behind everything in this document are RSVP-TE and PCEP. Both come with policy and authentication features, as described in [RFC3209] and [PCEP]. They can also run with more advanced security stuff like IPsec [RFC4301] and TLS [RFC4346].
Security is especially important in inter-domain deployments, so please give serious thought to the available security techniques, the ones described in the docs above and in [RFC4726]. Don't skip this part, I'm begging you ✨
There's more security discussion for MPLS/GMPLS networks in [SECURITY-FW]. Go read it 📚
This document doesn't add any extra security measures of its own, and it doesn't change the trust model that the underlying protocols already assume. BUT (not a requirement, just a warning 💀) domain confidentiality is a big deal here. That means keeping the topology and path info inside any one domain private. A ton of the mechanisms in this document exist specifically to protect it, so keep that in mind while you read 🦋
10. References
10.1. Normative References
[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.
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS
Inter-Autonomous System (AS) Traffic Engineering
(TE) Requirements", RFC 4216, November 2005.
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed.,
"Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4427, March 2006.
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A
Framework for Inter-Domain Multiprotocol Label
Switching Traffic Engineering", RFC 4726, November
2006.10.2. Informative References
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) Management Information Base (MIB)",
RFC 3812, 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.
[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.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y.
Rekhter, "Generalized Multiprotocol Label Switching
(GMPLS) User-Network Interface (UNI): Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE)
Support for the Overlay Model", RFC 4208, October
2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346,
April 2006.
[RFC4428] Papadimitriou, D., Ed., and E. Mannie, Ed.,
"Analysis of Generalized Multi-Protocol Label
Switching (GMPLS)-based Recovery Mechanisms
(including Protection and Restoration)", RFC 4428,
March 2006.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC
4655, August 2006.
[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized
Multiprotocol Label Switching (GMPLS) Traffic
Engineering Management Information Base", RFC 4802,
February 2007.
[RFC4847] Takeda, T., Ed., "Framework and Requirements for
Layer 1 Virtual Private Networks", RFC 4847, April
2007.
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D.
Papadimitriou, Ed., "RSVP-TE Extensions in Support
of End-to-End Generalized Multi-Protocol Label
Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A.
Farrel, "GMPLS Segment Recovery", RFC 4873, May
2007.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude
Routes - Extension to Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE)", RFC 4874,
April 2007.
[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.
[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.
[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.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang,
"A Per-Domain Path Computation Method for
Establishing Inter-Domain Traffic Engineering (TE)
Label Switched Paths (LSPs)", RFC 5152, February
2008.
[BRPC] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le
Roux, "A Backward Recursive PCE-Based Computation
(BRPC) Procedure to Compute Shortest Inter-Domain
Traffic Engineering Label Switched Paths", Work in
Progress, April 2008.
[PCE-PATH-KEY] Bradford, R., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain
Path Computation Using a Key-Based Mechanism", Work
in Progress, May 2008.
[PCEP] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path
Computation Element (PCE) Communication Protocol
(PCEP)", Work in Progress, March 2008.
[PCEP-XRO] Oki, E., Takeda, T., and A. Farrel, "Extensions to
the Path Computation Element Communication Protocol
(PCEP) for Route Exclusions", Work in Progress, July
2008.
[RSVP-PATH-KEY] Bradford, R., Vasseur, JP., and A. Farrel, "RSVP
Extensions for Path Key Support", Work in Progress,
May 2008.
[SECURITY-FW] Fang, L., Ed., " Security Framework for MPLS and
GMPLS Networks", Work in Progress, July 2008.11. Acknowledgments 🫶
The authors want to thank Eiji Oki, Ichiro Inoue, Kazuhiro Fujihara, Dimitri Papadimitriou, and Meral Shirazipour for their valuable comments. Deborah Brungard gave useful advice about the text. Iconic squad 👑
Authors' Addresses 🎀
Tomonori Takeda
NTT Network Service Systems Laboratories, NTT Corporation
3-9-11, Midori-Cho
Musashino-Shi, Tokyo 180-8585 Japan
EMail : takeda.tomonori@lab.ntt.co.jp
Yuichi Ikejiri
NTT Communications Corporation
Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku
Tokyo 163-1421, Japan
EMail: y.ikejiri@ntt.com
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk
Jean-Philippe Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
EMail: jpv@cisco.comFull Copyright Statement 🌈
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 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: rfc5298 2008-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms