--- 1/draft-ietf-ccamp-pc-spc-rsvpte-ext-06.txt 2010-02-15 11:10:51.000000000 +0100 +++ 2/draft-ietf-ccamp-pc-spc-rsvpte-ext-07.txt 2010-02-15 11:10:51.000000000 +0100 @@ -1,45 +1,45 @@ CCAMP Working Group D. Caviglia Internet-Draft D. Ceccarelli Intended status: Standards Track D. Bramanti -Expires: July 17, 2010 Ericsson +Expires: August 19, 2010 Ericsson D. Li Huawei Technologies S. Bardalai Fujitsu Network - January 13, 2010 + February 15, 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-06 + draft-ietf-ccamp-pc-spc-rsvpte-ext-07 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. + Data plane connection. 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. @@ -48,102 +48,104 @@ 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 July 17, 2010. + This Internet-Draft will expire on August 19, 2010. 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 BSD License. + described in the Simplified 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 + 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 . . . . . . . 7 4.2.1.1. MP to CP Handover Failure - Path message and Data Plane Failure . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . 11 + Restart . . . . . . . . . . . . . . . . . . . . . 12 4.3. CP to MP handover : LSP Ownership Transfer From 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 + 4.4. CP to MP Handover Procedure Failure . . . . . . . . . . . 15 + 5. Minimum Information for MP to CP Handover . . . . . . . . . . 17 + 6. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 18 + 7. Objects Modification . . . . . . . . . . . . . . . . . . . . . 18 + 7.1. Administrative Status Object . . . . . . . . . . . . . . . 18 + 7.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 18 + 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 19 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 + 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 21 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 + Network Management System (NMS) operating within the 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 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 an LSP in any DP switching technology and any - network architecture. + 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 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. + 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", @@ -169,32 +171,48 @@ 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 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 of - receiving the full Explicit Route Object (ERO) from the MP while the - alternative one is described in Section 5. + 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. - 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. + 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 MP to CP. + + This section (Section 4) describes the general procedures and + protocol extensions for MP to CP handover, and 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. 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. @@ -209,22 +227,22 @@ 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 timer SHOULD be configurable per LSP and have a default value of 30 seconds. - Each LSR that receives a Path message with the H bit set checks to - see whether there is any matching Path state. + 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. - 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.1.1 - 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 @@ -241,32 +259,33 @@ 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. + - 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. + 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 @@ -284,174 +303,180 @@ | Path | | | |--------------->| Path | | | |---------------X| | | | PathErr | | | PathErr |<---------------| | |<---------------| | | | | | | Ingress LER LSR A LSR B Egress LER - MP2CP - Path Msg and DP Failure + Figure 1: 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. 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. + 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 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 and the LSR MUST revert the LSP ownership to the MP. + 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 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| | | | | | Ingress LER LSR A LSR B Egress LER - MP2CP - Path Msg and Communication Failure (reliable delivery) + 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 - MP2CP - Path Msg and Communication Failure (no reliable delivery) + 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.1. Please note that any node that has forwarded a Path + 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 (accordingly 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 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 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 + signaling) the node MUST send a PathErr message [RFC2205] 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---------------| | | PathErr | PathTear | PathTear | |<---------------|--------------->|--------------->| | | | | Ingress LER LSR A LSR B Egress LER - MP2CP - Resv Error and DP Failure + Figure 4: 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 (with + 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 PahTear when it has Path state with the H bit set MUST remove Path + 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. 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 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). + 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 LER LSR A LSR B Egress LER + Ingress + LSR A LSR B Egress LER - MP2CP - Resv Error and Communication Failure (reliable delivery) + 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.1 and the LSP ownership returned to - the Management Plane. + aborted as described in Section 4.2.1.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. + Figure 6, on the other hand, shows the scenario in which no reliable + delivery mechanism is implemented. | Path | Path | Path | |--------------->|--------------->|--------------->| | | | Resv | | | Resv |<---------------| | | X---------| | 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) + Figure 6: 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. 4.2.2.3. MP to CP Handover Failure - Node Graceful Restart In the case of node restart and graceful restart is enabled then one of the following scenarios will happen. Case I - Finite Restart Time @@ -477,21 +502,21 @@ | PathTear | | |-------X Restart Timer | | Expires | | PathErr | PathTear | | X--------|--------------->| | | | | X | | | | | | Ingress LER LSR A LSR B Egress LER - MP2CP - Node graceful restart - Case I + 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 @@ -513,47 +538,57 @@ | | | | X | | | | | | | | Recovery Timer | | | Expires | | PathErr | PathErr | PathTear | |<---------------|<---------------|--------------->| | | | | Ingress LER LSR A LSR B Egress LER - MP2CP - Node graceful restart - Case II + Figure 8: MP2CP - Node graceful restart - Case II Case III - Ingress LER did not abort the handover process. Once LSR A restarts - the ingress LER MUST re-generate the Path message with the H bit set. - When LSR B receives the Path message it MAY generate a PathErr since - the RECOVERY LABEL may not be present. The reason is LSR A may not - have the label. Similarly LSR B and egress LER MUST NOT release the - DP resources since the H bit is set. + 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 re-start 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. | Path | Path | Path | |--------------->|--------------->|--------------->| | | | Resv | | | Resv |<---------------| | X X---------| | | | | | X | | | | | | | Path | Path | | |--------------->|--------------->| | | PathErr | PathErr | PathTear | |<---------------|<---------------|--------------->| | | | | Ingress LER LSR A LSR B Egress LER - MP2CP - Node graceful restart - Case III + 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 @@ -585,66 +620,75 @@ state. In other words, a normal LSP tear down signaling is exchanged between nodes traversed by 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 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. + [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 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 + Figure 10: Case I - Path message and node down + 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 and normal, i.e., pre CP to MP handover, LSP processing continues. - 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 [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 @@ -642,34 +686,36 @@ |--------------->|--------------->|--------------->| | 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 - 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. The full ERO method and the partial/no ERO - one do not exclude each other; both methods are required. + 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 + 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 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 @@ -751,86 +796,52 @@ 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. This requirement translates to an administrative requirement as it is - not enforced at the protocol level. As defined, non-supporting will - simply propagate the H bit without setting local state. This may - result in an impact data traffic during the handover procedure. - -9. Acknowledgments - - 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 - 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 + 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. -11. Security Considerations +9. 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. 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 +10. 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 @@ -827,22 +838,55 @@ 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 +11. Acknowledgments + + We wish to thank Adrian Farrel, Lou Berger, Alan Elder, and Ben + Campbell for their assistance and precious advices to prepare this + draft for publication. We also wish to thank Nicola Ciulli + (Nextworks) who contributed to the initial stage of this draft. + +12. Contributors + + Shan Zhu + Fujitsu Network Communications Inc. + 2801 Telecom Parkway, + Richardson, Texas 75082 USA + Email: Shan.Zhu@us.fujitsu.com + Tel: +1-972-479-2041 + Igor Bryskin + ADVA Optical Networking Inc + 7926 Jones Branch Drive + Suite 615 + McLean, VA - 22102 + Email: ibryskin@advaoptical.com + + 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 + +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.,