CCAMP Working Group                                          D. Caviglia
Internet-Draft                                             D. Ceccarelli
Expires: May 1, 2009
Intended status: Standards Track                             D. Bramanti
Expires: January 28, 2010                                       Ericsson
                                                                   D. Li
                                                     Huawei Technologies Co., LTD.
                                                             S. Bardalai
                                                         Fujitsu Network Communications Inc
                                                        October 28, 2008
                                                           July 27, 2009

 RSVP-TE Signaling Extension For The Conversion Between Permanent
Connections And Soft Permanent Connections Management Plane To Control Plane LSP
             Handover In A GMPLS Enabled Transport Network.

               draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt
                 draft-ietf-ccamp-pc-spc-rsvpte-ext-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she

   This Internet-Draft is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 1, 2009. January 28, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   We would like to dedicate this work to our friend and colleague Dino
   Bramanti, who passed away at the early age of 38.  Dino has been
   involved in this work since its beginning.

   In a transport network scenario, where Data Plane connections
   controlled either by GMPLS Control Plane (Soft Permanent Connections
   - SPC) or by Management System (Permanent Connections - PC) may
   independently coexist, the ability of transforming an existing PC
   into a SPC and vice versa - without actually affecting Data Plane
   traffic being carried over it - is a requirement.  See draft
   "draft-ietf-ccamp-pc-and-reqs-04.txt [1]. requirement [RFC5493].

   This memo provides a minor extension to RSVP-TE [RFC2205], [RFC3471],
   [RFC3473], [RFC4872] signaling protocol, within GMPLS architecture,
   to enable such connection ownership transfer and describes the proposed
   defined procedures.  Failure conductions conditions and subsequent roll back are
   also illustrated defined taking into account that an handover failure must not MUST NOT
   impact the already established data plane connections.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   3.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   4.  Overview Of Proposed RSVP-TE Based Solution  Procedures . . . . . . . . .  3
   5. . . . . . . . . . . . . . . . . .  4
     4.1.  MP to CP handover: LSP Ownership Transfer From
           Management Plane To Control Plane  . . . . . . . . . . . . . . . . . . . .  5
     5.1.
     4.2.  MP to CP Handover Procedure Success  . . . . Failure Handling . . . . . . .  6
     5.2.
       4.2.1.  MP to CP Handover Procedure Failure Handling - Path Failure . . . . . . .  7
       5.2.1.  6
         4.2.1.1.  MP to CP Handover Failure - Path message and
                   Data Plane Failure . . . . . . .  7
       5.2.2. . . . . . . . . .  6
         4.2.1.2.  MP to CP Handover Failure - Resv Error Path message and
                   Communication failure  . . . . . . . .  8
   6.  CP to MP handover : LSP Ownership Transfer From Control
       Plane To Management Plane . . . . . .  7
       4.2.2.  MP to CP Handover Failure - Resv Error . . . . . . . .  8
         4.2.2.1.  MP to CP Handover Failure - Resv Error and
                   Data Plane failure . . . . 13
     6.1.  CP to MP Handover Procedure Success . . . . . . . . . . . 13
     6.2.  CP to .  8
         4.2.2.2.  MP to CP Handover Procedure Failure - Resv Error and
                   Communication failure  . . . . . . . . . . . 14
   7.  Discovery Phase . . .  9
         4.2.2.3.  MP to CP Handover Failure - Node Graceful
                   Restart  . . . . . . . . . . . . . . . . . . . . 14
   8.  Alternative Way Of Retrieving . 10
     4.3.  CP to MP handover : LSP Ownership Transfer From
           Control Plane To Management Plane  . . . . . . . . . . . . 13
     4.4.  CP to MP Handover Procedure Failure  . . . . . . . . . . . 13
   5.  Alternative Way Of Retrieving Information Needed For MP To
       CP Handover  . . . . . . . . . . . . . . . . . . . . . . . . . 15
   9. 14
   6.  RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 16
   10. 15
   7.  Objects Modification . . . . . . . . . . . . . . . . . . . . . 17
     10.1. 15
     7.1.  Administrative Status Object . . . . . . . . . . . . . . . 17
     10.2. 15
     7.2.  Error Spec Object  . . . . . . . . . . . . . . . . . . . . 18
   11. Acknoledgments 16
   8.  Compatibility  . . . . . . . . . . . . . . . . . . . . . . . . 19
   12. Contributors 16
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   10. Contributors . . 19
   13. Security Considerations . . . . . . . . . . . . . . . . . . . 20
   14. IANA . . . . 17
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   12. IANA Considerations  . . 20
   15. References . . . . . . . . . . . . . . . . . . . 17
   13. References . . . . . . . 20
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     15.2. Informational 18
     13.1. Normative References . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . 18
     13.2. Informational References . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 23 . . . . . . . 19

1.  Introduction

   In a typical traditional transport network scenario, Data Plane (DP)
   connections between two endpoints are controlled by means of a
   Network Management System (NMS) operating within Management Plane
   (MP).  NMS/MP is the owner of such transport connections, being
   responsible of their set up, tear down and maintenance.

   The adoption of a GMPLS Control Plane (CP) over networks that are
   already in service - controlled by NMS at Management Plane MP level - introduces the
   need for a procedure able to coordinate a control handover of a
   generic data plane connection from MP to CP.

   In addition, the control handover in the opposite direction, from CP
   to MP SHOULD be possible as well.  The procedures described in this
   memo can be applied to any kind of LSP and network architecture.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Motivation

   The main motivation behind this work is the definition of a simple
   and very low impacting procedure that satisfies the requirements
   defined in "draft-ietf-ccamp-pc-and-reqs-04.txt [1]. [RFC5493].  Such procedure is aimed at giving the
   transport network operators the chance to
   convert handover the ownership of
   existing LSP LSPs provisioned as PC by NMS from the MP to SPC the CP without
   disrupting user traffic flowing on it.  Conversion them.  Handover from PC MP to SPC CP
   (i.e. when existing Data Plane DP connection ownership and control is passed
   from MP to CP) has been proposed defined as mandatory requirement, while the
   opposite operation, SPC CP to SC conversion, MP handover, has been considered as a nice-to-have nice-
   to-have feature that can be seen as a back-out
   option. an emergency procedure to disable
   the CP and take the manual control of the LSP.  For more details on
   requirements and motivations please refer to "draft-ietf-ccamp-pc-and-reqs-04.txt [1]. [RFC5493].

4.  Overview Of Proposed RSVP-TE Based Solution

   The whole process comprises of the discovery and conversion phases.  Procedures

   The discovery phase being described modification defined in this document is an OPTIONAL
   procedure and not mandatory for the conversion phase refers only to proceed.  The
   discovery phase is typically initiated by
   Administrative Status object, that is, the operator and message flow is
   performed hop-by-hop in order to discover the route.  The route
   discovered SHOULD be consistent with the network topology.  For
   example, left
   unmodified for both LSP set-up and deletion.  Moreover a multi-layer network the hops discovered should be
   contained within the same layer.

   Prior to initiating the discovery process it new Error
   Value is assumed that the
   Control Plane domains have been established.  The operator at the
   originating node can optionally specify the terminating end-point at defined to identify the time failure of initiating the discovery request or it could be
   automatically discovered.  For example, at a network layer boundary Handover procedure.

   Following paragraphs give detailed description of defined "MP to CP
   handover" and "CP to MP handover" procedures, based on the discovery process can be terminated generating usage a response back
   newly define bit called H bit.

   MP to CP handover procedure foreseen two different methods for
   retrieving required information.  The primary one consists on
   receiving the full Explicit Route Object (ERO) from the originator.  Another possibility MP while the
   alternative one is described in Section 5.

   Please note that if the primary method is used the labels SHOULD be
   included in the ERO and for bidirectional LSPs both upstream and
   downstream labels SHOULD be included.  Per Section 5.1.1. of
   [RFC3473], the labels are indicated on an output basis.  As
   described, this means that the labels are used by the upstream node
   to terminate create the request at LABEL_SET object and, for bidirectional LSPs,
   UPSTREAM_LABEL object used in the outgoing Path message.

4.1.  MP to CP handover: LSP Ownership Transfer From Management Plane To
      Control Plane domain boundary.

   For conversion

   The MP to PC or SPC the conversion phase will CP handover procedure MUST create an RSVP-
   TE RSVP-TE session along
   the discovered or user-specified route and bind with path of the LSP to be moved from MP to CP, associating it to the
   existing Management Plane owned cross-connect cross-connected resources owned by the MP (e.g. lambdas,
   time slots and or reserved bandwidth)and bandwidth) and at the same time
   transfer the transferring
   their ownership to the Control Plane.  For conversion CP.

   A standard RSVP-TE signaling flow MUST be used to PC
   the conversion phase will delete the existing RSVP- TE session
   information without deleting the cross-connect resources and transfer inform nodes about
   the ownership to the Management Plane.

   Proposed procedure relies on the utilization of handover request.  Such flow MUST be tagged with a
   newly introduced flag, here named Handover flag, H bit and described in Section 7.1,
   that is set in the Administrative Status Object
   [RFC3471] ([RFC3471] and [RFC3473].  The point is that standard
   [RFC3473]) of RSVP-TE
   signaling flow can messages.  The H bit MUST be used set in order to inform nodes about
   discriminate the ownership handover request regarding one procedure from normal, DP affecting, LSP that is already in place on their
   Data Plane, where such flow has to be flagged in order to
   discriminate it from normal, Data Plane affecting, LSP setup/release
   procedure.  When a LSP owned by Management Plane (i.e. a PC) has to
   be handed over to Control Plane (i.e. converted into a SPC), a
   signaling set-up with HANDOVER flag set has to be sent from ingress
   node.

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

   So, basically the HANDOVER flag is introduced and exploited to tell
   apart a normal set-up (or tear-down) procedure - that has to trigger
   an action on Data Plane state at each addressed node along the path
   as usual - from the LSP ownership handover procedure that MUST leave
   untouched Data Plane state.

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

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

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

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

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

      - Control requests are sent to the ingress LSR by the MP
      - The MP has some way of knowing when the CP has completed its
      task or has failed.

   Ingress node collects from MP all the LSP related information needed
   at Control Plane level.  The way this operation is done and where
   such information is collected within MP is outside the scope of this
   document.  One possible (optional) way to collect it is explained in
   Section 8.

   A relevant part of such information is represented by the LSP path,
   which has to be handed over to CP to be used by signalling entity to
   fill the Explicit Route Object (ERO) during setup.  In order to
   support the MP to CP handover of LSP, the ERO object in the Path
   message MUST be filled with all the LSP relevant information down to
   the Label level.  That can be done by means of the object and
   procedures defined in [RFC3473].

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

   Either
   setup/release procedure.  The DP MUST NOT be affected from the
   handover procedure.

   The ingress node of MUST send a Path message in the LSP (upon request from MP) and
   intermediate downstream direction
   with the H and egress nodes (when R ([RFC3471]) bit set.  Upon receiving a Path/Resv message Path Message
   containing an Administrative Status object Object with the Handover flag
   set) are informed about the fact that a LSP handover procedure is
   requested or ongoing.  The H bit set, each
   node assumes that MUST check if there is a Data Plane resource
   related to the info carried in local Path Message is already allocated and
   in place.

   The following of the section illustrates in detail State matching the procedure in
   cases in success and failures.

5.1. MP to CP
   Handover Procedure Success

   Upon receiving a request.  If no local Path Message, each node SHOULD check State exists, the consistence
   of node MUST
   confirm that there is an existing DP state that corresponds to the actual Data Plane status of
   Path message.  In case such resource.  Say the check goes
   OK DP state exists (failure cases are illustrated
   defined in the next sections), then local Path state MUST be installed.
   The H bit MUST be stored in the local Path state.

   After propagating a
   RSVP-TE record for Path message with the LSP is created associating it to H bit set, a node MUST wait
   for a Resv message including Administrative Status Object with H bit
   set.  After the
   corresponding Data Plane state.  The ingress node accepts all receives it, the actual migration of LSP
   information carried in is complete, the Path message (if LSP is left completely under control of
   RSVP-TE within Control Plane.

   If the node Resv message is not received by the
   Ingress LER expiration of a timer
   (called Expiration timer in the LSP, otherwise following) set by the information ingress LER,
   the handover procedure is aborted, that is, a PathTear message MUST
   be sent from
   relevant MP entity) and stores it in Path State Block.  After that, the procedure goes on as described below.

   After propagating handover Path message, a downstream direction.

   In order to complete the Handover process the ingress node MUST wait for send
   a Resv Path message including Administrative Status Object with Handover flag
   set.  After receiving it, the actual migration H bit cleared (set to zero) upon receipt of LSP information is
   complete, a
   corresponding Resv message.  The R bit SHOULD NOT be set in this
   message.  Downstream nodes MUST clear their local "Handover" state
   based on a received Path message with the LSP is left completely under control of RSVP- TE within
   Control Plane. H bit cleared.  This means
   that once a downstream node processes a Path message with the cleared
   H bit, any memory about state related to the former MP ownership of the LSP is
   lost.  If a Confirmation message was
   requested, then it is generated.  Normal ResvConf process occurs as normal.  The handover
   procedure does not modify the Confirmation procedure.

5.2.

   In case the path of the LSP is not fully passed to the ingress LER,
   each node can determine the next hop looking at its data plane and
   exploit the similarity between the MP to CP Handover procedure and
   the Restart Procedure.  Please refer to Section 5.

4.2.  MP to CP Handover Procedure Failure Handling

   In case of Management Plane MP to Control Plane CP Procedure, two different failure scenarios can
   happen: Path Failure and Resv Failure.  Moreover, each failure can be
   due to two different causes: Data Plane DP failure or Communication Failure.  In
   any case the LSP ownership MUST be immediately roll backed to the one
   previous to the handover procedure.  A section for each combination
   will be analyzed in the following.

5.2.1.

4.2.1.  MP to CP Handover Failure - Path Failure

5.2.1.1.

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

   The handover procedure can fail due to different causes, but in any
   case the network status MUST be immediately rollbacked to the one
   previous to the handover procedure.  The failure can happen during
   the Path message or the Resv message forwarding.

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

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

                      MP2CP - Path Msg and DP Failure

   If an error occurs in an LSR or a LER, the last node that has
   received the Path message MUST send a Path Error PathErr message in the upstream
   direction including an Error_Spec object and the Handover
   flag set. handover procedure is aborted.  The Path Error PathErr message
   SHOULD have the Path_State_Removed
   flag set and Path_State_Removed flag set.

   Nodes receiving a PathErr message MUST follow standard PathErr
   message processing with the exception that when their local state
   indicates that a Handover is in progress (based on the H bit in the upstream nodes MAY process
   Path message) the Error_Spec object.

5.2.1.2. associated DP resources MUST NOT be impacted during
   such processing.

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

   Other possible scenarios are shown in the following pictures and
   consist on the unreachability of inability to reach a node along the path of the LSP.

   The below scenario postulates the usage of a reliable message
   delivery based on the mechanism defined in [RFC2961].

     |      Path      |                |                |
   |---------------------->|
     |--------------->|      Path      |                |
     |                       |------------X          |                |---------------X|                |
     |                       |------------X          |                |---------------X|                |
     |                |      ...       |                |
     |                       |------------X          |                       |
   |                       |                       |                       |
   |       Path Err        |                       |                       |
   |<----------------------|                       |                |---------------X|                |
     |                |                |                |
   Ingress LER      LSR A            LSR B       Egress LER

      MP2CP - Path Msg and Communication Failure (reliable delivery)

   The Path message sent from LSR A towards LSR B is lost or does not
   reach the destination for any reason.  A  As a reliable delivery
   mechanism is implemented, LSR A retransmits the Path Message message for a
   configurable number of times, then, times and if no ack is received, a Path Error message
   MUST be sent back to the ingress LER, received the Path_State_Removed flag
   SHOULD handover
   procedure will be set and aborted (via the adoption procedure is aborted. Expiration timer).

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

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

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

   If the Resv Message message is not received by the expiration of a timer set
   by the ingress LER,
   Expiration timer the adoption handover procedure is again aborted and a
   PathTear message MAY be sent as described in the downstream direction with the H
   bit set.

5.2.2.
   Section 4.1.

4.2.2.  MP to CP Handover Failure - Resv Error

5.2.2.1.

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

   In case a failure occurs during the Resv Message forwarding, things
   are quite different, because after the handover procedure an LSR is
   not able to distinguish an LSP created by message processing, the Control Plane from an
   LSP created by node
   MUST send a PathErr message in the Management Plane upstream direction.  The PathErr
   message is constructed and then moved to the Control
   Plane. processed as defined above in
   Section 4.2.1.1.  The failure detection node MUST also send a
   PathTear message downstream.  The PathTear message is constructed and
   processed as defined above in Section 4.2.1.1.

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

                     MP2CP - Resv Error and DP Failure
   In the case shown in the above picture, the failure occurs in LSR A.
   Considering to have a reliable message delivery mechanism, a Path
   Tear
   A PathTear message MUST be is sent in the downstream direction towards B and a Path
   Error PathErr message MUST is sent in
   the upstream direction and the
   Path_State_Removed SHOULD flag should be set. direction.  The Path Err PathErr and Path
   Tear PathTear messages remove the
   Path state established by the Path messages along the nodes of the
   LSP and abort the adoption handover procedure.

   Please note that the failure occurred after the handover procedure
   was successfully completed in LSR B. This means that LSR B is no
   longer able to know if the LSP was created by the Control Plane or a
   handover procedure took place.

   Upon receiving B, but Handover state will still be
   maintained locally as, per Section 4.1, a Path Tear message, LSR B would delete the LSP also
   from the Data Plane point of view.  To prevent this from happening,
   LSR A MUST set the handover flag in the Path Tear message.  The
   downstream node move the LSP ownership back to the Management Plane
   and MUST NOT modify message with the Data Plane.

5.2.2.2. H bit
   clear will have not yet been sent or received.

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

   In case a Resv Message message cannot reach one or more of the downstream upstream
   nodes, the procedure is quite similar to the one previously seen
   about the Path Message. message.  Even in this case it is possible to
   distinguish two different scenarios.

   In the first scenario we consider the utilization of a reliable
   message delivery based on the mechanism defined in [RFC2961].  After
   a correct forwarding of the Path message along the nodes of the LSP,
   the Egress LSR sends a Resv message in the opposite direction.  It
   might happen that the Resv message does not reach the ingress LER or
   an LSR, say LSR A. LSR B, after sending the B MUST send a Resv message again for a
   configurable number of times, MUST send a Path Tear message in the downstream direction
   towards the Egress LER times and a Path Error message (with the
   Path_State_Removed flag set) in the upstream direction towards the
   Ingress LER in order to inform the nodes of then, if the path that delivery does not
   succeed, the adoption procedure has failed and that the LSP ownership is to will be
   moved back to aborted (via the management plane. Expiration
   timer).

     |      Path      |      Path      |      Path      |
|---------------------->|---------------------->|---------------------->|
     |--------------->|--------------->|--------------->|
     |                |                |      Resv      |
     |                |      Resv         |<----------------------|      |<---------------|
     |                |           X-----------|      X---------|                |
     |                |           X-----------|      X---------|                |
     |                |      ...       |                |
     |                       |           X-----------|                       |
|                       |                       |                       |
|       Path Err        |       Path Err        |       Path Tear       |
|<----------------------|<----------------------|---------------------->|
|                       |                       |                       |
Ingress LER           LSR A                   LSR B             Egress LER

   Please note that the failure occurred after the handover procedure
   was successfully completed in the Egress LER.  This means that it is
   no longer able to know if the LSP was created by the Control Plane or
   a handover procedure took place.

   Upon receiving a Path Tear message, the downstream nodes would delete
   the LSP also from the Data Plane point of view.  To prevent this from
   happening, the Path Tear message MUST include the Handover flag.                |      X---------|                |
     |                |                |                |
   Ingress LER      LSR A            LSR B       Egress LER

     MP2CP - Resv Error and Communication Failure (reliable delivery)

   Considering that the Resv message did not manage to reach LSR A, it
   is highly probable that the Path Error PathErr would fail too.  Due to this
   fact, a configurable the Expiration timer MUST be set is used on the Ingress LER after sending
   the path and on LSR A after forwanding forwarding it.  When the timer expires,
   if no Resv or Path Error PathErr message is received, the handover procedure MUST be is
   aborted as described in Section 4.1 and the LSP ownership returned to
   the Management Plane.

   The following picture, on the other hand, shows the scenario in which
   no reliable delivery mechanism is implemented.

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

   After sending the path message, the ingress LER sets a timer.

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

   If non Resv message is received before the Expiration timer expires, then the adoption
   procedure is aborted and
   the Ingress ingress LER MAY signal it by a Path Tear
   message with follows the H bit set.

5.2.2.3. same procedure defined in Section 4.1.

4.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 MUST abort the conversion handover process by generating a
   PathTear message downstream.  Also, if LSR A does not complete the
   restart process within the restart time interval then LSR B will MUST
   start tearing down all LSPs between LSR A and LSR B and this includes
   the LSP that is being used to carry out the conversion handover of MP resources
   to CP.  LSP B will MUST generate a PathTear message downstream and a
   PathErr message upstream.  Both LSR B and the egress LER will
   not MUST NOT
   release the data-plane DP resources because in both nodes the H-bit H bit is set in
   the PSB. local Path state.

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

                  MP2CP - Node graceful restart - Case I

   Case II

   Restart timer is infinite.  The sequence is quite similar to the
   previous one.  In this sequence the restart timer will not expire in
   LSR B since it is run infinitely.  Instead after LSR A restarts LSR B
   will
   MUST start the recovery timer.  The recovery timer will expire since
   there will be no Path message with the RECOVERY LABEL received from
   LSR A given the ingress node had already removed the PSB local Path state
   after it aborts the conversion handover process.  Thus LSR B will MUST tear-down the
   specific LSP that is being used to convert the MP resources to CP by
   generating a PathTear message downstream and PathErr message
   upstream.  Similarily  Similarly to the previous case both LSR B and the egress
   LER will not MUST NOT release the
   data-plane DP resources because the H-bit H bit is set in the PSB.
   local Path state.

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

                  MP2CP - Node graceful restart - Case II

   Case III

   Ingress LER did not abort the conversion handover process.  Once LSR A restarts
   the ingress LER will MUST re-generate the Path message with the
   H-bit H bit set.
   When LSR B receives the Path message it may MAY generate a PathErr since
   the RECOVERY LABEL may not be present.  The reason is LSR A may not
   have the label.  Similarily  Similarly LSR B and egress LER will
   not MUST NOT release the data-plane
   DP resources since the H-bit H bit is set.

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

6.

                 MP2CP - Node graceful restart - Case III

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

   Let's now consider the case of LSP Ownership Transfer From Control
   Plane To Management Plane.  Also in this sections we will analyze the
   handover procedure success and failure.

6.1.  CP to MP Handover Procedure Success

   The scenario is still a Data Plane DP connection between two nodes acting as
   ingress and egress for a LSP.  But let's assume LSP, but in this case that Control Plane the CP has the
   ownership and control of the LSP and
   that we want to hand it over to Management Plane.  This means that at
   the end of such procedure, the Data Plane state related LSP.  The CP to that
   connection is still untouched, but MP handover procedure
   MUST delete the LSP related information record
   is no more owned by existing RSVP-TE over Control Plane. session information and MUST NOT
   affect the cross-connected resources, but just move their ownership
   to the MP.

   In other words, after LSP ownership transfer from CP to MP, the LSP
   is no more longer under control of RSVP-TE, which is no more able to "see"
   the LSP itself.  This Section covers the procedure needed  The CP to manage
   this MP handover procedure as MUST be a dual, opposite procedure respect to the one
   described in previous section.  The standard
   LSP deletion procedure is performed at a
   signaling level as described in Section 7.2.1 of [RFC3473].

   At LSP ingress node, relevant MP entity requests the ownership of the
   LSP, How this is done
   The procedure is outside initiated at the scope ingress node of memo. the LSP by a MP
   entity.  Ingress node and MP exchange the relevant information for
   this task and then
   propagates propagate it over Control Plane CP by means of RSVP-TE tear down
   signaling flow as detailed described below.

   Ingress

   The ingress node MUST send out a Path message, message in the downstream direction
   with Handover and Reflect bits set in the Admin Status set. Object.  No
   action is taken over Data Plane the DP and
   Control Plane keeps track transit LSRs must forward such
   message towards the egress node.  All of special handover state the LSP is in.
   Transit and Egress nodes, upon reception nodes MUST keep track of such handover Path,
   propagate it without any Data Plane action, retaining
   the handover
   state information associated to procedure storing the LSP.  After that, H and R bits in their local Path and Resv
   states.  Then every node waits until for the Handover H bit to be received within
   the related Resv message.  After the Resv message is received back in by the Resv.  Then
   ingress LER, it MUST send a PathTear is issued and message in order to clear the
   whole LSP information record is cleared
   from RSVP- TE recorded on the RSVP-TE data structures of the
   nodes.  Downstream nodes processing a PathTear message which follows
   a Path message with the H bit set, MUST NOT remove any associated
   data structures. plane state.  In other words, a normal LSP tear down signaling
   is exchanged between nodes traversed by the LSP, but
   handover flag set in Path message indicates that no Data Plane action
   has to correspond to Control Plane signaling.  At the end of handover
   tear down signaling flow, the LSP is released from Control Plane
   point of view, but its Data Plane state is still unmodified and it is
   now owned and controllable by MP.

6.2. the LSP, but H bit set in the
   Path message indicates that no DP action has to correspond to CP
   signaling.

4.4.  CP to MP Handover Procedure Failure

   Failures during CP to MP handover procedure MUST be managed at
   signaling level as in normal LSP tear down procedure.  The only
   difference is the handover flag H bit set in Administrative Status Object inside
   Path message which MUST be read by receiving node and imposes that no
   action has to be made over Data Plane DP resource whose corresponding Control
   Plane record is involved in handover procedure.

7.  Discovery Phase

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

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

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

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

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

   The format of the Notify Message is as follows:

   <Notify message>  ::= <Common Header> [ <INTEGRITY> ]
                            [[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...]
                                     [ <MESSAGE_ID> ]
                                     <ERROR_SPEC>
                                     <discovery info>

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

   The RECORD_ROUTE object in the discovery response SHOULD be put
   together such that it can be directly used in a Path message for the
   coversion phase.  For example, explitcit label sub-objects can be
   specified only for outgoing links in the Path message [RFC3473].

8.

5.  Alternative Way Of Retrieving Information Needed For MP To CP
    Handover

   An alternative way of getting the LSP related information required
   for the MP to CP handover is also proposed defined in this draft.  The
   rationale behind this way is that only a minimal set of information
   is handed over from MP to CP at LSPs Ingress node.  Instead of
   collecting within MP all the LSP relevant information down to the
   Label level, formatting it to an ERO and passing it to CP, as in
   previously described solution, it is possible to start with a minimum
   amount of information.  At the ingress node, the information needed
   to specify the LSP is the outgoing interface ID, upstream label and
   downstream label of this interface and the incoming interface ID of egress node. node ID.  The
   remaining information about an existing LSP can then be collected hop
   by hop, as the signalling is going on, by looking up the cross-connection cross-
   connection table in Data Plane DP at each node along the LSP path.

   Starting from the information available at ingress LER about the
   outgoing interface ID of that ingress node, the incoming interface ID
   of next hop can be found by looking up the link resource table/
   database in the LER itself.  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 that ingress node, the Upstream Label Object MUST incoming interface ID
   of next hop can be used to carry found by looking up the upstream
   label to link resource table/
   database in the next node. LER itself.

   The Path message is hence built with the Recovery Label LABEL_SET Object ([RFC3473])
   and the Upstream Label UPSTREAM_LABEL Object ([RFC3473]), where the upstream label
   and downstream label of ingress outgoing interface of the LSP are
   included in these two objects.  In addition to above mentioned
   objects, the Path message MUST include the Administrative Status
   Object with HANDOVER flag H bit set, as already defined in previous
   chapter chapters for
   the detailed ERO based way of proceeding.  Such handover Path is sent
   to the incoming interface of next hop.  When this Path message
   reaches the second node along the LSP path, the information about
   incoming interface ID and the upstream and downstream labels of this
   interface is extracted from it and it is used to find next hop
   outgoing interface ID and the upstream/downstream labels by looking
   up the Data Plane DP cross-connection table.

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

   Re-iterating

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

9.

   Where the DP path continues beyond the egress, by indicating the
   Egress label at the head-end of an LSP, the traffic can be directed
   to the right destination.  The GMPLS Signaling Procedure for Egress
   Control is described in [RFC4003]

6.  RSVP Message Formats

   This memo does not introduce any modification in RSVP messages object
   composition.

10.

7.  Objects Modification

   The modifications required concern two RSVP Objects: the
   Administrative Status and the Error Spec Object.

10.1.

7.1.  Administrative Status Object

   This memo introduces a new flag into the Administrative Status
   object.  The Admin_Status Object is defined in [RFC3473].  This
   document uses the H-bit 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 (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. [RFC3471]

   - Testing (T): 1 bit - Defined in [RFC3471]
      When set, indicates that the local actions related to the
      "testing" mode should be taken.

   - Administratively down (A): 1 bit - Defined in [RFC3471]
      When set, indicates that the local actions related to the
      "administratively down" state should be taken. [RFC4974]

   - Deletion in progress (D): 1 bit - Defined in [RFC3471]
      When set, indicates that that the local actions related to LSP
      teardown should be taken.

   The H bit must be used in conjunction with the R flag when is set in
   the Path message.  This will assures that the Resv message will
   maintain the H flag set.

10.2.

7.2.  Error Spec Object

   It is possible that a failure, such as the lost loss of DCN connection or
   the restart of a node, occurs during the LSP ownership handing over.
   In this case the LSP adoption MUST be handover is 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 does not affect the Data
   Plane. DP.  The LSP MUST be is kept in place
   and no traffic hit MUST occur. occurs.

   The failure is signaled by Path Error PathErr in the upstream direction and
   Path Tear
   PathTear Messages in the downstream direction.  The Path Error PathErr messages
   include an Error_Spec_Object (the Path_State_Removed flag
   SHOUL always be set) specifying the causes of the failure, while the
   Path Tear messages, required in case of reliable recovery and
   optional otherwise, include the handover flag to prevent the deletion
   of the LSP from the Data Plane. the failure.

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

      * ERROR_SPEC class = 6.
      * IPv4 ERROR_SPEC object: Class = 6, C-Type = 1

           +-------------+-------------+-------------+-------------+
           |            IPv4 Error Node Address (4 bytes)          |
           +-------------+-------------+-------------+-------------+
           |    Flags    |  Error Code |        Error Value        |
           +-------------+-------------+-------------+-------------+

   The fields of the object 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:

         * 0x01 = InPlace

         * 0x02 = NotGuilty
      Proposed new value (TBD) = HandOverFailure

   The new flag is "Handover Procedure Failure" and the actual value is
   (TBD by IANA).  When this flag is set during an handover from
   Management Plane to Control Plane, the receiver must delete the
   Control Plane status associated with the LSP and move the ownership
   of the cross-connections back to the Management Plane.

   The 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

      3 = Other failure

8.  Compatibility

   The main requirement for Handover procedure to work is that all nodes
   along the path MUST support the extension defined in this draft.  In
   case a node does not support the Handover procedure, the upstream
   node along the path MUST send a PathErr message in the upstream
   direction including an Error_Spec_Object specifying the causes of the
   failure.

9.  Acknowledgments

   We wish to thank Adrian Farrel and Lou Berger for his editorial their assistance
   and precious advices to prepare this draft for publication.  We also
   wish to thank Nicola Ciulli, that contributed to initial stage of
   this draft.

12.

10.  Contributors

      Shan Zhu
      Fujitsu Network Communications Inc.
      2801 Telecom Parkway,
      Richardson, Texas 75082
      USA
      Email: Shan.Zhu@us.fujitsu.com
      Tel: +1-972-479-2041

      Igor Bryskin
      ADVA Optical Networking Inc
      7926 Jones Branch Drive
      Suite 615
      McLean, VA - 22102
      Email: ibryskin@advaoptical.com

13.

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

11.  Security Considerations

   The procedures described in this document rely completely on RSVP-TE
   messages and mechanism.  The use of Handover Flag H bit set in Admin Status Object
   basically informs the receiving entity that no operations are to be
   done over Data Plane DP as consequence of such special signaling flow.  Using
   specially flagged signaling messages we want to limit the function of
   setup and tear down messages to Control Plane, CP, making them not effective over
   related Data Plane DP resource usage.  So, no additional or special issues are
   arisen by adopting this procedure, that aren't already brought up by
   the use of the same messages, without handover flag H bit setting, for LSP control.
   For RSVP-TE Security please refer to [RFC3473].

14.

12.  IANA Considerations

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

15.

13.  References

15.1.

13.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", S. Molendini, "RSVP Refresh Overhead Reduction
              Extensions", RFC 2961, April 2001.

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

   [RFC4003]  Berger, L., "GMPLS Signaling Procedure for Egress
              Control", RFC 4003, February 2005.

   [RFC4974]  Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS)
              RSVP-TE Signaling Extensions in Support of Calls",
              RFC 2961, April 2001.

15.2. 4974, August 2007.

13.2.  Informational References

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

   [RFC4606]  Mannie, E. and D. Papadimitriou, "Generalized Multi-
              Protocol Label Switching (GMPLS) Extensions for
              Synchronous Optical Network (SONET) and Synchronous
              Digital Hierarchy (SDH) Control", RFC 4606, August 2006.

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

   [RFC4783]  Berger, L., "GMPLS - Communication of Alarm Information",
              RFC 4783, December 2006.

   [RFC4872]  Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
              Extensions in Support of End-to-End Generalized Multi-
              Protocol Label Switching (GMPLS) Recovery", RFC 4872,
              May 2007.

   [RFC4783]  Berger, L., "GMPLS - Communication of Alarm Information",

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

URIs

   [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> 5493,
              April 2009.

Authors' Addresses

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

   Email: diego.caviglia@ericsson.com

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

   Email: daniele.ceccarelli@ericsson.com

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

   Email: dino.bramanti@ericsson.com

   Dan Li
   Huawei Technologies Co., LTD.
   F3-5-B R&D Center, Huawei Base
   Shenzhen 518129
   Huawei Base, Bantian, Longgang
   Italy
   P.R.China

   Email: dan.li@huawei.com danli@huawei.com
   Snigdho Bardalai
   Fujitsu Network Communications Inc
   2801 Telecom Parkway
   Richrdson, Texas 75082
   USA

   Email: Snigdho.Bardalai@us.fujitsu.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

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

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.