RFC 5150
Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)
RFC 5150: Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) 🎀
Okay bestie, this one is RFC 5150, a Standards Track doc from the Network Working Group, dated February 2008. The authors are A. Ayyangar and K. Kompella from Juniper Networks, JP. Vasseur from Cisco Systems, Inc., and A. Farrel from Old Dog Consulting. Its title block doesn't list any RFCs it obsoletes or updates, so it's not replacing or patching anything. Main character energy 💅✨
Status of This Memo 📜
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈
Abstract 💖
Sometimes you need to join several Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs) together so that you get one single end-to-end (e2e) LSP, and all the traffic from one of the smaller LSPs gets switched onto the next one. This is called "LSP stitching" 🧵 The big rule is that a constituent LSP can't be allocated to more than one e2e LSP. The constituent LSPs are called "LSP segments" (S-LSPs).
This document extends the existing GMPLS signaling protocol, Resource Reservation Protocol-Traffic Engineering (RSVP-TE), so it can set up e2e LSPs built from S-LSPs. It also explains how those LSPs can be managed using the GMPLS signaling and routing protocols 🦋
It may be possible to configure a GMPLS node so it switches traffic from an LSP where it's the egress onto another LSP where it's the ingress. That needs no signaling or routing extensions at all, and other nodes don't notice a thing. This also results in LSP stitching in the data plane 👀 However, this document doesn't cover that scenario.
Table of Contents 🧚
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Comparison with LSP Hierarchy ...................................3
3. Usage ...........................................................4
3.1. Triggers for LSP Segment Setup .............................4
3.2. Applications ...............................................5
4. Routing Aspects .................................................5
5. Signaling Aspects ...............................................6
5.1. RSVP-TE Signaling Extensions ...............................7
5.1.1. Creating and Preparing an LSP Segment for
Stitching ...........................................7
5.1.1.1. Steps to Support Penultimate Hop
Popping ....................................8
5.1.2. Stitching the e2e LSP to the LSP Segment ............9
5.1.3. RRO Processing for e2e LSPs ........................10
5.1.4. Teardown of LSP Segments ...........................11
5.1.5. Teardown of e2e LSPs ...............................11
5.2. Summary of LSP Stitching Procedures .......................12
5.2.1. Example Topology ...................................12
5.2.2. LSP Segment Setup ..................................12
5.2.3. Setup of an e2e LSP ................................13
5.2.4. Stitching of an e2e LSP into an LSP Segment ........13
6. Security Considerations ........................................14
7. IANA Considerations ............................................15
7.1. Attribute Flags for LSP_ATTRIBUTES Object .................15
7.2. New Error Codes ...........................................15
8. Acknowledgments ................................................16
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................171. Introduction ✨
A stitched GMPLS Traffic Engineering (TE) LSP is built from a bunch of different "LSP segments" (S-LSPs) that get connected together in the data plane, so that a single end-to-end LSP exists there. In this document, we define LSP stitching and detail the control plane mechanisms and procedures (routing and signaling) that make it happen. Where it applies, we also highlight the similarities and differences between LSP hierarchy [RFC4206] and LSP stitching. The signaling extensions required for LSP stitching are described here too 🎀
It may be possible to configure a GMPLS node to switch traffic from an LSP where it's the egress onto another LSP where it's the ingress, with no signaling or routing extensions and completely transparent to other nodes. That does result in LSP stitching in the data plane, but it needs management intervention at the node doing the stitching. With the mechanism described in this document, the stitching node doesn't need the pair of S-LSPs to be stitched together configured for it 🙌 Also, LSP stitching as defined here gives you an end-to-end LSP in both the control and data planes 💜
1.1. Conventions Used in This Document 📏
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🤓
2. Comparison with LSP Hierarchy 👑
LSP hierarchy ([RFC4206]) gives you signaling and routing procedures so that:
- a. You can create a Hierarchical LSP (H-LSP). An LSP created in one layer can appear as a data link to LSPs in higher layers. That means one or more LSPs in a higher layer can traverse this H-LSP as a single hop. We call this "nesting" 🪆
- b. An H-LSP may be managed and advertised (although this is not a requirement) as a Traffic Engineering (TE) link. Advertising it as a TE link lets other nodes in the TE domain where it's advertised use it in path computation. If the H-LSP TE link is advertised in the same instance of the control plane (TE domain) where it was provisioned, it's defined as a forwarding adjacency LSP (FA-LSP), and GMPLS nodes can form a forwarding adjacency (FA) over this FA-LSP. There's usually no routing adjacency between the end points of an FA. An H-LSP can also be advertised as a TE link in a different TE domain. In that case, the end points of the H-LSP are required to have a routing adjacency between them 🧐
- c. RSVP signaling ([RFC3473], [RFC3209]) for LSP setup can happen between nodes that don't have a routing adjacency 📡
In LSP stitching, an LSP segment (S-LSP) is created between two GMPLS nodes instead of an H-LSP. An S-LSP for stitching is considered the moral equivalent of an H-LSP for nesting. But unlike an H-LSP, an S-LSP created in one layer provides a data link to other LSPs in that same layer 😤 Like an H-LSP, an S-LSP could be managed and advertised, though it's not required, as a TE link, either in the same TE domain where it was provisioned or in a different one. If it's advertised, other GMPLS nodes can use that S-LSP TE link in path computation. There's a forwarding adjacency between the end points of an H-LSP TE link, but there's no forwarding adjacency between the end points of an S-LSP TE link. In this sense, an H-LSP TE link looks more like a 'basic' TE link than an S-LSP TE link does 💅
LSP hierarchy lets more than one LSP map to an H-LSP, but with LSP stitching, at most one LSP may be associated with an S-LSP. So if LSP-AB is an H-LSP between nodes A and B, then multiple LSPs, say LSP1, LSP2, and LSP3, can potentially be 'nested into' LSP-AB. This works by exchanging a unique label for each of LSP1..3 over the LSP-AB hop, which keeps the data for each of LSP1..3 separate while it traverses the H-LSP LSP-AB. Each of LSP1..3 may reserve some bandwidth on LSP-AB. On the flip side, if LSP-AB is an S-LSP, then at most one LSP, say LSP1, may be stitched to the S-LSP LSP-AB. LSP-AB is then dedicated to LSP1, and no other LSPs can be associated with LSP-AB. The entire bandwidth on S-LSP LSP-AB is allocated to LSP1. Still, just like H-LSPs, several S-LSPs may be bundled into a TE link ([RFC4201]) 🧃
The LSPs LSP1..3 that are either nested or stitched into another LSP are called e2e LSPs for the rest of this document. The routing procedures specific to LSP stitching are detailed in Section 4 🗺️
Targeted (non-adjacent) RSVP signaling, defined in [RFC4206], is required for LSP stitching of an e2e LSP to an S-LSP. The specific extensions for LSP stitching are described in Section 5.1. So in the control plane, there's one RSVP session for the e2e LSP and one for each S-LSP. An S-LSP may be created or terminated either by administrative control (statically provisioned) or because of another incoming LSP request (dynamic). The triggers for dynamic creation of an S-LSP can be different from those for an H-LSP, and they're described in detail in Section 3.1 🌸
3. Usage 🦋
3.1. Triggers for LSP Segment Setup 🌸
An S-LSP may be created either by administrative control (a configuration trigger) or dynamically, because of an incoming LSP request. LSP hierarchy ([RFC4206]) defines one possible trigger for dynamic creation of an FA-LSP by introducing the notion of LSP regions based on Interface Switching Capabilities. As per [RFC4206], dynamic FA-LSP creation may be triggered on a node when an incoming LSP request crosses region boundaries. However, this trigger MUST NOT be used for creating an S-LSP for LSP stitching as described in this document 🙅♀️ For LSP stitching, the switching capabilities of the previous hop and the next hop TE links MUST be the same. That's why local policies configured on the node SHOULD be used for dynamic creation of LSP segments 🔥
Other possible triggers for dynamic creation of both H-LSPs and S-LSPs include cases where an e2e LSP may cross domain boundaries, or where it satisfies locally configured policies on the node, as described in [RFC5151] 🧚
3.2. Applications
okay so the LSP stitching procedures in this doc are for GMPLS nodes that need to tie an e2e LSP to another S-LSP of the same switching type 🔗, and LSP hierarchy procedures do not apply there. example time 🎀: if an e2e lambda LSP runs over an LSP segment TE link that's also lambda-switch capable, LSP hierarchy is not possible, and LSP switching may be an option ✨
stitching is also giving inter-domain TE LSP signaling realness 🌍. you can stitch an inter-domain e2e LSP onto a local intra-domain TE S-LSP ([RFC4726] and [RFC5151]) 💖
and it's lowkey iconic for bypassing legacy nodes 🦋 that don't have certain new control plane and/or data plane capabilities. one suggested usage for point-to-multipoint (P2MP) RSVP LSPs ([RFC4875]) is to stitch a P2MP RSVP LSP onto an LSP segment between P2MP-capable Label Switching Routers (LSRs) in the network 🧚. that LSP segment goes through legacy LSRs that might not be able to act as P2MP branch points, so they get shielded from the P2MP control and data path 🛡️. BUT ngl, this setup might limit how attractive RSVP P2MP is, so it should carefully be examined before deployment 🙈
4. Routing Aspects
an S-LSP gets created between two GMPLS nodes, and it may go through zero or more intermediate GMPLS nodes 🌸. there's no forwarding adjacency between the end points of an S-LSP TE link. so even though those end points are adjacent in the TE topology, they don't have an adjacency in the data plane 💅. which also means any data plane resource identifier between them is meaningless ✨
traffic arriving at the head end of the S-LSP gets switched into it contiguously with a label swap 🔁, and no label is associated directly between the end nodes of the S-LSP itself 💜
an S-LSP MAY be treated and managed as a TE link 🎀. that TE link MAY be numbered or unnumbered. for an unnumbered S-LSP TE link, the schemes for assigning and handling local and remote link identifiers from [RFC3477] SHOULD be used 🫶. when it fits, the TE info for an S-LSP TE link MAY get flooded via ISIS-TE [RFC4205] or OSPF-TE [RFC4203] 📡. similar mechanisms to regular (basic) TE links SHOULD be used to flood S-LSP TE links. advertising or flooding the S-LSP TE link is NOT a requirement for LSP stitching, so it's optional bestie 🦋 if you do advertise it, the TE info lives in the TE database (TED) and other GMPLS nodes in that TE domain can use it for path computation 🧠. just keep in mind that advertised S-LSPs add to the size and complexity of the link-state database 🙈
if an S-LSP is advertised as a TE link in the same TE domain where it was provisioned, there's no need for a routing adjacency between its end points 🙌. but if the S-LSP TE link is advertised in a different TE domain, its end points SHOULD have a routing adjacency between them 🤝
the TE parameters defined for an FA in [RFC4206] SHOULD be used for an S-LSP TE link as well 💅. the switching capability of an S-LSP TE link MUST be equal to the switching type of the underlying S-LSP. like, an S-LSP TE link gives a data link to other LSPs in the same layer, so no hierarchy is possible 🚫
an S-LSP MUST NOT admit more than one e2e LSP into it 🚷. if an S-LSP gets allocated to an e2e LSP, its unreserved bandwidth SHOULD be set to zero so no more e2e LSPs get admitted 🔒
multiple S-LSPs between the same pair of nodes MAY be bundled into a single TE link using Link Bundling ([RFC4201]) 🎁. in that case, each component S-LSP may be allocated to at most one e2e LSP. when any component S-LSP is allocated for an e2e LSP, that component's unreserved bandwidth SHOULD be set to zero, and the Minimum and Maximum LSP bandwidth of the TE link SHOULD be recalculated 🧮. this stops more than one LSP from being computed and admitted over an S-LSP 👑
5. Signaling Aspects
the end nodes of an S-LSP may or may not have a routing adjacency 🤷♀️. however, they SHOULD have a signaling adjacency (RSVP neighbor relationship) and will exchange RSVP messages with each other 💬. it may actually be desirable to exchange RSVP Hellos directly between the LSP segment end points, so state recovery works during Graceful Restart procedures as described in [RFC3473] 🔄
to signal an e2e LSP over an LSP segment, the signaling procedures in Section 8.1.1 of [RFC4206] MUST be used 📞. extra signaling extensions for stitching are in the next section 💖
5.1. RSVP-TE Signaling Extensions
the signaling extensions described here MUST be used for stitching an e2e packet or non-packet GMPLS LSP ([RFC3473]) to an S-LSP 🎀
stitching an e2e LSP to an LSP segment is a two-step process 🪜:
- creating and prepping the S-LSP for stitching by signaling the desire to stitch between its end points; and
- stitching the e2e LSP to the S-LSP.
5.1.1. Creating and Preparing an LSP Segment for Stitching
if a GMPLS node wants to create an S-LSP (aka one that's going to be used for stitching) then it MUST indicate that in the Path message for the S-LSP 📨. this signaling explicitly tells the S-LSP egress node that the ingress node is planning to do stitching over the S-LSP 👀. an S-LSP is not conceptually different from any other LSP, so explicitly signaling 'LSP stitching desired' helps clarify the data plane actions to take when some other e2e LSP uses the S-LSP 🧠. also, for packet LSPs, this is what lets the S-LSP egress do label allocation (more on that below) 🏷️. and so the head-end node can make sure the right stitching actions happen at the egress node, the egress node MUST signal this info back to the head-end node in the Resv, as explained below 🔁
to request LSP stitching on the S-LSP, we define a new bit in the Attributes Flags TLV of the LSP_ATTRIBUTES object defined in [RFC4420] ✨:
- LSP stitching desired bit - This bit SHOULD be set in the Attributes Flags TLV of the
LSP_ATTRIBUTESobject in the Path message for the S-LSP by the head end of the S-LSP that desires LSP stitching. This bit MUST NOT be modified by any other nodes in the network. Nodes other than the egress of the S-LSP SHOULD ignore this bit. The bit number for this flag is defined in Section 7.1. 🎀
an LSP segment can only be used for stitching if the S-LSP's egress node is also ready to take part in stitching 🙋♀️. to tell the head-end node that, a new bit is defined in the Flags field of the Record Route object (RRO) Attributes subobject: "LSP segment stitching ready". the bit number for this flag is defined in Section 7.1 💜
if an egress node of the S-LSP gets the Path message and supports the LSP_ATTRIBUTES object and the Attributes Flags TLV, and also recognizes the "LSP stitching desired" bit but can't support the requested stitching behavior 😬, then it MUST send back a PathErr message with an error code of "Routing Problem" and an error value of "Stitching unsupported" to the head-end node of the S-LSP. the new error value is defined in Section 7.2 🚨
if an egress node receives a Path message with the "LSP stitching desired" bit set in the Flags field of the received LSP_ATTRIBUTES object, and it recognizes the object, the TLV TLV, and the bit, and also supports the desired stitching behavior 🙌, then it MUST allocate a non-NULL label for that S-LSP in the corresponding Resv message. also, so the head-end node can make sure the correct label (forwarding) actions happen at the egress node and the S-LSP can be used for stitching, the egress node MUST set the "LSP segment stitching ready" bit defined in the Flags field of the RRO Attribute subobject 🫶
finally, if the egress node for the S-LSP supports the LSP_ATTRIBUTES object but doesn't recognize the Attributes Flags TLV, or supports the TLV but doesn't recognize this particular bit, then it SHOULD simply ignore the above request 🙈
an ingress node requesting LSP stitching MUST check the RRO Attributes subobject Flags for the egress node of the S-LSP 🔍, to make sure stitching actions are carried out at that egress node. it MUST NOT use the S-LSP for stitching if the "LSP segment stitching ready" bit is cleared 🚫
5.1.1.1. Steps to Support Penultimate Hop Popping
this section only applies to packet LSPs that use Penultimate Hop Popping (PHP) at the last hop, where the egress node distributes the Implicit NULL Label ([RFC3032]) in the Resv Label 🍓. these steps MUST NOT be used for a non-packet LSP, or for packet LSPs where PHP is not desired 🙅♀️
when the egress node of a packet S-LSP receives a Path message for an e2e LSP that uses the S-LSP, the S-LSP egress SHOULD first check whether it's also the egress of the e2e LSP 👀. if the node is the egress for both the S-LSP and the e2e TE LSP, and this is a packet LSP that requires PHP, then the node MUST send back a Resv trigger message for the S-LSP with a new label corresponding to the Implicit or Explicit NULL Label 🏷️. this doesn't cause any traffic disruption, because the S-LSP isn't carrying any traffic yet since the e2e LSP hasn't been established 🫧
if the e2e LSP and the S-LSP are bidirectional, the ingress of the e2e LSP SHOULD first check whether it's also the ingress of the S-LSP 🔄. if so, it SHOULD re-issue the Path message for the S-LSP with an Implicit or Explicit NULL Upstream Label, and only then proceed with signaling the e2e LSP 💅✨
5.1.2. Stitching the e2e LSP to the LSP Segment ✨
okay so, when a GMPLS node gets an e2e LSP request, it depends on the trigger 🎀. It can either make a brand new S-LSP dynamically using the procedures from above, or it can map the e2e LSP onto an S-LSP that already exists 💅. The switching type in the Generalized Label Request of the e2e LSP MUST be equal to the switching type of the S-LSP. Other constraints like the explicit path in the Explicit Route object (ERO), bandwidth, and local TE policies MUST also be used for S-LSP selection or signaling 🧚. Either way, once an S-LSP is picked for an e2e LSP, the following procedures MUST be followed in order to stitch the e2e LSP to the S-LSP 🦋.
The GMPLS node that receives the e2e LSP setup Path message MUST use the signaling procedures from [RFC4206] to send the Path message to the end point of the S-LSP 💖. In that Path message, the node MUST identify the S-LSP in the RSVP_HOP. The egress node should also be able to figure out the S-LSP TE link from what's signaled in the RSVP_HOP 🔥. If the S-LSP TE link is numbered, the addressing scheme proposed in [RFC4206] SHOULD be used to number it 🌸. If the S-LSP TE link is unnumbered, any of the schemes proposed in [RFC3477] SHOULD be used to swap S-LSP TE link identifiers between the S-LSP end points 🫶. If the TE link is bundled, the RSVP_HOP SHOULD identify the component link as defined in [RFC4201] 🌈.
Okay, now the bidirectional case, which is lowkey where it gets spicy 🌶️. For a bidirectional e2e TE LSP, an Upstream Label MUST be signaled in the Path message for the e2e LSP over the S-LSP hop. BUT, since there's no forwarding adjacency between the S-LSP end points, any label they swap has zero significance 💀. So the node MAY choose any label value for the Upstream Label. The value it picks and signals is out of scope for this document and is specific to that node's implementation 🙈. The egress node that receives this Path message MUST ignore the Upstream Label in the Path message over the S-LSP hop 🍓.
The egress node that receives this Path message MUST signal a Label in the Resv message for the e2e TE LSP over the S-LSP hop. Again, no forwarding adjacency between the egress and ingress S-LSP nodes means any label they exchange is meaningless 😭. So the egress node MAY choose any label value for the Label. The value it chooses and signals is out of scope here and specific to the egress node's implementation ✨. The egress S-LSP node SHOULD also do data plane operations so traffic coming in on the S-LSP gets switched over to the e2e LSP downstream, if the egress of the e2e LSP is some other node downstream 💜. If the e2e LSP is bidirectional, that means setting up label switching in both directions 🦋. The Resv message from the egress S-LSP node is IP routed back to the previous hop (the ingress of the S-LSP) 🎀. The ingress node that stitches an e2e TE LSP to an S-LSP MUST ignore the Label object it gets in the Resv for the e2e TE LSP over the S-LSP hop 💅. The S-LSP ingress node SHOULD also do data plane operations so traffic coming in on the e2e LSP gets switched into the S-LSP 🧚. It should also take actions to handle traffic going the opposite way if the e2e LSP is bidirectional 🌸.
Note that the label exchange for LSP stitching on the S-LSP hop is pretty similar to LSP hierarchy over the H-LSP hop 👑. The difference is that in stitching the label doesn't mean anything between the S-LSP end points. So in stitching, the recipients of the Label/Upstream Label MUST NOT process these labels 🙈. Also, at most one e2e LSP is associated with one S-LSP 🔥. If a node at the head end of an S-LSP gets a Path message for an e2e LSP that names the S-LSP in the ERO, and the S-LSP bandwidth has already been given to some other LSP, then regular RSVP-TE pre-emption rules apply to settle the fight over the S-LSP bandwidth ⚔️. If the LSP request over the S-LSP can't be satisfied, the node SHOULD send back a PathErr with the error codes described in [RFC3209] 💖.
5.1.3. RRO Processing for e2e LSPs
RRO procedures for the S-LSP that are specific to LSP stitching were already covered in Section 5.1.1 🌈. In this section, we're looking at RRO processing for the e2e LSP over the S-LSP hop 🦋.
An e2e LSP that goes through an S-LSP SHOULD record an identifier for the S-LSP TE link in the RRO for that hop 🎀. This applies to both Path and Resv messages over the S-LSP hop 🫶. If the S-LSP is numbered, the IPv4 or IPv6 address subobject ([RFC3209]) SHOULD be used to record the S-LSP TE link address 🌸. If the S-LSP is unnumbered, the Unnumbered Interface ID subobject described in [RFC3477] SHOULD be used to record the node's Router ID and Interface ID of the S-LSP TE link 💅. Either way, the RRO subobject SHOULD identify the S-LSP TE link end point 💜. Intermediate links or nodes that the S-LSP itself goes through SHOULD NOT be recorded in the RRO for the e2e LSP over the S-LSP hop 🙅♀️.
5.1.4. Teardown of LSP Segments
S-LSP teardown follows the standard procedures from [RFC3209] and [RFC3473] 🧚. That includes both the procedures without and with setting the administrative status 💖. Teardown of an S-LSP can be started by the ingress, the egress, or any other node along the S-LSP path 🔥. Deleting or tearing down the S-LSP SHOULD be treated as a failure event for the e2e LSP tied to it, and the matching teardown or recovery procedures SHOULD be triggered for the e2e LSP 😭. If the S-LSP is torn down for maintenance, the S-LSP ingress node MAY treat it as the same thing as administratively shutting down a TE link along the e2e LSP path, and take the matching actions to tell the ingress about this event 🌈. The actual signaling procedures for handling this event are out of scope for this document 🫶.
5.1.5. Teardown of e2e LSPs
e2e LSP teardown also follows the standard procedures from [RFC3209] and [RFC3473], either without or with the administrative status 🎀. But here's the tea ☕: the teardown procedures for the e2e LSP and the S-LSP are independent of each other 💅. So it's possible that while one LSP does a graceful teardown with the administrative status, the other gets torn down without it (using PathTear/ResvTear/PathErr with state removal) 💀.
When an e2e LSP teardown starts at the head end and a PathTear reaches the GMPLS stitching node, the PathTear message MUST be IP routed to the LSP segment egress node, just like the Path message, with the destination IP address of the Path message set to the address of the S-LSP end node 🦋. Router Alert MUST be off, and the RSVP Time to Live (TTL) check MUST be disabled on the receiving node 🙈. The PathTear deletes the RSVP states for the e2e LSP and frees the label allocations and bandwidth reservations on the S-LSP 🔥. The unreserved bandwidth on the S-LSP TE link SHOULD be readjusted 🌸.
Similarly, the tail end can start an e2e LSP teardown with a ResvTear or a PathErr with state removal 🧚. The egress of the S-LSP MUST propagate the ResvTear/PathErr upstream, and it MUST use IP addressing to target the ingress of the LSP segment 💖.
Graceful LSP teardown using ADMIN_STATUS, as described in [RFC3473], also works for stitched LSPs 👑.
If the S-LSP was statically provisioned, tearing down an e2e LSP MAY not result in tearing down the S-LSP 🌈. But if the S-LSP was dynamically set up because of the e2e LSP setup request, then, depending on local policy, the S-LSP MAY be torn down once no e2e LSP is using it 💅. The S-LSP can get torn down while the e2e LSP is being torn down, but it is RECOMMENDED to add a delay before tearing down the S-LSP once the e2e LSP teardown is complete 😭. The reason is to cut down on RSVP errors and teardown messages being generated all at once from multiple events 🫶. The delay can be set based on local implementation 🎀. The RECOMMENDED interval is 30 seconds ⏰.
5.2. Summary of LSP Stitching Procedures 🌸
5.2.1. Example Topology
The following topology is used for the examples quoted in the sections below 🦋.
e2e LSP
+++++++++++++++++++++++++++++++++++> (LSP1-2)
LSP segment (S-LSP)
====================> (LSP-AB)
C --- E --- G
/|\ | / |\
/ | \ | / | \
R1 ---- A \ | \ | / | / B --- R2
\| \ |/ |/
D --- F --- H
PATH
====================> (LSP stitching desired)
RESV
<==================== (LSP segment stitching ready)
PATH (Upstream Label)
+++++++++++++++++++++
+++++++ ++++++>
<++++++ +++++++
+++++++++++++++++++++
RESV (Label)5.2.2. LSP Segment Setup
Let's say an S-LSP called LSP-AB is being set up between two nodes, A and B, that are more than one hop apart 🎀. Node A sends a Path message for LSP-AB with "LSP stitching desired" set in the Flags field of the LSP_ATTRIBUTES object 💖. If egress node B is ready to do the stitching procedures, B responds with "LSP segment stitching ready" set in the Flags field of the RRO Attributes subobject, in the RRO sent in the Resv for the S-LSP ✨. Once A gets the Resv for LSP-AB and sees that bit set in the RRO, it can use LSP-AB for stitching 🫶. If the bit is cleared in the RRO, Node A cannot use LSP-AB for stitching 😭.
5.2.3. Setup of an e2e LSP
Now let's look at an e2e LSP called LSP1-2 that starts one hop before A on R1 and ends on node R2, as shown above 👑. If the S-LSP has been advertised as a TE link in the TE domain, and R1 and A are in the same domain, then R1 may compute a path for LSP1-2 over the S-LSP LSP-AB and identify the LSP-AB hop in the ERO 🦋. If not, R1 may compute hops between A and B, and A may use those ERO hops to select an S-LSP or to signal a new one 🧚. If R1 and A are in different domains, then LSP1-2 is an inter-domain LSP 🌈. In that case, S-LSP LSP-AB, just like any other basic TE link in the domain, won't be advertised outside the domain 🔥. R1 would use either per-domain path computation ([RFC5152]) or PCE-based computation ([RFC4655]) for LSP1-2 💜.
5.2.4. Stitching of an e2e LSP into an LSP Segment ✨
okay so the Path message for the e2e LSP LSP1-2 shows up at node A 👀. A checks whether the switching type of LSP1-2 matches the switching type of the S-LSP LSP-AB. If they don't match, then LSP-AB can't be used to stitch LSP1-2 🙅♀️. Once A has picked the S-LSP LSP-AB that LSP1-2 is going to be stitched onto, it sends the Path message for LSP1-2 over to node B (through IP routing, if it needs that), with the IF_ID RSVP_HOP pointing at LSP-AB 📬.
Now B gets that Path message. If B is also the egress for LSP1-2, and this is a packet LSP that needs PHP, then B sends a Resv refresh for LSP-AB with the NULL Label 💅. But B isn't the egress here, so the Path message for LSP1-2 just keeps going on to R2 🏃♀️. The Resv for LSP1-2 comes back from B to A, carrying a Label that B picked itself. B also sets up its data plane to swap the Label it sends to G or H on the S-LSP for the Label it got from R2 🔁.
A ignores the Label that arrives in that Resv (not me being chill about it 🙈), and then passes the Resv along to R1. A sets up its own data plane to swap the Label it sends to R1 for the Label it received on the S-LSP from C or D 🫶.
This stitches the e2e LSP LSP1-2 to an S-LSP LSP-AB between nodes A and B 🦋. In the data plane, that gives you a whole series of label swaps from R1 to R2 along e2e LSP LSP1-2 ✨👑
6. Security Considerations 🔐
okay this section is serious, so read it with your whole brain 🧠. From a security point of view, the changes in this document model the changes introduced by [RFC4206]. That means the control interface that RSVP messages are sent or received on doesn't have to be the same as the data interface that the message names for switching traffic 🦋. The capability for this was introduced in [RFC3473] to support the concept of out-of-fiber control channels, so there's nothing new in this concept for signaling or security 💜.
Here's the tricky bit 😬. Applying this facility means the "sending interface" or "receiving interface" can change as routing changes. So these interfaces can't be used to establish security associations between neighbors, and security associations MUST be bound to the communicating neighbors themselves 🚨.
[RFC2747] has a fix for this: in Section 2.1, under "Key Identifier", an IP address is a valid identifier for the sending (and by analogy, receiving) interface 🧩. Since RSVP messages for a given LSP are sent to an IP address that identifies the next or previous hop for that LSP, you can replace every occurrence of 'sending [receiving] interface' with 'receiver's [sender's] IP address' (respectively) 💅. For example, in Section 4, third paragraph, instead of:
"Each sender SHOULD have distinct security associations (and keys)
per secured sending interface (or LIH). ... At the sender,
security association selection is based on the interface through
which the message is sent."it should read:
"Each sender SHOULD have distinct security associations (and keys)
per secured receiver's IP address. ... At the sender, security
association selection is based on the IP address to which the
message is sent."So the mechanisms of [RFC2747] can be used unchanged to establish security associations between control plane neighbors 🎀.
This document lets the IP destination address of Path and PathTear messages be the IP address of a next hop node (the receiver's address), instead of the RSVP session destination address 🌸. That matters because the IPsec Authentication Header (AH) was ruled out in [RFC2747], since RSVP messages were encapsulated in IP packets addressed to the ultimate destination of the Path or PathTear messages. Now AH is perfectly applicable, and standard IPsec procedures can be used to secure the message exchanges 🔥.
An analysis of GMPLS security issues can be found in [MPLS-SEC] 📖.
7. IANA Considerations 🧾
IANA has made the following codepoint allocations for this document 🌈.
7.1. Attribute Flags for LSP_ATTRIBUTES Object
The "RSVP TE Parameters" registry includes the "Attributes Flags" sub-registry 📋.
IANA has allocated the following new bit (5) defined for the Attributes Flags TLV in the LSP_ATTRIBUTES object ✨.
LSP stitching bit - Bit Number 5
This bit is only to be used in the Attributes Flags TLV on a Path message 💖.
The 'LSP stitching desired' bit has a corresponding 'LSP segment stitching ready' bit (Bit Number 5) to be used in the RRO Attributes subobject 🦋.
The following text has been includuded in the registry:
Bit | Name | Attribute | Path | RRO | Reference
No | | Flags Path | Flags Resv | |
----+----------------------+------------+------------+-----+----------
5 LSP stitching desired Yes No Yes [RFC5150]7.2. New Error Codes
The "Resource ReSerVation Protocol (RSVP) Parameters" registry includes the "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry 🧚.
IANA has assigned a new error sub-code (30) under the RSVP error-code "Routing Problem" (24) 💀.
This error code (30) is to be used only in an RSVP PathErr 🙈.
The following text has been included in the registry:
24 Routing Problem [RFC3209]
30 = Stitching unsupported [RFC5150]8. Acknowledgments 🫶
the authors want to thank Dimitri Papadimitriou and Igor Bryskin for their thorough review of the document and for the discussions about it 💜. Main character energy for the reviewers 👑.
9. References 📚
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
[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.
[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.
[RFC4420] Farrel, A., Ed., 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.9.2. Informative References
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
Links in Resource ReSerVation Protocol - Traffic
Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October
2005.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005.
[RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate
System to Intermediate System (IS-IS) Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4205, October 2005.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A
Framework for Inter-Domain Multiprotocol Label Switching
Traffic Engineering", RFC 4726, November 2006.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
May 2007.
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-
Domain MPLS and GMPLS Traffic Engineering -- Resource
Reservation Protocol-Traffic Engineering (RSVP-TE)
Extensions", RFC 5151, February 2008.
[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.
[MPLS-SEC] Fang, L., Ed., Behringer, M., Callon, R., Le Roux, J.
L., Zhang, R., Knight, P., Stein, Y., Bitar, N., and R.
Graveman., "Security Framework for MPLS and GMPLS
Networks", Work in Progress, July 2007.Authors' Addresses 📮
Arthi Ayyangar
Juniper Networks
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
EMail: arthi@juniper.net
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
JP Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
EMail: jpv@cisco.com
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.ukFull Copyright Statement ⚖️
the legal bits stay word-for-word, bc lawyers 💼
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: rfc5150 2008-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms