Internet Engineering Task Force (IETF) D. Caviglia Request for Comments: 5852 D. Ceccarelli Category: Standards Track D. Bramanti ISSN: 2070-1721 Ericsson D. Li Huawei Technologies S. Bardalai Fujitsu Network April 2010 RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network
AbstractIn a transport network scenario, Data Plane connections controlled by either a Generalized Multiprotocol Label Switching (GMPLS) Control Plane (Soft Permanent Connections - SPC) or a Management System (Permanent Connections - PC) may independently coexist. The ability of transforming an existing PC into an SPC and vice versa -- without actually affecting Data Plane traffic being carried over it -- is a requirement. The requirements for the conversion between permanent connections 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 enables the transfer of connection ownership between the Management and the Control Planes. Such a transfer is referred to as a Handover. This document defines all Handover-related procedures. This includes the handling of failure conditions and subsequent reversion to 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. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 126.96.36.199. MP-to-CP Handover Failure - Path Message and Data Plane Failure .............8 188.8.131.52. MP-to-CP Handover Failure - Path Message and Communication Failure ..........8 4.2.2. MP-to-CP Handover Failure - Resv Error ..............9 184.108.40.206. MP-to-CP Handover Failure - Resv Error and Data Plane Failure ...............9 220.127.116.11. MP-to-CP Handover Failure - Resv Error and Communication Failure ...........10 18.104.22.168. 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 ...................................22
RFC3945] Control Plane (CP) in a network that is already in service -- controlled by the NMS at the MP level -- introduces the need for a procedure able to coordinate a controlled Handover of a Data Plane connection from the MP to the CP. In addition, the control Handover in the opposite direction, from CP to MP should be possible as well. The procedures described 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 Handover-related procedures are defined below. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the Handover procedures must never impact the exchange of user data on LSPs that are already established in the DP. RFC2119]. RFC5493]. Such a procedure is aimed at giving the transport network operators the chance to hand over the ownership of existing LSPs provisioned by NMS from the MP to the CP without disrupting user
traffic flowing on them. Handover from the MP to the CP (i.e., when existing DP connection ownership and control is passed from the MP to the CP) has been defined as a mandatory requirement, while the opposite operation, CP-to-MP Handover, has been considered as a nice- to-have feature that can be seen as an emergency procedure to disable the CP and take manual control of the LSP. For more details on requirements and motivations, please refer to [RFC5493]. RFC3473], the Path message may contain full information about the explicit route including the links and labels traversed by the LSP. This information is encoded in the Explicit Route Object (ERO), and must be supplied by the MP using details recorded when the LSP was provisioned, or collected by the MP by inspecting the nodes along the path. Alternatively, and also just as when setting up an LSP using the CP [RFC3473], the ERO may include less information such that the details of the next hop have to be determined by each node along the LSP as it processes the Path message. This approach may be desirable when the full information is not available to the MP or cannot 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 it uses the case of a fully detailed ERO to describe the mechanism. Section 5 describes how each node behaves in the case of a limited amount of information in the ERO. Note that 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; this means that the labels are used by the upstream node to create the LABEL_SET Object and, for bidirectional LSPs, the UPSTREAM_LABEL Object used in the outgoing Path message.
Section 22.214.171.124 for expiration of this timer). Such a timer SHOULD be configurable per LSP and have a default value of 30 seconds. Each Label Switching Router (LSR) that receives a Path message with the H bit set checks to see whether there is any matching Path state. o If matching Path state is found with the H bit set, this is a Path refresh and should be treated accordingly [RFC3473]. o 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 126.96.36.199. o If no Path state is found, the LSR goes on to check whether there is any matching Data Plane state. o 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 188.8.131.52.
o 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 as any other LSR, except that there is no downstream node to which to forward the Path message. If all checks are passed, 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. o If the timer is not running, the Resv is treated as a refresh and no special action is taken [RFC3473]. o 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 will travel the length of the LSP and will result in the return of a Resv with the H bit clear according to normal processing [RFC3473]. As a result, the H bit will be cleared in the stored Path state at each transit LSR and at the egress LSR. Each LSR SHOULD release any associated MP state associated with the LSP when it receives the Path message with H bit clear, but MAY retain the 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.
| Path | | | |--------------->| Path | | | |---------------X| | | | PathErr | | | PathErr |<---------------| | |<---------------| | | | | | | Ingress LER LSR A LSR B Egress LER Figure 1: MP2CP - Path Msg and DP Failure If an error occurs, the node detecting the error 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 retain their local state and wait for Path state timeout as per normal RSVP processing. Nodes receiving a PathErr message MUST follow standard PathErr message processing and the associated DP resources MUST NOT be impacted. If the local CP state indicates 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. 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 is lost or does not reach the destination for any reason. As a reliable delivery mechanism is implemented, LSR A retransmits the Path message for a configurable number of times, and if no ack is received, the Handover procedure will be aborted (via the Expiration timer). In the next scenario RSVP-TE messages are sent without reliable message delivery, that is, 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 is not received before the expiration of the Expiration timer, the Handover procedure is aborted as described in Section 184.108.40.206. Please note that any node that has forwarded a Path (LSR A), i.e., has installed local path state, will send a PathTear when that state is removed (according to [RFC2205]). RFC2205] in the upstream direction. The PathErr message is constructed and
processed as defined above in Section 220.127.116.11. The failure detection node MUST also send a PathTear message downstream. The PathTear message is constructed and processed as defined above in Section 18.104.22.168. | Path | Path | Path | |--------------->|--------------->|--------------->| | | | Resv | | | Resv |<---------------| | |X---------------| | | PathErr | PathTear | PathTear | |<---------------|--------------->|--------------->| | | | | Ingress LER LSR A LSR B Egress LER Figure 4: MP2CP - Resv Error and DP Failure In the case shown in Figure 4, the failure occurs in LSR A. A PathTear message is sent towards B and a PathErr message (with ErrorCode set to "Handover Procedure Failure") is sent in the upstream direction. The PathErr and PathTear messages remove the Path state established by the Path messages along the nodes of the LSP and abort the Handover procedure. Please note that the failure occurred after the Handover procedure was successfully completed in LSR B, but Handover state will still be maintained locally as, per Section 4.1, a Path message with the H bit clear will have not yet been sent or received. A node that receives a PathTear when it has Path state with the H bit set MUST remove Path state, but MUST NOT change Data Plane state. It MUST return LSP ownership to the MP.
In the first scenario we consider the utilization of a reliable message delivery based on the mechanism defined in [RFC2961]. After a correct forwarding of the Path message along the nodes of the LSP, the Egress LSR sends a Resv message in the opposite direction. It might happen that the Resv message does not reach the ingress Label Edge Router (LER) or an LSR, say LSR A. LSR B MUST send a Resv message again for a configurable number of times and then, if the delivery does not 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) Considering that the Resv message did not manage to reach LSR A, it is highly probable that the PathErr would fail too. Due to this fact, the Expiration timer is used on the ingress LER after sending the path and on LSR A after forwarding it. When the timer expires, if no Resv or PathErr message is received, the Handover procedure is aborted as described in Section 22.214.171.124 and the LSP ownership is returned to the Management Plane. Figure 6, on the other hand, shows the scenario in which 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. 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 I Case 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. In this sequence, 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 PathErr message upstream. Similarly 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 II Case III In this case, 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 and also sees that it has the H-bit set in its own state and that it has sent the Resv. But it is 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 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 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 III 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 Handover and Reflect bits set in the ADMIN_STATUS Object. No action is taken over the DP and transit LSRs must forward such message towards the egress node. All of the nodes MUST keep track of the procedure 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 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. Section 7.2.2. of [RFC3473] different processing is required. While the H bit is set in the Path state, a node MUST NOT send a PathTear when a failure is detected. Instead, the failure is reported upstream using a PathErr. The only node that can send a PathTear is the ingress node, and it can only do this as a step in the procedures specified in this document. This applies to both MP-to-CP and CP-to-MP Handover. The ingress node MAY choose to report the failure in the CP-to-MP Handover procedure via the MP. The CP-to-MP Handover procedure can also fail due to two causes: PathTear lost or node down. In the former case, if the LSP is not under MP control after the Expiration timer elapses, a manual intervention from the network operator is requested, while in the latter case, different scenarios may happen: - 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 Down Per [RFC3473], Section 7.2.2, the ingress node should wait for 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 elapses, a manual intervention from network operator is requested and normal, i.e., pre-CP-to-MP Handover, LSP processing continues. - 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 Down The procedure to be followed is the same depicted in CASE I. 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 Down This scenario can be managed as a normal PathTear lost described above in this section. Section 4, it is also possible for the ERO to contain less than the full set of path information for the LSP being handed over. This arises when only a minimal set of information is handed
to the CP by the MP at the LSP's head-end. Instead of collecting all of the LSP information (including the labels) and formatting it into an ERO, as described in Section 4, it is possible to start with a minimum amount of information. The full ERO method and the partial/no ERO method are not mutually exclusive; support of both methods is required. At the ingress node, the information needed to specify the LSP is the outgoing interface ID, upstream label, and downstream label of this interface and egress node ID. The remaining information about an existing LSP can then be collected hop by hop, as the signaling is going on, by looking up the cross-connection table in the DP at each node along the LSP path. Starting from the information available at the ingress LER about the outgoing interface ID of that ingress node, 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 hence built with the LABEL_SET Object ([RFC3473]) and the UPSTREAM_LABEL Object ([RFC3473]), where the upstream label and downstream label of ingress outgoing interface of the LSP are included in these two objects. In addition to the above mentioned objects, the Path message MUST include the ADMIN_STATUS Object with the H bit set, as already defined in previous chapters for the detailed ERO-based way of proceeding. Such a Handover Path is sent to the incoming interface of the next hop. When this Path message reaches the second node along the LSP, the information about incoming interface ID and the upstream and downstream labels of this interface is extracted from it, and it is used to find next hop outgoing interface ID and the upstream/downstream labels by looking up the DP cross-connection table. After having determined, in this way, the parameters describing the LSPs next hop, the outgoing Path message to be sent is built replacing the LABEL_SET Object and UPSTREAM_LABEL Object content with the looked-up values of upstream and downstream labels. By repeating this procedure for each transit node along the LSP, it is possible to make the Handover Path message reach the egress node, exactly following the LSP that is in place over DP. The ERO MAY, in this case, be included in the Path message as an optional object, and MAY be filled with the 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 the consistency of resource in the DP down to the port level or label level at each intermediate node along the LSP.
Where the DP path continues beyond the egress, by indicating the Egress label at the head-end of an LSP, the traffic can be directed to the right destination. The GMPLS signaling procedure for egress control is described in [RFC4003] RFC3473]. This document uses the H bit of the ADMIN_STATUS Object. The bit is bit number 25. 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 failure
RFC3473], for the GMPLS security framework, please refer to [sec-fwk]. 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 failure
[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. [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.