--- 1/draft-ietf-ccamp-pc-spc-rsvpte-ext-01.txt 2008-10-31 12:12:03.000000000 +0100 +++ 2/draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt 2008-10-31 12:12:03.000000000 +0100 @@ -1,25 +1,26 @@ CCAMP Working Group D. Caviglia -Internet-Draft D. Bramanti -Expires: January 16, 2009 Ericsson +Internet-Draft D. Ceccarelli +Expires: May 1, 2009 D. Bramanti + Ericsson D. Li Huawei Technologies Co., LTD. S. Bardalai Fujitsu Network Communications Inc - July 15, 2008 + October 28, 2008 RSVP-TE Signaling Extension For The Conversion Between Permanent Connections And Soft Permanent Connections In A GMPLS Enabled Transport Network. - draft-ietf-ccamp-pc-spc-rsvpte-ext-01.txt + draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -30,21 +31,21 @@ 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 January 16, 2009. + This Internet-Draft will expire on May 1, 2009. Abstract We would like to dedicate this work to our friend and colleague Dino Bramanti, who passed away at the early age of 38. Dino has been involved in this work since its beginning. In a transport network scenario, where Data Plane connections controlled either by GMPLS Control Plane (Soft Permanent Connections - SPC) or by Management System (Permanent Connections - PC) may @@ -81,39 +82,39 @@ 9. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 16 10. Objects Modification . . . . . . . . . . . . . . . . . . . . . 17 10.1. Administrative Status Object . . . . . . . . . . . . . . . 17 10.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 18 11. Acknoledgments . . . . . . . . . . . . . . . . . . . . . . . . 19 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. Security Considerations . . . . . . . . . . . . . . . . . . . 20 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 15.1. Normative References . . . . . . . . . . . . . . . . . . . 20 - 15.2. Informational References . . . . . . . . . . . . 20 + 15.2. Informational References . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 23 1. Introduction In a typical traditional transport network scenario, Data Plane 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 over networks that are already in service - controlled by NMS at Management Plane level - introduces the need for a procedure able to coordinate a control handover of a generic data plane connection from MP to CP. In addition, the control handover in the opposite direction, from CP - to MP should be possible as well. The procedures described in this + to MP SHOULD be possible as well. The procedures described in this memo can be applied to any kind of LSP and network architecture. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Motivation @@ -292,120 +293,126 @@ Moreover, each failure can be due to two different causes: Data Plane failure or Communication Failure. A section for each combination will be analyzed in the following. 5.2.1. MP to CP Handover Failure - Path Failure 5.2.1.1. MP to CP Handover Failure - Path Message and Data Plane Failure The handover procedure can fail due to different causes, but in any - case the network status but be immediately rollbacked to the one + case the network status MUST be immediately rollbacked to the one previous to the handover procedure. The failure can happen during the Path message or the Resv message forwarding. In this paragraph we will analyze the first case. | Path | | | |---------------------->| Path | | | |----------------------X| | | | | | | Path Err | | | |<----------------------| | | | | | | Ingress LER LSR A LSR B Egress LER If an error occurs in an LSR or a LER, the last node that has received the Path message MUST send a Path Error message in the upstream direction including an Error_Spec object and the Handover - flag set. The upstream nodes MAY process the Error_Spec object. + flag set. The Path Error message SHOULD have the Path_State_Removed + flag set and the upstream nodes MAY process the Error_Spec object. 5.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 the unreachability of a node of the LSP. The below scenario postulates the usage of a reliable message - delivery based on the mechanism defined in [RFC2961] + delivery based on the mechanism defined in [RFC2961]. + | Path | | | |---------------------->| Path | | | |------------X | | | |------------X | | | | ... | | | |------------X | | | | | | | Path Err | | | |<----------------------| | | | | | | Ingress LER LSR A LSR B Egress LER The Path message sent from LSR A towards LSR B is lost or does not reach the destination for any reason. A reliable delivery mechanism is implemented, LSR A retransmits the Path Message for a configurable - number of times, then, if no ack is received, a Path Error message is - sent back to the ingress LER and the adoption procedure aborted. + number of times, then, if no ack is received, a Path Error message + MUST be sent back to the ingress LER, the Path_State_Removed flag + SHOULD be set and the adoption procedure is aborted. 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 | | | |---------------------->| | | | | | | Ingress LER LSR A LSR B Egress LER If the Resv Message is not received by the expiration of a timer set by the ingress LER, the adoption procedure is again aborted and a PathTear message MAY be sent in the downstream direction with the H - bit set + bit set. 5.2.2. MP to CP Handover Failure - Resv Error 5.2.2.1. MP to CP Handover Failure - Resv Error and Data Plane failure In case a failure occurs during the Resv Message forwarding, things are quite different, because after the handover procedure an LSR is not able to distinguish an LSP created by the Control Plane from an LSP created by the Management Plane and then moved to the Control Plane. | Path | Path | Path | |---------------------->|---------------------->|---------------------->| | | | Resv | | | Resv |<----------------------| | |X----------------------| | -| Path Err | Resv Err | | -|<----------------------|---------------------->| Resv Err | +| Path Err | Path Tear | | +|<----------------------|---------------------->| Path Tear | | | |---------------------->| | | | | Ingress LER LSR A LSR B Egress LER In the case shown in the above picture, the failure occurs in LSR A. - A Resv Error message is sent in the downstream direction and a Path - Error message is sent in the upstream direction. + Considering to have a reliable message delivery mechanism, a Path + Tear message MUST be sent in the downstream direction and a Path + Error message MUST sent in the upstream direction and the + Path_State_Removed SHOULD flag should be set. The Path Err and Path + Tear messages remove the Path state established by the Path messages + along the nodes of the LSP and abort the adoption procedure. Please note that the failure occurred after the handover procedure was successfully completed in LSR B. This means that LSR B is no longer able to know if the LSP was created by the Control Plane or a handover procedure took place. - Upon receiving a Resv Error message, LSR B would delete the LSP also + Upon receiving a Path Tear message, LSR B would delete the LSP also from the Data Plane point of view. To prevent this from happening, - LSR A MUST include an Error_Spec object into the Resv Error message - setting the handover flag. The downstream nodes MUST process the - Error Spec object, move the LSP ownership back to the Management - Plane and MUST NOT modify the Data Plane. + LSR A MUST set the handover flag in the Path Tear message. The + downstream node move the LSP ownership back to the Management Plane + and MUST NOT modify the Data Plane. 5.2.2.2. MP to CP Handover Failure - Resv Error and Communication failure In case a Resv Message cannot reach one or more of the downstream 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 @@ -406,52 +413,51 @@ In case a Resv Message cannot reach one or more of the downstream 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 an LSR, say LSR A. + LSR B, after sending the Resv message again for a configurable number - of times, sends a Resv Error message in the downstream direction - towards the Egress LER and a Path Error message in the upstream - direction towards the Ingress LER in order to inform the nodes of the - path that the adoption procedure has failed and that the LSP - ownership is to be moved back to the management plane. + of times, MUST send a Path Tear message in the downstream direction + towards the Egress LER and a Path Error message (with the + Path_State_Removed flag set) in the upstream direction towards the + Ingress LER in order to inform the nodes of the path that the + adoption procedure has failed and that the LSP ownership is to be + moved back to the management plane. | Path | Path | Path | |---------------------->|---------------------->|---------------------->| | | | Resv | | | Resv |<----------------------| | | X-----------| | | | X-----------| | | | ... | | | | X-----------| | | | | | -| Path Err | Path Err | Resv Err | +| Path Err | Path Err | Path Tear | |<----------------------|<----------------------|---------------------->| | | | | Ingress LER LSR A LSR B Egress LER Please note that the failure occurred after the handover procedure was successfully completed in the Egress LER. This means that it is no longer able to know if the LSP was created by the Control Plane or a handover procedure took place. - Upon receiving a Resv Error message, the downstream nodes would - delete the LSP also from the Data Plane point of view. To prevent - this from happening, LSR B MUST include an Error_Spec object into the - Resv Error message setting the Handover flag. The downstream nodes - MUST process the Error Spec object, move the LSP ownership back to - the Management Plane and MUST NOT modify the Data Plane. + Upon receiving a Path Tear message, the downstream nodes would delete + the LSP also from the Data Plane point of view. To prevent this from + happening, the Path Tear message MUST include the Handover flag. Considering that the Resv message did not manage to reach LSR A, it is highly probable that the Path Error would fail too. Due to this fact, a configurable timer MUST be set on the Ingress LER after sending the path and on LSR A after forwanding it. When the timer expires, if no Resv or Path Error message is received, the handover procedure MUST be aborted and the LSP ownership returned to the Management Plane. The following picture, on the other hand, shows the scenario in which @@ -785,24 +791,29 @@ the Path message. This will assures that the Resv message will maintain the H flag set. 10.2. Error Spec Object It is possible that a failure, such as the lost of DCN connection or the restart of a node, occurs during the LSP ownership handing over. In this case the LSP adoption MUST be interrupted and the ownership of the LSP MUST be moved back to the Plane it belonged to. It is important that the transaction failure MUST not affect the Data - Plane. The LSP MUST be kept in place and no traffic hint MUST occur. + Plane. The LSP MUST be kept in place and no traffic hit MUST occur. - The failure is signaled by Path and Resv Error Messages, which - include an Error_Spec_Object specifying the causes of the failure. + The failure is signaled by Path Error in the upstream direction and + Path Tear Messages in the downstream direction. The Path Error + messages include an Error_Spec_Object (the Path_State_Removed flag + SHOUL always be set) specifying the causes of the failure, while the + Path Tear messages, required in case of reliable recovery and + optional otherwise, include the handover flag to prevent the deletion + of the LSP from the Data Plane. This memo introduces a new Flag and a new Error Code(with different Error Values) into the Error_Spec Object, defined in [RFC2205]. * ERROR_SPEC class = 6. * IPv4 ERROR_SPEC object: Class = 6, C-Type = 1 +-------------+-------------+-------------+-------------+ | IPv4 Error Node Address (4 bytes) | +-------------+-------------+-------------+-------------+ @@ -823,34 +834,38 @@ * 0x01 = InPlace * 0x02 = NotGuilty Proposed new value (TBD) = HandOverFailure The new flag is "Handover Procedure Failure" and the actual value is (TBD by IANA). When this flag is set during an handover from Management Plane to Control Plane, the receiver must delete the Control Plane status associated with the LSP and move the ownership - of the cross-connections back to the Management Plane. The proposed - Error Code is "Handover Procedure Failure", and its value is (TBD by - IANA)(33). For this Error Code the following Error Values are - defined: 1 = Cross-connection mismatch 2 = DCN error + of the cross-connections back to the Management Plane. + + The proposed Error Code is "Handover Procedure Failure", and its + value is (TBD by IANA)(33). For this Error Code the following Error + Values are defined: + + 1 = Cross-connection mismatch + + 2 = DCN error 11. Acknoledgments We wish to thank Adrian Farrel for his editorial assistance and precious advices to prepare this draft for publication. We also wish to thank Nicola Ciulli, that contributed to initial stage of this draft. 12. Contributors - Shan Zhu Fujitsu Network Communications Inc. 2801 Telecom Parkway, Richardson, Texas 75082 USA Email: Shan.Zhu@us.fujitsu.com Tel: +1-972-479-2041 Igor Bryskin ADVA Optical Networking Inc @@ -852,27 +867,20 @@ Email: Shan.Zhu@us.fujitsu.com Tel: +1-972-479-2041 Igor Bryskin ADVA Optical Networking Inc 7926 Jones Branch Drive Suite 615 McLean, VA - 22102 Email: ibryskin@advaoptical.com - Daniele Ceccarelli - Ericsson - Via A. Negrone 1/A - Genova-Sestri Ponente, Italy - Phone: +390106002515 - Email: daniele.ceccarelli@ericsson.com - 13. Security Considerations The procedures described in this document rely completely on RSVP-TE messages and mechanism. The use of Handover Flag set in Admin Status Object basically informs the receiving entity that no operations are to be done over Data Plane as consequence of such special signaling flow. Using specially flagged signaling messages we want to limit the function of setup and tear down messages to Control Plane, making them not effective over related Data Plane resource usage. So, no additional or special issues are arisen by adopting this procedure, @@ -896,21 +904,21 @@ Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001. -15.2. Informational References +15.2. Informational References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, August 2006. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching @@ -934,28 +942,36 @@ Authors' Addresses Diego Caviglia Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: diego.caviglia@ericsson.com + Daniele Ceccarelli + Ericsson + Via A. Negrone 1/A + Genova - Sestri Ponente + Italy + + Email: daniele.ceccarelli@ericsson.com Dino Bramanti Ericsson Via Moruzzi 1 C/O Area Ricerca CNR Pisa Italy Email: dino.bramanti@ericsson.com + Dan Li Huawei Technologies Co., LTD. Shenzhen 518129 Huawei Base, Bantian, Longgang Italy Email: dan.li@huawei.com Snigdho Bardalai Fujitsu Network Communications Inc