Network
CCAMP Working Group
Internet Draft                                             Diego                                          D. Caviglia
                                                               (Ericsson)
                                                            Dino
Internet-Draft                                               D. Bramanti
                                                               (Ericsson)
                                                          Dan
Expires: January 16, 2009                                       Ericsson
                                                                   D. Li (Huawei)
                                                         Snigdho
                                           Huawei 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 enabled Enabled Transport Network

                     draft-ietf-ccamp-pc-spc-rsvpte-ext-00.txt
                                Network.

               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 2008

   This 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 [1].  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
   document subsequent roll back are to be interpreted as described in RFC2119 [1]. also illustrated
   taking into account that an handover failure must not impact the
   already established data plane connections.

Table of Contents

   1. Introduction...................................................3  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Motivation.....................................................3  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  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.1 Solution  . . . . . . . . .  3
   5.  MP to CP handover: LSP Ownership Transfer From Management
       Plane To Control Plane.............   ......................5
     4.2 Plane . . . . . . . . . . . . . . . . . . . .  5
     5.1.  MP to CP Handover Procedure Success  . . . . . . . . . . .  6
     5.2.  MP to CP Handover Procedure Failure Handling . . . . . . .  7
       5.2.1.  MP handover to 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.3 Plane  . . . . . . . . . . . . . . . . . . 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.1 Modification . . . . . . . . . . . . . . . . . . . . . 17
     10.1. Administrative Status Object..............................12
      8.2 Object . . . . . . . . . . . . . . . 17
     10.2. Error Spec Object.........................................13
   9. Security Considerations.......................................13
   10. IANA Consideration...........................................14 Object  . . . . . . . . . . . . . . . . . . . . 18
   11. References...................................................14 Acknoledgments . . . . . . . . . . . . . . . . . . . . . . . . 19
   12. Acknowledgments..............................................14 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
   13. Author's Addresses...........................................14 Security 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 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. 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 [3]. "draft-ietf-ccamp-pc-and-reqs-04.txt [1].  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 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. "draft-ietf-ccamp-pc-and-reqs-04.txt [1].

4.  Overview Of Proposed RSVP-TE Based Solution

        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
   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 Control Plane domain boundary.

   For conversion to SC PC 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 Management 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[4]
   [RFC3471] and RFC 3473 [5]). [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 plane 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 Data Plane state at each addressed node along the path

      draft-ietf-ccamp-pc-spc-rsvpte-ext-00 February 2008
   as usual - from the LSP ownership handover procedure that MUST leave
   untouched data plane Data Plane state.

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

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

   Following paragraphs give detailed description of proposed "MP to CP
   handover" and "CP to MP handover" procedure, based on Handover flag
   usage.  Handover of a bidirectional LSP is assumed.  The case of
   unidirectional LSP can be easily derived from that.

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

5.  MP to CP handover: LSP Ownership Transfer From Management Plane To
    Control Plane

   Let's consider the case of a Data Plane connection created by NMS.
   The Management Plane has the ownership and control of the LSP and
   wants to hand it over to Control Plane.  At the ingress node NMS
   initiates the transfer of LSP related information residing within
   Management Plane to RSVP-TE records within Control Plane.  We assume
   that this happens under operator or management application control
   and in particular that:

        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
   document.  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 .ignalling signalling entity to
   fill the Explicit Route Object (ERO) during setup.  In order to
   support the MP to CP handover of LSP, the ERO object in the Path
   message MUST be filled with all the LSP relevant information down to
   the Label level.  That can be done by means of the object and
   procedures defined in [5]. [RFC3473].

   The precise filling of the ERO object is needed as we are assuming
   that the LSP already exists in data plane Data Plane and that every .ignalling signalling
   relevant info about it is available and accessible to MP in terms of
   required LSP parameters to build a RSVP-TE PATH message.  After the
   collection of all the LSP related information, the ingress node
   issues
   starts the handover procedure issuing a RSVP-TE PATH message
   including the Administrative Status Object with both HANDOVER and
   REFLECT flags set.  The R flag set assures that also the Resv message
   will set the H flag.  Upon reception of such RSVP-TE PATH, a node
   MUST be able to understand that a MP to CP handover procedure is in
   progress by reading the Handover flag.

   Either the ingress node of the LSP (upon request from MP) and
   intermediate and egress nodes (when receiving a Path Path/Resv message
   containing an Administrative Status object with the Handover flag
   set) is are 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

   The following of the Path Message section 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:

   - If resource.  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 PATH the Path message (if the node is not
     ingress the
   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.

    - If

   After 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 is actual Data Plane state for migration of LSP information is
   complete, the
      indicated resource LSP is different from left completely under control of RSVP- TE within
   Control Plane.  This means that any memory about the one indicated in former 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 about LSP is lost.  If a Confirmation message was
   requested, then it is not accepted
        by the generated.  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 procedure 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 occurred Management Plane to Control Plane Procedure, two different
   failure scenarios can happen: Path Failure and no LSP control
   handover is possible but no operation MUST Resv Failure.
   Moreover, each failure can be performed at the due to two different causes: Data Plane that is the already present cross-connection MUST not
   failure or Communication Failure.  A section for each combination
   will be
   deleted. The procedure rolls back and information transfer process
   from analyzed 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 a Handover Failure - Path Failure

5.2.1.1.  MP to CP Handover Failure - Path Message and Data Plane
          Failure

   The handover procedure MUST can fail due to different causes, but in fact
   keep track of the special 'handover' condition of any
   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 to network status but be taken on immediately rollbacked to the LSP outside one
   previous to the control of handover procedure.  The failure can happen during
   the procedure itself. Such special
   state regarding Path message or the involved LSP has to be retained until Resv 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 for send a Resv Path Error message in the
   upstream direction including Administrative Status Object with an 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.

5.2.1.2.  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 about following pictures and
   consist on the former MP ownership unreachability of
   the LSP is lost.  If a Confirmation message was requested that it is
   generated.  The handover procedure does not modify the Confirmation
   procedure.

   In case node of failures during the processing of LSP.

   The below scenario postulates the Resv usage 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 with                   LSR B             Egress LER

   The Path State Removed flag and an error value
     indicating 'handover procedure failure' set should be message sent from LSR A towards
     Ingress node.  This case LSR B is similar to a failure during lost or does not
   reach the Path
     processing
   - destination for any reason.  A ResvErr message, with the indication (a special Flag) that an
     error occurred during reliable delivery mechanism
   is implemented, LSR A retransmits the Resv processing, towards Egress Node.
     Nodes processing this RescErr with special flag and Path Message for a configurable
   number of times, then, if no ack is received, a Path Error Value
     will delete the Control Plane information associated with message is
   sent back to the

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

   cross-connection ingress LER and move its ownership under the Management Plane
   domain.

   Let's consider a LSP over adoption procedure aborted.

   In the network, connecting an 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 node say
   I with an Egress node say E.  Let's call timeslot LER           LSR A and                   LSR B             Egress LER

   If the Data
   Plane resources referred Resv Message is not received by control information involved in Handover
   in the expiration of a given node traversed timer set
   by the LSP. This means that Handover
   flagged signaling refers to A-B cross-connection over Data Plane.
   The ingress node initiates LER, the adoption 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 again 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 that the two Timeslots
   involved in Data Plane cross-connection are actually cross-connected
   over Data Plane, hence Data Plane state corresponds to downstream direction with the indication
   provided by LSP data held by H
   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  |OK to CP Handover Failure - Resv Error

5.2.2.1.  MP to CP
         |           |               |                |LSP handover
         ----------------------------------------------------------------
   Case 2|  A<---->C |No info yet    |MP expects A-B  |NOT OK for MP Handover Failure - Resv Error and Data Plane failure

   In case a failure occurs during the Resv Message forwarding, things
   are quite different, because after the handover procedure an LSR is
   not able to distinguish an LSP created 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 on          Path         |
|---------------------->|---------------------->|---------------------->|
|                |locally                       |                       |                |configured policy
         |---------------------------------------------------------------

   Case 1:
   - LSP info from MP to be used for LSP control handover to RSVP-TE
     matches Data Plane state          Resv         |
|                       |          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
     control the 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 state sent in the upstream direction.

   Please note that the failure occurred after Handover flagged signaling
     flow (Path/Resv with Handover flag set) has ended.
   - At the end of signaling handover 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 in was 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 info also
   from MP to be used for LSP control handover to RSVP-TE
     doesn't match the Data Plane state in terms point of involved resources.

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

   - Control Plane does not own LSP data record yet; hence view.  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 up ownership back to MP.
   - Checks are NOT OK. A-B connection is not actually present over
     Data the Management
   Plane and indicated resources are used within other context
     (A is x-connected MUST NOT modify the Data Plane.

5.2.2.2.  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 associated quite similar to the
     cross connection after Handover flagged one previously seen
   about the Path message.
   - A PathErr with 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 State Removed flag set MUST be sent Upstream.
   - LSP ownership remains completely under MP control. Handover has
     failed.
   - No actions are taken message 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-TE opposite direction.  It
   might happen that the Resv message does not exist reach 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 Plane downstream direction
   towards the Egress LER and a Path Error message in terms the 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 record
   ownership is not owned yet to 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, hence Plane or
   a handover procedure took place.

   Upon receiving a Resv Error message, the downstream nodes would
   delete the LSP
     control also 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 up highly probable that the Path Error would fail too.  Due to MP
   - decision about this
   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.2 implemented.

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

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

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

7.  Discovery Phase

   The discovery process starts by at the orignating end-point transmitting end-point, which
   transmits a discovery request Notify message out a link as specified by on the
   cross-connection link identified
   to be part of the converted LSP in the
   originating node. to be converted.  The Notify message is
   forwarded hop-by-hop by tracing the cross-connect LSP information and identifying the
   next-hop.  The assumption being made here is that information
   regarding individual neighbors is already available.

   In case the destination address is not known the RSVP-TE session
   destination address MAY not be specified (i.e. set to 0.0.0.0) in the
   discovery request Notify message.

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

   In case of

   If any errors detected which prevent error prevents the discovery process to
   complete be successfully
   completed, the ERROR_SPEC ERROS_SPEC object in the response Notify message will
   be filled in with a failure code code, else it MUST be se set to the success
   code.  The discovery response message SHOULD be sent hop-by-hop back
   to the requestor.

   In case the destination address in the request message is 0.0.0.0
   then it MUST be filled in by the terminating entity in the response
   message SESSION object.

       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> ]
                                     <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 plane Data Plane at each node
   along the LSP path.

   Starting from the information available at ingress TNE 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 table/
   database in TNE the LER itself.  Following the similarity existing
   between the MP to CP handover procedure and the Restart Procedure,
   the Recovery Label Object MUST be used to carry the downstream label
   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])
   ([RFC3473]) and the Upstream Label Object (RFC 3473[5]), ([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 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 upstream/downstream labels by looking
   up the data plane 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. 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 Data 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.1

   The 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 [5]. [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 [2]
      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 for the transfer of local 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.2

10.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 and a new flag Flag and a new Error Code/Value Code(with different
   Error Values) into the Error_Spec Object that is Object, defined in RFC 2205 [6]. [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 values values:

         * 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
   plane
   Control Plane status associated with the LPS LSP 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: ibryskin@advaoptical.com

      Daniele Ceccarelli
      Ericsson
      Via A. Negrone 1/A
      Genova-Sestri Ponente, Italy
      Phone: +390106002515
      Email: daniele.ceccarelli@ericsson.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 [5].

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

10. [RFC3473].

14.  IANA Consideration Considerations

   IANA has been asked to manage the bit allocations for the
   Administrative Status object [5]. ([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

   [1]

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
   [2] Levels", BCP 14, RFC 2119, March 1997.

   [RFC4606]  Mannie, E, 'Generalized Multi-Protocol E. 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

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

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

   [5] L. Berger (Ed.) "Generalized Multi-Protocol 2003.

   [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

   [6] 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's Alarm Information",
              RFC 4783, December 2006.

URIs

   [1]  <http://tools.ietf.org/html/draft-ietf-ccamp-pc-and-sc-reqs-04>

   [2]  <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: +390106003738

   Email: diego.caviglia@ericsson.com

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

   Email: dino.bramanti@ericsson.com
   Dan Li
   Huawei Technologies Co., LTD.
   Shenzhen 518129
   Huawei Base, Bantian, Longgang,
   Shenzhen 518129 P.R.China Longgang
   Italy

   Email: danli@huawei.com
   Tel: +86-755-28972910 dan.li@huawei.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: ibryskin@advaoptical.com

    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
   "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-
   ipr@ietf.org.
   ietf-ipr@ietf.org.