Network Working Group
Internet Draft                                             Diego Caviglia
                                                            Dino Bramanti
                                                          Dan Li (Huawei)
                                                         Snigdho Bardalai
                                                       Shan Zhu (Fujitsu)
                                                             Igor Bryskin
                                                            (ADVA Optical

Intended Status: Updates RFC 3473
Expires: Septembers 2008                                   March 28, 2008

    RSVP-TE Signaling Extension For The Conversion Between Permanent
      Connections And Soft Permanent Connections In A GMPLS enabled
                            Transport Network


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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

Caviglia et al.         Expires - September 2008           [Page 1]

      draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008

   This Internet-Draft will expire on August 18, 2008.

   Copyright Notice

   Copyright (C) The IETF Trust (2008).


   In a transport network scenario, where Data Plane connections
   controlled either by GMPLS (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.
   This memo provides a minor extension to RSVP-TE 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",
   document are to be interpreted as described in RFC2119 [1].

Table of Contents

   1. Introduction...................................................3
   2. Motivation.....................................................3
   3. Overview Of Proposed RSVP-TE Based Solution...................3
   4. LSP Control Handover Procedure Between Management And Control
     4.1 MP to CP handover: LSP Ownership Transfer From Management
         Plane To Control Plane.............   ......................5
     4.2 CP to MP handover - LSP Ownership Transfer From Control Plane
         To     Management Plane.....................................9
     4.3 CP to MP Handover Procedure Failure Handling.......... ....10
     5. Discovery Phase.............................................10

   Caviglia et al.         Expires - September 2008           [Page 2]

          draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008

   6. Alternative Way Of Retrieving Information Needed For MP To CP
   7. RSVP Message Formats..........................................12
   8. Objects Modification..........................................12
      8.1 Administrative Status Object..............................12
      8.2 Error Spec Object.........................................13
   9. Security Considerations.......................................13
   10. IANA Consideration...........................................14
   11. References...................................................14
   12. Acknowledgments..............................................14
   13. Author's Addresses...........................................14

1.   Introduction

   In a typical, traditional transport network scenario, Data Plane
   connections between two endpoints are controlled basically 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 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 [2] supported by GMPLS but can be applied to any
   kind of LSPs.

2.   Motivation

   The main motivation behind this work is the definition of a simple
   and very low impacting procedure that satisfies the requirements
   defined in [3]. 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 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].

3.   Overview Of Proposed RSVP-TE Based Solution

Caviglia et al.         Expires - September 2008           [Page 3]

        draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008

   The 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-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-plane domain boundary.

   For conversion to SC or SPC the conversion phase will create an RSVP-
   TE session along the discovered or user-specified route and bind with
   the existing management-plane owned cross-connect resources and at
   the same time transfer the ownership to the control-plane. For
   conversion to PC the conversion phase will delete the existing RSVP-
   TE session without deleting the cross-connect resources and transfer
   the ownership to the management-plane.

   Proposed procedure relies on the utilization of a newly introduced
   flag, here named Handover flag, in the Administrative Status Object
   (RFC 3471[4] and RFC 3473 [5]).
   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, where such flow has to
   be flagged in order to discriminate it from normal, data plane
   affecting, LSP setup/release procedure. When a LSP owned by
   Management Plane (i.e. a PC) has to be handed over to Control Plane
   (i.e. converted into a SPC), a signaling set-up with HANDOVER flag
   set has to be sent from ingress node.

   For the opposite procedure (when a LSP owned and controlled by
   Control Plane has to be handed over to Management Plane, i.e. SPC to
   PC conversion - or back out procedure for previous case) a signaling
   tear-down with HANDOVER flag set has to be sent from ingress or
   egress node, following the same procedure of a normal tear-down, from
   which is recognizable again by reading flag value.

   So, basically the HANDOVER flag is introduced and exploited to tell
   apart a normal set-up (or tear-down) procedure - that has to trigger
   an action on data plane state at each addressed node along the path

Caviglia et al.         Expires - September 2008           [Page 4]

      draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008

   as usual - from the LSP ownership handover procedure that MUST leave
   untouched data plane state.

   This is in some way similar as an approach to the Restart Procedure,
   (Section 4.3 RFC 3473 [5]), in the sense that the status of the
   physical resources at Data Plane has to stay unmodified but the
   associated information allowing its control has to be transferred.
   The modification proposed in this document refers only to
   Administrative Status object, that is, the message flow is left
   unmodified for both set-up and deletion.  Moreover a new Error Value
   is defined to identify the failure of an Handover procedure.

   It is worth stressing that, when the LSP over data plane is adopted
   either by CP or MP, i.e. at the end of signaling with Handover flag
   set, normal CP procedures or MP procedures have to take their place
   as usual when needed.  This means that a LSP formerly owned by MP,
   signalled within CP with Handover flag set (i.e. handed over to CP)
   can be controlled by usual relevant Control Plane signaling flows
   (i.e. with Handover flag not set).  The same applies when considering
   the handover of a LSP from CP to MP when, at the end of procedure,
   the LSP belongs to Management Plane and can be fully controlled by
   NMS.  In other words, after the LSP handover procedures have taken
   place, the LSP is not different from the other LSP owned by handover
   destination entity and it has to be treated with usual rules for that

   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.1 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:

Caviglia et al.         Expires - September 2008           [Page 5]

        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 one possible (optional) way to collect it is explained in
   Section 5.
   A relevant part of such information is represented by the LSP path,
   which has to be handed over to CP to be used by .ignalling 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 [5].
   The precise filling of the ERO object is needed as we are assuming
   that the LSP already exists in data plane and that every .ignalling
   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
   issues 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 Path message
   containing an Administrative Status object with the Handover flag
   set) is 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 receipt of the Path Message the node SHOULD check
   the consistence of the actual Data Plane status of such resource:

   - If the check goes OK, 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 PATH (if the node is not
     ingress 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.

    - If the check goes NOT OK, that is actual Data Plane state for the
      indicated resource is different from the one indicated in the Path
      message, then:

Caviglia et al.         Expires - September 2008           [Page 6]

          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 about it is not accepted
        by 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 since the
   connection is already set up and in service. In case of negative
   check, a mismatch or some other error has occurred and no LSP control
   handover is possible but no operation MUST be performed at the Data
   Plane that is the already present cross-connection MUST not be
   deleted. The procedure rolls back and information transfer process
   from MP to CP at ingress node of the LSP has to be fixed and

   A node participating in a MP to CP handover procedure MUST in fact
   keep track of the special 'handover' condition of 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 to be taken on
   the LSP outside the control of the procedure itself. Such special
   state regarding the involved LSP has to be retained until the
   procedure itself has correctly ended.

   After propagating handover Path, a node MUST wait for a Resv message
   including Administrative Status Object with Handover flag set. After
   receiving it, the actual migration of LSP information is complete,
   the LSP is left completely under control of RSVP- TE within Control
   Plane.  This means that any memory about the former MP ownership of
   the LSP is lost.  If a Confirmation message was requested that it is
   generated.  The handover procedure does not modify the Confirmation

   In case of failures during the processing of the Resv message the
   node that generates the failure sends:

   - A PathErr with Path State Removed flag and an error value
     indicating 'handover procedure failure' set should be towards
     Ingress node.  This case is similar to a failure during the Path
   - A ResvErr message, with the indication (a special Flag) that an
     error occurred during the Resv processing, towards Egress Node.
     Nodes processing this RescErr with special flag and Error Value
     will delete the Control Plane information associated with the

Caviglia et al.         Expires - September 2008           [Page 7]

        draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008

   cross-connection and move its ownership under the Management Plane

   Let's consider a LSP over the network, connecting an Ingress node say
   I with an Egress node say E.  Let's call timeslot A and B the Data
   Plane resources referred by control information involved in Handover
   in a given node traversed by the LSP. This means that Handover
   flagged signaling refers to A-B cross-connection over Data Plane.
   The ingress node initiates the procedure upon request from Management
   Plane. The way LSP related information is passed from MP to ingress
   node is outside the scope of this procedure description.
   Intermediates nodes and egress node receive the request for LSP
   adoption and the information needed for the operation from Handover
   flagged RSVP-TE signaling.
   The symbol <----> in table below indicates that the two Timeslots
   involved in Data Plane cross-connection are actually cross-connected
   over Data Plane, hence Data Plane state corresponds to the indication
   provided by LSP data held by MP and in the process of being handed
   over to CP.

   Case 1|  A<---->B |No info yet    |MP expects A-B  |OK to MP to CP
         |           |               |                |LSP handover
   Case 2|  A<---->C |No info yet    |MP expects A-B  |NOT OK for MP to
         |           |               |                |CP LSP handover
   Case 3|  No state |No info yet    |MP expects A-B  |Depends on
         |                           |                |locally
         |                           |                |configured policy

   Case 1:
   - LSP info from MP to be used for LSP control handover to RSVP-TE
     matches Data Plane state in terms of involved resources
   - LSP data record is not owned yet by Control Plane, hence LSP
     control is still up to MP
   - Checks are OK, so RSVP-TE state (related to involved LSP) is
     associated to Data Plane state after Handover flagged signaling
     flow (Path/Resv with Handover flag set) has ended.
   - At the end of signaling the LSP is completely under CP control.
   - No actions are taken in the Data Plane.

   Case 2:
   - LSP info from MP to be used for LSP control handover to RSVP-TE
     doesn't match Data Plane state in terms of involved resources.

Caviglia et al.         Expires - September 2008           [Page 8]

      draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008

   - Control Plane does not own LSP data record yet; hence LSP control
     is still up to MP.
   - Checks are NOT OK. A-B connection is not actually present over
     Data Plane and indicated resources are used within other context
     (A is x-connected to C).
   - RSVP-TE state (related to involved LSP) is not associated to the
     cross connection after Handover flagged Path message.
   - A PathErr with Path State Removed flag set MUST be sent Upstream.
   - LSP ownership remains completely under MP control. Handover has
   - No actions are taken in the Data Plane.

   Case 3:
   - LSP info from MP to be used for LSP control handover to RSVP-TE
     does not exist in the Data Plane in terms of involved resources.
   - LSP data record is not owned yet by Control Plane, hence LSP
     control is still up to MP
   - decision about if the procedure is OK or KO is a local policy.

 4.2 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. 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
   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 [5].

   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

Caviglia et al.         Expires - September 2008           [Page 9]

       draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008

   state 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.3     CP to MP Handover Procedure Failure Handling

   Failures during CP to MP handover procedure MUST be managed at
   signaling level as in normal LSP tear down procedure. The only
   difference is the handover 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.   Discovery Phase

   The discovery process starts by the orignating end-point transmitting
   a discovery request Notify message out a link as specified by the
   cross-connection identified to be part of the converted LSP in the
   originating node. The Notify message is forwarded hop-by-hop by
   tracing the cross-connect 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 in the
   discovery request Notify message.

   Any node that decides to terminate the discovery process will not
   forward the Notify message and generate a discovery response Notify

   In case of any errors detected which prevent the discovery process to
   complete the ERROR_SPEC object in the response Notify message will be
   filled in with a failure code else it MUST be 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
   then it MUST be filled in by the terminating entity in the response
   message SESSION object.

Caviglia et al.         Expires - September 2008          [Page 10]

       draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008

   The format of the Notify Message is as follows:
               <Notify message>  ::= <Common Header> [ <INTEGRITY> ]
                            [[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...]
                                     [ <MESSAGE_ID> ]
                                     <discovery info>

               <discovery info> ::= <SESSION> <RSVP_HOP> <RECOVERY_LABEL>
                                      [ <ADMIN_STATUS> ]
                                      [ <POLICY DATA> ]
                                      [ <SESSION_ATTRIBUTES>]
                                      [ <UPSTREAM_LABEL> ]
                                      [ <RECORD_ROUTE> ]

6.   Alternative Way Of Retrieving Information Needed For MP To CP

   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 plane at each node along the LSP

   Starting from the information available at ingress TNE 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 TNE 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[5]) and the Upstream Label Object (RFC 3473[5]), 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

Caviglia et al.         Expires - September 2008          [Page 11]

      draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008

   message reaches the second node along the LSP path, the information
   about incoming interface ID and the upstream and downstream labels of
   this interface is extracted from it and it is used to find next hop
   outgoing interface ID and the upstream/ downstream labels by looking
   up the data 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. 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 plane down to
   the port level or label level at each intermediate node along the LSP

7.   RSVP Message Formats

   This memo does not introduce any modification in RSVP messages object

8.   Objects Modification

 8.1    Administrative Status Object

   This memo introduces a new flag into the Administrative Status
   The Admin_Status Object is defined in RFC 3473 [5].
   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|

        Handover signaling (H): 1 bit

Caviglia et al.         Expires - September 2008          [Page 12]

      draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008

   When set, indicates that a Handover procedure for the transfer of LSP
   ownership between Management and Control Planes is ongoing.

   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.2    Error Spec Object

   This memo introduces and a new flag and new Error Code/Value into
   Error_Spec Object that is defined in RFC 2205 [6].

            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        |

            Flags assigned values
                       0x01 = InPlace
                       0x02 = NotGuilty

            Proposed new value
                       (TBD) = HandOverFailure

   The new flag is 'handover procedure failurei' the actual value is (TBD
   by IANA).  When this flag is set the receiver must delete the control
   plane status associated with the LPS and move the ownership of the
   cross-connections to the Management Plane.

9.   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 [5].

Caviglia et al.         Expires - September 2008          [Page 13]

    draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008

10.    IANA Consideration

   IANA has been asked to manage the bit allocations for the
   Administrative Status object [5].
   This document requires the allocation of the Handover bit: the H-bit.
   IANA is requested to allocate a bit for this purpose.

11.    References

   [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997

   [2] Mannie, E, 'Generalized Multi-Protocol Label Switching (GMPLS)
       Extensions for Synchronous Optical Network (SONET) and Synchronous
       Digital Hierarchy (SDH) Control', RFC4606, August 2006

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

   [4] L. Berger (Ed.) "Generalized Multi-Protocol Label Switching
      (GMPLS) Signaling Functional Description", RFC 3471, January 2003

   [5] L. Berger (Ed.) "Generalized Multi-Protocol Label Switching
       (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering
       (RSVP-TE) Extensions", RFC 3473, January 2003

   [6] Braden, R., Zhang, 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 of this

13.    Author's Addresses

   Diego Caviglia
   Via A. Negrone 1/A

Caviglia et al.         Expires - September 2008          [Page 14]

      draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008

   Genova-Sestri Ponente, Italy
   Phone: +390106003738

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

   Dan Li
   Huawei Technologies Co., LTD.
   Huawei Base, Bantian, Longgang,
   Shenzhen 518129 P.R.China
   Tel: +86-755-28972910

   Snigdho Bardalai
   Fujitsu Network Communications Inc
   2801 Telecom Parkway,
   Richardson, Texas 75082
   Tel: +1-972-479-2951

   Shan Zhu
   Fujitsu Network Communications Inc.
   2801 Telecom Parkway,
   Richardson, Texas 75082
   Tel: +1-972-479-2041

   Igor Bryskin
   ADVA Optical Networking Inc
   7926 Jones Branch Drive
   Suite 615
   McLean, VA - 22102

Caviglia et al.         Expires - September 2008          [Page 15]

    draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008

   Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

   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

   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-

Caviglia et al.         Expires - September 2008          [Page 16]