RFC 5852
RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network
RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network 🦋
(part 1 of 5, more coming!! 💅)
Okay bestie, let's do the ID card first 🪪✨ Here's the title block:
- Who wrote it: D. Caviglia, D. Ceccarelli, and D. Bramanti from Ericsson, plus D. Li from Huawei Technologies and S. Bardalai from Fujitsu Network 👑
- Category: Standards Track (this is an official IETF standard, not just an idea doc) 💖
- Date: April 2010 🌸
- ISSN: 2070-1721 🎀
- Obsoletes/Updates: Nothing! It doesn't obsolete or update any other RFCs 🙈
The IETF is the group that writes the rules for how the Internet works, and this doc is an RFC, which is basically a spec people build from. Let's get into it 🧚
Abstract
Okay so the big picture: in a transport network, Data Plane connections can be run either by a GMPLS Control Plane (that's Soft Permanent Connections, or SPC) or by a Management System (that's Permanent Connections, or PC), and they can totally coexist 🦋 Being able to turn a PC into an SPC and back again, without actually messing with the Data Plane traffic riding on it, is a requirement. The requirements for converting between permanent and switched connections in a GMPLS Network are defined in RFC 5493 ✨
This memo describes an extension to GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling that lets connection ownership move between the Management and the Control Planes. That move is called a Handover 🔥 This document defines all the Handover-related procedures, including how failures are handled and how everything reverts to its original state. A basic premise of the extension is that the Handover procedures must never impact an already established Data Plane connection 💅
Status of This Memo
This is an Internet Standards Track document 👑
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741 📜
For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc5852 🌈
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, bestie, because they spell out your rights and restrictions. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🙈
Table of Contents
1. Introduction ....................................................4
1.1. Dedication .................................................4
2. Terminology .....................................................4
3. Motivation ......................................................4
4. Procedures ......................................................5
4.1. MP-to-CP Handover: LSP Ownership Transfer from
Management Plane to Control Plane ..........................6
4.2. MP-to-CP Handover Procedure Failure Handling ...............7
4.2.1. MP-to-CP Handover Failure - Path Failure ............8
4.2.1.1. MP-to-CP Handover Failure - Path
Message and Data Plane Failure .............8
4.2.1.2. MP-to-CP Handover Failure - Path
Message and Communication Failure ..........8
4.2.2. MP-to-CP Handover Failure - Resv Error ..............9
4.2.2.1. MP-to-CP Handover Failure - Resv
Error and Data Plane Failure ...............9
4.2.2.2. MP-to-CP Handover Failure - Resv
Error and Communication Failure ...........10
4.2.2.3. MP-to-CP Handover Failure - Node
Graceful Restart ..........................12
4.3. CP-to-MP Handover: LSP Ownership Transfer from
Control Plane to Management Plane .........................15
4.4. CP-to-MP Handover Procedure Failure .......................16
5. Minimum Information for MP-to-CP Handover ......................17
6. RSVP Message Formats ...........................................19
7. Objects Modification ...........................................19
7.1. Administrative Status Object ..............................19
7.2. Error Spec Object .........................................19
8. Compatibility ..................................................20
9. Security Considerations ........................................20
10. IANA Considerations ...........................................20
11. Acknowledgments ...............................................21
12. Contributors ..................................................21
13. References ....................................................21
13.1. Normative References .....................................21
13.2. Informative References ...................................221. Introduction ✨
Okay, so in a typical traditional transport network, Data Plane (DP) connections between two endpoints are controlled through a Network Management System (NMS) running in the Management Plane (MP). The NMS/MP owns those transport connections and is responsible for setting them up, tearing them down, and maintaining them 🧚
Now here's the plot twist 🌸 Adopting a Generalized MPLS (GMPLS) [RFC3945] Control Plane (CP) in a network that's already in service and controlled by the NMS at the MP level means you need a procedure that can coordinate a controlled Handover of a Data Plane connection from the MP to the CP. That's the whole reason this exists 💖
The control Handover should also be possible in the opposite direction, from CP to MP. The procedures in this memo can be applied to a Label Switched Path (LSP) in any DP switching technology and any network architecture 🦋
This memo describes an extension to GMPLS Resource reSerVation Protocol - Traffic Engineering (RSVP-TE) [RFC3471] [RFC3473] signaling that enables the Handover of connection ownership between the Management and the Control Planes. All the Handover-related procedures are defined below, including how failure conditions are handled and how things revert to the original state. Like before, a basic premise is that the Handover procedures must never impact the exchange of user data on LSPs that are already established in the DP 🫶
1.1. Dedication 🕊️
We'd like to dedicate this work to our friend and colleague Dino Bramanti, who passed away at the early age of 38. Dino was involved in this work from the very beginning 💜
2. Terminology 📖
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. Motivation 🎀
The main motivation behind this work is a simple and very low-impact procedure that satisfies the requirements defined in [RFC5493]. It's aimed at giving transport network operators a way to hand over ownership of existing LSPs (provisioned by the NMS) from the MP to the CP, without disrupting the user traffic flowing on them 🔥
Here's the breakdown. Handover from the MP to the CP (meaning existing DP connection ownership and control gets passed from the MP to the CP) is a mandatory requirement. The opposite, CP-to-MP Handover, is more of a nice-to-have feature. Think of it as an emergency procedure to disable the CP and take manual control of the LSP 😭 For more details on requirements and motivations, check out [RFC5493] 💅
4. Procedures 💅
Here's the tea: the modification defined in this document only touches the ADMIN_STATUS Object. In other words, the message flow stays unmodified for both LSP setup and deletion. A new Error Value is also defined to identify the failure of a Handover procedure 👑
The following paragraphs give detailed descriptions of the "MP-to-CP Handover" and "CP-to-MP Handover" procedures, based on a newly defined bit called the "H bit" 🌈
Just like when you set up an LSP using the CP [RFC3473], the Path message may contain full information about the explicit route, including the links and labels the LSP traverses. This info is encoded in the Explicit Route Object (ERO). The MP has to supply it using details recorded when the LSP was provisioned, or by inspecting the nodes along the path 🧚
Alternatively (and, again, just like CP setup in [RFC3473]), the ERO can include less information. In that case, each node along the LSP has to figure out the details of the next hop itself as it processes the Path message. This approach may be desirable when the full information isn't available to the MP, or can't be passed to the head-end node when initiating the Handover from the MP to the CP 🦋
This section (Section 4) describes the general procedures and protocol extensions for MP-to-CP Handover, and uses the case of a fully detailed ERO to explain the mechanism. Section 5 describes how each node behaves when the ERO has a limited amount of information ✨
Note, bestie: when Handover is being performed for a bidirectional LSP and the ERO contains full information including labels, the ERO SHOULD include both upstream and downstream labels. Per Section 5.1.1 of [RFC3473], the labels are indicated on an output basis. That means the upstream node uses them to create the LABEL_SET Object and, for bidirectional LSPs, the UPSTREAM_LABEL Object used in the outgoing Path message 🫶
That's part 1 done! 🌈 More parts are coming, so stay tuned, bestie 💖
4.1. MP-to-CP Handover: LSP Ownership Transfer from Management Plane to Control Plane ✨
Okay bestie, the MP-to-CP Handover procedure MUST create an RSVP-TE session along the path of the LSP that's getting moved from the MP to the CP 🦋. That session gets tied to the cross-connected resources the MP already owns (think lambdas, time slots, or reserved bandwidth 🌈), and at the same time, ownership of those resources moves over to the CP. Main character energy 👑
The operator tells the ingress node to hand control of the LSP from the MP to the CP. In this Handover mode, the operator supplies the exact path of the LSP, including any resource reservation and label information 🎀
The ingress MUST check that no corresponding Path state exists and that corresponding Data Plane state does exist 🙈. If there's an error, it MUST be reported to the operator, and further protocol action MUST NOT be taken. Full stop, no cap 🛑
The ingress signals the LSP with a Path message that has the H bit and R bit set in the ADMIN_STATUS Object 💜. In this mode, the Path message also carries an ERO that includes Label subobjects, showing the labels the LSP uses at each hop 🧚. The ingress MUST start the Expiration timer (see Section 4.2.1.2 for expiration of this timer). That timer SHOULD be configurable per LSP and have a default value of 30 seconds ⏰.
Each Label Switching Router (LSR) that gets a Path message with the H bit set checks whether there's any matching Path state, and then it goes like this:
- If matching Path state is found with the H bit set, this is a Path refresh and should be treated accordingly [RFC3473].
- If matching Path state is found with the H bit clear, this is an error and MUST be treated according to the error case description in Section 4.2.1.1.
- If no Path state is found, the LSR goes on to check whether there is any matching Data Plane state.
- If no matching Data Plane state is found (including only partially matching Data Plane state), this is an error or a race condition. It MUST be handled according to the description in Section 4.2.1.1.
- If matching Data Plane state is found, the LSR MUST save the Path state (including the set H bit), and it MUST forward the Path message to the egress. The LSR MUST retain any MP state associated with the LSP at this point.
An egress LSR MUST act like any other LSR, except there's no downstream node to forward the Path message to 🌸. If all checks pass, the egress MUST respond with a Resv with the H bit set ✨.
A transit LSR MUST process each Resv according to the normal rules of [RFC3473] 💅.
When an ingress LSR receives a Resv message carrying the H bit set, it checks the Expiration timer 👀.
- If the timer is not running, the Resv is treated as a refresh and no special action is taken [RFC3473].
- If the timer is running, the ingress MUST cancel the timer and SHOULD notify the operator that the first stage of Handover is complete. The ingress MUST send a Path message that is no different from the previous message, except that the H bit MUST be clear 🦋.
The Path message with the H bit clear travels the length of the LSP and brings back a Resv with the H bit clear, using normal processing [RFC3473] 🌈. So the H bit gets cleared in the stored Path state at each transit LSR and at the egress LSR too. Each LSR SHOULD release any MP state tied to the LSP when it receives the Path message with H bit clear, but MAY keep that information according to local policy for use in future MP processing 🧠.
When the ingress receives a Resv with the H bit clear, the Handover is completed 🎉. The ingress SHOULD notify the operator that the Handover is correctly completed 💖.
4.2. MP-to-CP Handover Procedure Failure Handling
In the case of MP-to-CP Handover, two different failure scenarios can happen: Path Failure and Resv Failure 😬. On top of that, each failure can have one of two causes: DP Failure or Communication Failure. Either way, the LSP ownership MUST be immediately rolled back to what it was before the Handover procedure. We'll go through each combination below 🫶.
4.2.1. MP-to-CP Handover Failure - Path Failure
4.2.1.1. MP-to-CP Handover Failure - Path Message and Data Plane Failure
In this part, we'll look at the case where the Handover procedure fails during Path message processing 🙃.
| Path | | |
|--------------->| Path | |
| |---------------X| |
| | PathErr | |
| PathErr |<---------------| |
|<---------------| | |
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 1: MP2CP - Path Msg and DP FailureIf an error occurs, the node that detects it MUST respond to the received Path message with a PathErr message, and MUST abort the Handover procedure 🚨. The PathErr message SHOULD have the Path_State_Removed flag set [RFC3473], but implementations MAY keep their local state and wait for the Path state timeout as per normal RSVP processing 🕰️.
Nodes that receive a PathErr message MUST follow standard PathErr message processing, and the associated DP resources MUST NOT be impacted 🛡️. If the local CP state shows that a Handover is in progress (based on the H bit in the Path message), the LSR MUST revert the LSP ownership to the MP 🔙.
4.2.1.2. MP-to-CP Handover Failure - Path Message and Communication Failure
Other possible scenarios are shown in the following figures. They're based on the inability to reach a node along the path of the LSP 📡.
The scenario below assumes reliable message delivery, based on the mechanism defined in [RFC2961] 💪.
| Path | | |
|--------------->| Path | |
| |---------------X| |
| |---------------X| |
| | ... | |
| |---------------X| |
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 2: MP2CP - Path Msg and Communication Failure
(Reliable Delivery)The Path message sent from LSR A towards LSR B gets lost or doesn't reach the destination for any reason 😭. Since a reliable delivery mechanism is implemented, LSR A retransmits the Path message a configurable number of times. If no ack comes back, the Handover procedure gets aborted (via the Expiration timer) ⏳.
In the next scenario, RSVP-TE messages are sent without reliable message delivery. That means no [RFC2961] MessageID procedure is used 🙈.
| Path | | |
|--------------->| Path | |
| |----------X | |
| | | |
TIMER EXPIRES | | |
| Path Tear | Path Tear | Path Tear |
|--------------->|--------------->|--------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 3: MP2CP - Path Msg and Communication Failure
(No Reliable Delivery)If the Resv message isn't received before the Expiration timer runs out, the Handover procedure is aborted, as described in Section 4.2.1.1 💔. Heads up: any node that has forwarded a Path (LSR A), meaning it has installed local path state, will send a PathTear when that state is removed (according to [RFC2205]) 🧹.
4.2.2. MP-to-CP Handover Failure - Resv Error
4.2.2.1. MP-to-CP Handover Failure - Resv Error and Data Plane Failure
If a failure happens while a Resv message is being processed (in case there's been any change in the Data Plane during the signaling), the node MUST send a PathErr message [RFC2205] in the upstream direction 🚫. The PathErr message is built and processed as defined above in Section 4.2.1.1. The failure-detecting node MUST also send a PathTear message downstream 🌊. The PathTear message is built and processed as defined above in Section 4.2.1.1 too.
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| |X---------------| |
| PathErr | PathTear | PathTear |
|<---------------|--------------->|--------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 4: MP2CP - Resv Error and DP FailureIn the case shown in Figure 4, the failure happens in LSR A. A PathTear message is sent towards B, and a PathErr message (with ErrorCode set to "Handover Procedure Failure") goes upstream 🥀. The PathErr and PathTear messages remove the Path state that the Path messages established along the nodes of the LSP, and they abort the Handover procedure ✂️.
Here's the tricky bit 🤓: the failure happened after the Handover procedure was successfully completed in LSR B, but Handover state is still kept locally. As Section 4.1 explains, a Path message with the H bit clear hasn't been sent or received yet. A node that receives a PathTear while it has Path state with the H bit set MUST remove that Path state, but MUST NOT change Data Plane state. It MUST return LSP ownership to the MP 🔁.
4.2.2.2. MP-to-CP Handover Failure - Resv Error and Communication Failure ✨
Okay so when a Resv message can't reach one or more of the upstream nodes 😭, it's giving the Path message drama all over again, just in reverse 🔄. There are two different scenarios here, bestie 💅.
In the first one, we're using reliable message delivery based on the mechanism defined in [RFC2961] 🫶. After the Path message gets correctly forwarded along the nodes of the LSP, the Egress LSR sends a Resv message in the opposite direction. Now it might happen that the Resv message doesn't reach the ingress Label Edge Router (LER) or an LSR, say LSR A 🙈. In that case, LSR B MUST send a Resv message again for a configurable number of times. If the delivery still doesn't succeed, the adoption procedure will be aborted (via the Expiration timer) 💀.
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| | X---------| |
| | X---------| |
| | ... | |
| | X---------| |
| | | |
Ingress
LSR A LSR B Egress LER
Figure 5: MP2CP - Resv Error and Communication Failure
(Reliable Delivery)Since the Resv message didn't manage to reach LSR A, it's highly probable that the PathErr would fail too 😩. That's why the Expiration timer is used on the ingress LER after sending the path, and on LSR A after forwarding it. When the timer expires and no Resv or PathErr message is received, the Handover procedure is aborted as described in Section 4.2.1.1, and the LSP ownership is returned to the Management Plane 🔙✨.
Figure 6 shows the other scenario, where no reliable delivery mechanism is implemented 🌸.
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| | X---------| |
TIMER EXPIRES | | |
| Path Tear | Path Tear | Path Tear |
|--------------->|--------------->|--------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 6: MP2CP - Resv Error and Communication Failure
(No Reliable Delivery)If no Resv message is received before the Expiration timer expires, the ingress LER follows the same procedure defined in Section 4.1 🧚.
4.2.2.3. MP-to-CP Handover Failure - Node Graceful Restart 🔁
If node restart and graceful restart are enabled, then one of the following scenarios will happen 👑.
Case I - Finite Restart Time
Here the Restart Time (see [RFC3473]) is finite, i.e., not a value of 0xffffffff ⏳. In the sequence diagram below, assume LSR A restarts. If the ingress LER does not receive the Resv message in time, it MUST abort the Handover process by generating a PathTear message downstream 🛑. Also, if LSR A does not complete the restart process within the restart time interval, then LSR B MUST start tearing down all LSPs between LSR A and LSR B, and this includes the LSP that is being used to carry out the Handover of MP resources to the CP 😤. LSP B MUST generate a PathTear message downstream and a PathErr message upstream. Both LSR B and the egress LER MUST NOT release the DP resources, because in both nodes the H bit is set in the local Path state 💜.
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| X X---------| |
| PathTear | |
|-------X Restart Timer |
| Expires |
| PathErr | PathTear |
| X--------|--------------->|
| | |
| X | |
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 7: MP2CP - Node Graceful Restart - Case ICase II - Infinite Restart Time
In this case, the Restart Time (see [RFC3473]) indicates that the restart of the sender's Control Plane may occur over an indeterminate interval, i.e., is 0xffffffff ♾️. The sequence is quite similar to the previous one. This time, though, the restart timer will not expire in LSR B, since it is run infinitely 🌀. Instead, after LSR A restarts, LSR B MUST start the recovery timer. The recovery timer will expire, since there will be no Path message with the RECOVERY LABEL received from LSR A, given the ingress node had already removed the local Path state after it aborts the Handover process 😭. Thus, LSR B MUST tear down the specific LSP that is being used to convert the MP resources to CP by generating a PathTear message downstream and a PathErr message upstream. Similar to the previous case, both LSR B and the egress LER MUST NOT release the DP resources, because the H bit is set in the local Path state 🫶.
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| X X---------| |
| PathTear | |
|-------X | |
| | |
| X | |
| | | |
| | Recovery Timer |
| | Expires |
| PathErr | PathErr | PathTear |
|<---------------|<---------------|--------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 8: MP2CP - Node Graceful Restart - Case IICase III
This time the ingress LER does not abort the Handover process 🙌. When LSR A restarts, the ingress LER detects the restart and MUST re-generate the Path message with the H bit set, in order to restart the Handover 🔄✨.
When LSR B receives the Path message, it sees the H-bit set on the message. It also sees that it has the H-bit set in its own state and that it has sent the Resv. But it's also aware that LSR A has restarted and could have sent a Path message with a RECOVERY LABEL object 🤔. LSR B may attempt to resume the Handover process, or it may abort the Handover. This choice is made according to local policy ⚖️.
If resuming the Handover, LSR B MUST treat the received Path message as a retransmission, and MUST retransmit its Resv 🔁. If aborting the Handover, LSR B MUST return a PathErr and MUST send a PathTear downstream 🛑. In both cases, LSR B MUST NOT modify the DP state 🔒.
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| X X---------| |
| | |
| X | |
| | | |
| Path | Path | |
|--------------->|--------------->| |
| PathErr | PathErr | PathTear |
|<---------------|<---------------|--------------->|
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 9: MP2CP - Node Graceful Restart - Case III4.3. CP-to-MP Handover: LSP Ownership Transfer from Control Plane to Management Plane 🦋
Let's now look at LSP ownership transfer from the Control Plane to the Management Plane 🎀. In this section we'll also analyze the Handover procedure's success and failure, so get ready 💅.
The scenario is still a DP connection between two nodes acting as ingress and egress for an LSP. The difference is that now the CP has the ownership and control of the LSP 👑. The CP-to-MP Handover procedure MUST delete the existing RSVP-TE session information and MUST NOT affect the cross-connected resources, but just move their ownership to the MP ✨.
So basically, after the LSP ownership transfers from CP to MP, the LSP is no longer under the control of RSVP-TE, which can no longer "see" the LSP itself 🙈. The CP-to-MP Handover procedure MUST be a standard LSP deletion procedure as described in Section 7.2.1 of [RFC3473]. The procedure is initiated at the ingress node of the LSP by an MP entity. The ingress node and MP exchange the relevant information for this task, and then propagate it over CP by means of RSVP-TE tear down signaling, as described below 🧚.
The ingress node MUST send a Path message in the downstream direction with the Handover and Reflect bits set in the ADMIN_STATUS Object 📨. No action is taken over the DP, and transit LSRs must forward such a message towards the egress node 🚀. All of the nodes MUST keep track of the procedure by storing the H bit in their local Path and Resv states 📝. Then every node waits for the H bit to be received within the related Resv message 👀. After the Resv message is received by the ingress LER, it MUST send a PathTear message in order to clear the whole LSP information recorded on the RSVP-TE data structures of the nodes 🧹. Downstream nodes processing a PathTear message that follows a Path message with the H bit set MUST NOT remove any associated Data Plane state 🔐. In other words, a normal LSP tear down signaling is exchanged between the nodes traversed by the LSP, but the H bit set in the Path message indicates that no DP action has to correspond to CP signaling 🌈✨.
4.4. CP-to-MP Handover Procedure Failure 💥
Okay bestie, the big rule here is that failures during the CP-to-MP Handover MUST NOT remove any Data Plane state 🫶 Nobody gets their traffic yeeted just because the handover glitched. When a Resv message with an ADMIN_STATUS Object whose H bit is not received during the window in Section 7.2.2. of [RFC3473], it's giving "different processing required" 👀 While the H bit is set in the Path state, a node MUST NOT send a PathTear when something fails. Instead, the failure gets reported upstream with a PathErr. ✨ Only the ingress node is allowed to send a PathTear, and only as a step in the procedures in this document. This applies to both MP-to-CP and CP-to-MP Handover. The ingress node MAY choose to report the CP-to-MP failure through the MP. 🎀
The CP-to-MP Handover can also fail for two reasons: a lost PathTear, or a node going down. For the lost PathTear case, if the LSP is still not under MP control once the Expiration timer runs out, a network operator manual intervention is requested. For the node-down case, a few different scenarios can happen. Let's look at them 🔍
- CASE I - Path message and node down
| Path | Path X |
|--------------->|--------------X |
| | |
| | X |
| | | |
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 10: Case I - Path Message and Node DownPer [RFC3473], Section 7.2.2, the ingress node should wait a configurable amount of time (30 seconds by default) and then send a PathTear message. In this case the normal deletion procedure MUST NOT be followed 🙅♀️ When the Expiration timer runs out, a manual intervention from the network operator is requested, and normal processing, the same as before CP-to-MP Handover, keeps going. 🦋
- CASE II - Resv message and node down
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| | | Resv |
| | Resv |<---------------|
| X X---------| |
| | |
| X | |
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 11: Case II - Resv Message and Node DownThe procedure is the same one shown in CASE I, no plot twist 💅 The network operator can ask for the automatic CP-to-MP procedure again after the failed node comes back up. Per [RFC3473], section 7.2, the nodes will forward the new Path and Resv messages correctly. 🌸
- CASE III - PathTear message and node down
| Path | Path | Path |
|--------------->|--------------->|--------------->|
| Resv | Resv | Resv |
|<---------------|<---------------|<---------------|
| PathTear | | |
|--------------->| PathTear X |
| |------------X |
| | X |
| | | |
Ingress LER LSR A LSR B Egress LER
Figure 12: Case III - PathTear Message and Node DownThis one can be handled like the lost PathTear case described above in this section. It's literally the same playbook 🧚
5. Minimum Information for MP-to-CP Handover 🍓
As we covered in Section 4, the ERO can also contain less than the full set of path information for the LSP being handed over. This happens when the MP hands the CP only a minimal set of information at the LSP's head-end. Instead of gathering all of the LSP information (labels included) and formatting it into an ERO like Section 4 describes, you can start with a smaller amount of info. The full ERO method and the partial/no ERO method are not mutually exclusive, so support of both methods is required. 💜
At the ingress node, the info needed to specify the LSP is the outgoing interface ID, the upstream label, the downstream label of this interface, and the egress node ID. The rest of the information about an existing LSP can be collected hop by hop, while the signaling is happening, by looking up the cross-connection table in the DP at each node along the LSP path. 🔎
Starting from what the ingress LER knows about its own outgoing interface ID, the incoming interface ID of the next hop can be found by looking up the link resource table/database in the LER itself. 🪄
The Path message is built with the LABEL_SET Object ([RFC3473]) and the UPSTREAM_LABEL Object ([RFC3473]), and the upstream label and downstream label of the ingress outgoing interface of the LSP go into these two objects. On top of those objects, the Path message MUST include the ADMIN_STATUS Object with the H bit set, just like earlier chapters already defined for the detailed ERO-based way. This Handover Path gets sent to the incoming interface of the next hop. When the Path message reaches the second node along the LSP, the incoming interface ID and the upstream and downstream labels of that interface are pulled out of it, and they're used to find the next hop outgoing interface ID and the upstream/downstream labels by looking up the DP cross-connection table. 🔥
Once the parameters describing the LSP's next hop are figured out this way, the outgoing Path message is built by swapping the contents of the LABEL_SET Object and UPSTREAM_LABEL Object with the looked-up upstream and downstream label values. 🎀
Repeat this for each transit node along the LSP, and the Handover Path message can reach the egress node, following exactly the LSP that's in place over DP. ✨ In this case the ERO MAY be included in the Path message as an optional object, and it MAY be filled with LSP-relevant information down to either the port level (with the interface ID) or the label level (with upstream and downstream labels). The ERO can be used to check that the resources in the DP are consistent down to the port or label level at each intermediate node along the LSP. 🫶
If the DP path continues past the egress, indicating the Egress label at the head-end of an LSP lets the traffic be directed to the right destination. 🌈 The GMPLS signaling procedure for egress control is described in [RFC4003]
6. RSVP Message Formats 🧾
This memo does not introduce any modification to RSVP message object composition. Nothing to see here, bestie 💅
7. Objects Modification 🛠️
The modifications required concern two RSVP objects: the ADMIN_STATUS and ERROR_SPEC Objects. 👑
7.1. Administrative Status Object
This memo introduces a new flag into the ADMIN_STATUS Object, which is defined in [RFC3473]. This document uses the H bit of the ADMIN_STATUS Object, and that bit is bit number 25. 🦋
7.2. Error Spec Object
It's possible that a failure, like losing the Data Communication Network (DCN) connection or a node restarting, happens while LSP ownership is being handed over. When that happens, the LSP Handover procedure is interrupted, and the ownership of the LSP must stay with whoever owned it before the Handover started. It's super important that the failed transaction doesn't affect the DP. The LSP stays in place and no traffic hit happens 🙌
Wait, I need to correct myself here. The original uses lowercase "must" in this sentence, which is not a BCP 14 key word, so it has to stay lowercase. The sentence keeps the same meaning with lowercase "must" as in the source. 💖
The failure is signaled by a PathErr message in the upstream direction and by PathTear messages in the downstream direction. The PathErr messages include an ERROR_SPEC Object that specifies the causes of the failure. 🚨
This memo introduces a new Error Code (with different Error Values) into the ERROR_SPEC Object, which is defined in [RFC2205]. 🧩
The defined Error Code is "Handover Procedure Failure", and its value is 35. For this Error Code, the following Error Value sub-codes are defined:
1 = Cross-connection mismatch
2 = Other failure8. Compatibility 🤝
The main requirement for the Handover procedure to work is that all nodes along the path MUST support the extension defined in this document. This requirement translates into an administrative requirement, because it isn't enforced at the protocol level. As defined, non-supporting nodes will simply propagate the H bit without setting local state. This may affect data traffic during the Handover procedure. 😬
9. Security Considerations 🔐
The procedures in this document rely completely on RSVP-TE messages and mechanisms. Setting the H bit in the ADMIN_STATUS Object basically tells the receiving entity that no operations are to be done over the DP as a result of this special signaling flow. By using specially flagged signaling messages, we want to limit the function of setup and teardown messages to the CP, so they become ineffective over related DP resource usage.
The Handover procedures, however, let the Control Plane be used to take an LSP out of the control of the Management Plane. This could cause considerable disruption and could introduce a new security concern. Because of that, using GMPLS security techniques matters even more. For RSVP-TE security, please refer to [RFC3473]. For the GMPLS security framework, please refer to [sec-fwk]. 🛡️
10. IANA Considerations 📋
IANA manages the bit allocations for the ADMIN_STATUS Object ([RFC3473]). This document requires the allocation of the Handover bit, the H bit. IANA has allocated a bit for this purpose:
Bit Number Hex Value Name Reference
---------- ----------- --------------------------------- ---------
25 0x00000040 Handover (H) [RFC5852]IANA has also allocated a new Error Code:
35 Handover failure
This Error Code has the following globally defined Error
Value sub-codes:
1 = Cross-connection mismatch
2 = Other failure11. Acknowledgments 💐
We wish to thank Adrian Farrel, Lou Berger, Alan Elder, and Ben Campbell for their assistance and precious advice in preparing this document for publication. We also wish to thank Nicola Ciulli (Nextworks), who contributed to the initial stage of this document. 🥰
12. Contributors 🌟
Shan Zhu
Fujitsu Network Communications Inc.
2801 Telecom Parkway,
Richardson, TX 75082
USA
EMail: Shan.Zhu@us.fujitsu.com
Tel: +1-972-479-2041
Igor Bryskin
ADVA Optical Networking Inc
7926 Jones Branch Drive, Suite 615
McLean, VA 22102
USA
EMail: ibryskin@advaoptical.com
Francesco Fondelli
Ericsson
Via Negrone 1A
Genova - 16145
Italy
EMail: francesco.fondelli@ericsson.com
Lou Berger
LabN Consulting, LLC
Phone: +1 301 468 9228
EMail: lberger@labn.net13. References 📚
13.1. Normative References 📚✨
bestie, these are the must-read-first docs. Everything the spec leans on lives here, so here's the full list 💅
[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.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 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.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress
Control", RFC 4003, February 2005.13.2. Informative References 🧚
these ones are the extra reading 🌸 helpful for the vibes, but not required to get the spec right
[RFC5493] Caviglia, D., Bramanti, D., Li, D., and D. McDysan,
"Requirements for the Conversion between Permanent
Connections and Switched Connections in a Generalized
Multiprotocol Label Switching (GMPLS) Network", RFC 5493,
April 2009.
[sec-fwk] Fang, L. and M. Behringer, "Security Framework for MPLS
and GMPLS Networks", Work in Progress, March 2010.Authors' Addresses 💌
the squad behind this one 🫶 here's where to find them
Diego Caviglia
Ericsson
Via A. Negrone 1A
Genova - Sestri Ponente 16153
Italy
EMail: diego.caviglia@ericsson.com
Daniele Ceccarelli
Ericsson
Via A. Negrone 1A
Genova - Sestri Ponente 16153
Italy
EMail: daniele.ceccarelli@ericsson.com
Dino Bramanti
Ericsson
Dan Li
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Shenzhen 518129
P.R. China
EMail: danli@huawei.com
Snigdho Bardalai
Fujitsu Network
2801 Telecom Parkway
Richardson, TX 75082
USA
EMail: sbardalai@gmail.comand that's a wrap on RFC 5852!! 🌈✨ thank u for reading with me bestie 🎀💖
📦 where this page comes from
- ietf: rfc5852 2010-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms