CCAMP Working Group                                          D. Caviglia
Internet-Draft                                             D. Ceccarelli
Intended status: Standards Track                             D. Bramanti
Expires: March 26, 2010                                         Ericsson
                                                                   D. Li
                                                     Huawei Technologies
                                                             S. Bardalai
                                                         Fujitsu Network
                                                      September 22, 2009


 RSVP-TE Signaling Extension For Management Plane To Control Plane LSP
             Handover In A GMPLS Enabled Transport Network.
                 draft-ietf-ccamp-pc-spc-rsvpte-ext-04

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   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 March 26, 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.



Caviglia, et al.         Expires March 26, 2010                 [Page 1]


Internet-Draft     RSVP-TE Ext for MP2CP LSP Handover     September 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 requirement.

   This memo describes an extension to GMPLS RSVP-TE signaling that
   enables the transfer of connection ownership between the Management
   and the Control Planes.  Such a transfer is referred to as a
   Handover.  This document defines all Handover related procedures.
   This includes the handling of failure conditions and subsequent
   reversion to original state.  A basic premise of the extension is
   that the handover procedures must never impact an already established
   Data plane.






























Caviglia, et al.         Expires March 26, 2010                 [Page 2]


Internet-Draft     RSVP-TE Ext for MP2CP LSP Handover     September 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Procedures . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  MP to CP handover: LSP Ownership Transfer From
           Management Plane To Control Plane  . . . . . . . . . . . .  5
     4.2.  MP to CP Handover Procedure Failure Handling . . . . . . .  6
       4.2.1.  MP to CP Handover Failure - Path Failure . . . . . . .  6
         4.2.1.1.  MP to CP Handover Failure - Path message and
                   Data Plane Failure . . . . . . . . . . . . . . . .  6
         4.2.1.2.  MP to CP Handover Failure - Path message and
                   Communication failure  . . . . . . . . . . . . . .  7
       4.2.2.  MP to CP Handover Failure - Resv Error . . . . . . . .  8
         4.2.2.1.  MP to CP Handover Failure - Resv Error and
                   Data Plane failure . . . . . . . . . . . . . . . .  8
         4.2.2.2.  MP to CP Handover Failure - Resv Error and
                   Communication failure  . . . . . . . . . . . . . .  9
         4.2.2.3.  MP to CP Handover Failure - Node Graceful
                   Restart  . . . . . . . . . . . . . . . . . . . . . 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  . . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 15
   7.  Objects Modification . . . . . . . . . . . . . . . . . . . . . 15
     7.1.  Administrative Status Object . . . . . . . . . . . . . . . 15
     7.2.  Error Spec Object  . . . . . . . . . . . . . . . . . . . . 16
   8.  Compatibility  . . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     13.2. Informational References . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19












Caviglia, et al.         Expires March 26, 2010                 [Page 3]


Internet-Draft     RSVP-TE Ext for MP2CP LSP Handover     September 2009


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 MP 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.

   This memo describes an extension to Generalized Multi-Protocol Label
   Switching (GMPLS) RSVP-TE (see [RFC3471] and [RFC3473]) signaling
   that enables the handover of connection ownership between the
   Management and the Control Planes.  All handover related procedures
   are defined below.  This includes the handling of failure conditions
   and subsequent reversion to original state.  A basic premise of the
   extension is that the handover procedures must never impact an
   already established Data plane.


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 [RFC5493].  Such procedure is aimed at giving the
   transport network operators the chance to handover the ownership of
   existing LSPs provisioned by NMS from the MP to the CP without
   disrupting user traffic flowing on them.  Handover from MP to CP
   (i.e. when existing DP connection ownership and control is passed
   from MP to CP) has been defined as mandatory requirement, while the
   opposite operation, CP to MP handover, has been considered as a nice-
   to-have feature that can be seen as an emergency procedure to disable
   the CP and take the manual control of the LSP.  For more details on
   requirements and motivations please refer to [RFC5493].



Caviglia, et al.         Expires March 26, 2010                 [Page 4]


Internet-Draft     RSVP-TE Ext for MP2CP LSP Handover     September 2009


4.  Procedures

   The modification defined in this document refers only to ADMIN_STATUS
   Object, that is, the message flow is left unmodified for both LSP
   set-up and deletion.  Moreover a new Error Value is defined to
   identify the failure of a Handover procedure.

   The following paragraphs give detailed description of defined "MP to
   CP handover" and "CP to MP handover" procedures, based on the usage a
   newly define bit called H bit.

   The MP to CP handover procedures support two different methods for
   retrieving required information.  The primary one consists on
   receiving the full Explicit Route Object (ERO) from the MP 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 create the LABEL_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

   The MP to CP handover procedure MUST create an RSVP-TE session along
   the path of the LSP to be moved from MP to CP, associating it to the
   existing cross-connected resources owned by the MP (e.g. lambdas,
   time slots or reserved bandwidth) and at the same time transferring
   their ownership to the CP.

   A standard RSVP-TE signaling flow MUST be used to inform nodes about
   the ownership handover request.  Such flows MUST be tagged with a new
   flag that is carried within the ADMIN_STATUS Object ([RFC3471] and
   [RFC3473]).  The new flag is referred to as the H bit and is
   described in Section 7.1.  The H bit MUST be set in order to
   discriminate the handover procedure from normal, DP affecting, LSP
   setup/release procedure.  The DP MUST NOT be affected from the
   handover procedure.

   The ingress node MUST send a Path message in the downstream direction
   with the H and R ([RFC3471]) bit set.  Upon receiving a Path Message
   containing an ADMIN_STATUS Object with the H bit set, each node MUST
   check if there is a local Path State matching the MP to CP Handover
   request.  If no local Path State exists, the node MUST confirm that
   there is an existing DP state that corresponds to the Path message.



Caviglia, et al.         Expires March 26, 2010                 [Page 5]


Internet-Draft     RSVP-TE Ext for MP2CP LSP Handover     September 2009


   In the case of DP state lack (failure cases are defined in the next
   sections), local Path state MUST be installed.  The H bit MUST be
   stored in the local Path state.

   After propagating a Path message with the H bit set, a node MUST wait
   for a Resv message including ADMIN_STATUS Object with H bit set.
   After the ingress node receives it, the actual migration of LSP
   information is complete, the LSP is left completely under control of
   RSVP-TE within Control Plane.

   If the Resv message is not received by the expiration of a timer
   (called Expiration timer in the following) set by the ingress LER,
   the handover procedure is aborted, that is, a PathTear message MUST
   be sent in the downstream direction.

   In order to complete the Handover process the ingress node MUST send
   a Path message with the H bit cleared (set to zero) upon receipt of 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 H bit cleared.  This means
   that once a downstream node processes a Path message with the cleared
   H bit, any state related to the former MP ownership of the LSP is
   lost.  Normal ResvConf process occurs as normal.  The handover
   procedure does not modify the Confirmation procedure.

   When 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 the case of MP to CP Procedure, two different failure scenarios
   can happen: Path Failure and Resv Failure.  Moreover, each failure
   can be due to two different causes: DP 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.

4.2.1.  MP to CP Handover Failure - Path Failure

4.2.1.1.  MP to CP Handover Failure - Path message and Data Plane
          Failure

   In this paragraph we will analyze the case where the handover
   procedure fails during the Path message processing.





Caviglia, et al.         Expires March 26, 2010                 [Page 6]


Internet-Draft     RSVP-TE Ext for MP2CP LSP Handover     September 2009


     |      Path      |                |                |
     |--------------->|      Path      |                |
     |                |---------------X|                |
     |                |                |                |
     |    PathErr     |                |                |
     |<---------------|                |                |
     |                |                |                |
   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 PathErr message in the upstream
   direction and the handover procedure is aborted.  The PathErr message
   SHOULD have the Path_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
   Path message) the associated DP resources MUST NOT be impacted during
   such processing.

4.2.1.2.  MP to CP Handover Failure - Path message and Communication
          failure

   Other possible scenarios are shown in the following pictures and
   consist on inability 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|                |
     |                |                |                |
   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.  As a reliable delivery
   mechanism is implemented, LSR A retransmits the Path message for a
   configurable number of times and if no ack is received the handover



Caviglia, et al.         Expires March 26, 2010                 [Page 7]


Internet-Draft     RSVP-TE Ext for MP2CP LSP Handover     September 2009


   procedure will be aborted (via the Expiration timer).

   In the next scenario RSVP-TE messages are sent without reliable
   message delivery, that is, no [RFC2961] MessageID procedure is used.




     |      Path      |                |                |
     |--------------->|      Path      |                |
     |                |----------X     |                |
     |                |                |                |
     |-TIMER EXPIRES--|                |                |
     |   Path Tear    |                |                |
     |--------------->|                |                |
     |                |                |                |
   Ingress LER      LSR A            LSR B       Egress LER

     MP2CP - Path Msg and Communication Failure (no reliable delivery)

   If the Resv message is not received by the expiration of the
   Expiration timer the handover procedure is aborted as described in
   Section 4.1.

4.2.2.  MP to CP Handover Failure - Resv Error

4.2.2.1.  MP to CP Handover Failure - Resv Error and Data Plane failure

   In the case of failure occurrence during the Resv message processing,
   the node MUST send a PathErr message in the upstream direction.  The
   PathErr message is constructed and processed as defined above in
   Section 4.2.1.1.  The failure detection node MUST also send a
   PathTear message downstream.  The PathTear message is constructed and
   processed as defined above in Section 4.2.1.1.



     |      Path      |      Path      |      Path      |
     |--------------->|--------------->|--------------->|
     |                |                |      Resv      |
     |                |      Resv      |<---------------|
     |                |      X---------|                |
     |    PathErr     |    PathTear    |    PathTear    |
     |<---------------|--------------->|--------------->|
     |                |                |                |
   Ingress LER      LSR A            LSR B       Egress LER

                     MP2CP - Resv Error and DP Failure



Caviglia, et al.         Expires March 26, 2010                 [Page 8]


Internet-Draft     RSVP-TE Ext for MP2CP LSP Handover     September 2009


   In the case shown in the above picture, the failure occurs in LSR A.
   A PathTear message is sent towards B and a PathErr message is sent in
   the upstream direction.  The PathErr and PathTear messages remove the
   Path state established by the Path messages along the nodes of the
   LSP and abort the handover procedure.

   Please note that the failure occurred after the handover procedure
   was successfully completed in LSR B, but Handover state will still be
   maintained locally as, per Section 4.1, a Path message with the H bit
   clear will have not yet been sent or received.

4.2.2.2.  MP to CP Handover Failure - Resv Error and Communication
          failure

   When a Resv message cannot reach one or more of the upstream nodes,
   the procedure is quite similar to the one previously seen about the
   Path 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 MUST send a Resv message again for a
   configurable number of times and then, if the delivery does not
   succeed, the adoption procedure will be aborted (via the Expiration
   timer).




     |      Path      |      Path      |      Path      |
     |--------------->|--------------->|--------------->|
     |                |                |      Resv      |
     |                |      Resv      |<---------------|
     |                |      X---------|                |
     |                |      X---------|                |
     |                |      ...       |                |
     |                |      X---------|                |
     |                |                |                |
   Ingress 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 PathErr would fail too.  Due to this
   fact, the Expiration timer is used on the Ingress LER after sending



Caviglia, et al.         Expires March 26, 2010                 [Page 9]


Internet-Draft     RSVP-TE Ext for MP2CP LSP Handover     September 2009


   the path and on LSR A after forwarding it.  When the timer expires,
   if no Resv or PathErr message is received, the handover procedure is
   aborted as described in Section 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---------|                |
     |-TIMER EXPIRES--|                |                |
     |   Path Tear    |   Path Tear    |   Path Tear    |
     |--------------->|--------------->|--------------->|
     |                |                |                |
   Ingress LER      LSR A            LSR B       Egress LER

    MP2CP - Resv Error and Communication Failure (no reliable delivery)

   If non Resv message is received before the Expiration timer expires,
   the ingress LER follows the same procedure defined in Section 4.1.

4.2.2.3.  MP to CP Handover Failure - Node Graceful Restart

   In the case of node restart and graceful restart is enabled then one
   of the following scenarios will happen.

   Case I - Finite Restart Time

   In this case, the Restart Time (see [RFC3473]) is finite, i.e., not a
   value of 0xffffffff.  In the sequence diagram below, assume LSR A
   restarts.  If the ingress LER does not receive the Resv message in
   time it MUST abort the handover process by generating a PathTear
   message downstream.  Also, if LSR A does not complete the restart
   process within the restart time interval then LSR B MUST start
   tearing down all LSPs between LSR A and LSR B and this includes the
   LSP that is being used to carry out the handover of MP resources to
   CP.  LSP B MUST generate a PathTear message downstream and a PathErr
   message upstream.  Both LSR B and the egress LER MUST NOT release the
   DP resources because in both nodes the H bit is set in the local Path
   state.





Caviglia, et al.         Expires March 26, 2010                [Page 10]


Internet-Draft     RSVP-TE Ext for MP2CP LSP Handover     September 2009


     |      Path      |      Path      |      Path      |
     |--------------->|--------------->|--------------->|
     |                |                |      Resv      |
     |                |      Resv      |<---------------|
     |                X      X---------|                |
     |   PathTear                      |                |
     |-------X                   Restart Timer          |
     |                              Expires             |
     |                     PathErr     |    PathTear    |
     |                        X--------|--------------->|
     |                                 |                |
     |                X                |                |
     |                |                |                |
   Ingress LER      LSR A            LSR B       Egress LER

                  MP2CP - Node graceful restart - Case I

   Case II - Infinite Restart Time

   In this case, the Restart Time (see [RFC3473]) indicates that the
   restart of the sender's control plane may occur over an indeterminate
   interval, i.e., is 0xffffffff.  The sequence is quite similar to the
   previous one.  In this sequence the restart timer will not expire in
   LSR B since it is run infinitely.  Instead after LSR A restarts LSR B
   MUST start the recovery timer.  The recovery timer will expire since
   there will be no Path message with the RECOVERY LABEL received from
   LSR A given the ingress node had already removed the local Path state
   after it aborts the handover process.  Thus LSR B MUST tear-down the
   specific LSP that is being used to convert the MP resources to CP by
   generating a PathTear message downstream and PathErr message
   upstream.  Similarly to the previous case both LSR B and the egress
   LER MUST NOT release the DP resources because the H bit is set in the
   local Path state.


















Caviglia, et al.         Expires March 26, 2010                [Page 11]


Internet-Draft     RSVP-TE Ext for MP2CP LSP Handover     September 2009


     |      Path      |      Path      |      Path      |
     |--------------->|--------------->|--------------->|
     |                |                |      Resv      |
     |                |      Resv      |<---------------|
     |                X      X---------|                |
     |   PathTear                      |                |
     |-------X                         |                |
     |                                 |                |
     |                X                |                |
     |                |                |                |
     |                |          Recovery Timer         |
     |                |             Expires             |
     |    PathErr     |    PathErr     |    PathTear    |
     |<---------------|<---------------|--------------->|
     |                |                |                |
   Ingress LER      LSR A            LSR B       Egress LER

                  MP2CP - Node graceful restart - Case II

   Case III

   Ingress LER did not abort the handover process.  Once LSR A restarts
   the ingress LER MUST 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.  Similarly LSR B and egress LER MUST NOT release the
   DP 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

                 MP2CP - Node graceful restart - Case III




Caviglia, et al.         Expires March 26, 2010                [Page 12]


Internet-Draft     RSVP-TE Ext for MP2CP LSP Handover     September 2009


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 section we will analyze the
   handover procedure success and failure.

   The scenario is still a DP connection between two nodes acting as
   ingress and egress for a LSP, but in this case the CP has the
   ownership and control of the LSP.  The CP to MP handover procedure
   MUST delete the existing RSVP-TE session information and MUST NOT
   affect the cross-connected resources, but just move their ownership
   to the MP.

   In other words, after LSP ownership transfer from CP to MP, the LSP
   is no longer under control of RSVP-TE, which is no more able to "see"
   the LSP itself.  The CP to MP handover procedure MUST be a standard
   LSP deletion procedure as described in Section 7.2.1 of [RFC3473].
   The procedure is initiated at the ingress node of the LSP by a MP
   entity.  Ingress node and MP exchange the relevant information for
   this task and then propagate it over CP by means of RSVP-TE tear down
   signaling as described below.

   The ingress node MUST send a Path message in the downstream direction
   with Handover and Reflect bits set in the ADMIN_STATUS Object.  No
   action is taken over the DP and transit LSRs must forward such
   message towards the egress node.  All of the nodes MUST keep track of
   the procedure storing the H bit in their local Path and Resv states.
   Then every node waits for the H bit to be received within the related
   Resv message.  After the Resv message is received by the ingress LER,
   it MUST send a PathTear message in order to clear the whole LSP
   information recorded on the RSVP-TE data structures of the nodes.
   Downstream nodes processing a PathTear message which follows a Path
   message with the H bit set, MUST NOT remove any associated data plane
   state.  In other words, a normal LSP tear down signaling is exchanged
   between nodes traversed by the LSP, but 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 NOT result in the
   removal of any associated data plane state.  To that end, when a Resv
   message containing an ADMIN_STATUS Object with the H bit is not
   received during the period of time described in Section 7.2.2. of
   [RFC3473] different processing is required.  Specifically, the
   ingress node MUST NOT send a PathTear message before a Resv message
   containing the H bit is received.  The ingress node MAY choose to
   report the failure in the CP to MP handover procedure via the MP



Caviglia, et al.         Expires March 26, 2010                [Page 13]


Internet-Draft     RSVP-TE Ext for MP2CP LSP Handover     September 2009


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 defined 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 egress node ID.  The
   remaining information about an existing LSP can then be collected hop
   by hop, as the signaling is going on, by looking up the cross-
   connection table in DP 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.

   The Path message is hence built with the LABEL_SET Object ([RFC3473])
   and the UPSTREAM_LABEL Object ([RFC3473]), where the upstream label
   and downstream label of ingress outgoing interface of the LSP are
   included in these two objects.  In addition to above mentioned
   objects, the Path message MUST include the ADMIN_STATUS Object with H
   bit set, as already defined in previous chapters 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 DP cross-connection
   table.

   After having determined in this way the parameters describing the
   LSPs next hop, the outgoing Path message to be sent is built
   replacing the LABEL_SET Object and UPSTREAM_LABEL Object content with
   the looked-up values of upstream and downstream labels.

   By repeating this procedure for each transit node along the LSP path,
   it is possible to make the handover Path message reach the egress
   node, exactly following the LSP that is in place over DP.  The ERO
   MAY in this case be included in the Path message as an optional
   object, and MAY be filled with the LSP relevant information down to
   either the port level with interface ID or the Label level with
   upstream and downstream labels.  The ERO can be used to check the



Caviglia, et al.         Expires March 26, 2010                [Page 14]


Internet-Draft     RSVP-TE Ext for MP2CP LSP Handover     September 2009


   consistency of resource in DP down to the port level or label level
   at each intermediate node along the LSP path.

   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.


7.  Objects Modification

   The modifications required concern two RSVP objects: the ADMIN_STATUS
   and the ERROR_SPEC Object.

7.1.  Administrative Status Object

   This memo introduces a new flag into the ADMIN_STATUS object.  The
   ADMIN_STATUS Object is defined in [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]

   - 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]

   - Inhibit Alarm Communication (I): 1 bit - Defined in [RFC4783]




Caviglia, et al.         Expires March 26, 2010                [Page 15]


Internet-Draft     RSVP-TE Ext for MP2CP LSP Handover     September 2009


   - Call Control (C): 1 bit - Defined in [RFC3471]

   - Testing (T): 1 bit - Defined in [RFC3471]

   - Administratively down (A): 1 bit - Defined in [RFC4974]

   - Deletion in progress (D): 1 bit - Defined in [RFC3471]

7.2.  Error Spec Object

   It is possible that a failure, such as the loss of DCN connection or
   the restart of a node, occurs during the LSP ownership handing over.
   In this case the LSP handover procedure is interrupted, the ownership
   of the LSP must remain with the ownership prior to the initiation of
   the handover procedure.  It is important that the transaction failure
   does not affect the DP.  The LSP is kept in place and no traffic hit
   occurs.

   The failure is signaled by PathErr in the upstream direction and
   PathTear Messages in the downstream direction.  The PathErr messages
   include an ERROR_SPEC Object specifying the causes of the failure.

   This memo introduces a new Error Code (with different Error Values)
   into the ERROR_SPEC Object, defined in [RFC2205].

   The defined 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 = 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.
   This requirement translates to an administrative requirement as it is
   not enforced at the protocol level.  As defined, non-supporting will
   simply propagate the H bit without setting local state.  This may
   result in an impact data traffic during the handover procedure.


9.  Acknowledgments

   We wish to thank Adrian Farrel and Lou Berger for their assistance
   and precious advices to prepare this draft for publication.  We also



Caviglia, et al.         Expires March 26, 2010                [Page 16]


Internet-Draft     RSVP-TE Ext for MP2CP LSP Handover     September 2009


   wish to thank Nicola Ciulli (Nextworks), that contributed to the
   initial stage of this draft.


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: ibryskin@advaoptical.com

      Lou Berger
      LabN Consulting, LLC
      Phone: +1 301 468 9228
      EMail: lberger@labn.net



11.  Security Considerations

   The procedures described in this document rely completely on RSVP-TE
   messages and mechanism.  The use of H bit set in ADMIN_STATUS Object
   basically informs the receiving entity that no operations are to be
   done over DP 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 CP, making them not effective over
   related DP 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 H bit setting, for LSP control.
   For RSVP-TE Security please refer to [RFC3473].


12.  IANA Considerations

   IANA has been asked to manage the bit allocations for the
   ADMIN_STATUS Object ([RFC3473]).  This document requires the
   allocation of the Handover bit: the H bit.  IANA is requested to



Caviglia, et al.         Expires March 26, 2010                [Page 17]


Internet-Draft     RSVP-TE Ext for MP2CP LSP Handover     September 2009


   allocate a bit for this purpose.


13.  References

13.1.  Normative References

   [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.

   [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 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.

   [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.

   [RFC5493]  Caviglia, D., Bramanti, D., Li, D., and D. McDysan,
              "Requirements for the Conversion between Permanent
              Connections and Switched Connections in a Generalized
              Multiprotocol Label Switching (GMPLS) Network", RFC 5493,
              April 2009.



Caviglia, et al.         Expires March 26, 2010                [Page 18]


Internet-Draft     RSVP-TE Ext for MP2CP LSP Handover     September 2009


Authors' Addresses

   Diego Caviglia
   Ericsson
   Via A. Negrone 1/A
   Genova - Sestri Ponente
   Italy

   Email: diego.caviglia@ericsson.com


   Daniele Ceccarelli
   Ericsson
   Via A. Negrone 1/A
   Genova - Sestri Ponente
   Italy

   Email: daniele.ceccarelli@ericsson.com


   Dino Bramanti
   Ericsson
   Via Moruzzi 1 C/O Area Ricerca CNR
   Pisa
   Italy

   Email: dino.bramanti@ericsson.com


   Dan Li
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Shenzhen 518129
   P.R.China

   Email: danli@huawei.com


   Snigdho Bardalai
   Fujitsu Network
   2801 Telecom Parkway
   Richrdson, Texas 75082
   USA

   Email: Snigdho.Bardalai@us.fujitsu.com






Caviglia, et al.         Expires March 26, 2010                [Page 19]