CCAMP Working Group D. Caviglia Internet-Draft D. Ceccarelli
Expires: May 1, 2009Intended status: Standards Track D. Bramanti Expires: January 28, 2010 Ericsson D. Li Huawei Technologies Co., LTD.S. Bardalai Fujitsu Network Communications Inc October 28, 2008July 27, 2009 RSVP-TE Signaling Extension For The Conversion Between Permanent Connections And Soft Permanent ConnectionsManagement Plane To Control Plane LSP Handover In A GMPLS Enabled Transport Network. draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txtdraft-ietf-ccamp-pc-spc-rsvpte-ext-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or sheThis Internet-Draft is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed,submitted to IETF in accordancefull conformance with Section 6the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 1, 2009.January 28, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract We would like to dedicate this work to our friend and colleague Dino Bramanti, who passed away at the early age of 38. Dino has been involved in this work since its beginning. In a transport network scenario, where Data Plane connections controlled either by GMPLS Control Plane (Soft Permanent Connections - SPC) or by Management System (Permanent Connections - PC) may independently coexist, the ability of transforming an existing PC into a SPC and vice versa - without actually affecting Data Plane traffic being carried over it - is a requirement. See draft "draft-ietf-ccamp-pc-and-reqs-04.txt .requirement [RFC5493]. This memo provides a minor extension to RSVP-TE [RFC2205], [RFC3471], [RFC3473], [RFC4872] signaling protocol, within GMPLS architecture, to enable such connection ownership transfer and describes the proposeddefined procedures. Failure conductionsconditions and subsequent roll back are also illustrateddefined taking into account that an handover failure must notMUST NOT impact the already established data plane connections. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 34 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 34 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4. Overview Of Proposed RSVP-TE Based SolutionProcedures . . . . . . . . . 3 5.. . . . . . . . . . . . . . . . . 4 4.1. MP to CP handover: LSP Ownership Transfer From Management Plane To Control Plane . . . . . . . . . . . . . . . . . . . .5 22.214.171.124. MP to CP Handover Procedure Success . . . .Failure Handling . . . . . . . 6 126.96.36.199.1. MP to CP Handover ProcedureFailure Handling- Path Failure . . . . . . . 7 188.8.131.52 184.108.40.206. MP to CP Handover Failure - Path message and Data Plane Failure . . . . . . . 7 5.2.2.. . . . . . . . . 6 220.127.116.11. MP to CP Handover Failure - Resv ErrorPath message and Communication failure . . . . . . . . 8 6. CP to MP handover : LSP Ownership Transfer From Control Plane To Management Plane. . . . . . 7 4.2.2. MP to CP Handover Failure - Resv Error . . . . . . . . 8 18.104.22.168. MP to CP Handover Failure - Resv Error and Data Plane failure . . . . 13 6.1. CP to MP Handover Procedure Success. . . . . . . . . . . 13 6.2. CP to. 8 22.214.171.124. MP to CP Handover ProcedureFailure - Resv Error and Communication failure . . . . . . . . . . . 14 7. Discovery Phase. . . 9 126.96.36.199. MP to CP Handover Failure - Node Graceful Restart . . . . . . . . . . . . . . . . . . . . 14 8. Alternative Way Of Retrieving. 10 4.3. CP to MP handover : LSP Ownership Transfer From Control Plane To Management Plane . . . . . . . . . . . . 13 4.4. CP to MP Handover Procedure Failure . . . . . . . . . . . 13 5. Alternative Way Of Retrieving Information Needed For MP To CP Handover . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.14 6. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 16 10.15 7. Objects Modification . . . . . . . . . . . . . . . . . . . . . 17 10.1.15 7.1. Administrative Status Object . . . . . . . . . . . . . . . 17 10.2.15 7.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 18 11. Acknoledgments16 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 19 12. Contributors16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. Contributors . . 19 13. Security Considerations. . . . . . . . . . . . . . . . . . . 20 14. IANA. . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 12. IANA Considerations . . 20 15. References. . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . 20 15.1. Normative References. . . . . . . . . . . . . . . . . . . 20 15.2. Informational18 13.1. Normative References . . . . . . . . . . . . . . . . . 21 Authors' Addresses. . 18 13.2. Informational References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . 21 Intellectual Property and Copyright Statements. . . . . . . . . . 23. . . . . . . 19 1. Introduction In a typical traditional transport network scenario, Data Plane (DP) connections between two endpoints are controlled by means of a Network Management System (NMS) operating within Management Plane (MP). NMS/MP is the owner of such transport connections, being responsible of their set up, tear down and maintenance. The adoption of a GMPLS Control Plane (CP) over networks that are already in service - controlled by NMS at Management PlaneMP level - introduces the need for a procedure able to coordinate a control handover of a generic data plane connection from MP to 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 any kind of LSP and network architecture. 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 the definition of a simple and very low impacting procedure that satisfies the requirements defined in "draft-ietf-ccamp-pc-and-reqs-04.txt .[RFC5493]. Such procedure is aimed at giving the transport network operators the chance to converthandover the ownership of existing LSPLSPs provisioned as PCby NMS from the MP to SPCthe CP without disrupting user traffic flowing on it. Conversionthem. Handover from PCMP to SPCCP (i.e. when existing Data PlaneDP connection ownership and control is passed from MP to CP) has been proposeddefined as mandatory requirement, while the opposite operation, SPCCP to SC conversion,MP handover, has been considered as a nice-to-havenice- to-have feature that can be seen as a back-out option.an emergency procedure to disable the CP and take the manual control of the LSP. For more details on requirements and motivations please refer to "draft-ietf-ccamp-pc-and-reqs-04.txt .[RFC5493]. 4. Overview Of Proposed RSVP-TE Based Solution The whole process comprises of the discovery and conversion phases.Procedures The discovery phase being describedmodification defined in this document is an OPTIONAL procedure and not mandatory for the conversion phaserefers only to proceed. The discovery phase is typically initiated byAdministrative Status object, that is, the operator andmessage flow is performed hop-by-hop in order to discover the route. The route discovered SHOULD be consistent with the network topology. For example,left unmodified for both LSP set-up and deletion. Moreover a multi-layer network the hops discovered should be contained within the same layer. Prior to initiating the discovery process itnew Error Value is assumed that the Control Plane domains have been established. The operator at the originating node can optionally specify the terminating end-point atdefined to identify the timefailure of initiating the discovery request or it could be automatically discovered. For example, ata network layer boundaryHandover procedure. Following paragraphs give detailed description of defined "MP to CP handover" and "CP to MP handover" procedures, based on the discovery process can be terminated generatingusage a response backnewly define bit called H bit. MP to CP handover procedure foreseen two different methods for retrieving required information. The primary one consists on receiving the full Explicit Route Object (ERO) from the originator. Another possibilityMP while the alternative one is described in Section 5. Please note that if the primary method is used the labels SHOULD be included in the ERO and for bidirectional LSPs both upstream and downstream labels SHOULD be included. Per Section 5.1.1. of [RFC3473], the labels are indicated on an output basis. As described, this means that the labels are used by the upstream node to terminatecreate the request atLABEL_SET object and, for bidirectional LSPs, UPSTREAM_LABEL object used in the outgoing Path message. 4.1. MP to CP handover: LSP Ownership Transfer From Management Plane To Control Plane domain boundary. For conversionThe MP to PC or SPC the conversion phase willCP handover procedure MUST create an RSVP- TERSVP-TE session along the discovered or user-specified route and bind withpath of the LSP to be moved from MP to CP, associating it to the existing Management Plane owned cross-connectcross-connected resources owned by the MP (e.g. lambdas, time slots andor reserved bandwidth)andbandwidth) and at the same time transfer thetransferring their ownership to the Control Plane. For conversionCP. A standard RSVP-TE signaling flow MUST be used to PC the conversion phase will delete the existing RSVP- TE session information without deleting the cross-connect resources and transferinform nodes about the ownership to the Management Plane. Proposed procedure relies on the utilization ofhandover request. Such flow MUST be tagged with a newly introduced flag, here named Handover flag,H bit and described in Section 7.1, that is set in the Administrative Status Object [RFC3471]([RFC3471] and [RFC3473]. The point is that standard[RFC3473]) of RSVP-TE signaling flow canmessages. The H bit MUST be usedset in order to inform nodes aboutdiscriminate the ownershiphandover request regarding oneprocedure from normal, DP affecting, LSP that is already in place on their Data Plane, where such flow has to be flagged in order to discriminate it from normal, Data Plane affecting, LSP setup/release procedure. When a LSP owned by Management Plane (i.e. a PC) has to be handed over to Control Plane (i.e. converted into a SPC), a signaling set-up with HANDOVER flag set has to be sent from ingress node. For the opposite procedure (when a LSP owned and controlled by Control Plane has to be handed over to Management Plane, i.e. SPC to PC conversion - or back out procedure for previous case) a signaling tear-down with HANDOVER flag set has to be sent from ingress or egress node, following the same procedure of a normal tear-down, from which is recognizable again by reading flag value. So, basically the HANDOVER flag is introduced and exploited to tell apart a normal set-up (or tear-down) procedure - that has to trigger an action on Data Plane state at each addressed node along the path as usual - from the LSP ownership handover procedure that MUST leave untouched Data Plane state. This is in some way similar as an approach to the Restart Procedure, ([RFC2119]), in the sense that the status of the physical resources at Data Plane has to stay unmodified but the associated information allowing its control has to be transferred. The modification proposed in this document refers only to Administrative Status object, that is, the message flow is left unmodified for both set-up and deletion. Moreover a new Error Value is defined to identify the failure of an Handover procedure. It is worth stressing that, when the LSP over Data Plane is adopted either by CP or MP, i.e. at the end of signaling with Handover flag set, normal CP procedures or MP procedures have to take their place as usual when needed. This means that a LSP formerly owned by MP, signalled within CP with Handover flag set (i.e. handed over to CP) can be controlled by usual relevant Control Plane signaling flows (i.e. with Handover flag not set). The same applies when considering the handover of a LSP from CP to MP when, at the end of procedure, the LSP belongs to Management Plane and can be fully controlled by NMS. In other words, after the LSP handover procedures have taken place, the LSP is not different from the other LSP owned by handover destination entity and it has to be treated with usual rules for that entity. Following paragraphs give detailed description of proposed "MP to CP handover" and "CP to MP handover" procedure, based on Handover flag usage. Handover of a bidirectional LSP is assumed. The case of unidirectional LSP can be easily derived from that. 5. MP to CP handover: LSP Ownership Transfer From Management Plane To Control Plane Let's consider the case of a Data Plane connection created by NMS. The Management Plane has the ownership and control of the LSP and wants to hand it over to Control Plane. At the ingress node NMS initiates the transfer of LSP related information residing within Management Plane to RSVP-TE records within Control Plane. We assume that this happens under operator or management application control and in particular that: - Control requests are sent to the ingress LSR by the MP - The MP has some way of knowing when the CP has completed its task or has failed. Ingress node collects from MP all the LSP related information needed at Control Plane level. The way this operation is done and where such information is collected within MP is outside the scope of this document. One possible (optional) way to collect it is explained in Section 8. A relevant part of such information is represented by the LSP path, which has to be handed over to CP to be used by signalling entity to fill the Explicit Route Object (ERO) during setup. In order to support the MP to CP handover of LSP, the ERO object in the Path message MUST be filled with all the LSP relevant information down to the Label level. That can be done by means of the object and procedures defined in [RFC3473]. The precise filling of the ERO object is needed as we are assuming that the LSP already exists in Data Plane and that every signalling relevant info about it is available and accessible to MP in terms of required LSP parameters to build a RSVP-TE PATH message. After the collection of all the LSP related information, the ingress node starts the handover procedure issuing a RSVP-TE PATH message including the Administrative Status Object with both HANDOVER and REFLECT flags set. The R flag set assures that also the Resv message will set the H flag. Upon reception of such RSVP-TE PATH, a node MUST be able to understand that a MP to CP handover procedure is in progress by reading the Handover flag. Eithersetup/release procedure. The DP MUST NOT be affected from the handover procedure. The ingress node ofMUST send a Path message in the LSP (upon request from MP) and intermediatedownstream direction with the H and egress nodes (whenR ([RFC3471]) bit set. Upon receiving a Path/Resv messagePath Message containing an Administrative Status objectObject with the Handover flag set) are informed about the fact that a LSP handover procedure is requested or ongoing. TheH bit set, each node assumes thatMUST check if there is a Data Plane resource related to the info carried inlocal Path Message is already allocated and in place. The following of the section illustrates in detailState matching the procedure in cases in success and failures. 5.1.MP to CP Handover Procedure Success Upon receiving arequest. If no local Path Message, each node SHOULD checkState exists, the consistence ofnode MUST confirm that there is an existing DP state that corresponds to the actual Data Plane status ofPath message. In case such resource. Say the check goes OKDP state exists (failure cases are illustrateddefined in the next sections), thenlocal Path state MUST be installed. The H bit MUST be stored in the local Path state. After propagating a RSVP-TE record forPath message with the LSP is created associating it toH bit set, a node MUST wait for a Resv message including Administrative Status Object with H bit set. After the corresponding Data Plane state. Theingress node accepts allreceives it, the actual migration of LSP information carried inis complete, the Path message (ifLSP is left completely under control of RSVP-TE within Control Plane. If the nodeResv message is not received by the Ingress LERexpiration of a timer (called Expiration timer in the LSP, otherwisefollowing) set by the informationingress LER, the handover procedure is aborted, that is, a PathTear message MUST be sent from relevant MP entity) and stores itin Path State Block. After that,the procedure goes on as described below. After propagating handover Path message, adownstream direction. In order to complete the Handover process the ingress node MUST wait forsend a ResvPath message including Administrative Status Objectwith Handover flag set. After receiving it,the actual migrationH bit cleared (set to zero) upon receipt of LSP information is complete,a corresponding Resv message. The R bit SHOULD NOT be set in this message. Downstream nodes MUST clear their local "Handover" state based on a received Path message with the LSP is left completely under control of RSVP- TE within Control Plane.H bit cleared. This means that once a downstream node processes a Path message with the cleared H bit, any memory aboutstate related to the former MP ownership of the LSP is lost. If a Confirmation message was requested, then it is generated.Normal ResvConf process occurs as normal. The handover procedure does not modify the Confirmation procedure. 5.2.In case the path of the LSP is not fully passed to the ingress LER, each node can determine the next hop looking at its data plane and exploit the similarity between the MP to CP Handover procedure and the Restart Procedure. Please refer to Section 5. 4.2. MP to CP Handover Procedure Failure Handling In case of Management PlaneMP to Control PlaneCP Procedure, two different failure scenarios can happen: Path Failure and Resv Failure. Moreover, each failure can be due to two different causes: Data PlaneDP failure or Communication Failure. In any case the LSP ownership MUST be immediately roll backed to the one previous to the handover procedure. A section for each combination will be analyzed in the following. 188.8.131.52.2.1. MP to CP Handover Failure - Path Failure 184.108.40.206.220.127.116.11. MP to CP Handover Failure - Path Messagemessage and Data Plane Failure The handover procedure can fail due to different causes, but in any case the network status MUST be immediately rollbacked to the one previous to the handover procedure. The failure can happen during the Path message or the Resv message forwarding.In this paragraph we will analyze the first case.case where the handover procedure fails during the Path message processing. | Path | | | |---------------------->||--------------->| Path | | | |----------------------X||---------------X| | | | | | | Path ErrPathErr | | | |<----------------------||<---------------| | | | | | | Ingress LER LSR A LSR B Egress LER MP2CP - Path Msg and DP Failure If an error occurs in an LSR or a LER, the last node that has received the Path message MUST send a Path ErrorPathErr message in the upstream direction including an Error_Spec objectand the Handover flag set.handover procedure is aborted. The Path ErrorPathErr message SHOULD have the Path_State_Removed flag set andPath_State_Removed flag set. Nodes receiving a PathErr message MUST follow standard PathErr message processing with the exception that when their local state indicates that a Handover is in progress (based on the H bit in the upstream nodes MAY processPath message) the Error_Spec object. 18.104.22.168.associated DP resources MUST NOT be impacted during such processing. 22.214.171.124. MP to CP Handover Failure - Path Messagemessage and Communication failure Other possible scenarios are shown in the following pictures and consist on the unreachability ofinability to reach a node along the path of the LSP. The below scenario postulates the usage of a reliable message delivery based on the mechanism defined in [RFC2961]. | Path | | | |---------------------->||--------------->| Path | | | |------------X ||---------------X| | | |------------X ||---------------X| | | | ... | | | |------------X | | | | | | | Path Err | | | |<----------------------| ||---------------X| | | | | | Ingress LER LSR A LSR B Egress LER 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. AAs a reliable delivery mechanism is implemented, LSR A retransmits the Path Messagemessage for a configurable number of times, then,times and if no ack is received, a Path Error message MUST be sent back to the ingress LER,received the Path_State_Removed flag SHOULDhandover procedure will be set andaborted (via the adoption procedure is aborted.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 | | | ||----------X | | | | | | |----TIMER EXPIRES------||-TIMER EXPIRES--| | | | Path Tear | | | |---------------------->||--------------->| | | | | | | Ingress LER LSR A LSR B Egress LER MP2CP - Path Msg and Communication Failure (no reliable delivery) If the Resv Messagemessage is not received by the expiration of a timer set bythe ingress LER,Expiration timer the adoptionhandover procedure is againaborted and a PathTear message MAY be sentas described in the downstream direction with the H bit set. 5.2.2.Section 4.1. 4.2.2. MP to CP Handover Failure - Resv Error 126.96.36.199.188.8.131.52. MP to CP Handover Failure - Resv Error and Data Plane failure In case a failure occurs during the Resv Message forwarding, things are quite different, because after the handover procedure an LSR is not able to distinguish an LSP created bymessage processing, the Control Plane from an LSP created bynode MUST send a PathErr message in the Management Planeupstream direction. The PathErr message is constructed and then moved to the Control Plane.processed as defined above in Section 184.108.40.206. The failure detection node MUST also send a PathTear message downstream. The PathTear message is constructed and processed as defined above in Section 220.127.116.11. | Path | Path | Path | |---------------------->|---------------------->|---------------------->||--------------->|--------------->|--------------->| | | | Resv | | | Resv |<----------------------| | |X----------------------||<---------------| | | Path Err | Path TearX---------| | | |<----------------------|---------------------->| Path TearPathErr | PathTear | PathTear | |---------------------->||<---------------|--------------->|--------------->| | | | | Ingress LER LSR A LSR B Egress LER MP2CP - Resv Error and DP Failure In the case shown in the above picture, the failure occurs in LSR A. Considering to have a reliable message delivery mechanism, a Path TearA PathTear message MUST beis sent in the downstream directiontowards B and a Path ErrorPathErr message MUSTis sent in the upstream direction and the Path_State_Removed SHOULD flag should be set.direction. The Path ErrPathErr and Path TearPathTear messages remove the Path state established by the Path messages along the nodes of the LSP and abort the adoptionhandover procedure. Please note that the failure occurred after the handover procedure was successfully completed in LSR B. This means that LSR B is no longer able to know if the LSP was created by the Control Plane or a handover procedure took place. Upon receivingB, but Handover state will still be maintained locally as, per Section 4.1, a Path Tear message, LSR B would delete the LSP also from the Data Plane point of view. To prevent this from happening, LSR A MUST set the handover flag in the Path Tear message. The downstream node move the LSP ownership back to the Management Plane and MUST NOT modifymessage with the Data Plane. 18.104.22.168.H bit clear will have not yet been sent or received. 22.214.171.124. MP to CP Handover Failure - Resv Error and Communication failure In case a Resv Messagemessage cannot reach one or more of the downstreamupstream nodes, the procedure is quite similar to the one previously seen about the Path Message.message. Even in this case it is possible to distinguish two different scenarios. 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 LER or an LSR, say LSR A. LSR B, after sending theB MUST send a Resv message again for a configurable number of times, MUST send a Path Tear message in the downstream direction towards the Egress LERtimes and a Path Error message (with the Path_State_Removed flag set) in the upstream direction towards the Ingress LER in order to inform the nodes ofthen, if the path thatdelivery does not succeed, the adoption procedure has failed and that the LSP ownership is towill be moved back toaborted (via the management plane.Expiration timer). | Path | Path | Path | |---------------------->|---------------------->|---------------------->||--------------->|--------------->|--------------->| | | | Resv | | | Resv |<----------------------||<---------------| | | X-----------|X---------| | | | X-----------|X---------| | | | ... | | | | X-----------| | | | | | | Path Err | Path Err | Path Tear | |<----------------------|<----------------------|---------------------->| | | | | Ingress LER LSR A LSR B Egress LER Please note that the failure occurred after the handover procedure was successfully completed in the Egress LER. This means that it is no longer able to know if the LSP was created by the Control Plane or a handover procedure took place. Upon receiving a Path Tear message, the downstream nodes would delete the LSP also from the Data Plane point of view. To prevent this from happening, the Path Tear message MUST include the Handover flag.| X---------| | | | | | Ingress LER LSR A LSR B Egress LER 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 Path ErrorPathErr would fail too. Due to this fact, a configurablethe Expiration timer MUST be setis used on the Ingress LER after sending the path and on LSR A after forwandingforwarding it. When the timer expires, if no Resv or Path ErrorPathErr message is received, the handover procedure MUST beis aborted as described in Section 4.1 and the LSP ownership returned to the Management Plane. The following picture, on the other hand, shows the scenario in which no reliable delivery mechanism is implemented. | Path | Path | Path | |---------------------->|---------------------->|---------------------->||--------------->|--------------->|--------------->| | | | Resv | | | Resv |<----------------------| | | X-----------| | | | ||<---------------| | | X---------| | | | |----TIMER EXPIRES------||-TIMER EXPIRES--| | | | Path Tear | Path Tear | Path Tear | |---------------------->|---------------------->|---------------------->||--------------->|--------------->|--------------->| | | | | Ingress LER LSR A LSR B Egress LER After sending the path message, the ingress LER sets a timer.MP2CP - Resv Error and Communication Failure (no reliable delivery) If non Resv message is received before the Expiration timer expires, then the adoption procedure is aborted andthe Ingressingress LER MAY signal it by a Path Tear message withfollows the H bit set. 126.96.36.199.same procedure defined in Section 4.1. 188.8.131.52. MP to CP Handover Failure - Node Graceful Restart In case one of the nodes restarts and graceful restart is enabled then one of the following scenarios will happen. Case I Restart timer is not infinite. In the sequence diagram below, assume LSR A restarts. In case the ingress LER does not receive the Resv message in time it willMUST abort the conversionhandover 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 willMUST start tearing down all LSPs between LSR A and LSR B and this includes the LSP that is being used to carry out the conversionhandover of MP resources to CP. LSP B willMUST generate a PathTear message downstream and a PathErr message upstream. Both LSR B and the egress LER will notMUST NOT release the data-planeDP resources because in both nodes the H-bitH bit is set in the PSB.local Path state. | Path | Path | Path | |---------------------->|---------------------->|---------------------->||--------------->|--------------->|--------------->| | | | Resv | | | Resv |<----------------------||<---------------| | X X-----------|X---------| | | PathTear | | |----------X | | ||-------X Restart Timer | | PathErrExpires | | PathErr | PathTear | | X-----------|---------------------->|X--------|--------------->| | | | | X | | | | | | Ingress LER LSR A LSR B Egress LER MP2CP - Node graceful restart - Case I Case II Restart timer is infinite. 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 willMUST 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 PSBlocal Path state after it aborts the conversionhandover process. Thus LSR B willMUST 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. SimilarilySimilarly to the previous case both LSR B and the egress LER will notMUST NOT release the data-planeDP resources because the H-bitH bit is set in the PSB.local Path state. | Path | Path | Path | |---------------------->|---------------------->|---------------------->||--------------->|--------------->|--------------->| | | | Resv | | | Resv |<----------------------||<---------------| | X X-----------|X---------| | | PathTear | | |----------X|-------X | | | | | | X | | | | | | | | Recovery Timer | | | PathErrExpires PathTear| | PathErr | PathErr | PathTear | |<---------------|<---------------|--------------->| | X-----------|---------------------->|| | | Ingress LER LSR A LSR B Egress LER MP2CP - Node graceful restart - Case II Case III Ingress LER did not abort the conversionhandover process. Once LSR A restarts the ingress LER willMUST re-generate the Path message with the H-bitH bit set. When LSR B receives the Path message it mayMAY generate a PathErr since the RECOVERY LABEL may not be present. The reason is LSR A may not have the label. SimilarilySimilarly LSR B and egress LER will notMUST NOT release the data-planeDP resources since the H-bitH bit is set. | Path | Path | Path | |---------------------->|---------------------->|---------------------->||--------------->|--------------->|--------------->| | | | Resv | | | Resv |<----------------------||<---------------| | X X-----------|X---------| | | | | | X | | | | X| | | Path | Path | | |---------------------->|---------------------->||--------------->|--------------->| | | PathErr | PathErr | PathTear | |<----------------------|<----------------------|---------------------->||<---------------|<---------------|--------------->| | | | | Ingress LER LSR A LSR B Egress LER 6.MP2CP - Node graceful restart - Case III 4.3. CP to MP handover : LSP Ownership Transfer From Control Plane To Management Plane Let's now consider the case of LSP Ownership Transfer From Control Plane To Management Plane. Also in this sections we will analyze the handover procedure success and failure. 6.1. CP to MP Handover Procedure SuccessThe scenario is still a Data PlaneDP connection between two nodes acting as ingress and egress for a LSP. But let's assumeLSP, but in this case that Control Planethe CP has the ownership and control of the LSP and that we want to hand it over to Management Plane. This means that at the end of such procedure, the Data Plane state relatedLSP. The CP to that connection is still untouched, butMP handover procedure MUST delete the LSP related information record is no more owned byexisting RSVP-TE over Control Plane.session information and MUST NOT affect the cross-connected resources, but just move their ownership to the MP. In other words, after LSP ownership transfer from CP to MP, the LSP is no morelonger under control of RSVP-TE, which is no more able to "see" the LSP itself. This Section covers the procedure neededThe CP to manage thisMP handover procedure asMUST be a dual, opposite procedure respect to the one described in previous section. Thestandard LSP deletion procedure is performed at a signaling levelas described in Section 7.2.1 of [RFC3473]. At LSP ingress node, relevant MP entity requests the ownership of the LSP, How this is doneThe procedure is outsideinitiated at the scopeingress node of memo.the LSP by a MP entity. Ingress node and MP exchange the relevant information for this task and then propagatespropagate it over Control PlaneCP by means of RSVP-TE tear down signaling flowas detaileddescribed below. IngressThe ingress node MUST send outa Path message,message in the downstream direction with Handover and Reflect bits set in the Admin Status set.Object. No action is taken over Data Planethe DP and Control Plane keeps tracktransit LSRs must forward such message towards the egress node. All of special handover statethe LSP is in. Transit and Egress nodes, upon receptionnodes MUST keep track of such handover Path, propagate it without any Data Plane action, retainingthe handover state information associated toprocedure storing the LSP. After that,H and R bits in their local Path and Resv states. Then every node waits untilfor the HandoverH bit to be received within the related Resv message. After the Resv message is received back inby the Resv. Theningress LER, it MUST send a PathTear is issued andmessage in order to clear the whole LSP information record is cleared from RSVP- TErecorded on the RSVP-TE data structures of the nodes. Downstream nodes processing a PathTear message which follows a Path message with the H bit set, MUST NOT remove any associated data structures.plane state. In other words, a normal LSP tear down signaling is exchanged between nodes traversed by the LSP, but handover flag set in Path message indicates that no Data Plane action has to correspond to Control Plane signaling. At the end of handover tear down signaling flow, the LSP is released from Control Plane point of view, but its Data Plane state is still unmodified and it is now owned and controllable by MP. 6.2.the LSP, but 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 Failures during CP to MP handover procedure MUST be managed at signaling level as in normal LSP tear down procedure. The only difference is the handover flagH bit set in Administrative Status Object inside Path message which MUST be read by receiving node and imposes that no action has to be made over Data PlaneDP resource whose corresponding Control Plane record is involved in handover procedure. 7. Discovery Phase The discovery process starts at the orignating end-point, which transmits a discovery request Notify message on the link identified to be part of the LSP to be converted. The Notify message is forwarded hop-by-hop tracing the LSP information and identifying the next-hop. The assumption being made here is that information regarding individual neighbors is already available. In case the destination address is not known the RSVP-TE session destination address MAY not be specified (i.e. set to 0.0.0.0) in the discovery request Notify message. Any node that decides to terminate the discovery process will not forward the Notify message and will generate a discovery response Notify message. If any error prevents the discovery process to be successfully completed, the ERROS_SPEC object in the response Notify message will be filled with a failure code, else it MUST be se set to the success code. The discovery response message SHOULD be sent hop-by-hop back to the requestor. In case the destination address in the request message is 0.0.0.0 then it MUST be filled in by the terminating entity in the response message SESSION object. The format of the Notify Message is as follows: <Notify message> ::= <Common Header> [ <INTEGRITY> ] [[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...] [ <MESSAGE_ID> ] <ERROR_SPEC> <discovery info> <discovery info> ::= <SESSION> <RSVP_HOP> <RECOVERY_LABEL> [ <ADMIN_STATUS> ] [ <POLICY DATA> ] [ <SESSION_ATTRIBUTES>] [ <UPSTREAM_LABEL> ] [ <RECORD_ROUTE> ] The RECORD_ROUTE object in the discovery response SHOULD be put together such that it can be directly used in a Path message for the coversion phase. For example, explitcit label sub-objects can be specified only for outgoing links in the Path message [RFC3473]. 8.5. Alternative Way Of Retrieving Information Needed For MP To CP Handover An alternative way of getting the LSP related information required for the MP to CP handover is also proposeddefined in this draft. The rationale behind this way is that only a minimal set of information is handed over from MP to CP at LSPs Ingress node. Instead of collecting within MP all the LSP relevant information down to the Label level, formatting it to an ERO and passing it to CP, as in previously described solution, it is possible to start with a minimum amount of information. 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 the incoming interface ID ofegress node.node ID. The remaining information about an existing LSP can then be collected hop by hop, as the signalling is going on, by looking up the cross-connectioncross- connection table in Data PlaneDP at each node along the LSP path. Starting from the information available at ingress LER about the outgoing interface ID of that ingress node, the incoming interface ID of next hop can be found by looking up the link resource table/ database in the LER itself. Following the similarity existing between the MP to CP handover procedure and the Restart Procedure, the Recovery Label Object MUST be used to carry the downstream label andthat ingress node, the Upstream Label Object MUSTincoming interface ID of next hop can be used to carryfound by looking up the upstream label tolink resource table/ database in the next node.LER itself. The Path message is hence built with the Recovery LabelLABEL_SET Object ([RFC3473]) and the Upstream LabelUPSTREAM_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 above mentioned objects, the Path message MUST include the Administrative Status Object with HANDOVER flagH bit set, as already defined in previous chapterchapters for the detailed ERO based way of proceeding. Such handover Path is sent to the incoming interface of next hop. When this Path message reaches the second node along the LSP path, 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 Data PlaneDP 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 Recovery LabelLABEL_SET Object and Upstream LabelUPSTREAM_LABEL Object content with the looked-up values of upstream and downstream labels. Re-iteratingBy repeating this procedure for each transit node along the LSP path, it is possible to make the handover Path message reach the egress node, exactly following the LSP that is in place over Data Plane.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 interface ID or the Label level with upstream and downstream labels. The ERO can be used to check the consistenceconsistency of resource in Data PlaneDP down to the port level or label level at each intermediate node along the LSP path. 9.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] 6. RSVP Message Formats This memo does not introduce any modification in RSVP messages object composition. 10.7. Objects Modification The modifications required concern two RSVP Objects: the Administrative Status and the Error Spec Object. 10.1.7.1. Administrative Status Object This memo introduces a new flag into the Administrative Status object. The Admin_Status Object is defined in [RFC3473]. This document uses the H-bitH bit of the Admin_Status object. The bit is bit number (TBD by IANA). The format of the Admin_Status Object is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num(196)| C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Reserved |H|L|I|C|T|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The different flags are defined as follows: - Reflect (R): 1 bit - Defined in [RFC3471] When set, indicates that the edge node SHOULD reflect the object/ TLV back in the appropriate message.- Handover (H): 1bit When set, the H bit indicates that a Handover procedure for the transfer of LSP ownership between Management and Control Planes is ongoing. - Lockout (L): 1 bit - Defined in [RFC4872] When set, forces the recovery LSP to be temporarily unavailable to transport traffic (either normal or extra traffic).- Inhibit Alarm Communication (I): 1 bit - Defined in [RFC4783] When set, indicates that alarm communication is disabled for the LSP and that nodes SHOULD NOT add local alarm information.- Call Control (C): 1 bit - Defined in draft-ietf-ccamp-gmpls-rsvp-te-call-04  This bit is set when the message is being used to control and manage a Call.[RFC3471] - Testing (T): 1 bit - Defined in [RFC3471] When set, indicates that the local actions related to the "testing" mode should be taken.- Administratively down (A): 1 bit - Defined in [RFC3471] When set, indicates that the local actions related to the "administratively down" state should be taken.[RFC4974] - Deletion in progress (D): 1 bit - Defined in [RFC3471] When set, indicates that that the local actions related to LSP teardown should be taken. The H bit must be used in conjunction with the R flag when is set in the Path message. This will assures that the Resv message will maintain the H flag set. 10.2.7.2. Error Spec Object It is possible that a failure, such as the lostloss of DCN connection or the restart of a node, occurs during the LSP ownership handing over. In this case the LSP adoption MUST behandover is interrupted and the ownership of the LSP MUST bemoved back to the Plane it belonged to. It is important that the transaction failure MUSTdoes not affect the Data Plane.DP. The LSP MUST beis kept in place and no traffic hit MUST occur.occurs. The failure is signaled by Path ErrorPathErr in the upstream direction and Path TearPathTear Messages in the downstream direction. The Path ErrorPathErr messages include an Error_Spec_Object (the Path_State_Removed flag SHOUL always be set)specifying the causes of the failure, while the Path Tear messages, required in case of reliable recovery and optional otherwise, include the handover flag to prevent the deletion of the LSP from the Data Plane.the failure. This memo introduces a new Flag and a newError Code (with different Error Values) into the Error_Spec Object, defined in [RFC2205]. * ERROR_SPEC class = 6. * IPv4 ERROR_SPEC object: Class = 6, C-Type = 1 +-------------+-------------+-------------+-------------+ | IPv4 Error Node Address (4 bytes) | +-------------+-------------+-------------+-------------+ | Flags | Error Code | Error Value | +-------------+-------------+-------------+-------------+The fields of the object aredefined as follows: - Error Node Address The IP address of the node in which the error was detected. - Error Code A one-octet error description. - Error Value A two-octet field containing additional information about the error. Its contents depend upon the Error Type - Flags Flags assigned values: * 0x01 = InPlace * 0x02 = NotGuilty Proposed new value (TBD) = HandOverFailure The new flag is "Handover Procedure Failure" and the actual value is (TBD by IANA). When this flag is set during an handover from Management Plane to Control Plane, the receiver must delete the Control Plane status associated with the LSP and move the ownership of the cross-connections back to the Management Plane. The proposedError Code is "Handover Procedure Failure", and its value is (TBD by IANA)(33). For this Error Code the following Error Values are defined: 1 = Cross-connection mismatch 2 = DCN error 11. Acknoledgments3 = Other failure 8. Compatibility The main requirement for Handover procedure to work is that all nodes along the path MUST support the extension defined in this draft. In case a node does not support the Handover procedure, the upstream node along the path MUST send a PathErr message in the upstream direction including an Error_Spec_Object specifying the causes of the failure. 9. Acknowledgments We wish to thank Adrian Farrel and Lou Berger for his editorialtheir assistance and precious advices to prepare this draft for publication. We also wish to thank Nicola Ciulli, that contributed to initial stage of this draft. 12.10. Contributors Shan Zhu Fujitsu Network Communications Inc. 2801 Telecom Parkway, Richardson, Texas 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 Email: firstname.lastname@example.org 13.Lou Berger LabN Consulting, LLC Phone: +1 301 468 9228 EMail: email@example.com 11. Security Considerations The procedures described in this document rely completely on RSVP-TE messages and mechanism. The use of Handover FlagH bit set in Admin Status Object basically informs the receiving entity that no operations are to be done over Data PlaneDP as consequence of such special signaling flow. Using specially flagged signaling messages we want to limit the function of setup and tear down messages to Control Plane,CP, making them not effective over related Data PlaneDP resource usage. So, no additional or special issues are arisen by adopting this procedure, that aren't already brought up by the use of the same messages, without handover flagH bit setting, for LSP control. For RSVP-TE Security please refer to [RFC3473]. 14.12. IANA Considerations IANA has been asked to manage the bit allocations for the Administrative Status object ([RFC3473]). This document requires the allocation of the Handover bit: the H-bit.H bit. IANA is requested to allocate a bit for this purpose. 15.13. References 184.108.40.206. Normative References [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.[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",S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005. [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 2961, April 2001. 15.2.4974, August 2007. 13.2. Informational References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, August 2006.[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC4783] Berger, L., "GMPLS - Communication of Alarm Information", RFC 4783, December 2006. [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE Extensions in Support of End-to-End Generalized Multi- Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007. [RFC4783] Berger, L., "GMPLS - Communication of Alarm Information",[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 4783, December 2006. URIs  <http://tools.ietf.org/html/draft-ietf-ccamp-pc-and-sc-reqs-04>  <http://tools.ietf.org/html/ draft-ietf-ccamp-gmpls-rsvp-te-call-04>5493, April 2009. Authors' Addresses Diego Caviglia Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: firstname.lastname@example.org Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: email@example.com Dino Bramanti Ericsson Via Moruzzi 1 C/O Area Ricerca CNR Pisa Italy Email: firstname.lastname@example.org Dan Li Huawei Technologies Co., LTD.F3-5-B R&D Center, Huawei Base Shenzhen 518129 Huawei Base, Bantian, Longgang ItalyP.R.China Email: email@example.com@huawei.com Snigdho Bardalai Fujitsu Network Communications Inc2801 Telecom Parkway Richrdson, Texas 75082 USA Email: Snigdho.Bardalai@us.fujitsu.com Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org.