GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5852

Internet Engineering Task Force (IETF) D. Caviglia Request for Comments: 5852 D. Ceccarelli Category: Standards Track D. Bramanti ISSN: 2070-1721 Ericsson

                                                                 D. Li
                                                   Huawei Technologies
                                                           S. Bardalai
                                                       Fujitsu Network
                                                            April 2010

RSVP-TE Signaling Extension for LSP Handover from the Management Plane

     to the Control Plane in a GMPLS-Enabled Transport Network

Abstract

 In a transport network scenario, Data Plane connections controlled by
 either a Generalized Multiprotocol Label Switching (GMPLS) Control
 Plane (Soft Permanent Connections - SPC) or a Management System
 (Permanent Connections - PC) may independently coexist.  The ability
 of transforming an existing PC into an SPC and vice versa -- without
 actually affecting Data Plane traffic being carried over it -- is a
 requirement.  The requirements for the conversion between permanent
 connections and switched connections in a GMPLS Network are defined
 in RFC 5493.
 This memo describes an extension to GMPLS Resource Reservation
 Protocol - Traffic Engineering (RSVP-TE) signaling that enables the
 transfer of connection ownership between the Management and the
 Control Planes.  Such a transfer is referred to as a Handover.  This
 document defines all Handover-related procedures.  This includes the
 handling of failure conditions and subsequent reversion to original
 state.  A basic premise of the extension is that the Handover
 procedures must never impact an already established Data Plane
 connection.

Caviglia, et al. Standards Track [Page 1] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5852.

Copyright Notice

 Copyright (c) 2010 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
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Caviglia, et al. Standards Track [Page 2] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

Table of Contents

 1. Introduction ....................................................4
    1.1. Dedication .................................................4
 2. Terminology .....................................................4
 3. Motivation ......................................................4
 4. Procedures ......................................................5
    4.1. MP-to-CP Handover: LSP Ownership Transfer from
         Management Plane to Control Plane ..........................6
    4.2. MP-to-CP Handover Procedure Failure Handling ...............7
         4.2.1. MP-to-CP Handover Failure - Path Failure ............8
                4.2.1.1. MP-to-CP Handover Failure - Path
                         Message and Data Plane Failure .............8
                4.2.1.2. MP-to-CP Handover Failure - Path
                         Message and Communication Failure ..........8
         4.2.2. MP-to-CP Handover Failure - Resv Error ..............9
                4.2.2.1. MP-to-CP Handover Failure - Resv
                         Error and Data Plane Failure ...............9
                4.2.2.2. MP-to-CP Handover Failure - Resv
                         Error and Communication Failure ...........10
                4.2.2.3. MP-to-CP Handover Failure - Node
                         Graceful Restart ..........................12
    4.3. CP-to-MP Handover: LSP Ownership Transfer from
         Control Plane to Management Plane .........................15
    4.4. CP-to-MP Handover Procedure Failure .......................16
 5. Minimum Information for MP-to-CP Handover ......................17
 6. RSVP Message Formats ...........................................19
 7. Objects Modification ...........................................19
    7.1. Administrative Status Object ..............................19
    7.2. Error Spec Object .........................................19
 8. Compatibility ..................................................20
 9. Security Considerations ........................................20
 10. IANA Considerations ...........................................20
 11. Acknowledgments ...............................................21
 12. Contributors ..................................................21
 13. References ....................................................21
    13.1. Normative References .....................................21
    13.2. Informative References ...................................22

Caviglia, et al. Standards Track [Page 3] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

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 the Management Plane
 (MP).  NMS/MP is the owner of such transport connections, being
 responsible for their setup, teardown, and maintenance.
 The adoption of a Generalized MPLS (GMPLS) [RFC3945] Control Plane
 (CP) in a network that is already in service -- controlled by the NMS
 at the MP level -- introduces the need for a procedure able to
 coordinate a controlled Handover of a Data Plane connection from the
 MP to the 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 a Label Switched Path (LSP) in any DP
 switching technology and any network architecture.
 This memo describes an extension to GMPLS Resource reSerVation
 Protocol - Traffic Engineering (RSVP-TE) [RFC3471] [RFC3473]
 signaling that enables the Handover of connection ownership between
 the Management and the Control Planes.  All Handover-related
 procedures are defined below.  This includes the handling of failure
 conditions and subsequent reversion to original state.  A basic
 premise of the extension is that the Handover procedures must never
 impact the exchange of user data on LSPs that are already established
 in the DP.

1.1. Dedication

 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.

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-impact procedure that satisfies the requirements defined
 in [RFC5493].  Such a procedure is aimed at giving the transport
 network operators the chance to hand over the ownership of existing
 LSPs provisioned by NMS from the MP to the CP without disrupting user

Caviglia, et al. Standards Track [Page 4] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

 traffic flowing on them.  Handover from the MP to the CP (i.e., when
 existing DP connection ownership and control is passed from the MP to
 the CP) has been defined as a mandatory requirement, while the
 opposite operation, CP-to-MP Handover, has been considered as a nice-
 to-have feature that can be seen as an emergency procedure to disable
 the CP and take manual control of the LSP.  For more details on
 requirements and motivations, please refer to [RFC5493].

4. Procedures

 The modification defined in this document refers only to the
 ADMIN_STATUS Object, that is, the message flow is left unmodified for
 both LSP setup and deletion.  Moreover, a new Error Value is defined
 to identify the failure of a Handover procedure.
 The following paragraphs give detailed description of the "MP-to-CP
 Handover" and "CP-to-MP Handover" procedures, based on the use of a
 newly defined bit called "H bit".
 Just as when setting up an LSP using the CP [RFC3473], the Path
 message may contain full information about the explicit route
 including the links and labels traversed by the LSP.  This
 information is encoded in the Explicit Route Object (ERO), and must
 be supplied by the MP using details recorded when the LSP was
 provisioned, or collected by the MP by inspecting the nodes along the
 path.
 Alternatively, and also just as when setting up an LSP using the CP
 [RFC3473], the ERO may include less information such that the details
 of the next hop have to be determined by each node along the LSP as
 it processes the Path message.  This approach may be desirable when
 the full information is not available to the MP or cannot be passed
 to the head-end node when initiating the Handover from the MP to the
 CP.
 This section (Section 4) describes the general procedures and
 protocol extensions for MP-to-CP Handover, and it uses the case of a
 fully detailed ERO to describe the mechanism.  Section 5 describes
 how each node behaves in the case of a limited amount of information
 in the ERO.
 Note that when Handover is being performed for a bidirectional LSP
 and the ERO contains full information including labels, the ERO
 SHOULD include both upstream and downstream labels.  Per Section
 5.1.1 of [RFC3473], the labels are indicated on an output basis; this
 means that the labels are used by the upstream node to create the
 LABEL_SET Object and, for bidirectional LSPs, the UPSTREAM_LABEL
 Object used in the outgoing Path message.

Caviglia, et al. Standards Track [Page 5] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

4.1. MP-to-CP Handover: LSP Ownership Transfer from Management Plane to

    Control Plane
 The MP-to-CP Handover procedure MUST create an RSVP-TE session along
 the path of the LSP to be moved from the MP to the CP, associating it
 with the existing cross-connected resources owned by the MP (e.g.,
 lambdas, time slots, or reserved bandwidth) and at the same time
 transferring their ownership to the CP.
 The operator instructs the ingress node to hand over control of the
 LSP from the MP to the CP.  In this Handover mode, it supplies the
 exact path of the LSP including any resource reservation and label
 information.
 The ingress MUST check that no corresponding Path state exists and
 that corresponding Data Plane state does exist.  If there is an
 error, this MUST be reported to the operator and further protocol
 action MUST NOT be taken.
 The ingress signals the LSP using a Path message with the H bit and R
 bit set in the ADMIN_STATUS Object.  In this mode of Handover, the
 Path message also carries an ERO that includes Label subobjects
 indicating the labels used by the LSP at each hop.  The ingress MUST
 start the Expiration timer (see Section 4.2.1.2 for expiration of
 this timer).  Such a timer SHOULD be configurable per LSP and have a
 default value of 30 seconds.
 Each Label Switching Router (LSR) that receives a Path message with
 the H bit set checks to see whether there is any matching Path state.
 o  If matching Path state is found with the H bit set, this is a Path
    refresh and should be treated accordingly [RFC3473].
 o  If matching Path state is found with the H bit clear, this is an
    error and MUST be treated according to the error case description
    in Section 4.2.1.1.
 o  If no Path state is found, the LSR goes on to check whether there
    is any matching Data Plane state.
 o  If no matching Data Plane state is found (including only partially
    matching Data Plane state), this is an error or a race condition.
    It MUST be handled according to the description in Section
    4.2.1.1.

Caviglia, et al. Standards Track [Page 6] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

 o  If matching Data Plane state is found, the LSR MUST save the Path
    state (including the set H bit), and it MUST forward the Path
    message to the egress.  The LSR MUST retain any MP state
    associated with the LSP at this point.
 An egress LSR MUST act as any other LSR, except that there is no
 downstream node to which to forward the Path message.  If all checks
 are passed, the egress MUST respond with a Resv with the H bit set.
 A transit LSR MUST process each Resv according to the normal rules of
 [RFC3473].
 When an ingress LSR receives a Resv message carrying the H bit set,
 it checks the Expiration timer.
 o  If the timer is not running, the Resv is treated as a refresh and
    no special action is taken [RFC3473].
 o  If the timer is running, the ingress MUST cancel the timer and
    SHOULD notify the operator that the first stage of Handover is
    complete.  The ingress MUST send a Path message that is no
    different from the previous message except that the H bit MUST be
    clear.
 The Path message with the H bit clear will travel the length of the
 LSP and will result in the return of a Resv with the H bit clear
 according to normal processing [RFC3473].  As a result, the H bit
 will be cleared in the stored Path state at each transit LSR and at
 the egress LSR.  Each LSR SHOULD release any associated MP state
 associated with the LSP when it receives the Path message with H bit
 clear, but MAY retain the information according to local policy for
 use in future MP processing.
 When the ingress receives a Resv with the H bit clear, the Handover
 is completed.  The ingress SHOULD notify the operator that the
 Handover is correctly completed.

4.2. MP-to-CP Handover Procedure Failure Handling

 In the case of MP-to-CP Handover, two different failure scenarios can
 happen: Path Failure and Resv Failure.  Moreover, each failure can be
 due to two different causes: DP Failure or Communication Failure.  In
 any case, the LSP ownership MUST be immediately rolled back to the
 one previous to the Handover procedure.  A section for each
 combination will be analyzed in the following.

Caviglia, et al. Standards Track [Page 7] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

4.2.1. MP-to-CP Handover Failure - Path Failure

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

        Failure
 In the following paragraph, we will analyze the case where the
 Handover procedure fails during the Path message processing.
   |      Path      |                |                |
   |--------------->|      Path      |                |
   |                |---------------X|                |
   |                |    PathErr     |                |
   |    PathErr     |<---------------|                |
   |<---------------|                |                |
   |                |                |                |
 Ingress LER      LSR A            LSR B       Egress LER
               Figure 1: MP2CP - Path Msg and DP Failure
 If an error occurs, the node detecting the error MUST respond to the
 received Path message with a PathErr message, and MUST abort the
 Handover procedure.  The PathErr message SHOULD have the
 Path_State_Removed flag set [RFC3473], but implementations MAY retain
 their local state and wait for Path state timeout as per normal RSVP
 processing.
 Nodes receiving a PathErr message MUST follow standard PathErr
 message processing and the associated DP resources MUST NOT be
 impacted.  If the local CP state indicates that a Handover is in
 progress (based on the H bit in the Path message), the LSR MUST
 revert the LSP ownership to the MP.

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

        Failure
 Other possible scenarios are shown in the following figures and are
 based on the inability to reach a node along the path of the LSP.
 The below scenario postulates the use of a reliable message delivery
 based on the mechanism defined in [RFC2961].

Caviglia, et al. Standards Track [Page 8] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

   |      Path      |                |                |
   |--------------->|      Path      |                |
   |                |---------------X|                |
   |                |---------------X|                |
   |                |      ...       |                |
   |                |---------------X|                |
   |                |                |                |
 Ingress LER      LSR A            LSR B       Egress LER
         Figure 2: MP2CP - Path Msg and Communication Failure
                          (Reliable Delivery)
 The Path message sent from LSR A towards LSR B is lost or does not
 reach the destination for any reason.  As a reliable delivery
 mechanism is implemented, LSR A retransmits the Path message for a
 configurable number of times, and if no ack is received, the Handover
 procedure will be aborted (via the Expiration timer).
 In the next scenario RSVP-TE messages are sent without reliable
 message delivery, that is, no [RFC2961] MessageID procedure is used.
      |      Path      |                |                |
      |--------------->|      Path      |                |
      |                |----------X     |                |
      |                |                |                |
 TIMER EXPIRES         |                |                |
      |   Path Tear    |   Path Tear    |   Path Tear    |
      |--------------->|--------------->|--------------->|
      |                |                |                |
    Ingress LER      LSR A            LSR B       Egress LER
         Figure 3: MP2CP - Path Msg and Communication Failure
                        (No Reliable Delivery)
 If the Resv message is not received before the expiration of the
 Expiration timer, the Handover procedure is aborted as described in
 Section 4.2.1.1.  Please note that any node that has forwarded a Path
 (LSR A), i.e., has installed local path state, will send a PathTear
 when that state is removed (according to [RFC2205]).

4.2.2. MP-to-CP Handover Failure - Resv Error

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

 In the case of a failure occurrence during the Resv message
 processing (in case there has been any change in the Data Plane
 during the signaling), the node MUST send a PathErr message [RFC2205]
 in the upstream direction.  The PathErr message is constructed and

Caviglia, et al. Standards Track [Page 9] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

 processed as defined above in Section 4.2.1.1.  The failure detection
 node MUST also send a PathTear message downstream.  The PathTear
 message is constructed and processed as defined above in
 Section 4.2.1.1.
   |      Path      |      Path      |      Path      |
   |--------------->|--------------->|--------------->|
   |                |                |      Resv      |
   |                |      Resv      |<---------------|
   |                |X---------------|                |
   |    PathErr     |    PathTear    |    PathTear    |
   |<---------------|--------------->|--------------->|
   |                |                |                |
 Ingress LER      LSR A            LSR B       Egress LER
              Figure 4: MP2CP - Resv Error and DP Failure
 In the case shown in Figure 4, the failure occurs in LSR A.  A
 PathTear message is sent towards B and a PathErr message (with
 ErrorCode set to "Handover Procedure Failure") is sent in the
 upstream direction.  The PathErr and PathTear messages remove the
 Path state established by the Path messages along the nodes of the
 LSP and abort the Handover procedure.
 Please note that the failure occurred after the Handover procedure
 was successfully completed in LSR B, but Handover state will still be
 maintained locally as, per Section 4.1, a Path message with the H bit
 clear will have not yet been sent or received.  A node that receives
 a PathTear when it has Path state with the H bit set MUST remove Path
 state, but MUST NOT change Data Plane state.  It MUST return LSP
 ownership to the MP.

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

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

Caviglia, et al. Standards Track [Page 10] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

 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 Label
 Edge Router (LER) or an LSR, say LSR A.  LSR B MUST send a Resv
 message again for a configurable number of times and then, if the
 delivery does not succeed, the adoption procedure will be aborted
 (via the Expiration timer).
   |      Path      |      Path      |      Path      |
   |--------------->|--------------->|--------------->|
   |                |                |      Resv      |
   |                |      Resv      |<---------------|
   |                |      X---------|                |
   |                |      X---------|                |
   |                |      ...       |                |
   |                |      X---------|                |
   |                |                |                |
 Ingress
       LSR A            LSR B       Egress LER
        Figure 5: MP2CP - Resv Error and Communication Failure
                          (Reliable Delivery)
 Considering that the Resv message did not manage to reach LSR A, it
 is highly probable that the PathErr would fail too.  Due to this
 fact, the Expiration timer is used on the ingress LER after sending
 the path and on LSR A after forwarding it.  When the timer expires,
 if no Resv or PathErr message is received, the Handover procedure is
 aborted as described in Section 4.2.1.1 and the LSP ownership is
 returned to the Management Plane.
 Figure 6, on the other hand, shows the scenario in which no reliable
 delivery mechanism is implemented.

Caviglia, et al. Standards Track [Page 11] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

         |      Path      |      Path      |      Path      |
         |--------------->|--------------->|--------------->|
         |                |                |      Resv      |
         |                |      Resv      |<---------------|
         |                |      X---------|                |
 TIMER EXPIRES            |                |                |
         |   Path Tear    |   Path Tear    |   Path Tear    |
         |--------------->|--------------->|--------------->|
         |                |                |                |
    Ingress LER      LSR A            LSR B       Egress LER
        Figure 6: MP2CP - Resv Error and Communication Failure
                        (No Reliable Delivery)
 If no Resv message is received before the Expiration timer expires,
 the ingress LER follows the same procedure defined in Section 4.1.

4.2.2.3. MP-to-CP Handover Failure - Node Graceful Restart

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

Caviglia, et al. Standards Track [Page 12] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

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

Caviglia, et al. Standards Track [Page 13] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

   |      Path      |      Path      |      Path      |
   |--------------->|--------------->|--------------->|
   |                |                |      Resv      |
   |                |      Resv      |<---------------|
   |                X      X---------|                |
   |   PathTear                      |                |
   |-------X                         |                |
   |                                 |                |
   |                X                |                |
   |                |                |                |
   |                |          Recovery Timer         |
   |                |             Expires             |
   |    PathErr     |    PathErr     |    PathTear    |
   |<---------------|<---------------|--------------->|
   |                |                |                |
 Ingress LER      LSR A            LSR B       Egress LER
           Figure 8: MP2CP - Node Graceful Restart - Case II
 Case III
 In this case, the ingress LER does not abort the Handover process.
 When LSR A restarts, the ingress LER detects the restart and MUST
 re-generate the Path message with the H bit set in order to restart
 the Handover.
 When LSR B receives the Path message, it sees the H-bit set on the
 message and also sees that it has the H-bit set in its own state and
 that it has sent the Resv.  But it is also aware that LSR A has
 restarted and could have sent a Path message with a RECOVERY LABEL
 object.  LSR B may attempt to resume the Handover process or may
 abort the Handover.  This choice is made according to local policy.
 If resuming the Handover, LSR B MUST treat the received Path message
 as a retransmission, and MUST retransmit its Resv.  If aborting
 Handover, LSR B MUST return a PathErr and MUST send a PathTear
 downstream.  In both cases, LSR B MUST NOT modify the DP state.

Caviglia, et al. Standards Track [Page 14] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

   |      Path      |      Path      |      Path      |
   |--------------->|--------------->|--------------->|
   |                |                |      Resv      |
   |                |      Resv      |<---------------|
   |                X      X---------|                |
   |                                 |                |
   |                X                |                |
   |                |                |                |
   |      Path      |      Path      |                |
   |--------------->|--------------->|                |
   |    PathErr     |    PathErr     |    PathTear    |
   |<---------------|<---------------|--------------->|
   |                |                |                |
 Ingress LER      LSR A            LSR B       Egress LER
          Figure 9: 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 section, we will analyze the
 Handover procedure success and failure.
 The scenario is still a DP connection between two nodes acting as
 ingress and egress for a LSP, but in this case, the CP has the
 ownership and control of the LSP.  The CP-to-MP Handover procedure
 MUST delete the existing RSVP-TE session information and MUST NOT
 affect the cross-connected resources, but just move their ownership
 to the MP.
 In other words, after LSP ownership transfer from CP to MP, the LSP
 is no longer under the control of RSVP-TE, which is no more able to
 "see" the LSP itself.  The CP-to-MP Handover procedure MUST be a
 standard LSP deletion procedure as described in Section 7.2.1 of
 [RFC3473].  The procedure is initiated at the ingress node of the LSP
 by an MP entity.  The ingress node and MP exchange the relevant
 information for this task and then propagate it over CP by means of
 RSVP-TE tear down signaling as described below.
 The ingress node MUST send a Path message in the downstream direction
 with Handover and Reflect bits set in the ADMIN_STATUS Object.  No
 action is taken over the DP and transit LSRs must forward such
 message towards the egress node.  All of the nodes MUST keep track of
 the procedure storing the H bit in their local Path and Resv states.
 Then, every node waits for the H bit to be received within the
 related Resv message.  After the Resv message is received by the
 ingress LER, it MUST send a PathTear message in order to clear the

Caviglia, et al. Standards Track [Page 15] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

 whole LSP information recorded on the RSVP-TE data structures of the
 nodes.  Downstream nodes processing a PathTear message that follows a
 Path message with the H bit set, MUST NOT remove any associated Data
 Plane state.  In other words, a normal LSP tear down signaling is
 exchanged between nodes traversed by the LSP, but the H bit set in
 the Path message indicates that no DP action has to correspond to CP
 signaling.

4.4. CP-to-MP Handover Procedure Failure

 Failures during CP-to-MP Handover procedure MUST NOT result in the
 removal of any associated Data Plane state.  To that end, when a Resv
 message containing an ADMIN_STATUS Object with the H bit not received
 during the period of time described in Section 7.2.2. of [RFC3473]
 different processing is required.  While the H bit is set in the Path
 state, a node MUST NOT send a PathTear when a failure is detected.
 Instead, the failure is reported upstream using a PathErr.  The only
 node that can send a PathTear is the ingress node, and it can only do
 this as a step in the procedures specified in this document.  This
 applies to both MP-to-CP and CP-to-MP Handover.  The ingress node MAY
 choose to report the failure in the CP-to-MP Handover procedure via
 the MP.
 The CP-to-MP Handover procedure can also fail due to two causes:
 PathTear lost or node down.  In the former case, if the LSP is not
 under MP control after the Expiration timer elapses, a manual
 intervention from the network operator is requested, while in the
 latter case, different scenarios may happen:
  1. CASE I - Path message and node down
         |      Path      |      Path      X                |
         |--------------->|--------------X                  |
         |                |                                 |
         |                |                X                |
         |                |                |                |
         |                |                |                |
    Ingress LER      LSR A            LSR B       Egress LER
            Figure 10: Case I - Path Message and Node Down
 Per [RFC3473], Section 7.2.2, the ingress node should wait for a
 configurable amount of time (30 seconds by default) and then send a
 PathTear message.  In this case, the normal deletion procedure MUST

Caviglia, et al. Standards Track [Page 16] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

 NOT be followed.  When the Expiration timer elapses, a manual
 intervention from network operator is requested and normal, i.e.,
 pre-CP-to-MP Handover, LSP processing continues.
  1. CASE II - Resv message and node down
         |      Path      |      Path      |      Path      |
         |--------------->|--------------->|--------------->|
         |                |                |      Resv      |
         |                |      Resv      |<---------------|
         |                X      X---------|                |
         |                                 |                |
         |                X                |                |
         |                |                |                |
    Ingress LER      LSR A            LSR B       Egress LER
            Figure 11: Case II - Resv Message and Node Down
 The procedure to be followed is the same depicted in CASE I.  The
 network operator can ask for the automatic CP-to-MP procedure again
 after the failed node comes back up.  Per [RFC3473], section 7.2, the
 nodes will forward the new Path and Resv messages correctly.
  1. CASE III - PathTear message and node down
         |      Path      |      Path      |      Path      |
         |--------------->|--------------->|--------------->|
         |      Resv      |      Resv      |      Resv      |
         |<---------------|<---------------|<---------------|
         |    PathTear    |                |                |
         |--------------->|    PathTear    X                |
         |                |------------X                    |
         |                |                X                |
         |                |                |                |
    Ingress LER      LSR A            LSR B       Egress LER
         Figure 12: Case III - PathTear Message and Node Down
 This scenario can be managed as a normal PathTear lost described
 above in this section.

5. Minimum Information for MP-to-CP Handover

 As described in Section 4, it is also possible for the ERO to contain
 less than the full set of path information for the LSP being handed
 over.  This arises when only a minimal set of information is handed

Caviglia, et al. Standards Track [Page 17] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

 to the CP by the MP at the LSP's head-end.  Instead of collecting all
 of the LSP information (including the labels) and formatting it into
 an ERO, as described in Section 4, it is possible to start with a
 minimum amount of information.  The full ERO method and the
 partial/no ERO method are not mutually exclusive; support of both
 methods is required.
 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 egress node ID.  The remaining information about an
 existing LSP can then be collected hop by hop, as the signaling is
 going on, by looking up the cross-connection table in the DP at each
 node along the LSP path.
 Starting from the information available at the ingress LER about the
 outgoing interface ID of that ingress node, the incoming interface ID
 of the next hop can be found by looking up the link resource table/
 database in the LER itself.
 The Path message is hence built with the LABEL_SET Object ([RFC3473])
 and the UPSTREAM_LABEL Object ([RFC3473]), where the upstream label
 and downstream label of ingress outgoing interface of the LSP are
 included in these two objects.  In addition to the above mentioned
 objects, the Path message MUST include the ADMIN_STATUS Object with
 the H bit set, as already defined in previous chapters for the
 detailed ERO-based way of proceeding.  Such a Handover Path is sent
 to the incoming interface of the next hop.  When this Path message
 reaches the second node along the LSP, the information about incoming
 interface ID and the upstream and downstream labels of this interface
 is extracted from it, and it is used to find next hop outgoing
 interface ID and the upstream/downstream labels by looking up the DP
 cross-connection table.
 After having determined, in this way, the parameters describing the
 LSPs next hop, the outgoing Path message to be sent is built
 replacing the LABEL_SET Object and UPSTREAM_LABEL Object content with
 the looked-up values of upstream and downstream labels.
 By repeating this procedure for each transit node along the LSP, it
 is possible to make the Handover Path message reach the egress node,
 exactly following the LSP that is in place over DP.  The ERO MAY, in
 this case, be included in the Path message as an optional object, and
 MAY be filled with the LSP-relevant information down to either the
 port level with the interface ID or the label level with upstream and
 downstream labels.  The ERO can be used to check the consistency of
 resource in the DP down to the port level or label level at each
 intermediate node along the LSP.

Caviglia, et al. Standards Track [Page 18] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

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

6. RSVP Message Formats

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

7. Objects Modification

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

7.1. Administrative Status Object

 This memo introduces a new flag into the ADMIN_STATUS Object.  The
 ADMIN_STATUS Object is defined in [RFC3473].  This document uses the
 H bit of the ADMIN_STATUS Object.  The bit is bit number 25.

7.2. Error Spec Object

 It is possible that a failure, such as the loss of the Data
 Communication Network (DCN) connection or the restart of a node,
 occurs during the LSP ownership handing over.  In this case, the LSP
 Handover procedure is interrupted, the ownership of the LSP must
 remain with the ownership prior to the initiation of the Handover
 procedure.  It is important that the transaction failure not affect
 the DP.  The LSP is kept in place and no traffic hit occurs.
 The failure is signaled by a PathErr message in the upstream
 direction and PathTear messages in the downstream direction.  The
 PathErr messages include an ERROR_SPEC Object specifying the causes
 of the failure.
 This memo introduces a new Error Code (with different Error Values)
 into the ERROR_SPEC Object, defined in [RFC2205].
 The defined Error Code is "Handover Procedure Failure", and its value
 is 35.  For this Error Code, the following Error Value sub-codes are
 defined:
    1 = Cross-connection mismatch
    2 = Other failure

Caviglia, et al. Standards Track [Page 19] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

8. Compatibility

 The main requirement for the Handover procedure to work is that all
 nodes along the path MUST support the extension defined in this
 document.  This requirement translates to an administrative
 requirement as it is not enforced at the protocol level.  As defined,
 non-supporting nodes will simply propagate the H bit without setting
 local state.  This may result in an impact on data traffic during the
 Handover procedure.

9. Security Considerations

 The procedures described in this document rely completely on RSVP-TE
 messages and mechanism.  The use of the H bit being set in the
 ADMIN_STATUS Object basically informs the receiving entity that no
 operations are to be done over the DP as a consequence of such
 special signaling flow.  Using specially flagged signaling messages,
 we want to limit the function of setup and teardown messages to the
 CP, making them ineffective over related DP resource usage.
 However, the Handover procedures allow the Control Plane to be used
 to take an LSP out of the control of the Management Plane.  This
 could cause considerable disruption and could introduce a new
 security concern.  As a consequence, the use of GMPLS security
 techniques is more important.  For RSVP-TE security, please refer to
 [RFC3473], for the GMPLS security framework, please refer to
 [sec-fwk].

10. IANA Considerations

 IANA manages the bit allocations for the ADMIN_STATUS Object
 ([RFC3473]).  This document requires the allocation of the Handover
 bit: the H bit.  IANA has allocated a bit for this purpose.
 Bit Number  Hex Value    Name                               Reference
 ----------  -----------  ---------------------------------  ---------
 25          0x00000040   Handover (H)                       [RFC5852]
 IANA has also allocated a new Error Code:
   35  Handover failure
       This Error Code has the following globally defined Error
       Value sub-codes:
           1 =  Cross-connection mismatch
           2 =  Other failure

Caviglia, et al. Standards Track [Page 20] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

11. Acknowledgments

 We wish to thank Adrian Farrel, Lou Berger, Alan Elder, and Ben
 Campbell for their assistance and precious advice to prepare this
 document for publication.  We also wish to thank Nicola Ciulli
 (Nextworks) who contributed to the initial stage of this document.

12. Contributors

 Shan Zhu
 Fujitsu Network Communications Inc.
 2801 Telecom Parkway,
 Richardson, TX 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
 USA
 EMail: ibryskin@advaoptical.com
 Francesco Fondelli
 Ericsson
 Via Negrone 1A
 Genova - 16145
 Italy
 EMail: francesco.fondelli@ericsson.com
 Lou Berger
 LabN Consulting, LLC
 Phone: +1 301 468 9228
 EMail: lberger@labn.net

13. References

13.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
            Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
            Functional Specification", RFC 2205, September 1997.

Caviglia, et al. Standards Track [Page 21] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

 [RFC2961]  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
            and S. Molendini, "RSVP Refresh Overhead Reduction
            Extensions", RFC 2961, April 2001.
 [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
            (GMPLS) Signaling Functional Description", RFC 3471,
            January 2003.
 [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
            (GMPLS) Signaling Resource ReserVation Protocol-Traffic
            Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
 [RFC3945]  Mannie, E., "Generalized Multi-Protocol Label Switching
            (GMPLS) Architecture", RFC 3945, October 2004.
 [RFC4003]  Berger, L., "GMPLS Signaling Procedure for Egress
            Control", RFC 4003, February 2005.

13.2. Informative References

 [RFC5493]  Caviglia, D., Bramanti, D., Li, D., and D. McDysan,
            "Requirements for the Conversion between Permanent
            Connections and Switched Connections in a Generalized
            Multiprotocol Label Switching (GMPLS) Network", RFC 5493,
            April 2009.
 [sec-fwk]  Fang, L. and M. Behringer, "Security Framework for MPLS
            and GMPLS Networks", Work in Progress, March 2010.

Caviglia, et al. Standards Track [Page 22] RFC 5852 RSVP-TE Ext for MP2CP LSP Handover April 2010

Authors' Addresses

 Diego Caviglia
 Ericsson
 Via A. Negrone 1A
 Genova - Sestri Ponente  16153
 Italy
 EMail: diego.caviglia@ericsson.com
 Daniele Ceccarelli
 Ericsson
 Via A. Negrone 1A
 Genova - Sestri Ponente  16153
 Italy
 EMail: daniele.ceccarelli@ericsson.com
 Dino Bramanti
 Ericsson
 Dan Li
 Huawei Technologies
 F3-5-B R&D Center, Huawei Base
 Shenzhen  518129
 P.R. China
 EMail: danli@huawei.com
 Snigdho Bardalai
 Fujitsu Network
 2801 Telecom Parkway
 Richardson, TX  75082
 USA
 EMail: sbardalai@gmail.com

Caviglia, et al. Standards Track [Page 23]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5852.txt · Last modified: 2010/04/26 22:44 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki