--- 1/draft-ietf-ccamp-pc-spc-rsvpte-ext-04.txt 2010-01-08 13:12:09.000000000 +0100 +++ 2/draft-ietf-ccamp-pc-spc-rsvpte-ext-05.txt 2010-01-08 13:12:09.000000000 +0100 @@ -1,24 +1,45 @@ CCAMP Working Group D. Caviglia Internet-Draft D. Ceccarelli Intended status: Standards Track D. Bramanti -Expires: March 26, 2010 Ericsson +Expires: July 12, 2010 Ericsson D. Li Huawei Technologies S. Bardalai Fujitsu Network - September 22, 2009 + January 08, 2010 RSVP-TE Signaling Extension For Management Plane To Control Plane LSP Handover In A GMPLS Enabled Transport Network. - draft-ietf-ccamp-pc-spc-rsvpte-ext-04 + draft-ietf-ccamp-pc-spc-rsvpte-ext-05 + +Abstract + + In a transport network scenario, where Data Plane connections are + controlled either by a Generalized Multi-Protocol Label Switching + (GMPLS) Control Plane (Soft Permanent Connections - SPC) or by a + 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. The requirements for the + conversion between permanent connections and switched connections in + a GMPLS Network are defined in [RFC5493]. + + This memo describes an extension to GMPLS RSVP-TE signaling that + enables the transfer of connection ownership between the Management + and the Control Planes. Such a transfer is referred to as a + Handover. This document defines all Handover related procedures. + This includes the handling of failure conditions and subsequent + reversion to original state. A basic premise of the extension is + that the handover procedures must never impact an already established + Data plane. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -27,265 +48,274 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on March 26, 2010. + This Internet-Draft will expire on July 12, 2010. Copyright Notice - Copyright (c) 2009 IETF Trust and the persons identified as the + 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 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. - - This memo describes an extension to GMPLS RSVP-TE signaling that - enables the transfer of connection ownership between the Management - and the Control Planes. Such a transfer is referred to as a - Handover. This document defines all Handover related procedures. - This includes the handling of failure conditions and subsequent - reversion to original state. A basic premise of the extension is - that the handover procedures must never impact an already established - Data plane. + 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 BSD License. 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 . . . . . . . . . . . . 5 - 4.2. MP to CP Handover Procedure Failure Handling . . . . . . . 6 - 4.2.1. MP to CP Handover Failure - Path Failure . . . . . . . 6 + 4.2. MP to CP Handover Procedure Failure Handling . . . . . . . 7 + 4.2.1. MP to CP Handover Failure - Path Failure . . . . . . . 7 4.2.1.1. MP to CP Handover Failure - Path message and - Data Plane Failure . . . . . . . . . . . . . . . . 6 + Data Plane Failure . . . . . . . . . . . . . . . . 7 4.2.1.2. MP to CP Handover Failure - Path message and - Communication failure . . . . . . . . . . . . . . 7 - 4.2.2. MP to CP Handover Failure - Resv Error . . . . . . . . 8 + 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 . . . . . . . . . . . . . . . . 8 + Data Plane failure . . . . . . . . . . . . . . . . 9 4.2.2.2. MP to CP Handover Failure - Resv Error and - Communication failure . . . . . . . . . . . . . . 9 + Communication failure . . . . . . . . . . . . . . 10 4.2.2.3. MP to CP Handover Failure - Node Graceful - Restart . . . . . . . . . . . . . . . . . . . . . 10 + Restart . . . . . . . . . . . . . . . . . . . . . 11 4.3. CP to MP handover : LSP Ownership Transfer From - Control Plane To Management Plane . . . . . . . . . . . . 13 - 4.4. CP to MP Handover Procedure Failure . . . . . . . . . . . 13 - 5. Alternative Way Of Retrieving Information Needed For MP To - CP Handover . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 6. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 15 - 7. Objects Modification . . . . . . . . . . . . . . . . . . . . . 15 - 7.1. Administrative Status Object . . . . . . . . . . . . . . . 15 - 7.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 16 - 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 16 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 - 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 - 13.2. Informational References . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 + Control Plane To Management Plane . . . . . . . . . . . . 14 + 4.4. CP to MP Handover Procedure Failure . . . . . . . . . . . 14 + 5. Minimum Information for MP to CP Handover . . . . . . . . . . 16 + 6. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 17 + 7. Objects Modification . . . . . . . . . . . . . . . . . . . . . 17 + 7.1. Administrative Status Object . . . . . . . . . . . . . . . 17 + 7.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 17 + 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 18 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 + 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 13.2. Informational References . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction In a typical traditional transport network scenario, Data Plane (DP) connections between two endpoints are controlled by means of a Network Management System (NMS) operating within Management Plane (MP). NMS/MP is the owner of such transport connections, being responsible of their set up, tear down and maintenance. - The adoption of a GMPLS Control Plane (CP) over networks that are - already in service - controlled by NMS at MP level - introduces the - need for a procedure able to coordinate a control handover of a - generic data plane connection from MP to CP. + The adoption of a Generalized MPLS (GMPLS) [RFC3945] Control Plane + (CP) in a network that is already in service - controlled by NMS at + MP level - introduces the need for a procedure able to coordinate a + controlled handover of a 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. + to MP should be possible as well. The procedures described in this + memo can be applied to an LSP in any DP switching technology and any + network architecture. - This memo describes an extension to Generalized Multi-Protocol Label - Switching (GMPLS) RSVP-TE (see [RFC3471] and [RFC3473]) signaling - that enables the handover of connection ownership between the - Management and the Control Planes. All handover related procedures - are defined below. This includes the handling of failure conditions - and subsequent reversion to original state. A basic premise of the - extension is that the handover procedures must never impact an - already established Data plane. + This memo describes an extension to GMPLS RSVP-TE 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 impacting procedure that satisfies the requirements - defined in [RFC5493]. Such procedure is aimed at giving the - transport network operators the chance to handover the ownership of - existing LSPs provisioned by NMS from the MP to the CP without - disrupting user traffic flowing on them. Handover from MP to CP - (i.e. when existing DP connection ownership and control is passed - from MP to CP) has been defined as mandatory requirement, while the - opposite operation, CP to MP handover, has been considered as a nice- - to-have feature that can be seen as an emergency procedure to disable - the CP and take the manual control of the LSP. For more details on - requirements and motivations please refer to [RFC5493]. + 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 handover the ownership of existing + LSPs provisioned by NMS from the MP to the CP without disrupting user + traffic flowing on them. Handover from MP to CP (i.e. when existing + DP connection ownership and control is passed from MP to CP) has been + defined as 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 the + 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 ADMIN_STATUS - Object, that is, the message flow is left unmodified for both LSP - set-up and deletion. Moreover a new Error Value is defined to - identify the failure of a Handover procedure. + The modification defined in this document refers only to the + ADMIN_STATUS Object, that is, the message flow is left unmodified for + both LSP set-up and deletion. Moreover a new Error Value is defined + to identify the failure of a Handover procedure. - The following paragraphs give detailed description of defined "MP to - CP handover" and "CP to MP handover" procedures, based on the usage a - newly define bit called H bit. + The following paragraphs give detailed description of the "MP to CP + handover" and "CP to MP handover" procedures, based on the usage a + newly defined bit called H bit. The MP to CP handover procedures support two different methods for - retrieving required information. The primary one consists on + retrieving required information. The primary one consists of receiving the full Explicit Route Object (ERO) from the MP while the alternative one is described in Section 5. Please note that if the primary method is used the labels SHOULD be included in the ERO and for bidirectional LSPs both upstream and downstream labels SHOULD be included. Per Section 5.1.1. of [RFC3473], the labels are indicated on an output basis. As described, this means that the labels are used by the upstream node to create the LABEL_SET Object and, for bidirectional LSPs, UPSTREAM_LABEL Object used in the outgoing Path message. 4.1. MP to CP handover: LSP Ownership Transfer From Management Plane To Control Plane The MP to CP handover procedure MUST create an RSVP-TE session along the path of the LSP to be moved from MP to CP, associating it to the existing cross-connected resources owned by the MP (e.g. lambdas, time slots or reserved bandwidth) and at the same time transferring their ownership to the CP. - A standard RSVP-TE signaling flow MUST be used to inform nodes about - the ownership handover request. Such flows MUST be tagged with a new - flag that is carried within the ADMIN_STATUS Object ([RFC3471] and - [RFC3473]). The new flag is referred to as the H bit and is - described in Section 7.1. The H bit MUST be set in order to - discriminate the handover procedure from normal, DP affecting, LSP - setup/release procedure. The DP MUST NOT be affected from the - handover procedure. + The operator instructs the ingress node to handover 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 node MUST send a Path message in the downstream direction - with the H and R ([RFC3471]) bit set. Upon receiving a Path Message - containing an ADMIN_STATUS Object with the H bit set, each node MUST - check if there is a local Path State matching the MP to CP Handover - request. If no local Path State exists, the node MUST confirm that - there is an existing DP state that corresponds to the Path message. + 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. - In the case of DP state lack (failure cases are defined in the next - sections), local Path state MUST be installed. The H bit MUST be - stored in the local Path state. + 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 timer SHOULD be configurable per LSP. - After propagating a Path message with the H bit set, a node MUST wait - for a Resv message including ADMIN_STATUS Object with H bit set. - After the ingress node receives it, the actual migration of LSP - information is complete, the LSP is left completely under control of - RSVP-TE within Control Plane. + Each LSR that receives a Path message with the H bit set checks to + see whether there is any matching Path state. - If the Resv message is not received by the expiration of a timer - (called Expiration timer in the following) set by the ingress LER, - the handover procedure is aborted, that is, a PathTear message MUST - be sent in the downstream direction. + - If matching Path state is found with the H bit set, this is a + Path refresh and should be treated accordingly [RFC3473]. + - 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.xx + - If no Path state is found, the LSR goes on to check whether + there is any matching Data Plane state. + - 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.xx + - If matching Data Plane state is found, the LSR MUST save the + Path state (including the set H bit), and MUST forward the Path + message to the egress. The LSR MUST retain any MP state + associated with the LSP at this point. - In order to complete the Handover process the ingress node MUST send - a Path message with the H bit cleared (set to zero) upon receipt of a - corresponding Resv message. The R bit SHOULD NOT be set in this - message. Downstream nodes MUST clear their local "Handover" state - based on a received Path message with the H bit cleared. This means - that once a downstream node processes a Path message with the cleared - H bit, any state related to the former MP ownership of the LSP is - lost. Normal ResvConf process occurs as normal. The handover - procedure does not modify the Confirmation procedure. + 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. - When the path of the LSP is not fully passed to the ingress LER, each - node can determine the next hop looking at its data plane and exploit - the similarity between the MP to CP Handover procedure and the - Restart Procedure. Please refer to Section 5. + 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. + + - If the timer is not running, the Resv is treated as a refresh and + no special action is taken [RFC3473]. + + - If the timer is running, the ingress MUST cancel the timer and MAY + 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. + + 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 Procedure, two different failure scenarios - can happen: Path Failure and Resv Failure. Moreover, each failure - can be due to two different causes: DP failure or Communication - Failure. In any case the LSP ownership MUST be immediately roll - backed to the one previous to the handover procedure. A section for - each combination will be analyzed in the following. + 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. 4.2.1. MP to CP Handover Failure - Path Failure 4.2.1.1. MP to CP Handover Failure - Path message and Data Plane Failure In this paragraph we will analyze the case where the handover procedure fails during the Path message processing. | Path | | | |--------------->| Path | | | |---------------X| | - | | | | - | PathErr | | | + | | PathErr | | + | PathErr |<---------------| | |<---------------| | | | | | | Ingress LER LSR A LSR B Egress LER MP2CP - Path Msg and DP Failure If an error occurs in an LSR or a LER, the last node that has received the Path message MUST send a PathErr message in the upstream - direction and the handover procedure is aborted. The PathErr message - SHOULD have the Path_State_Removed flag set. + direction and the handover procedure is aborted. Upon receiving the + PathErr message the Path state of the node MUST be removed. The + PathErr message SHOULD have the Path_State_Removed flag set. Nodes receiving a PathErr message MUST follow standard PathErr message processing with the exception that when their local state indicates that a Handover is in progress (based on the H bit in the Path message) the associated DP resources MUST NOT be impacted during - such processing. + such processing and 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 pictures and - consist on inability to reach a node along the path of the LSP. + Other possible scenarios are shown in the following pictures and are + based on the 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| | @@ -300,65 +330,72 @@ 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 | | | - |--------------->| | | + TIMER EXPIRES | | | + | Path Tear | Path Tear | Path Tear | + |--------------->|--------------->|--------------->| | | | | Ingress LER LSR A LSR B Egress LER MP2CP - Path Msg and Communication Failure (no reliable delivery) - If the Resv message is not received by the expiration of the + If the Resv message is not received before the expiration of the Expiration timer the handover procedure is aborted as described in - Section 4.1. + Section 4.1. Please note that any node that has forwarded a Path + (LSR A), i.e. has installed local path state, MUST send a PathTear + when that state is removed. 4.2.2. MP to CP Handover Failure - Resv Error 4.2.2.1. MP to CP Handover Failure - Resv Error and Data Plane failure In the case of failure occurrence during the Resv message processing, - the node MUST send a PathErr message in the upstream direction. The - PathErr message is constructed and processed as defined above in - Section 4.2.1.1. The failure detection node MUST also send a - PathTear message downstream. The PathTear message is constructed and - processed as defined above in Section 4.2.1.1. + (in case there has been any change in the data plane during the + signaling) the node MUST send a PathErr message in the upstream + direction. The PathErr message is constructed and processed as + defined above in Section 4.2.1.1. The failure detection node MUST + also send a PathTear message downstream. The PathTear message is + constructed and processed as defined above in Section 4.2.1.1. | Path | Path | Path | |--------------->|--------------->|--------------->| | | | Resv | | | Resv |<---------------| - | | X---------| | + | |X---------------| | | 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. - A PathTear message is sent towards B and a PathErr message is sent in - the upstream direction. The PathErr and PathTear messages remove the + 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. + clear will have not yet been sent or received. A node that receives + a PahTear 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. In the first scenario we consider the utilization of a reliable @@ -393,21 +430,21 @@ the Management Plane. The following picture, on the other hand, shows the scenario in which no reliable delivery mechanism is implemented. | Path | Path | Path | |--------------->|--------------->|--------------->| | | | Resv | | | Resv |<---------------| | | X---------| | - |-TIMER EXPIRES--| | | + TIMER EXPIRES | | | | Path Tear | Path Tear | Path Tear | |--------------->|--------------->|--------------->| | | | | Ingress LER LSR A LSR B Egress LER MP2CP - Resv Error and Communication Failure (no reliable delivery) If non Resv message is received before the Expiration timer expires, the ingress LER follows the same procedure defined in Section 4.1. @@ -550,38 +587,94 @@ 4.4. CP to MP Handover Procedure Failure Failures during CP to MP handover procedure MUST NOT result in the removal of any associated data plane state. To that end, when a Resv message containing an ADMIN_STATUS Object with the H bit is not received during the period of time described in Section 7.2.2. of [RFC3473] different processing is required. Specifically, the ingress node MUST NOT send a PathTear message before a Resv message containing the H bit is received. The ingress node MAY choose to - report the failure in the CP to MP handover procedure via the MP + report the failure in the CP to MP handover procedure via the MP. -5. Alternative Way Of Retrieving Information Needed For MP To CP - Handover + The CP to MP handover procedure can fail also 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: + + - CASE I - Path message and node down + + | Path | Path X | + |--------------->|--------------X | + | | | + | | X | + | | | | + | | | | + Ingress LER LSR A LSR B Egress LER + + Per [RFC 3473] 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 + NOT be followed. When the Expiration timer elapses a manual + intervention from network operator is requested. + + - CASE II - Resv message and node down + + | Path | Path | Path | + |--------------->|--------------->|--------------->| + | | | Resv | + | | Resv |<---------------| + | X X---------| | + | | | + | X | | + | | | | + Ingress LER LSR A LSR B Egress LER + + 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 [RFC 3473] section 7.2 the + nodes will forward the new Path and Resv messages correctly. + + - 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 + + This scenario can be managed as a normal PathTear lost described + above in this section. + +5. Minimum Information for MP to CP Handover An alternative way of getting the LSP related information required for the MP to CP handover is also defined in this draft. The rationale behind this way is that only a minimal set of information is handed over from MP to CP at LSPs Ingress node. Instead of collecting within MP all the LSP relevant information down to the Label level, formatting it to an ERO and passing it to CP, as in previously described solution, it is possible to start with a minimum - amount of information. At the ingress node, the information needed - to specify the LSP is the outgoing interface ID, upstream label and - downstream label of this interface and the egress node ID. The - remaining information about an existing LSP can then be collected hop - by hop, as the signaling is going on, by looking up the cross- - connection table in DP at each node along the LSP path. + amount of information. The full ERO method and the partial/no ERO + one do not exclude each other; both methods are 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 the egress node ID. The remaining information about an + existing LSP can then be collected hop by hop, as the signaling is + going on, by looking up the cross-connection table in DP at each node + along the LSP path. Starting from the information available at ingress LER about the outgoing interface ID of that ingress node, the incoming interface ID of next hop can be found by looking up the link resource table/ database in the LER itself. The Path message is hence built with the LABEL_SET Object ([RFC3473]) and the UPSTREAM_LABEL Object ([RFC3473]), where the upstream label and downstream label of ingress outgoing interface of the LSP are included in these two objects. In addition to above mentioned @@ -593,29 +686,29 @@ and the upstream and downstream labels of this interface is extracted from it and it is used to find next hop outgoing interface ID and the upstream/downstream labels by looking up the DP cross-connection table. After having determined in this way the parameters describing the LSPs next hop, the outgoing Path message to be sent is built replacing the LABEL_SET Object and UPSTREAM_LABEL Object content with the looked-up values of upstream and downstream labels. - By repeating this procedure for each transit node along the LSP path, - it is possible to make the handover Path message reach the egress - node, exactly following the LSP that is in place over DP. The ERO - MAY in this case be included in the Path message as an optional - object, and MAY be filled with the LSP relevant information down to - either the port level with interface ID or the Label level with - upstream and downstream labels. The ERO can be used to check the - consistency of resource in DP down to the port level or label level - at each intermediate node along the LSP path. + 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 interface ID or the Label level with upstream and + downstream labels. The ERO can be used to check the consistency of + resource in DP down to the port level or label level at each + intermediate node along the LSP path. Where the DP path continues beyond the egress, by indicating the Egress label at the head-end of an LSP, the traffic can be directed to the right destination. The GMPLS Signaling Procedure for Egress Control is described in [RFC4003] 6. RSVP Message Formats This memo does not introduce any modification in RSVP messages object composition. @@ -623,54 +716,27 @@ 7. Objects Modification The modifications required concern two RSVP objects: the ADMIN_STATUS and the ERROR_SPEC Object. 7.1. Administrative Status Object This memo introduces a new flag into the ADMIN_STATUS object. The ADMIN_STATUS Object is defined in [RFC3473]. This document uses the H bit of the ADMIN_STATUS Object. The bit is bit number (TBD by - IANA). The format of the ADMIN_STATUS Object is: - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Length | Class-Num(196)| C-Type (1) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |R| Reserved |H|L|I|C|T|A|D| - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The different flags are defined as follows: - - - Reflect (R): 1 bit - Defined in [RFC3471] - - - Handover (H): 1bit - When set, the H bit indicates that a Handover procedure for the - transfer of LSP ownership between Management and Control Planes is - ongoing. - - - Lockout (L): 1 bit - Defined in [RFC4872] - - - Inhibit Alarm Communication (I): 1 bit - Defined in [RFC4783] - - Call Control (C): 1 bit - Defined in [RFC3471] - - - Testing (T): 1 bit - Defined in [RFC3471] - - - Administratively down (A): 1 bit - Defined in [RFC4974] - - - Deletion in progress (D): 1 bit - Defined in [RFC3471] + IANA) (25). 7.2. Error Spec Object It is possible that a failure, such as the loss of DCN connection or the restart of a node, occurs during the LSP ownership handing over. + In this case the LSP handover procedure is interrupted, the ownership of the LSP must remain with the ownership prior to the initiation of the handover procedure. It is important that the transaction failure does not affect the DP. The LSP is kept in place and no traffic hit occurs. The failure is signaled by PathErr in the upstream direction and PathTear Messages in the downstream direction. The PathErr messages include an ERROR_SPEC Object specifying the causes of the failure. @@ -671,21 +737,21 @@ occurs. The failure is signaled by PathErr in the upstream direction and PathTear Messages in the downstream direction. The PathErr messages include an ERROR_SPEC Object specifying the causes of the failure. This memo introduces a new Error Code (with different Error Values) into the ERROR_SPEC Object, defined in [RFC2205]. The defined Error Code is "Handover Procedure Failure", and its value - is (TBD by IANA)(33). For this Error Code the following Error Values + is (TBD by IANA)(35). For this Error Code the following Error Values are defined: 1 = Cross-connection mismatch 2 = Other failure 8. Compatibility The main requirement for Handover procedure to work is that all nodes along the path MUST support the extension defined in this draft. @@ -699,134 +765,145 @@ We wish to thank Adrian Farrel and Lou Berger for their assistance and precious advices to prepare this draft for publication. We also wish to thank Nicola Ciulli (Nextworks), that contributed to the initial stage of this draft. 10. Contributors Shan Zhu Fujitsu Network Communications Inc. 2801 Telecom Parkway, - Richardson, Texas 75082 - USA + 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 + Francesco Fondelli + Ericsson + Via Negrone 1/A + Genova - 16145 + Email: francesco.fondelli@ericsson.com + Lou Berger LabN Consulting, LLC Phone: +1 301 468 9228 EMail: lberger@labn.net 11. Security Considerations The procedures described in this document rely completely on RSVP-TE messages and mechanism. The use of H bit set in ADMIN_STATUS Object basically informs the receiving entity that no operations are to be done over DP as consequence of such special signaling flow. Using specially flagged signaling messages we want to limit the function of setup and tear down messages to CP, making them not effective over - related DP resource usage. So, no additional or special issues are - arisen by adopting this procedure, that aren't already brought up by - the use of the same messages, without H bit setting, for LSP control. - For RSVP-TE Security please refer to [RFC3473]. + 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], + while for GMPLS security framework please refer to [sec-fwk]. 12. IANA Considerations IANA has been asked to manage the bit allocations for the ADMIN_STATUS Object ([RFC3473]). This document requires the allocation of the Handover bit: the H bit. IANA is requested to allocate a bit for this purpose. +Bit Number Hex Value Name Reference +---------- ----------- ------------------------------------ --------- +25 0x00000040 Handover (H) [This.I-D] + + IANA has also been asked to allocate a new error code: + + 35 Handover failure + + This Error Code has the following globally-defined Error + Value sub-code: + + 1 = Cross-connection mismatch + 2 = Other failure + 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. [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. - [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) - RSVP-TE Signaling Extensions in Support of Calls", - RFC 4974, August 2007. - 13.2. Informational References - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching - (GMPLS) Signaling Functional Description", RFC 3471, - January 2003. - - [RFC4783] Berger, L., "GMPLS - Communication of Alarm Information", - RFC 4783, December 2006. - - [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE - Extensions in Support of End-to-End Generalized Multi- - Protocol Label Switching (GMPLS) Recovery", RFC 4872, - May 2007. - [RFC5493] Caviglia, D., Bramanti, D., Li, D., and D. McDysan, "Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network", RFC 5493, April 2009. + [sec-fwk] Fang, L., "Security Framework for MPLS and GMPLS + Networks", July 2009. + Authors' Addresses Diego Caviglia Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: diego.caviglia@ericsson.com Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: daniele.ceccarelli@ericsson.com Dino Bramanti Ericsson - Via Moruzzi 1 C/O Area Ricerca CNR - Pisa - Italy - - Email: dino.bramanti@ericsson.com Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 P.R.China Email: danli@huawei.com - Snigdho Bardalai Fujitsu Network 2801 Telecom Parkway Richrdson, Texas 75082 USA Email: Snigdho.Bardalai@us.fujitsu.com