NetworkCCAMP Working Group Internet Draft DiegoD. Caviglia (Ericsson) DinoInternet-Draft D. Bramanti (Ericsson) DanExpires: January 16, 2009 Ericsson D. Li (Huawei) SnigdhoHuawei Technologies Co., LTD. S. Bardalai (Fujitsu) Shan Zhu (Fujitsu) Igor Bryskin (ADVA Optical Networking) Intended Status: Updates RFC 3473 Expires: Septembers 2008 March 28,Fujitsu Network Communications Inc July 15, 2008 RSVP-TE Signaling Extension For The Conversion Between Permanent Connections And Soft Permanent Connections In A GMPLS enabledEnabled Transport Network draft-ietf-ccamp-pc-spc-rsvpte-ext-00.txtNetwork. draft-ietf-ccamp-pc-spc-rsvpte-ext-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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. draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008This Internet-Draft will expire on August 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2008).January 16, 2009. 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 valuable option. This applies especially when a GMPLS based Control Plane is first introduced into an existing network and there may be the need, from a Carrier point of view, to pass under GMPLS control existing connections already set up over Data Plane. In other terms, such operation could be seen as a way of transferring the ownership and control of an existing and in-use Data Plane connection between the Management Plane and the Control Plane, leaving its Data Plane state untouched.requirement. See draft "draft-ietf-ccamp-pc-and-reqs-04.txt . 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 proposed procedures. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",Failure conductions and "OPTIONAL" in this documentsubsequent roll back are to be interpreted as described in RFC2119 .also illustrated taking into account that an handover failure must not impact the already established data plane connections. Table of Contents 1. Introduction...................................................3Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation.....................................................3Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview Of Proposed RSVP-TE Based Solution...................3 4. LSP Control Handover Procedure Between Management And Control Planes.........................................................5 4.1Solution . . . . . . . . . 3 5. MP to CP handover: LSP Ownership Transfer From Management Plane To Control Plane............. ......................5 4.2Plane . . . . . . . . . . . . . . . . . . . . 5 5.1. MP to CP Handover Procedure Success . . . . . . . . . . . 6 5.2. MP to CP Handover Procedure Failure Handling . . . . . . . 7 5.2.1. MP handoverto CP Handover Failure - Path Failure . . . . . . . 7 5.2.2. MP to CP Handover Failure - Resv Error . . . . . . . . 8 6. CP to MP handover : LSP Ownership Transfer From Control Plane To Management Plane.....................................9 4.3Plane . . . . . . . . . . . . . . . . . . 13 6.1. CP to MP Handover Procedure Success . . . . . . . . . . . 13 6.2. CP to MP Handover Procedure Failure Handling.......... ....10 5.. . . . . . . . . . . 14 7. Discovery Phase.............................................10 draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008 6.Phase . . . . . . . . . . . . . . . . . . . . . . . 14 8. Alternative Way Of Retrieving Information Needed For MP To CP Handover......................................................11 7.Handover . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. RSVP Message Formats..........................................12 8.Formats . . . . . . . . . . . . . . . . . . . . . 16 10. Objects Modification..........................................12 8.1Modification . . . . . . . . . . . . . . . . . . . . . 17 10.1. Administrative Status Object..............................12 8.2Object . . . . . . . . . . . . . . . 17 10.2. Error Spec Object.........................................13 9. Security Considerations.......................................13 10. IANA Consideration...........................................14Object . . . . . . . . . . . . . . . . . . . . 18 11. References...................................................14Acknoledgments . . . . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgments..............................................14Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. Author's Addresses...........................................14Security Considerations . . . . . . . . . . . . . . . . . . . 20 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 15.1. Normative References . . . . . . . . . . . . . . . . . . . 20 15.2. Informa</artwork>tional References . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 23 1. Introduction In a typical,typical traditional transport network scenario, Data Plane connections between two endpoints are controlled basicallyby 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 over networks that are already in service - controlled by NMS at Management Plane 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 have been thought having in mind SDH/SONET LSPs  supported by GMPLS butcan be applied to any kind of LSPs.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 . Such procedure is aimed at giving the transport network operators the chance to convert existing LSP provisioned as PC by NMS to SPC without disrupting user traffic flowing on it. Conversion from PC to SPC (i.e. when existing data planeData Plane connection ownership and control is passed from MP to CP) has been proposed as mandatory requirement, while the opposite operation, SPC to SC conversion, has been considered as a nice-to-have feature that can be seen as a back-out option. For more details on requirements and motivations please refer to . 3."draft-ietf-ccamp-pc-and-reqs-04.txt . 4. Overview Of Proposed RSVP-TE Based Solution draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008The whole process comprises of the discovery and conversion phases. The discovery phase being described in this document is an OPTIONAL procedure and not mandatory for the conversion phase to proceed. The discovery phase is typically initiated by the operator and is performed hop-by-hop in order to discover the route. The route discovered SHOULD be consistent with the network topology. For example, for a multi-layer network the hops discovered should be contained within the same layer. Prior to initiating the discovery process it is assumed that the control-planeControl Plane domains have been established. The operator at the originating node can optionally specify the terminating end-point at the time of initiating the discovery request or it could be automatically discovered. For example, at a network layer boundary the discovery process can be terminated generating a response back to the originator. Another possibility is to terminate the request at the control-planeControl Plane domain boundary. For conversion to SCPC or SPC the conversion phase will create an RSVP- TE session along the discovered or user-specified route and bind with the existing management-planeManagement Plane owned cross-connect resources (e.g. lambdas, time slots and reserved bandwidth)and at the same time transfer the ownership to the control-plane.Control Plane. For conversion to PC the conversion phase will delete the existing RSVP- TE session information without deleting the cross-connect resources and transfer the ownership to the management-plane.Management Plane. Proposed procedure relies on the utilization of a newly introduced flag, here named Handover flag, in the Administrative Status Object (RFC 3471[RFC3471] and RFC 3473 ).[RFC3473]. The point is that standard RSVP-TE signaling flow can be used to inform nodes about the ownership handover request regarding one LSP that is already in place on their data plane,Data Plane, where such flow has to be flagged in order to discriminate it from normal, data planeData 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 planeData Plane state at each addressed node along the path draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008as usual - from the LSP ownership handover procedure that MUST leave untouched data planeData Plane state. This is in some way similar as an approach to the Restart Procedure, (Section 4.3 RFC 3473 ),( [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 planeData 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. 4. LSP Control Handover Procedure Between Management And Control Planes The procedure described below describes how to move the ownership of an LSP from the Management Plane to Control Plane. 4.15. 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: draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008- 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 onedocument. One possible (optional) way to collect it is explained in Section 5.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 .ignallingsignalling 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 planeData Plane and that every .ignallingsignalling 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 issuesstarts 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. Either the ingress node of the LSP (upon request from MP) and intermediate and egress nodes (when receiving a PathPath/Resv message containing an Administrative Status object with the Handover flag set) isare informed about the fact that a LSP handover procedure is requested or ongoing. The node assumes that a Data Plane resource related to the info carried in Path Message is already allocated and in place. At the receiptThe following of the Path Messagesection illustrates in detail the procedure in cases in success and failures. 5.1. MP to CP Handover Procedure Success Upon receiving a Path Message, each node SHOULD check the consistence of the actual Data Plane status of such resource: - Ifresource. Say the check goes OK,OK (failure cases are illustrated in the next sections), then a RSVP-TE record for the LSP is created associating it to the corresponding Data Plane state. The node accepts all the LSP information carried in PATHthe Path message (if the node is not ingressthe Ingress LER of the LSP, otherwise the information is sent from relevant MP entity) and stores it in Path State Block. After that, the procedure goes on as described below. - IfAfter propagating handover Path message, a node MUST wait for a Resv message including Administrative Status Object with Handover flag set. After receiving it, the check goes NOT OK, that isactual Data Plane state formigration of LSP information is complete, the indicated resourceLSP is different fromleft completely under control of RSVP- TE within Control Plane. This means that any memory about the one indicated informer MP ownership of the Path message, then: draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008 * A PathErr with Path State Removed flag and an error value indicating 'handover procedure failure' set must be generated * GMPLS Control Plane state information aboutLSP is lost. If a Confirmation message was requested, then it is not accepted by thegenerated. The handover destination entity In both cases, no operation is done over Data Plane. In case of positive check, no change is required at that level sinceprocedure does not modify the connection is already set up and in service.Confirmation procedure. 5.2. MP to CP Handover Procedure Failure Handling In case of negative check, a mismatch or some other error has occurredManagement Plane to Control Plane Procedure, two different failure scenarios can happen: Path Failure and no LSP control handover is possible but no operation MUSTResv Failure. Moreover, each failure can be performed at thedue to two different causes: Data Plane that is the already present cross-connection MUST notfailure or Communication Failure. A section for each combination will be deleted. The procedure rolls back and information transfer process fromanalyzed in the following. 5.2.1. MP to CP at ingress node of the LSP has to be fixed and reinitiated. A node participating in aHandover Failure - Path Failure 126.96.36.199. MP to CP Handover Failure - Path Message and Data Plane Failure The handover procedure MUSTcan fail due to different causes, but in fact keep track of the special 'handover' condition ofany case the LSP involved, by retaining information that an handover procedure is ongoing. This is important because during handover procedure no other Data Plane, Control Plane or Management Plane action has tonetwork status but be taken onimmediately rollbacked to the LSP outsideone previous to the control ofhandover procedure. The failure can happen during the procedure itself. Such special state regardingPath message or the involved LSP has to be retained untilResv message forwarding. In this paragraph we will analyze the procedure itself has correctly ended. After propagating handover Path,first case. | Path | | | |---------------------->| Path | | | |----------------------X| | | | | | | Path Err | | | |<----------------------| | | | | | | Ingress LER LSR A LSR B Egress LER If an error occurs in an LSR or a LER, the last node that has received the Path message MUST wait forsend a ResvPath Error message in the upstream direction including Administrative Status Object withan Error_Spec object and the Handover flag set. After receiving it,The upstream nodes MAY process the actual migration of LSP information is complete,Error_Spec object. 188.8.131.52. MP to CP Handover Failure - Path Message and Communication failure Other possible scenarios are shown in the LSP is left completely under control of RSVP- TE within Control Plane. This means that any memory aboutfollowing pictures and consist on the former MP ownershipunreachability of the LSP is lost. Ifa Confirmation message was requested that it is generated. The handover procedure does not modify the Confirmation procedure. In casenode of failures duringthe processing ofLSP. The below scenario postulates the Resvusage of a reliable message delivery based on the node that generates the failure sends: -mechanism defined in [RFC2961] | Path | | | |---------------------->| Path | | | |------------X | | | |------------X | | | | ... | | | |------------X | | | | | | | Path Err | | | |<----------------------| | | | | | | Ingress LER LSR A PathErr withLSR B Egress LER The Path State Removed flag and an error value indicating 'handover procedure failure' set should bemessage sent from LSR A towards Ingress node. This caseLSR B is similar to a failure duringlost or does not reach the Path processing -destination for any reason. A ResvErr message, with the indication (a special Flag) that an error occurred duringreliable delivery mechanism is implemented, LSR A retransmits the Resv processing, towards Egress Node. Nodes processing this RescErr with special flag andPath Message for a configurable number of times, then, if no ack is received, a Path Error Value will delete the Control Plane information associated withmessage is sent back to the draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008 cross-connectioningress LER and move its ownership underthe Management Plane domain. Let's consider a LSP overadoption procedure aborted. In the network, connecting annext 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 | | | |---------------------->| | | | | | | Ingress node say I with an Egress node say E. Let's call timeslotLER LSR A andLSR B Egress LER If the Data Plane resources referredResv Message is not received by control information involved in Handover inthe expiration of a given node traversedtimer set by the LSP. This means that Handover flagged signaling refers to A-B cross-connection over Data Plane. Theingress node initiatesLER, the adoption procedure upon request from Management Plane. The way LSP related information is passed from MP to ingress nodeis outside the scope of this procedure description. Intermediates nodes and egress node receive the request for LSP adoptionagain aborted and the information needed for the operation from Handover flagged RSVP-TE signaling. The symbol <---->a PathTear message MAY be sent in table below indicates thatthe two Timeslots involved in Data Plane cross-connection are actually cross-connected over Data Plane, hence Data Plane state corresponds todownstream direction with the indication provided by LSP data held byH bit set 5.2.2. MP and in the process of being handed over to CP. Case 1| A<---->B |No info yet |MP expects A-B |OKto CP Handover Failure - Resv Error 184.108.40.206. MP to CP | | | |LSP handover ---------------------------------------------------------------- Case 2| A<---->C |No info yet |MP expects A-B |NOT OK for MPHandover 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 by the Control Plane from an LSP created by the Management Plane and then moved to the Control Plane. | Path | Path | |CP LSP handover ---------------------------------------------------------------- Case 3| No state |No info yet |MP expects A-B |Depends onPath | |---------------------->|---------------------->|---------------------->| | |locally| | |configured policy |--------------------------------------------------------------- Case 1: - LSP info from MP to be used for LSP control handover to RSVP-TE matches Data Plane stateResv | | | Resv |<----------------------| | |X----------------------| | | Path Err | Resv Err | | |<----------------------|---------------------->| Resv Err | | | |---------------------->| | | | | Ingress LER LSR A LSR B Egress LER In the case shown in terms of involved resources - LSP data record is not owned yet by Control Plane, hence LSP controlthe above picture, the failure occurs in LSR A. A Resv Error message is still up to MP - Checks are OK, so RSVP-TE state (related to involved LSP)sent in the downstream direction and a Path Error message is associated to Data Plane statesent in the upstream direction. Please note that the failure occurred after Handover flagged signaling flow (Path/Resv with Handover flag set) has ended. - Atthe end of signalinghandover procedure was successfully completed in LSR B. This means that LSR B is no longer able to know if the LSP is completely under CP control. - No actions are taken inwas created by the Control Plane or a handover procedure took place. Upon receiving a Resv Error message, LSR B would delete the Data Plane. Case 2: -LSP infoalso from MP to be used for LSP control handover to RSVP-TE doesn't matchthe Data Plane state in termspoint of involved resources. draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008 - Control Plane does not own LSP data record yet; henceview. To prevent this from happening, LSR A MUST include an Error_Spec object into the Resv Error message setting the handover flag. The downstream nodes MUST process the Error Spec object, move the LSP control is still upownership back to MP. - Checks are NOT OK. A-B connection is not actually present over Datathe Management Plane and indicated resources are used within other context (A is x-connectedMUST NOT modify the Data Plane. 220.127.116.11. MP to C).CP Handover Failure - RSVP-TE state (related to involved LSP)Resv Error and Communication failure In case a Resv Message cannot reach one or more of the downstream nodes, the procedure is not associatedquite similar to the cross connection after Handover flaggedone previously seen about the Path message. - A PathErr withMessage. 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 State Removed flag set MUST be sent Upstream. - LSP ownership remains completely under MP control. Handover has failed. - No actions are takenmessage along the nodes of the LSP, the Egress LSR sends a Resv message in the Data Plane. Case 3: - LSP info from MP to be used for LSP control handover to RSVP-TEopposite direction. It might happen that the Resv message does not existreach an LSR, say LSR A. LSR B, after sending the Resv message again for a configurable number of times, sends a Resv Error message in the Data Planedownstream direction towards the Egress LER and a Path Error message in termsthe upstream direction towards the Ingress LER in order to inform the nodes of involved resources. -the path that the adoption procedure has failed and that the LSP data recordownership is not owned yetto be moved back to the management plane. | Path | Path | Path | |---------------------->|---------------------->|---------------------->| | | | Resv | | | Resv |<----------------------| | | X-----------| | | | X-----------| | | | ... | | | | X-----------| | | | | | | Path Err | Path Err | Resv Err | |<----------------------|<----------------------|---------------------->| | | | | 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, hencePlane or a handover procedure took place. Upon receiving a Resv Error message, the downstream nodes would delete the LSP controlalso from the Data Plane point of view. To prevent this from happening, LSR B MUST include an Error_Spec object into the Resv Error message setting the Handover flag. The downstream nodes MUST process the Error Spec object, move the LSP ownership back to the Management Plane and MUST NOT modify the Data Plane. Considering that the Resv message did not manage to reach LSR A, it is still uphighly probable that the Path Error would fail too. Due to MP - decision aboutthis fact, a configurable timer MUST be set on the Ingress LER after sending the path and on LSR A after forwanding it. When the timer expires, if no Resv or Path Error message is received, the handover procedure MUST be aborted 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 OK or KO is a local policy. 4.2implemented. | Path | Path | Path | |---------------------->|---------------------->|---------------------->| | | | Resv | | | Resv |<----------------------| | | X-----------| | | | | | | | | | |----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. If non Resv message is received before the timer expires, then the adoption procedure is aborted and the Ingress LER MAY signal it by a Path Tear message with the H bit set. 18.104.22.168. 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 will abort the conversion 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 will start tearing down all LSPs between LSR A and LSR B and this includes the LSP that is being used to carry out the conversion of MP resources to CP. LSP B will generate a PathTear message downstream and a PathErr message upstream. Both LSR B and the egress LER will not release the data-plane resources because in both nodes the H-bit is set in the PSB. | Path | Path | Path | |---------------------->|---------------------->|---------------------->| | | | Resv | | | Resv |<----------------------| | X X-----------| | | PathTear | | |----------X | | | Restart Timer | | PathErr Expires PathTear | | X-----------|---------------------->| | X | | | | | | Ingress LER LSR A LSR B Egress LER 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 will 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 PSB after it aborts the conversion process. Thus LSR B will tear-down the specific LSP that is being used to convert the MP resources to CP by generating a PathTear downstream and PathErr upstream. Similarily to the previous case both LSR B and the egress LER will not release the data-plane resources because the H-bit is set in the PSB. | Path | Path | Path | |---------------------->|---------------------->|---------------------->| | | | Resv | | | Resv |<----------------------| | X X-----------| | | PathTear | | |----------X | | | | | | X | | | | | | | | Recovery Timer | | | PathErr Expires PathTear | | | X-----------|---------------------->| | | | Ingress LER LSR A LSR B Egress LER Case III Ingress LER did not abort the conversion process. Once LSR A restarts the ingress LER will re-generate the Path message with the H-bit set. When LSR B receives the Path message it may generate a PathErr since the RECOVERY LABEL may not be present. The reason is LSR A may not have the label. Similarily LSR B and egress LER will not release the data-plane resources since the H-bit is set. | Path | Path | Path | |---------------------->|---------------------->|---------------------->| | | | Resv | | | Resv |<----------------------| | X X-----------| | | | | | | | | X | | | Path | Path | | |---------------------->|---------------------->| | | PathErr | PathErr | PathTear | |<----------------------|<----------------------|---------------------->| | | | | Ingress LER LSR A LSR B Egress LER 6. 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 Success The scenario is still a Data Plane connection between two nodes acting as ingress and egress for a LSP. But let's assume in this case that Control Plane 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 related to that connection is still untouched, but the LSP related information record is no more owned by RSVP-TE over Control Plane. In other words, after LSP ownership transfer from CP to MP, the LSP is no more under control of RSVP-TE, which is no more able to "see" the LSP itself. This Section covers the procedure needed to manage this procedure as a dual, opposite procedure respect to the one described in previous section. The procedure is performed at a signaling level as described in Section 7.2.1 of the RFC 3473 .[RFC3473]. At LSP ingress node, relevant MP entity requests the ownership of the LSP, How this is done is outside the scope of memo. Ingress node and MP exchange the relevant information for this task and then propagates it over Control Plane by means of RSVP-TE tear down signaling flow as detailed below. Ingress node MUST send out a Path message, with Handover and Reflect bits in Admin Status set. No action is taken over Data Plane and Control Plane keeps track of special handover state the LSP is in. Transit and Egress nodes, upon reception of such handover Path, propagate it without any Data Plane action, retaining the handover draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008state information associated to the LSP. After that, every node waits until the Handover bit is received back in the Resv. Then a PathTear is issued and the whole LSP information record is cleared from RSVP- TE data structures. 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. 4.36.2. CP to MP Handover Procedure Failure HandlingFailures 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 flag 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 Plane resource whose corresponding Control Plane record is involved in handover procedure. 5.7. Discovery Phase The discovery process starts byat the orignating end-point transmittingend-point, which transmits a discovery request Notify message out a link as specified byon the cross-connectionlink identified to be part of the convertedLSP in the originating node.to be converted. The Notify message is forwarded hop-by-hop bytracing the cross-connectLSP 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. In case ofIf any errors detected which preventerror prevents the discovery process to completebe successfully completed, the ERROR_SPECERROS_SPEC object in the response Notify message will be filled inwith a failure codecode, 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. draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008The 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> ] 6.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. 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 proposed 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 of egress node. 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-connection table in data planeData Plane at each node along the LSP path. Starting from the information available at ingress TNELER 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/databasetable/ database in TNEthe 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 and the Upstream Label Object MUST be used to carry the upstream label to the next node. The Path message is hence built with the Recovery Label Object (RFC 3473)([RFC3473]) and the Upstream Label Object (RFC 3473),([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 flag set, as already defined in previous chapter for the detailed ERO based way of proceeding. Such handover Path is sent to the incoming interface of next hop. When this Path draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008message 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/ downstreamupstream/downstream labels by looking up the data planeData Plane 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 Label Object and Upstream Label Object content with the looked-up values of upstream and downstream labels. Re-iterating 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.Data Plane. 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 consistence of resource in data planeData Plane down to the port level or label level at each intermediate node along the LSP path. 7.9. RSVP Message Formats This memo does not introduce any modification in RSVP messages object composition. 8.10. Objects Modification 8.1The modifications required concern two RSVP Objects: the Administrative Status and the Error Spec Object. 10.1. Administrative Status Object This memo introduces a new flag into the Administrative Status object. The Admin_Status Object is defined in RFC 3473 .[RFC3473]. This document uses the H-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 signaling(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. -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 draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008- Defined in [RFC3471] When set, indicates that a Handover procedure forthe transfer oflocal actions related to the "administratively down" state should be taken. - Deletion in progress (D): 1 bit - Defined in [RFC3471] When set, indicates that that the local actions related to LSP ownership between Management and Control Planes is ongoing.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. 8.210.2. Error Spec Object It is possible that a failure, such as the lost of DCN connection or the restart of a node, occurs during the LSP ownership handing over. In this case the LSP adoption MUST be interrupted and the ownership of the LSP MUST be moved back to the Plane it belonged to. It is important that the transaction failure MUST not affect the Data Plane. The LSP MUST be kept in place and no traffic hint MUST occur. The failure is signaled by Path and Resv Error Messages, which include an Error_Spec_Object specifying the causes of the failure. This memo introduces anda new flagFlag and a new Error Code/ValueCode(with different Error Values) into the Error_Spec Object that isObject, defined in RFC 2205 .[RFC2205]. * ERROR_SPEC class = 6. o* 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 are defined 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 valuesvalues: * 0x01 = InPlace * 0x02 = NotGuilty Proposed new value (TBD) = HandOverFailure The new flag is 'handover procedure failurei'"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 planeControl Plane status associated with the LPSLSP and move the ownership of the cross-connections back to the Management Plane. 9.The proposed Error 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. Acknoledgments We wish to thank Adrian Farrel for his editorial 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. 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 Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova-Sestri Ponente, Italy Phone: +390106002515 Email: email@example.com 13. Security Considerations The procedures described in this document rely completely on RSVP-TE messages and mechanism. The use of Handover Flag set in Admin Status Object basically informs the receiving entity that no operations are to be done over Data Plane 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, making them not effective over related Data Plane 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 flag setting, for LSP control. For RSVP-TE Security please refer to . draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008 10.[RFC3473]. 14. IANA ConsiderationConsiderations 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. IANA is requested to allocate a bit for this purpose. 11.15. References 15.1. 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", RFC 2961, April 2001. 15.2. Informa</artwork>tional References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4606] Mannie, E, 'Generalized Multi-ProtocolE. and D. Papadimitriou, "Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control', RFC4606,Control", RFC 4606, August 2006  D. Caviglia, et ali. "GMPLS Requirements for the Conversion Between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network", draft- ietf-ccamp-pc-and-sc-reqs-02.txt, February 2008  L. Berger (Ed.)2006. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003  L. Berger (Ed.) "Generalized Multi-Protocol2003. [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE Extensions in Support of End-to-End Generalized Multi- Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions",Recovery", RFC 3473, January 2003  Braden, R., Zhang,4872, May 2007. [RFC4783] Berger, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997. 12. Acknowledgments We wish to thank Adrian Farrel for his editorial assistance and precious advices to prepare this draft for publication. We also wish to thank Nicola Ciulli that contributed to initial stage"GMPLS - Communication of this draft. 13. Author'sAlarm Information", 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> Authors' Addresses Diego Caviglia Ericsson Via A. Negrone 1/A draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008 Genova-Sestri Ponente,Genova - Sestri Ponente Italy Phone: +390106003738Email: firstname.lastname@example.org Dino Bramanti Ericsson Via Moruzzi 1 C/O Area Ricerca CNR Pisa,Pisa Italy Email: email@example.com Dan Li Huawei Technologies Co., LTD. Shenzhen 518129 Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.ChinaLonggang Italy Email: firstname.lastname@example.org Tel: +email@example.com Snigdho Bardalai Fujitsu Network Communications Inc 2801 Telecom Parkway, Richardson,Parkway Richrdson, Texas 75082 USA Email: Snigdho.Bardalai@us.fujitsu.com Tel: +1-972-479-2951 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 draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008Full 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 ietf- email@example.com@ietf.org.