RFC 5063
Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart
RFC 5063: Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart 🎀
okay bestie, this one is giving big "restart without losing your whole life" energy 💖 It's written by A. Satyanarayana, Ed. and R. Rahman, Ed., both from Cisco Systems. It's a Standards Track doc from the Network Working Group, dated October 2007. It updates RFC 2961 and RFC 3473, and its title block doesn't list any documents it obsoletes 📜✨
Status of This Memo 📝
ngl this part is the legal-ish bit, but it matters 💅 The doc specifies an Internet standards track protocol for the Internet community, and it wants feedback and suggestions for making things better 🫶 For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈
Abstract 🦋
So this doc extends the RSVP Graceful Restart mechanisms from RFC 3473 🔥 The big idea is that signaling state can be recovered based on the last Path message the restarting node sent 👑
Graceful Restart already existed (it's also called recovery from nodal faults) 💜 It lets a node grab signaling state back from its neighbors when the data plane kept its forwarding state through the restart 🧚 The catch is that it didn't fully cover ingress nodes or every RSVP object, which is kinda tragic 😭
These extensions build on the RSVP Hello stuff from RFC 3209 and the nodal-fault recovery from RFC 3473 🎀 With them, the restarting node can recover all the Path state it sent before, including the Explicit Route Object and the downstream (outgoing) interface identifiers 💖 It can also recover signaling state after an ingress node restarts ✨
Important: these extensions are NOT used to create or restore data plane state. They only deal with the signaling side 🙈
The extensions can also optionally use Summary Refresh (from RFC 2961) to cut down on the messages sent during the Recovery Phase, especially when the restarting node already recovered state locally for one or more Label Switched Paths (LSPs) 🌸
Table of Contents 📜
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................5
3. Terminology .....................................................5
4. Extensions to Nodal Fault Handling ..............................5
4.1. RecoveryPath Message Format ................................5
4.2. Capability Object ..........................................6
4.2.1. Conformance .........................................7
4.3. Related Procedures .........................................7
4.4. Procedures for the Capability Object .......................8
4.4.1. Procedures for the Downstream Neighbor ..............8
4.4.2. Procedures for the Restarting Node ..................8
4.5. Procedures for the RecoveryPath Message ....................9
4.5.1. Procedures for the Downstream Neighbor ..............9
4.5.2. Procedures for the Restarting Node .................10
4.5.2.1. Path and RecoveryPath Message Procedures ..11
4.5.2.2. Re-Synchronization Procedures .............12
4.5.2.3. Procedures on Expiration of
Recovery Period ...........................13
4.6. Compatibility .............................................13
5. RecoveryPath Summary Refresh ...................................14
5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects ...........15
5.2. RecoveryPath Srefresh Capable Bit .........................16
5.2.1. Procedures .........................................16
5.2.2. Compatibility ......................................17
5.3. RecoveryPath Summary Refresh Procedures ...................17
5.3.1. Generation of RecoveryPath-Related Srefresh
Messages ...........................................17
5.3.2. RecoveryPath-Related Srefresh Receive
Processing and NACK Generation .....................19
5.3.3. RecoveryPath-Related MESSAGE_ID NACK
Receive Processing .................................19
6. Security Considerations ........................................20
7. Acknowledgments ................................................21
8. IANA Considerations ............................................21
9. Normative References ...........................................221. Introduction 🧚
okay so RSVP Graceful Restart is defined in [RFC3473], and it uses the mechanisms from [RFC3209] 💅 When the data/forwarding plane can keep its state through a restart of the RSVP agent that set it up, Graceful Restart lets that agent resync its state using updates from its neighboring RSVP agents, and then match that state against the data plane state it kept 🔥 [RFC3209] describes using RSVP Hello messages to detect the state of an adjacent RSVP agent 🦋 [RFC3473] extends that to advertise whether a node can keep its data/forwarding plane state across a restart, aka a "nodal fault" 💖 [RFC3473] also defines the Recovery Label object, which goes in the Path message from the RSVP neighbor upstream of a restarting node, to say "hey, this Path message is for data plane state that already exists" 🌈
This document adds extensions for two parts of graceful restart that weren't supported before 🎀 They let a restarting node recover every object from the Path messages it sent earlier, including the Explicit Route Object (ERO), from its downstream neighbors, which brings back the control plane state 👑 The extensions don't help recover or create data/forwarding plane state, so they can only rebuild control plane state that matches the in-place data/forwarding state 🙈 They also let an ingress node do graceful restart even when it didn't keep full RSVP state across the restart 💜 And these extensions work for LSPs of the different switching types defined in [RFC3471] 🍓
Per [RFC3473], a restarting node can tell which Path messages belong to LSPs being recovered, because they have a Recovery Label object 🫶 To figure out the downstream (outgoing) interface and the associated label(s), the restarting node has to check the data plane 👀 That might not be possible on every kind of node 😬 Also, data plane info isn't enough to rebuild all the Path state that was sent earlier 💀 So in those cases, the only place to get RSVP state from is the downstream RSVP neighbor 🌸
For example, if the restarting node is an ingress node, it may need to recover all the Path state it sent earlier ✨ That state could include (but isn't limited to) the Protection object, the Admin Status object, the Session Attribute object, the Notify Request object, and the Sender Tspec object 💖 A restarting transit node may have changed the Path state it received, and then sent that changed state in its earlier Path message, and that can't be rebuilt internally during recovery 🙈
Another example of state that the data plane can't fully recover in some cases is the ERO that was sent earlier 🦋 Recovering it keeps the downstream LSP state from changing a bunch afterward 🧚 On a restarting ingress node, the ERO might have come from configuration or from an earlier path computation 💅 A restarting transit node might have done some kind of path computation because it got no ERO or got a loose hop in the ERO 🔥 Besides the ERO, the restarting node may have changed other Path state it received and then sent in its earlier Path message, and that can't be rebuilt internally during recovery either 👑
The defined extensions give a restarting upstream node all the info it sent earlier in Path messages 💜 That happens when the downstream RSVP neighbor sends a new message for every Path message it got from the restarting node, after RSVP communication is back up with a restarted node that supports the recovery procedures in Section 4.5.2 of this document 🍓
The new message is called the RecoveryPath message 🎀 It carries the contents of the last Path message received, back to the restarting node 🫶 The restarting node can use the RecoveryPath message, together with the state in the received Path message, to match control and data plane state and check the forwarding state against what the neighboring RSVP nodes present 🌈
The restarting node says it wants to receive and process RecoveryPath messages by including a new object called the Capability object, with the RecoveryPath Desired bit set, in the Hello messages it sends to its downstream RSVP neighbor 💖 The downstream RSVP neighbor says it can send RecoveryPath messages by including the Capability object with the RecoveryPath Transmit Enabled bit set in its Hello messages to the restarting node 👑 So with help from the Capability object, both sides can tell whether these RecoveryPath extensions can be used to recover signaling state after a restart ✨
If the restarting node is a transit node, it will receive a Path message with a Recovery Label object from its upstream RSVP neighbor 🦋 On top of that, the RecoveryPath message lets transit nodes rebuild any state they dynamically constructed earlier, like ERO sub-objects 🧚 If the restarting node is an ingress node, it can recover all the significant signaling state from the RecoveryPath message 🔥
Selective sending of the RecoveryPath message is supported by enhancing the Summary Refresh mechanisms from [RFC2961] 💅 When Recovery Summary Refresh is supported, the restarting node can pick which LSPs it wants RecoveryPath messages for 🌸 That's useful when the restarting node can locally recover signaling state for only some of its previously active LSPs 💜
Restarting egress nodes and Resv message processing aren't affected by these extensions, so check [RFC3473] for the details 🙈
2. 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] 🎀
3. Terminology 💖
The reader is assumed to already know the terminology defined in [RFC3209] and [RFC3473] 🫶
In this document, the term "node" (when used for a restarting or restarted node) usually means the control plane component, which is the signaling controller for a data plane switch 🌈
4. Extensions to Nodal Fault Handling ✨
This section presents the protocol modifications to Section 9 of [RFC3473] 👑
4.1. RecoveryPath Message Format 🎀
okay so a RecoveryPath message is basically a twin of a Path message 🦋 It follows the format from [RFC3473], but it wears a brand new message number (30) so everyone can tell them apart 💅
<RecoveryPath Message> ::= <Path Message>The destination address used in the IP header of a RecoveryPath message MUST be the same as the destination address used in the IP header of the corresponding Resv message last generated by the sending node. Except as specified below, all objects in a RecoveryPath message are identical to the objects in the corresponding Path message last received by the sending node. ✨
4.2. Capability Object 💖
Capability objects travel inside RSVP Hello messages 🧚 The Capability object uses Class-Number 134 (of form 10bbbbbb) and C-Type of 1.
The Hello message format gets a little glow-up too 💅
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
[ <RESTART_CAP> ] [ <CAPABILITY> ]Here's what a Capability object looks like, bestie 👑
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(134)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Now the three flag bits, which are literally the whole vibe 🔥
- RecoveryPath Transmit Enabled (T): 1 bit When set (1), it means the sending node is enabled to send RecoveryPath messages 🦋 Absence of the Capability object MUST be treated as if the T-bit is cleared (0).
- RecoveryPath Desired (R): 1 bit When set (1), it means the sending node wants to receive RecoveryPath messages 🌸 Absence of the Capability object MUST be treated as if the R-bit is cleared (0).
- RecoveryPath Srefresh Capable (S): 1 bit When set (1) along with the R-bit, it means the sending node can receive and process Srefresh messages with the RecoveryPath Flag set (1) in the MESSAGE_ID LIST object 🧠 Absence of the Capability object MUST be treated as if the S-bit is cleared (0). The related procedures live in Section 5.2.1.
- Reserved bits Reserved bits MUST be set to zero on transmission and MUST be ignored on receipt 🙈
4.2.1. Conformance 💅
All nodes supporting the extensions defined in this document MUST be able to transmit, and properly receive and process RecoveryPath messages 🫶 All nodes MUST be able to set both the T and R bits. Both the T and R bits SHOULD be set (1) by default. A node MAY allow RecoveryPath message transmission and reception to be independently disabled based on local policy. When RecoveryPath message transmission is disabled, the T-bit MUST be set to zero (0). When RecoveryPath message reception is not desired, the R-bit MUST be set to zero (0).
Any node that supports the extensions defined in this document and sets the Refresh-Reduction-Capable bit [RFC2961] SHOULD support setting of the S-bit and support the mechanisms defined in Section 5. 🔥
4.3. Related Procedures 🌈
This document does not modify the existing procedures for sending and receiving RSVP Hello messages, as defined in [RFC3209], or the Restart_Cap object in RSVP Hello messages, as defined in [RFC3473]. The procedures for control channel faults are defined in [RFC3473] and are not changed by this document.
The presented extensions require the use of RSVP Hellos, as defined in [RFC3209], and the use of the Restart_Cap object extension as defined in [RFC3473]. The presented extensions address only "Nodal Faults" as defined in [RFC3473]. Control channel faults are fully addressed in [RFC3473].
Note: There are no changes to the procedures defined in Section 9.5.3 in [RFC3473] (Procedures for the Neighbor of a Restarting node). There are no changes to the procedures defined in Section 9.5.2 in [RFC3473] if the restarting node is an egress node.
There are no changes to the procedures with respect to the data/forwarding plane as described in [RFC3473]. In particular, a restarting node MUST NOT create data/forwarding plane state as the result of any of the extensions defined in this document. 🚫
The following sections assume previously defined procedures are followed, except where explicitly modified. ✨
4.4. Procedures for the Capability Object 🦋
4.4.1. Procedures for the Downstream Neighbor 🌸
If a node is capable of sending RecoveryPath messages, it MUST include the Capability object with the RecoveryPath Transmit Enabled (T) bit set (1) in all its Hello messages.
If the downstream RSVP neighbor receives Hello messages from a restarting node, with the Restart_Cap object, as defined in [RFC3473], and with the Capability object with the RecoveryPath Desired (R) bit set (1), it MUST treat the restarting node as capable of receiving and processing RecoveryPath messages as defined in this document. 💖
If the downstream RSVP neighbor receives a Capability object in a Hello message with the RecoveryPath Desired (R) bit set (1), but without the Restart_Cap object, it MUST process the Hello message as if the RecoveryPath Receive Desired (R) bit is cleared (0) in the Hello message.
If the downstream RSVP neighbor does not receive the Capability object in Hello messages sent by the restarting node, or the RecoveryPath Desired (R) bit is cleared (0) in the Capability object, it MUST treat the restarting node as not capable of supporting the RecoveryPath message procedures defined in this document, and MUST revert to recovery procedures as defined in [RFC3473]. 😭
4.4.2. Procedures for the Restarting Node 🧚
A node that expects to recover RSVP state by the receipt and processing of RecoveryPath messages according to procedures defined in this document MUST include the Capability object with the RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to its neighbors. The node MUST also include the Restart_Cap object, as defined in [RFC3473], in all those Hello messages. 🎀
If the Recovery Time is zero (0), or the restarting node does not support/desire the use of RecoveryPath messages, the RecoveryPath Desired (R) bit MUST be cleared (0) in the Capability object included in Hello messages, or the Capability object MAY be omitted from Hello messages sent by the restarting node.
During the Recovery Period, if the restarting node receives Hello messages from a downstream RSVP neighbor with the RecoveryPath Transmit Enabled (T) bit set (1) in the Capability object and the Restart_Cap object, as defined in [RFC3473], it MUST treat the downstream RSVP neighbor as capable of sending RecoveryPath messages according to procedures defined in Section 4.5.1. If the restarting node expects to recover RSVP state by the receipt and processing of RecoveryPath messages, it MUST follow procedures defined in Section 4.5.2, with the downstream RSVP neighbor. 🥰
During the Recovery Period, if the restarting node receives Hello messages from a downstream RSVP neighbor with the RecoveryPath Transmit Enabled (T) bit cleared (0) in the Capability object, or with the Capability object not present, it MUST treat the downstream RSVP neighbor as not capable of the RecoveryPath message procedures defined in this document, and, it MUST revert to the recovery procedures defined in [RFC3473] immediately, with the downstream RSVP neighbor. 💀
4.5. Procedures for the RecoveryPath Message 🌟
4.5.1. Procedures for the Downstream Neighbor 👑
After a downstream RSVP neighbor has detected that its upstream node has restarted, is capable of recovery as defined in [RFC3473], and is capable of receiving RecoveryPath messages as defined in Section 4.4, the downstream RSVP neighbor MUST send a RecoveryPath message for each LSP associated with the restarting node for which it has sent a Resv message. During the Recovery Period, if the downstream RSVP neighbor detects that the restarting node is not capable of receiving RecoveryPath messages, by the absence of the Capability object or the RecoveryPath Desired (R) bit cleared (0) in the Capability object in the restarting node's Hello messages, the downstream RSVP neighbor SHOULD NOT send the RecoveryPath messages to the restarting node. 🙈
The RecoveryPath message is constructed by copying all objects from the last received associated Path message, with the following exceptions:
- The MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects are not copied. Any MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects used in RecoveryPath messages are generated based on procedures defined in [RFC2961].
- The Integrity object is not copied. Any Integrity objects used in RecoveryPath messages are generated based on procedures defined in [RFC2747].
- The RSVP Hop object is copied from the most recent associated Resv message sent to the restarted node for the LSP being recovered.
- In the sender descriptor, the Recovery Label object MUST be included, with the label value copied from the label value in the Label object in the most recent associated Resv message sent to the restarted node, for the LSP being recovered. 🔥
All other objects from the most recent received Path message MUST be included in the RecoveryPath message. ✨
All RecoveryPath messages SHOULD be sent at least once within approximately 1/2 of the Recovery Time advertised by the restarted neighbor. If there are many LSPs to be recovered by the restarted node, the downstream RSVP neighbor should avoid sending RecoveryPath messages in a short time interval to avoid overloading the restarted node's CPU. Instead, it should spread the messages across 1/2 the Recovery Time interval. The range of Recovery Time is dependent on many factors, including but not limited to the CPU processing power on the restarting node as well as the upstream and downstream neighbors, the amount of CPU available for processing RSVP recovery procedures, and the implementation specifics that affect the amount of time taken to verify the received recovery state against existing forwarding plane state. Such discussion is out of scope of this document. 🧠
After sending a RecoveryPath message and during the Recovery Period, the node SHOULD periodically resend the RecoveryPath message until it receives a corresponding response. A corresponding response is a Message ID acknowledgment or a Path message for the LSP the RecoveryPath message represents. Each such resend attempt is at the end of any Message ID rapid retransmissions, if the Message ID mechanism is used. If the Message ID mechanism is not in use, the period between resend attempts SHOULD be such that at least 3 attempts are completed before the expiry of 3/4 the Recovery Time interval. Each such resend attempt MUST treat the RecoveryPath message as a new message and update the MESSAGE_ID object according to procedures defined in [RFC2961]. Note, per [RFC3473], Resv messages are suppressed during this recovery period until a corresponding Path message is received. 🦋
4.5.2. Procedures for the Restarting Node ✨
okay so these procedures kick in during the "state recovery process" and the "Recovery Period" (see Section 9.5.2 of [RFC3473]) 🕰️ any RecoveryPath message that shows up after the Recovery Period has expired SHOULD get matched against the local LSP state. if the node finds matching, fully resynchronized state, it SHOULD send a Path message downstream 💌 if it finds non-resynchronized state, or no LSP state that matches the RecoveryPath message at all, the restarted node MAY send a PathTear message built from the RecoveryPath message 🧹 this helps clean up the unrecovered RSVP and associated forwarding state downstream of the restarted node, so it's giving efficiency 💅 and the restarting node MUST NOT create data plane or forwarding state to match the received RecoveryPath message 🙅♀️ that's a hard no, bestie.
the rest of the procedures are split into three sub-sections 🎀 the term "resynchronized state" was first defined in [RFC3473], and this document tweaks it a bit. it refers to LSP state that is fully recovered 🫶
signaling state can be recovered from sources other than the mechanisms defined in this document 🧩 the restarting node SHOULD treat signaling state as resynchronized for all of those LSPs and follow the matching procedures below 💜 also, local policy is allowed to override the recovery procedures below 👑
again, there are NO changes to the procedures in Section 9.5.2 of [RFC3473] if the restarting node is an egress node 🦋
4.5.2.1. Path and RecoveryPath Message Procedures 🌸
when a node gets a RecoveryPath message during the Recovery Period, it first checks whether it has resynchronized RSVP state linked to that message ✨ if resynchronized state exists, AND reliable message delivery [RFC2961] is supported, AND a MESSAGE_ID object is in the RecoveryPath message, the node MUST follow the Message ID acknowledgment procedures from [RFC2961] and consider the message processed 🎉 if there's resynchronized state but no MESSAGE_ID object, or reliable message delivery [RFC2961] isn't supported, the node SHOULD send a trigger Path message and consider the message processed 💖
if non-resynchronized state is found, or the node is the ingress, the node saves the info in the RecoveryPath message and keeps going with the procedures in Section 4.5.2.2 🧚
if no associated RSVP state is found and the node is NOT the ingress node, the node saves the info in the RecoveryPath message for later use 🍓
note the following modifies Section 9.5.2 of [RFC3473]:
When a node receives a Path message during the Recovery Period, the node first locates any RSVP state associated with the message. If resynchronized RSVP state is found, then the node handles this message according to previously defined procedures.
if non-resynchronized state is found, the node saves the info in the Path message, including the Recovery_Label object, and keeps going with Section 4.5.2.2 🩵
per [RFC3473], if no matching RSVP state is found AND the message does NOT carry a Recovery_Label object, the node treats it as a setup for a new LSP and handles it with the previously defined procedures 🆕
if no matching RSVP state is found and the message DOES carry a Recovery_Label object, the node saves the info in the Path message, including the Recovery_Label object, for later use 📦
4.5.2.2. Re-Synchronization Procedures 🔄
after the node gets the RecoveryPath message and, for non-ingress LSPs, the matching Path message with a Recovery Label object, the restarting node SHOULD locate and associate the corresponding forwarding state using the info it received 🔍 it ties the corresponding active forwarding plane state to the following signaled info:
- the upstream data interface is recovered from the
RSVP HOPobject in the received Path message. - the label on the upstream data interface is recovered from the
Recovery Labelobject in the received Path message. if the LSP is bidirectional, the label for the upstream direction is recovered from theUpstream Labelobject in the received Path message. - the downstream data interface is recovered from the
RSVP HOPobject in the received RecoveryPath message. - the label on the downstream data interface is recovered from the
Recovery Labelobject in the received RecoveryPath message. if the LSP is bidirectional, the label for the upstream direction is recovered from theUpstream Labelobject in the RecoveryPath message.
if complete forwarding state is located, the restarted node MUST treat the LSP as resynchronized and MUST send a trigger Path message downstream 🚀 the Explicit Route object in that Path message SHOULD match the Explicit Route object received in the RecoveryPath message 🗺️ on top of that, the restarted node SHOULD recover state from the other objects in the RecoveryPath message 🧁 ideally, the resulting Path message shouldn't cause any redundant or unnecessary reprocessing of state along the remaining downstream nodes 🌈 the dream is that, except for MESSAGE_ID processing and recovery processing, the downstream RSVP neighbor treats the Path message as a refresh (so it shouldn't trigger any Path messages with changed state further downstream) 💫
if no forwarding state is located, the node treats the received Path message as a setup request for a new LSP 🛠️ the outgoing interface and label(s) indicated in the RecoveryPath message SHOULD be reused when possible 🔁 all other info in the RecoveryPath message MAY also be used 🧃 forwarding state MUST NOT be created except after receiving a Path message from upstream or, at an ingress node, receiving a command from the management plane 🚫 and the forwarding state that gets created is subject to local policy, while the info received from downstream in the RecoveryPath message is treated only as advisory 🧠
4.5.2.3. Procedures on Expiration of Recovery Period ⏰
there are a few cleanup steps to follow when the Recovery Period ends 🧼 at that point, any state that was installed because of a received RecoveryPath message and is NOT resynchronized SHOULD be discarded 🗑️
any Path messages that were received carrying a Recovery_Label that has NOT been resynchronized MUST be treated as if they were received during the Recovery Period and processed per [RFC3473] 📬
per [RFC3473], any other state that isn't resynchronized during the Recovery Period SHOULD be removed at the end of the Period 🫧
4.6. Compatibility 🤝
this document introduces a new RSVP signaling message called the RecoveryPath message 🎀 it's generated by the downstream RSVP neighbor of a restarting node 🧑🤝🧑 to advertise the capability of sending and receiving RecoveryPath messages, this document also introduces the Capability object 🪪 it gets included in Hello messages sent by a restarting node and its downstream RSVP neighbors 💬
if a restarting node does NOT support the Capability object, it discards the object (the Class-Number is of the form 10bbbbbb) and reverts to the recovery processing defined in [RFC3473] 🙃 the restarting node won't include the Capability object in its Hello messages 📵 so every downstream RSVP neighbor that detects the restarting node can't support the extensions in this document won't send RecoveryPath messages to it, and will fall back to the recovery processing in [RFC3473] 🛟
if a downstream RSVP neighbor does NOT support the Capability object, it discards the object it received in Hello messages and reverts to the recovery processing in [RFC3473] 😅 that neighbor won't include the Capability object in its own Hello messages either 🫠 so the restarting node figures out the downstream neighbor can't support the extensions in this document, and it reverts to the recovery processing in [RFC3473] 💅
5. RecoveryPath Summary Refresh 🧚✨
Okay bestie, this section is all about deciding which LSP state gets sent in RecoveryPath messages 💅 It's basically a glow-up of the Summary Refresh mechanism from [RFC2961]. It runs on the RecoveryPath Srefresh Capable (S) bit in the Capability object (see Section 4.2), which rides along in the Hello message from [RFC3209] and [RFC3473]. The whole thing is called RecoveryPath Summary Refresh 🦋
Selective transmission of RecoveryPath messages is controlled pretty much the same way Path or Resv messages are controlled with standard Summary Refresh (see [RFC2961]) 🎀 In standard Summary Refresh, a node sends an Srefresh message to tell its neighbor which Path and Resv state it has installed locally and available. The receiver then tries to find matching state. If nothing matches, it can ask for the missing state by sending an Srefresh NACK back to the sender of the Srefresh message. Once that NACK arrives, the corresponding Path or Resv message gets sent 📨 MESSAGE_ID information is what lets everyone identify which Path and Resv state they're talking about 🫶
RecoveryPath Summary Refresh extends that same process to the Path state that can be represented in RecoveryPath messages 🌸 The difference is that here, the Srefresh messages represent Path messages that were previously received, not previously transmitted. That's the main difference between standard Summary Refresh and RecoveryPath Summary Refresh, and it's the whole point of this section 👑
When a node restarts and can support the mechanisms in this section, it includes the Capability object with the RecoveryPath Desired (R) bit set and the RecoveryPath Srefresh Capable (S) bit set in the Hello messages it sends to its RSVP neighbors 🍓
When a neighbor of the restarting node detects a restart (see [RFC3209]), it works out two things. First, that the restarted node can receive RecoveryPath messages, as defined in Section 4.4. Second, that the restarted node is asking for RecoveryPath Srefresh messages, because the S bit is set in its Capability object 🔥 When both of those check out, the neighbor generates one or more Srefresh messages. Each one says which Path state can be represented in a RecoveryPath message. Inside these Srefresh messages, that Path state is represented using MESSAGE_ID information, and the information travels inside MESSAGE_ID LIST objects. To mark a MESSAGE_ID LIST object as being for recovery purposes, a new flag gets set in it. It's called the RecoveryPath Flag, and we'll define it below 🧚
Next, the restarted node can use the Srefresh message and the MESSAGE_ID LIST object to figure out which of its transmitted Path state matches. It does this by matching Epoch and Message ID tuples against the Path messages it transmitted downstream before the restart 🔍
If matching state is found, the restarted node operates as if it had received a RecoveryPath message, per Section 4.5.2 💖 If no matching state can be found, the restarted node generates a Srefresh NACK (see Section 5.4 of [RFC2961]). That Srefresh NACK also gets the new RecoveryPath Flag, so everyone knows the NACK is about RecoveryPath messages 🙈
When the downstream node receives a Srefresh NACK, it generates a RecoveryPath message for the Path state indicated by each entry in the MESSAGE_ID LIST. From there, the restarted node and the downstream RSVP neighbor follow the procedures in Section 4 above 💅✨
5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects 🌈
The MESSAGE_ID ACK/NACK objects and the MESSAGE_ID LIST object are defined in [RFC2961], and this document updates them 🦋 A new bit is defined inside the existing Flags field of each object. That bit says the object carries MESSAGE_ID information about Path state that can be recovered using RecoveryPath messages. The same flag value is used in all of these objects, for consistency 💜
MESSAGE_ID_ACK object
MESSAGE_ID_NACK object
See Section 4.3 of [RFC2961] for definition of other fields.
MESSAGE_ID LIST object
See Section 5.1 of [RFC2961] for definition of other fields.
Flags: 8 bits
0x02: RecoveryPath Flag
Indicates that the associated object carries MESSAGE_ID
information related to one or more Path messages that can be
recovered using a RecoveryPath message.5.2. RecoveryPath Srefresh Capable Bit 🎀
The Capability object and the RecoveryPath Srefresh Capable (S) bit are defined in Section 4.2. No new definitions here, just a reminder that they exist 💅
5.2.1. Procedures 🍓
To support the selective receipt of RecoveryPath messages defined in this section, a restarting node MUST support receiving and processing RecoveryPath messages as defined in Section 4.5.2. It MUST also indicate that capability by including the Capability object with the RecoveryPath Desired (R) bit set, as defined in Section 4.4.2, in its Hello messages 💖
To tell an RSVP neighbor that selective transmission of RecoveryPath messages is desired, a node MUST set (1) the S-bit in the Capability object in all Hello messages it sends. When the restarting node does not want to receive RecoveryPath messages (see Section 4.4.2), or does not want the selective transmission mechanism defined in this section, it MUST clear (0) the S-bit in the Capability object if it's included in Hello messages 🙅♀️
The downstream RSVP neighbor checks the R-bit and the S-bit when it detects a restart of a node that supports state recovery with RecoveryPath messages. Detection of neighbor restarts with state recovery using RecoveryPath messages is defined in Section 4 🔍 If both the R-bit and the S-bit are set, the procedures defined below in Section 5.3.1 MUST be followed. If the S-bit is cleared, the downstream RSVP neighbor MUST go back to the normal procedures defined in Section 4.5.1. If the R-bit is cleared but the S-bit is set, the downstream RSVP neighbor MUST treat it as if the Capability object was received with the S-bit cleared. For how to handle Hello messages without the Capability object, see Section 4.4 ✨
5.2.2. Compatibility 🫶
There are no compatibility issues introduced by the procedures in Section 5.2.1 🥰
The restarting node will realize its neighbor doesn't support selective transmission of RecoveryPath messages when it receives a RecoveryPath message before getting a Srefresh message that contains a MESSAGE_ID LIST object with the RecoveryPath Flag set (1) 😭 When that happens, any RecoveryPath messages it receives MUST be processed as defined in Section 4 💀
5.3. RecoveryPath Summary Refresh Procedures 🧚
Related processing happens in the following logical order:
- Generation of RecoveryPath-related Srefresh messages
- RecoveryPath-related Srefresh message receive processing and NACK generation
- Message ID NACK receive processing and generation of RecoveryPath messages
- Receive processing of RecoveryPath messages
Actual processing MAY result in the above happening in an interlaced fashion when multiple LSPs are being recovered 🌀 Both the restarted node and the downstream RSVP neighbor MUST be able to process in this fashion 👑
5.3.1. Generation of RecoveryPath-Related Srefresh Messages 🦋
A neighbor of a restarting node generates one or more RecoveryPath-related Srefresh messages when the S-bit is set in the restarted node's Hello messages, as described in Section 5.2.1 ✨ The procedures for generating an Srefresh message are defined in [RFC2961], and only the modifications to them are described in this section. Also, Srefresh message transmit and receive processing may happen at the same time during the Recovery Period, and it isn't affected by the procedures defined in this section 🙌
To generate RecoveryPath-related Srefresh messages, a node must figure out which Path state can be represented in RecoveryPath messages, and which Srefresh message or messages can carry the related information 🔎 As mentioned before, the Path state that can be represented in RecoveryPath messages is indicated in Srefresh messages using the MESSAGE_ID information from the most recently received Path message associated with that state 💜
After processing the S-bit as described in Section 5.2.1, the node identifies all state associated with Path messages received from the restarted neighbor. Only Path state that has not been updated since the restart can be represented in the Srefresh messages 🫧 Received Path state containing a MESSAGE_ID object whose Epoch value matches the Epoch received in the most recent Hello message is considered updated after the upstream neighbor restarted. That Path state MUST NOT be represented in the Srefresh messages 🙅♀️ Each Srefresh message contains one or more MESSAGE_ID LIST objects, and each of those MESSAGE_ID LIST objects MUST have the RecoveryPath Flag set (1) 🎀
Multiple MESSAGE_ID LIST objects MAY be included so that multiple Epoch values can be accommodated 🌈 The MESSAGE_ID LIST objects represent the identified, non-updated, Path state. A Message_Identifier field created for each identified, non-updated Path state MUST be included in an appropriate MESSAGE_ID LIST object. The Message_Identifier field is created from the MESSAGE_ID object in the most recently received Path message associated with that identified Path state. If any identified Path state doesn't have an associated MESSAGE_ID object, that state MUST be processed as defined above in Section 4.5.1 😭
The source IP address for the Srefresh message SHOULD be the source IP address in the IP header of the corresponding Resv messages previously sent to the restarted node 🧚 The Srefresh message SHOULD be destined to the IP address in the HOP object in the corresponding Path messages. This may result in multiple Srefresh messages being generated 🍓 Per [RFC2961], implementations may choose to limit each Srefresh message to the MTU size of the outgoing link, and to not bundle Srefresh messages 📦 RecoveryPath-related Srefresh messages SHOULD be sent using reliable delivery, as defined in [RFC2961] 🫶
During the Recovery Period, unacknowledged RecoveryPath-related Srefresh messages SHOULD be periodically transmitted 🔁 The retransmission algorithm used can be the same one used for retransmitting RecoveryPath messages during the Recovery Period (see Section 4.5.1) 💅 Note that before each of these periodic retransmissions, the Srefresh message SHOULD be updated to exclude the Message IDs of Path state that has been updated by the receipt of a Path message 🙈
To give the restarted node enough processing time, the downstream RSVP neighbor MAY choose to generate multiple RecoveryPath-related Srefresh messages. Those messages contain partial but mutually exclusive sets of Message Identifiers, spread across 1/4 of the Recovery Time advertised by the restarted node ⏳💖
5.3.2. RecoveryPath-Related Srefresh Receive Processing and NACK Generation ✨
okay bestie, this is where the restarted node gets an Srefresh carrying a MESSAGE_ID LIST object with the RecoveryPath Flag set 💅. It has to go hunting for Path state it already sent out. The Epoch in the MESSAGE_ID LIST, plus each Message Identifier in that object, gets matched against the MESSAGE_ID object in the Path messages it previously sent to the downstream RSVP neighbor. For each Message Identifier in the MESSAGE_ID LIST:
- If matching transmitted Path state is found: the restarting node treats the corresponding LSP state as if it has already received and processed a RecoveryPath message, then does any further processing that Section 4.5.2 defines. Specifically, it MUST generate a trigger Path message for the LSP as defined in Section 4.5.2.2. The restarted node MAY spread those trigger Path messages across 1/2 of the remaining Recovery Period so the downstream RSVP neighbor has enough time to process them 🫶.
- If matching transmitted Path state is not found: the restarting node MUST generate a MESSAGE_ID NACK as defined in [RFC2961]. Every generated MESSAGE_ID NACK MUST have the RecoveryPath Flag set (1).
It is recommended that the restarted node combine multiple such MESSAGE_ID NACKs into a single ACK message, per [RFC2961] 🌸.
5.3.3. RecoveryPath-Related MESSAGE_ID NACK Receive Processing
this section lays out the rules for receiving MESSAGE_ID NACKs that have the RecoveryPath Flag set (1) 🧚. NACKs without the flag are handled by [RFC2961] and aren't changed by this document. NACKs with the flag also follow [RFC2961], unless this section explicitly modifies that behaviour.
For each MESSAGE_ID NACK with the RecoveryPath Flag set (1), the downstream RSVP neighbor must locate the matching received Path message. If a matching Path message is found, the downstream RSVP neighbor MUST generate a RecoveryPath message as defined in Section 4.5.1. If no matching Path message is found, the MESSAGE_ID NACK is ignored. One case where this can happen is when the restarted node has already sent an updated Path message after it restarted 🙈.
6. Security Considerations 🔐
this document introduces a new RSVP message that is restricted to one RSVP hop. It doesn't add any new security considerations beyond the ones already handled for existing RSVP hop-by-hop messages.
It also introduces a new RSVP object to be included in RSVP Hello messages. Again, no new security considerations beyond those already covered for existing objects in RSVP Hello messages.
The new procedures apply to RSVP agents that neighbor a restarting RSVP agent. Picture this: a node carrying one or more LSPs gets restarted because of external attacks, and the control plane (and the RSVP agent in particular) goes down with it. The procedures here let the restarting RSVP agent recover the RSVP state for those LSPs with the least possible disruption to the rest of the network 💥. Ideally, only the neighboring RSVP agents notice the restart and have to do any extra work. That way, a network with active LSPs can recover LSP state gracefully from an external attack without disturbing the data/forwarding plane state 🦋.
[RFC2747] provides mechanisms to protect against external agents compromising the RSVP signaling state in an RSVP agent. Used together with the new message and procedures in this document, those mechanisms give the restarting RSVP agent the same degree of protection against installing compromised signaling state from an external agent during signaling state recovery 🔒.
Note that the procedures assume a full trust model between RSVP neighbors. The protocol exchanges before and after a restart can be secured, and it's possible to authenticate the identity of the neighbors. However, no mechanism is provided to verify that the restart information has been correctly mapped from the protocol information exchanged before the restart. This is considered acceptable because a similar trust model is already required for normal operation of the protocol 🫶.
The procedures in this document add processing overhead for the RSVP agents that neighbor a restarting RSVP agent. If an RSVP agent restarts because of external attacks, that extra work on its neighbors could affect their ability to perform other control plane tasks, including processing for LSPs that don't involve the restarting node 😭. This impact can be minimalized by having the restarting RSVP agent use a large enough Recovery Time, so its neighbors have enough time to handle the additional processing while still performing their other control plane functions normally during the Recovery Period 🌈.
Note that the procedures defined in this document cannot be used to create false forwarding state. A restarting node that receives a RecoveryPath message that does not match the existing forwarding state MUST NOT create or modify its forwarding state to match. A restarting node SHOULD log such an event or otherwise notify the operator, since it might represent an attack 🚨.
7. Acknowledgments 🌸
The authors would like to thank the participants of the CCAMP WG for their comments and suggestions. Thanks also to Arthi Ayyangar, Adrian Farrel, Nick Neate, and Pavan Beeram for their helpful comments and feedback 🎀.
Derek Atkins provided useful discussion during SecDir review. Sam Hartman gave careful scrutiny of the security considerations and the potential impact on the RSVP-TE security trust model 👑.
Adrian Farrel edited the final revisions of this document as it progressed through IESG review 💜.
8. IANA Considerations 🦋
[RFC2205] defines the Class-Number name space for RSVP objects. That name space is managed by IANA.
A new RSVP object using a Class-Number of form 10bbbbbb, called the Capability Object, is defined in Section 4.2 of this document. The Class-Number is 134.
A new RSVP message type called a RecoveryPath message is defined in Section 4.1 of this document. The RSVP message type is 30.
This document creates a new name space in the Capability object defined in Section 4.2. The new name space is a 32-bit-wide field. New registrations in this name space are to be allocated by IANA through an IETF Consensus action, per [RFC2434]. IANA also serves as the repository for this name space.
Section 4.2 defines the following bits in the 32-bit field of the Capability Object (134):
RecoveryPath Transmit Enabled (T): 1 bit
RecoveryPath Desired (R): 1 bit
RecoveryPath Srefresh Capable (S): 1 bit9. Normative References 📚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.Editors' Addresses 📮
Arun Satyanarayana (editor)
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
USA
Phone: +1 408 853 3206
EMail: asatyana@cisco.com
Reshad Rahman (editor)
Cisco Systems, Inc.
2000 Innovation Dr.
Kanata, Ontario K2K 3E8
Canada
Phone: 613 254 3519
EMail: rrahman@cisco.comAuthors' Addresses 💌
Dimitri Papadimitriou
Alcatel
Francis Wellesplein 1
B-2018 Antwerpen
Belgium
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel-lucent.be
Lou Berger
LabN Consulting, L.L.C.
Phone: +1 301 468 9228
EMail: lberger@labn.net
Anca Zamfir
Cisco Systems, Inc.
2000 Innovation Dr.
Kanata, Ontario K2K 3E8
Canada
Phone: 613 254 3484
EMail: ancaz@cisco.com
Junaid Israr
Cisco Systems, Inc.
2000 Innovation Dr.
Kanata, Ontario K2K 3E8
Canada
Phone: 613 254 3693
EMail: jisrar@cisco.comFull Copyright Statement ⚖️
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 🧾
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: rfc5063 2007-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms