RFC 4873
GMPLS Segment Recovery
GMPLS Segment Recovery 🦋
Okay bestie, let's get into RFC 4873 🎀 The title is GMPLS Segment Recovery, and it's a Standards Track document, so this is the real deal that implementers actually rely on ✨ It came out in May 2007 💅 The authors are L. Berger (LabN Consulting), I. Bryskin (ADVA Optical), D. Papadimitriou (Alcatel), and A. Farrel (Old Dog Consulting), and it's from the Network Working Group 🫶 The header says Updates: 3473, 4872, so this one tweaks how two earlier specs work. 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. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice 🌸
Copyright (C) The IETF Trust (2007).
Abstract 💜
Okay so this doc is all about segment protection and restoration for LSPs (label switched paths) in GMPLS (Generalized Multi-Protocol Label Switching). The signaling uses RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) extensions, and it's meant to sit right alongside the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872) 🦋 It also talks about how this stuff interacts with fast reroute, and it updates how NOTIFY_REQUEST objects get handled 🔥
Table of Contents 🧚
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Segment Recovery ................................................4
2.1. Segment Protection .........................................6
2.2. Segment Re-routing and Restoration .........................6
3. ASSOCIATION Object ..............................................6
3.1. Format .....................................................7
3.2. Procedures .................................................7
3.2.1. Recovery Type Processing ............................7
3.2.2. Resource Sharing Association Type Processing ........7
4. Explicit Control of LSP Segment Recovery ........................8
4.1. Secondary Explicit Route Object Format .....................8
4.1.1. Protection Subobject ................................8
4.2. Explicit Control Procedures ................................9
4.2.1. Branch Failure Handling ............................10
4.2.2. Resv Message Processing ............................11
4.2.3. Admin Status Change ................................12
4.2.4. Recovery LSP Teardown ..............................12
4.3. Teardown From Non-Ingress Nodes ...........................12
4.3.1. Modified NOTIFY_REQUEST Object Processing ..........13
4.3.2. Modified Notify and Error Message Processing .......14
5. Secondary Record Route Objects .................................14
5.1. Format ....................................................14
5.2. Path Processing ...........................................15
5.3. Resv Processing ...........................................15
6. Dynamic Control of LSP Segment Recovery ........................16
6.1. Modified PROTECTION Object Format .........................16
6.2. Dynamic Control Procedures ................................17
7. Updated RSVP Message Formats ...................................18
8. Security Considerations ........................................20
9. IANA Considerations ............................................21
9.1. New Association Type Assignment ...........................21
9.2. Definition of PROTECTION Object Reserved Bits .............21
9.3. Secondary Explicit Route Object ...........................21
9.4. Secondary Record Route Object .............................21
9.5. New Error Code ............................................22
9.6. Use of PROTECTION Object C-type ...........................22
10. References ....................................................23
10.1. Normative References .....................................23
10.2. Informative References ...................................231. Introduction 🎀
Okay, so [RFC4427] covers a bunch of different protection types, including end-to-end and segment-based approaches 💖 Then "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery" [RFC4872] defines extensions for multiple kinds of recovery. Those include 1+1 unidirectional/1+1 bidirectional protection, LSP protection with extra-traffic (including 1:N protection with extra-traffic), pre-planned LSP re-routing without extra-traffic (including shared mesh), and full LSP re-routing 🌈 In every one of those cases, the recovery is end-to-end, meaning the ingress and egress nodes of both the protected and the protecting LSP are the same. Literally the same two nodes 😭
Next up, [RFC4090] gives us a form of segment recovery for packet MPLS-TE networks 🧚 It defines two fast reroute methods. The one-to-one backup method makes detour LSPs for each protected LSP at each potential point of local repair. The facility backup method makes a bypass tunnel that protects a potential failure point shared by multiple LSPs, and it uses label stacking. Neither one supports the full set of recovery types from [RFC4872], which is kind of a vibe check 💀 Also, the facility backup method isn't applicable to most non-PSC (packet switch capable) switching technologies. Not it. 🙈
Now here's where this doc comes in ✨ It lets you use the full set of recovery types from [RFC4872], but on a segment, which is a portion of the LSP. The extensions allow (a) signaling of the desired LSP segment protection type, (b) upstream nodes to optionally identify where segment protection starts and stops, (c) the optional identification of hops used on protection segments, and (d) reporting of the paths used to protect an LSP 💅 They also widen the topological scope where protection can work. Recovery segments can protect against an arbitrary number of nodes and links, and they can enable overlapping protection and nested protection. Iconic behavior 🔥 These extensions are meant to be compatible with fast reroute, and in some cases they can even be used together with it 🫶
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 [RFC2119].
Also, the reader is assumed to already know the terminology from [RFC3209], [RFC3471], and [RFC3473], plus [RFC4427], [RFC4426], [RFC4872], and [RFC4090]. No cap, that's a lot of reading, so get your snacks ready 🍓
(more soon, bestie 🧚💜)
2. Segment Recovery 🎀
Okay so segment recovery is how you protect and restore just a piece of an end-to-end LSP 🧚 It covers you when a span fails, when a node fails, or when something breaks over one particular stretch of the network that an LSP is using. Lowkey genius 💅
Check out this topology 👀
A---B---C---D---E---F
\ /
G---ISo here's the tea: end-to-end protection and recovery is not possible for an LSP going between node A and node F 😭 But you CAN protect/recover a portion of that LSP! If the LSP uses a working path of [A,B,C,D,E,F], then a protection or restoration LSP can be established along the path [C,G,I,E]. This LSP protects against failures on spans {C,D} and {D,E}, as well as a failure of node D. 🔥 This is called Segment Protection and Segment Restoration, or Segment Recovery for short when we talk about them together. The LSP doing the protecting or restoring is a segment protection LSP or a segment restoration LSP, and "segment recovery LSP" is the umbrella term that covers either one. The "branch node" is the node that initiates a recovery LSP (node C in the figure above). It's the same thing as the point of local repair (PLR) from [RFC4090]. As with [RFC4090], the "merge node" is the node that terminates a recovery LSP (node E in the figure above). 🦋
Segment protection or restoration is signaled using a working LSP and one or more segment recovery LSPs. Each segment recovery LSP is signaled as its own independent LSP. The Sender_Template object uses the IP address of the node originating the recovery path (node C in the topology above), and the Session object contains the IP address of the node terminating the recovery path (node E above). There's no specific requirement on LSP ID value, Tunnel ID, and Extended Tunnel ID. These fields are selected normally, including consideration for the make-before-break concept (as described in [RFC3209]). Intermediate nodes follow standard signaling procedures when processing segment recovery LSPs. A segment recovery LSP may be protected itself using segment or end-to-end protection/restoration. Also, in PSC environments, it may be desirable to construct the Sender_Template and Session objects per [RFC4090] 🌸
When [RFC4090] isn't being used, the association between segment recovery LSPs and other LSPs is indicated using the ASSOCIATION object defined in [RFC4872]. The ASSOCIATION object is used to associate recovery LSPs with the LSP they are protecting. Working and protecting LSPs, as well as primary and secondary LSPs, are identified using LSP Status as described in [RFC4872]. The O-bit in the segment flags portion of the PROTECTION object is used to identify when a recovery LSP is carrying the normal (active) traffic ✨
An upstream node can permit downstream nodes to dynamically identify branch and merge points by setting the desired LSP segment protection bits in the PROTECTION object. These bits are defined below. 🫶
Optionally, an upstream node (usually the ingress node) can identify the endpoints of a segment recovery LSP. This is done with a new object that uses the same format as an Explicit Route Object (ERO), called a Secondary Explicit Route object (SERO). See Section 4.1. SEROs also support a new subobject that indicates the type of protection or restoration to be provided. At a minimum, an SERO will indicate a recovery LSP's initiator, protection/restoration type, and terminator. Standard ERO semantics (see [RFC3209]) can optionally be used within an SERO to explicitly control the recovery LSP. There's also a Secondary Record Route object (SRRO) for recording the path of a segment recovery LSP; see Section 5 💖
SEROs are carried between the node creating the SERO (typically the ingress) and the node initiating a recovery LSP. The node initiating a recovery LSP uses the SERO to create the ERO for the recovery LSP. At this (branch) node, all local objects are removed, and the new protection subobject is used to create the PROTECTION object for the recovery LSP. It's also possible to control how a failure to establish a recovery LSP is handled 🙈
SRROs are carried in Path messages between the node terminating a recovery LSP (the merge node) and the egress. SRROs are used in Resv messages between a branch node and the ingress. The merge node of a recovery LSP creates an SRRO by copying the RRO from the Path message of the associated recovery LSP into a new SRRO object. Any SRROs present in the recovery LSP's Path message are also copied. The branch node of a recovery LSP creates an SRRO by copying the RRO from the Resv message of the associated recovery LSP into a new SRRO object. Any SRROs present in the recovery LSP's Resv message are also copied. 💅
Notify request processing is also impacted by LSP segment recovery. Per [RFC3473], only one NOTIFY_REQUEST object is meaningful and should be propagated. Additional NOTIFY_REQUEST objects are used to identify recovery LSP branch nodes 🌈
2.1. Segment Protection
Three approaches for end-to-end protection are defined in [RFC4872]:
- 1+1 Unidirectional Protection (Section 5)
- 1+1 Bidirectional Protection (Section 6)
- 1:1 Protection With Extra-Traffic (Section 7)
The segment protection forms of these approaches all operate much like their end-to-end counterparts. Each one behaves just like its end-to-end counterpart, with the exception that the protection LSP protects only a portion of the working LSP. The type of protection to be used on a segment protection LSP is indicated to the protection LSP's ingress, using the protection SERO subobject defined in Section 4.1 🦋
The switch-over processing for segment 1+1 Bidirectional protection and 1:1 Protection With Extra-Traffic follows the same procedures as the end-to-end protection forms. See Sections 6.2 and 7.2 of [RFC4872] for details ✨
2.2. Segment Re-routing and Restoration
Three re-routing and restoration approaches are defined in [RFC4872]:
- Re-routing without Extra-Traffic (Section 8)
- Shared-Mesh Restoration (Section 9)
- (Full) LSP Re-routing (Section 11)
As with protection, these approaches are supported on a segment basis. The segment forms of re-routing and restoration operate exactly like their end-to-end counterparts, with the exception that the restoration LSP recovers only a portion of the working LSP. The type of re-routing or restoration to be used on a segment restoration LSP is indicated to the restoration LSP's ingress using the new protection SERO subobject 💜
3. ASSOCIATION Object 🧚
The ASSOCIATION object is used for associating segment protection LSPs when [RFC4090] isn't being used. The ASSOCIATION object is defined in [RFC4872]. In this document, we define a new Association Type field value to support make-before-break. The formats and procedures defined in [RFC4872] are otherwise not modified 🎀
3.1. Format
The Association Type field is 16 bits, and the new value is:
Association Type: 16 bits
Value Type
----- ----
2 Resource Sharing (R)See [RFC4872] for the definition of other fields and values 💖
3.2. Procedures
The ASSOCIATION object is used to associate different LSPs with each other. In the protection and restoration context, the object is used to associate a recovery LSP with the LSP it is protecting. The ASSOCIATION object is also used to support resource sharing during make-before-break. This object MUST NOT be used when association is made according to the methods defined in [RFC4090] 🚫
3.2.1. Recovery Type Processing
Recovery type processing procedures are the same as those defined in [RFC4872], but processing and identification occur with respect to segment recovery LSPs. This means multiple ASSOCIATION objects of type recovery may be present on an LSP 🌸
3.2.2. Resource Sharing Association Type Processing
The ASSOCIATION object with an Association Type of Resource Sharing is used to enable resource sharing during make-before-break. Resource sharing during make-before-break is defined in [RFC3209]. The defined support only works with LSPs that share the same LSP egress. With the introduction of segment recovery LSPs, it is now possible for an LSP endpoint to change during make-before-break 👀
A node includes an ASSOCIATION object with a Resource Sharing Association Type in an outgoing Path message when it wishes to indicate resource sharing across an associated set of LSPs. The Association Source is set to the originating node's router address. The Association ID MUST be set to a value that uniquely identifies the association of LSPs. This MAY be set to the working LSP's LSP ID. Once included, an ASSOCIATION object with a Resource Sharing Association Type SHOULD NOT be removed from the Path messages associated with an LSP ✨
Any node processing a Path message for which it does not have matching state, and which contains an ASSOCIATION object with a Resource Sharing type, examines existing LSPs for matching Association Type, Association Source, and Association ID values. If any match is found, then [RFC3209] style resource sharing SHOULD be provided between the new and old LSPs. See [RFC3209] for additional details 🔥
4. Explicit Control of LSP Segment Recovery 👑
Secondary Explicit Route objects, or SEROs, are defined in this document. They may be used to indicate the branch and merge nodes of recovery LSPs. They may also provide additional information that is to be carried in a recovery LSP's ERO. When upstream control of branch and merge nodes is not desired, SEROs are not used 🫶
4.1. Secondary Explicit Route Object Format
The format of a SECONDARY_EXPLICIT_ROUTE object is the same as an EXPLICIT_ROUTE object. This includes the definition of subobjects defined for the EXPLICIT_ROUTE object. The class of the SECONDARY_EXPLICIT_ROUTE object is 200 (of the form 11bbbbbb) 🌈
4.1.1. Protection Subobject 🎀
Okay so there's a brand new subobject called the protection subobject 💖, and it's made for the SECONDARY_EXPLICIT_ROUTE object. Like we said up top, the protection subobject is what builds the PROTECTION object for the recovery LSP. The full procedures for it are in Section 4.2. Also, it is NOT valid with the Explicit and Record Route objects, so it MUST NOT be included in those objects 🙅♀️
The format looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROTECTION Object Contents |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+L-bit 🔥
This comes from [RFC3209], and it MUST be set to zero for protection subobjects.
Type 🧚
37 Protection
Length 📏
It's defined in [RFC3209], Section 4.3.3.
Reserved 🫶
This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. Zero going out, ignore coming in, we love a clear rule 💅
C-Type 🍓
This is the C-Type of the PROTECTION object that's included.
PROTECTION Object Contents 💜
These are the contents of the PROTECTION object. The format matches the C-Type you've got, and the object header is left out.
4.2. Explicit Control Procedures 🦋
Okay this part is the main event ✨ SEROs ride along in Path messages, and they tell you which node should start a recovery LSP, relative to the LSP that's carrying the SERO. You can have more than one SERO in a Path message, bestie 🌸
To mark the branch and merge nodes of a recovery LSP, an SERO gets created and added to the Path message of the LSP being recovered. Whether you make and insert an SERO is a local decision, and it's outside the scope of this document 🙈
An SERO SHOULD contain at least three subobjects. The first subobject MUST indicate the node that's going to originate the recovery LSP, i.e. the segment branch node. The address it uses SHOULD also be listed in the ERO or in another SERO. That way you know the branch node is really on the LSP path 👑 The second subobject SHOULD be a protection subobject, and it should show the protection or restoration that the recovery LSP is giving. When the protection subobject is there, the LSP Segment Recovery Flags in it MUST be ignored. The final subobject in the SERO MUST be the merge node of the recovery LSP, and it MAY have the L-bit set. Standard ERO subobjects MAY be inserted between the protection subobject and the final subobject. These subobjects MAY be loose or strict 🎀
A node that gets a Path message with one or more SEROs SHOULD look at each SERO to see if it marks a local branch point. To check, you look at the first object of each SERO and see if the address in that subobject can be tied to the local node. If any of the addresses match the local node, then the local node is a branch node. If the local node is NOT a branch node, every SERO it got MUST be sent on, without any changes, in the matching outgoing Path message 💖
At a branch node, the SERO plus the Path message for the LSP being recovered give you everything you need to build the recovery LSP 🦋 The Path message for the recovery LSP is made at the branch node by cloning the objects in the incoming Path message of the LSP being protected. A few objects get replaced or changed in the recovery LSP's outgoing Path message. The Sender_template object MUST be updated to use an address on the local node (in its Tunnel Sender Address field), and the LSP ID MUST be updated so it's unique 🫶 The Session object MUST be updated to use the address from the final subobject of the SERO as the tunnel endpoint address. The tunnel ID MAY be updated, and the extended tunnel ID MUST be set to the local node address. The PROTECTION object gets replaced with the contents of the matching SERO protection subobject, when there is one. In every case, the R-bit of a new PROTECTION object is reset (0). Any RROs and EROs in the incoming Path message MUST NOT be included in the recovery LSP. A new ERO MUST be included, with the contents of the SERO that pointed to a local branch. Like with all EROs, no local information (the local address and any protection subobjects) goes in the ERO that's in the recovery LSP's outgoing Path message. The SERO that pointed to a local branch MUST be left out of the recovery LSP's outgoing Path message. Heads up, by default all the other SEROs you got are passed along in the recovery LSP's outgoing Path message. SEROs MAY be left out of the recovery LSP's outgoing Path message, and also out of the outgoing Path message for the LSP being protected, when the SERO doesn't relate to that outgoing Path message 🧚
The resulting Path message is what creates the recovery LSP. From that point on, Standard Path message processing handles the resulting Path message ✨
4.2.1. Branch Failure Handling 🔥
Sometimes, during setup, a processing node just can't support a requested branch 😭 Also, during setup and during normal operation, PathErr messages can show up at a branch node. How these events get handled depends on a bunch of factors.
When a failure or a received PathErr message is tied to the LSP being protected, the event gets processed by standard processing rules first. That includes making a standard PathErr message. When LSP state gets removed because of a local failure, or because of a PathErr message with the Path_State_Removed flag set (1), the node MUST send a PathTear message downstream on all the other branches 💀
When a failure or a received PathErr message is tied to a recovery LSP, the handling is based on the R-bit, plus the Path_State_Removed flag. In every case, a received PathErr message gets processed by standard processing rules first, and the failure or received PathErr message SHOULD trigger a PathErr message upstream for the LSP being protected. The outgoing PathErr message SHOULD show an error of "Routing Problem/LSP Segment Protection Failed". The outgoing PathErr message MUST include any SEROs that came in a received PathErr message. If there's no SERO in a received PathErr message, or if the failure is local, then an SERO matching the errored LSP or the failed branch MUST be added to the outgoing PathErr message 🌈
When a PathErr message with the Path_State_Removed flag cleared (0) gets received, the outgoing (upstream) PathErr message SHOULD be sent with the Path_State_Removed flag cleared (0) 🌸
When a PathErr message for a recovery LSP with the Path_State_Removed flag set (1) gets received, the processing node MUST look at the R-bit (defined below) of the LSP being protected. The R-bit is carried in the PROTECTION object that started the recovery LSP. When the R-bit is not set (0), the outgoing (upstream) PathErr message SHOULD be sent with the Path_State_Removed flag cleared (0). When the R-bit is set (1), the outgoing (upstream) PathErr message MUST be sent with the Path_State_Removed flag set (1) 👑
In every case where an outgoing (upstream) PathErr message goes out with the Path_State_Removed flag set (1), all path state for the LSP being protected MUST be removed, and the node MUST send a PathTear message downstream on all active branches. Big deal, that's a full cleanup 🧹
4.2.2. Resv Message Processing 🌷
Branch nodes process Resv messages for both recovery LSPs and the LSPs being protected. Resv messages only get passed upstream from branch nodes after a Resv message has been received for the protected LSP. Resv messages on recovery LSPs typically won't trigger upstream Resv messages (for the LSP being protected). The exceptions are when RROs/SRROs are being collected, and during certain ADMIN_STATUS object processing. There's more on the related processing below 💅
4.2.3. Admin Status Change 🦋
Generally, objects in a recovery LSP get created from the matching objects in the LSP being protected. The ADMIN_STATUS object is made the same way, but it needs some special coordination at branch nodes too. Specifically, on top of normal processing, a branch node that gets an ADMIN_STATUS object in a Path message also MUST relay the ADMIN_STATUS object in a Path on every recovery LSP. All Path messages MAY be sent downstream at the same time 🎀
Downstream nodes handle the change in the ADMIN_STATUS object per [RFC3473], including making Resv messages. When the most recently received upstream ADMIN_STATUS object has the R bit set, branch nodes wait for a Resv message with a matching ADMIN_STATUS object to come in on all branches before they relay a matching Resv message upstream ✨
4.2.4. Recovery LSP Teardown 🧚
Removing a recovery LSP follows the standard procedures in [RFC3209] and [RFC3473]. That's true both with and without setting the administrative status 🫶
4.2.4.1. Teardown Without Admin Status Change
The node that starts the teardown originates a PathTear message. Each node that gets a PathTear message handles it with standard processing (see [RFC3209] and [RFC2205]), and it MUST also relay a PathTear on every recovery LSP. All PathTear messages (both the ones from upstream and the ones it originates locally) MAY be sent downstream at the same time 💜
4.2.4.2. Teardown With Admin Status Change
Per [RFC3473], the ingress node originates a Path message with the D and R bits set in the ADMIN_STATUS object. The admin status change procedure defined in Section 4.2.3 MUST then be followed. Once the ingress has all the Resv messages it expects, it MUST follow the teardown procedure described in Section 4.2.4.1 🍓
4.3. Teardown From Non-Ingress Nodes 💀
Like any LSP, any node along a recovery LSP can start removing the recovery LSP 🌈 To do that, the node starting the teardown sends a PathErr message with the right Error Code and the Path_State_Removed flag cleared (0) toward the LSP ingress. Like we covered above, the recovery LSP ingress passes the error along to the LSP ingress, and then the LSP ingress can signal the removal of the recovery LSP 👑
The node starting the teardown can also remove a recovery LSP in a non-graceful way 😬 In that case, the initiator sends a PathTear message downstream, and it also sends a PathErr message with a "Confirmation" indication (error code and value set to zero) toward the LSP ingress node, with the Path_State_Removed flag set (1). This kind of non-ingress teardown is NOT RECOMMENDED, because in some cases it can end up removing the LSP being protected. Be careful out there, bestie 🙅♀️💖
4.3.1. Modified NOTIFY_REQUEST Object Processing 💌
okay so branch and merge nodes get their own parallel set of rules 💅 they can slide a NOTIFY_REQUEST object into the Path and Resv messages of protected and recovery LSPs. branch nodes add them to Path messages, and merge nodes add them to Resv messages ✨
when a node is branching or merging a recovery LSP, it SHOULD include a single NOTIFY_REQUEST object in the Path message of the recovery LSP (for a branch node) or the Resv message of the recovery LSP (for a merge node). the notify node address MUST be set to the router address of the processing node 🫶
branch and merge nodes SHOULD also add a NOTIFY_REQUEST object to the LSP being protected. for branch nodes, the notify node address is the address used in the sender template object of the associated recovery LSP. for merge nodes, it's the address used in the session object of the associated recovery LSP. a locally added NOTIFY_REQUEST object MUST be listed first in an outgoing message, and any received NOTIFY_REQUEST objects MUST then be listed in the message in the order they were received. ngl this can end up as a stack (or ordered list) of objects 📚
normal notification procedures then apply to the LSP being protected. the notifying node MUST issue a Notify message to the recipient indicated by the notify address of the first listed NOTIFY_REQUEST object. under local policy control, a node issuing a Notify message MAY also send one to the Notify Node Address indicated in the last, or any other, NOTIFY_REQUEST object carried in the Path or Resv message 💜
recovery LSP merge and branch nodes remove the object that the recovery branch or merge node added from outgoing Path and Resv messages for the LSP being protected. they do this by removing the NOTIFY_REQUEST object that matches the source address of the recovery LSP (for a merge node) or matches the tunnel endpoint address of the recovery LSP (for a branch node). the matching one will normally be the first listed NOTIFY_REQUEST object. and to cover certain backwards compatibility scenarios, the NOTIFY_REQUEST object SHOULD NOT be removed if it is the sole NOTIFY_REQUEST object.
⚠️ that last bit is the compat safety net, so don't skip it 🙈
note this requires the following change to [RFC3473], Section 4.2.1:
- old text:
- If a message contains multiple NOTIFY_REQUEST objects, only the first object is meaningful. Subsequent NOTIFY_REQUEST objects MAY be ignored and SHOULD NOT be propagated.
- new text:
- If a message contains multiple NOTIFY_REQUEST objects, only the first object used is in notification. Subsequent NOTIFY_REQUEST objects MUST be propagated in the order received.
4.3.2. Modified Notify and Error Message Processing 🔔
branch and merge nodes MUST support this modification to Notify message processing. when a branch or merge node hears about an LSP failure and can't recover from it, it MUST notify the node indicated in the first NOTIFY_REQUEST object received in the Path message (for branch nodes) or Resv message (for merge nodes) associated with the LSP 🥹
5. Secondary Record Route Objects 🦋
Secondary Record Route objects, or SRROs, are what get used to record the path taken by recovery LSPs 🌸
5.1. Format
the format of a SECONDARY_RECORD_ROUTE object is the same as a RECORD_ROUTE object, Class number 21. that includes the definition of subobjects defined for the RECORD_ROUTE object. the class of the SECONDARY_RECORD_ROUTE object is 201 (of the form 11bbbbbb) 🎀
the protection subobject defined above can also be used in SECONDARY_RECORD_ROUTE objects ✨
5.2. Path Processing
SRROs may be carried in Path messages and indicate the presence of upstream recovery LSPs. More than one SRRO MAY be added and present in a Path message 💖
any received SRRO MUST be transmitted by transit nodes, without modification, in the corresponding outgoing Path message.
SRROs are inserted in Path messages by recovery LSP merge nodes. the SRRO is created by copying the contents of an RRO received by the recovery LSP into a new SRRO object. this SRRO is added to the outgoing Path message of the recovered LSP. note that multiple SRROs may be present. the collection of SRROs is controlled via the segment-recording-desired flag in the SESSION_ATTRIBUTE object. this flag MAY be set even when SEROs are not used 🧚
5.3. Resv Processing
SRROs may be carried in Resv messages and indicate the presence of downstream recovery LSPs. More than one SRRO MAY be added and present in a Resv message 🌈
any received SRRO MUST be transmitted by transit nodes, without modification, in the corresponding outgoing Resv message. when Resv messages are merged, the resulting merged Resv SHOULD contain all SRROs received in downstream Resv messages.
SRROs are inserted in Resv messages by branch nodes of recovery LSPs. the SRRO SHOULD be created with the first two objects being the local node address, followed by a protection subobject with the contents of the recovery LSP's PROTECTION object. the remainder of the SRRO SHOULD be created by copying the contents of the RRO received by the recovery LSP. this SRRO SHOULD be added to the outgoing Resv message of the recovered LSP. again, multiple SRROs may be present. 🍓
if the newly added SRRO causes the message to be too big to fit in a Resv message, SRRO subobjects SHOULD be removed from any present SRROs. when removing subobjects, the first two subobjects and the last subobject in an SRRO MUST NOT be removed. note that the subobject that followed a removed subobject MUST be updated with the L-bit set (1). if, after removing all but the first and last subobjects in all SRROs, the resulting message is still too large to fit, then whole SRROs SHOULD be removed until the message does fit 💀
6. Dynamic Control of LSP Segment Recovery 👑
dynamic identification of branch and merge nodes is supported via the LSP Segment Recovery Flags carried in the PROTECTION object. the LSP Segment Recovery Flags are carried within one of the Reserved fields defined in the PROTECTION object defined in [RFC4872]. LSP Segment Recovery Flags are used to indicate when LSP segment recovery is desired. when these bits are set, branch and merge nodes are dynamically identified 🦋
note, the procedures defined in this section parallel the explicit control procedures defined above in Section 4.2. the primary difference is in the creation of a recovery LSP's ERO 💅
6.1. Modified PROTECTION Object Format
LSP Segment Recovery Flags are carried in the PROTECTION object of the same C-Type defined in [RFC4872]. the format of the flags is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(37) | C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|R| Reserved | Seg.Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+In-Place (I): 1 bit 🌸
when set (1), this indicates that the desired segment recovery type indicated in the LSP Segment Recovery Flag is already in place for the associated LSP.
Required (R): 1 bit 🔥
when set (1), this indicates that failure to establish the indicated protection should result in a failure of the LSP being protected.
Segment Recovery Flags (Seg.Flags): 6 bits 🌈
this field is used to indicate when an upstream node desires LSP Segment recovery to be dynamically initiated where possible. the values used in this field are identical to the values defined for LSP Flags; see [RFC4872].
see [RFC4872] for the definition of other fields.
6.2. Dynamic Control Procedures
LSP Segment Recovery Flags are set to indicate that LSP segment recovery is desired for the LSP being signaled. the type of recovery desired is indicated by the flags. deciding to set the LSP Segment Recovery Flags is a local matter and outside the scope of this document. a value of zero (0) means that no dynamic identification of segment recovery branch nodes are needed for the associated LSP. when the In-Place bit is set, it means the desired type of recovery is already in place for that particular LSP 🫶
a transit node receiving a Path message containing a PROTECTION object with a non-zero LSP Segment Recovery Flags value and the In-Place bit clear (0) SHOULD consider if it can support the indicated recovery type and if it can identify an appropriate merge node for a recovery LSP. dynamic identification MUST NOT be done when the processing node is identified as a branch node in an SERO. if a node is unable to provide the indicated recovery type or identify a merge node, the Path message MUST be processed normally, and the LSP Segment Recovery Flags MUST NOT be modified 😭
when a node dynamically identifies itself as a branch node and identifies the merge node for the type of recovery indicated in the LSP Segment Recovery Flags, it attempts to set up a recovery LSP. the dynamically identified information, together with the Path message of the LSP being recovered, is used to create the recovery LSP 🧚
the Path message for the recovery LSP is created at the branch node by cloning the objects carried in the incoming Path message of the LSP being protected. certain objects are replaced or modified in the recovery LSP's outgoing Path message. the Sender_template object MUST be updated to use an address (in its Tunnel Sender Address field) on the local node, and the LSP ID MUST be updated to ensure uniqueness. the Session object MUST be updated to use the address of the dynamically identified merge node as the tunnel endpoint address, the tunnel ID MAY be updated, and the extended tunnel ID MUST be set to the local node address. the PROTECTION object is updated with the In-Place bit set (1). any RROs and EROs present in the incoming Path message MUST NOT be included in the recovery LSP. a new ERO MAY be created based on any path information dynamically computed by the local node 💖
the resulting Path message is used to create the recovery LSP. while the recovery LSP exists, the PROTECTION object in the original Path message (unless overridden by local policy) MUST also be updated with the In-Place bit set (1). from this point on, Standard Path message processing is used in processing the resulting and original Path messages 🌸
the merge node of a dynamically controlled recovery LSP SHOULD reset (0) the In-Place bit in the PROTECTION object of the outgoing Path message associated with the terminated recovery LSP.
unlike with explicit control, if the creation of a dynamically identified recovery LSP fails for any reason, the recovery LSP is removed, and no error message or indication is sent upstream. with this exception, all the other procedures for explicitly controlled recovery LSPs apply to dynamically controlled recovery LSPs. these other procedures are defined above in Sections 4.2.1 through 4.2.4 🍓
7. Updated RSVP Message Formats 🎀
Okay bestie, this section shows the RSVP message formats as they look after this document's changes 💅. Wherever the unidirectional LSP version differs from the bidirectional one, the two get their own grammar, so read the one that matches your LSP type. 🦋
The Path message format is:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ... ]
[ <ADMIN_STATUS> ]
[ <ASSOCIATION> ... ]
[ <SECONDARY_EXPLICIT_ROUTE> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>For unidirectional LSPs, the sender descriptor looks like this 🌸:
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
[ <SECONDARY_RECORD_ROUTE> ... ]For bidirectional LSPs, it's the same except it also has a mandatory upstream label slot 🧚:
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
<UPSTREAM_LABEL>
[ <SECONDARY_RECORD_ROUTE> ... ]The PathErr message format is:
<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <SECONDARY_EXPLICIT_ROUTE> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>And the Resv message format is:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <NOTIFY_REQUEST> ... ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC>
<LABEL> [ <RECORD_ROUTE> ]
[ <SECONDARY_RECORD_ROUTE> ... ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
[ <SECONDARY_RECORD_ROUTE> ... ]
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
[ <SECONDARY_RECORD_ROUTE> ... ]8. Security Considerations 🔥
Let's talk security, because this part matters. This document adds new message objects for GMPLS signaling [RFC3473]. It doesn't add any new signaling messages, and it doesn't change the relationship between LSRs that are adjacent in the control plane 🫶.
The procedures here do mean more topology info ends up in signaling messages. SEROs and SRROs are there, and they carry more info about LSP paths than plain EROs and RROs do. So if someone intercepts a signaling message, they could work out slightly more about the state of the network than before 😭. The authors judge this a very minor risk, since the same information is already available through routing 💀.
Other than that, this document adds no further security considerations. For the relevant security considerations, see [RFC3473] 🌈.
9. IANA Considerations 💜
IANA has assigned the following values for the namespaces defined in this document and covered in this section ✨.
9.1. New Association Type Assignment 🦋
IANA has made the following assignment to the "GMPLS Signaling Parameters" Registry (see [RFC4872]), which is located at http://www.iana.org/assignments/gmpls-sig-parameters.
Value Type
----- ----
2 Resource Sharing (R) [RFC4873]9.2. Definition of PROTECTION Object Reserved Bits 🌸
This document defines bits carried in the Reserved field of the PROTECTION object, which is defined in [RFC4872]. Since [RFC4872] doesn't request an IANA registry for these bits, no IANA action is needed for this definition 🙌.
9.3. Secondary Explicit Route Object 🧚
IANA has made the following assignments in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry, which is located at http://www.iana.org/assignments/rsvp-parameters.
A new class named SECONDARY_EXPLICIT_ROUTE has been created in the 11bbbbbb range (200), with this definition:
Class Types or C-types:
Same values as EXPLICIT_ROUTE object (C-Num 20)
For Class 1, C-Type 1, the following additional Subobject type is
defined:
37 PROTECTION [RFC4873]9.4. Secondary Record Route Object 🍓
IANA has made the following assignments in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry, which is located at http://www.iana.org/assignments/rsvp-parameters.
A new class named SECONDARY_RECORD_ROUTE has been created in the 11bbbbbb range (201), with this definition:
Class Types or C-types:
Same values as RECORD_ROUTE object (C-Num 21)
For Class 1, C-Type 1, the following additional Subobject type is
defined:
37 PROTECTION [RFC4873]9.5. New Error Code ⭐
IANA has made the following assignment in the "Routing Problem" subsection of the "Error Codes and Values" section of the "RSVP PARAMETERS" registry, which is located at http://www.iana.org/assignments/rsvp-parameters.
21 = LSP Segment Protection Failed [RFC4873]9.6. Use of PROTECTION Object C-type 👑
This document modifies the PROTECTION object, class number 37, C-Type 2 (defined in Section 14.1. of [RFC4872]) 💖.
10. References 📚
10.1. Normative References 🫶
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC4872] Lang, J.P., 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.10.2. Informative References 🌈
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005.
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D.
Papadimitriou, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Recovery Functional Specification," RFC
4426, March 2006.
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427, March
2006.Authors' Addresses 🎀
Here's where you can reach the authors, bestie 💌:
Lou Berger
LabN Consulting, L.L.C.
Phone: +1 301-468-9228
EMail: lberger@labn.net
Igor Bryskin
ADVA Optical
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
EMail: IBryskin@advaoptical.com
Dimitri Papadimitriou
Alcatel
Francis Wellesplein 1
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel-lucent.be
Adrian Farrel
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.ukFull Copyright Statement ⚖️
The legal stuff, kept complete and exactly as written 🙏:
Copyright (C) The IETF Trust (2007).
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 🔍
Here's the IP situation. The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to implementing or using the technology in this document, or on whether any license under those rights might be available. It also doesn't claim to have independently looked for any such rights. Info on the procedures for rights in RFC documents is in BCP 78 and BCP 79 📖.
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: rfc4873 2007-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms