Network Working Group A. Takacs Internet-Draft B. Tremblay Intended status: Standards Track Ericsson Expires: January 8, 2009 July 7, 2008 GMPLS RSVP-TE recovery extension for data plane initiated reversion draft-takacs-ccamp-revertive-ps-00 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 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 8, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Takacs & Tremblay Expires January 8, 2009 [Page 1] Internet-Draft GMPLS revertive protection signalling July 2008 Abstract RSVP-TE recovery extensions are specified in [RFC4872] and [RFC4873]. Currently these extensions cannot signal request for revertive protection to the remote endpoint. This document defines a new bit to signal this request and a new field to specify a wait-to-restore interval. Takacs & Tremblay Expires January 8, 2009 [Page 2] Internet-Draft GMPLS revertive protection signalling July 2008 Requirements Language 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 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. PROTECTION object extension . . . . . . . . . . . . . . . . . 6 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Takacs & Tremblay Expires January 8, 2009 [Page 3] Internet-Draft GMPLS revertive protection signalling July 2008 1. Introduction Reversion refers to the process of moving normal traffic back to the original working LSP after the failure is cleared and the path is repaired [RFC4426][RFC4427][RFC4872]. Reversion is desirable since the protection path may not be optimal from a routing and resource consumption point of view, additionally, moving traffic back to the working LSP allows the protection resources to be used to protect other LSPs. On the other hand, reversion requires that the working resources remain allocated during failure. The operator needs to have the choice between revertive and non-revertive protection to balance the pros and cons in a given situation. [RFC4426] and [RFC4872] describes control plane signalling procedures for reversion. This signaling can be used to initiate the actual reversion in the data plane; or simply to synchronise control plane states after data plane actions. This latter case, when independently from the control plane, data plane mechanisms autonomously initiate reversion is not detailed further in the documents. [RFC4426] and [RFC4872] assumed that signalling the revertive property of protection is not needed between protection endpoints. This assumption holds for uni- and bidirectional LSPs in the following cases. o The control plane is responsible to execute reversion and trigger data plane switch-over. o In the case of data plane initiated reversion there is a dedicated protocol for protection switching (e.g., Automatic Protection Switching (APS)) synchronising the switch-over of the data plane endpoints. In these cases, only one side: the ingress LER needs to be provided with information about the revertive property of protection. Hence, there is no need to signal any information in RSVP-TE to the remote endpoint. However, GMPLS may be applied in a scenario where the data plane autonomously executes reversion but it has no mechanism to communicate the revertive property of protection between the endpoints. Such an example is protection switching of bidirectional connections in Ethernet PBB-TE [IEEE-PBBTE] (currently under standardisation in IEEE). In this case revertiveness needs to be signalled by RSVP-TE during LSP establishment to properly setup the remote data plane endpoint. Further, although wait-to-restore (WTR) intervals may be pre-configured, it may be beneficial to signal the Takacs & Tremblay Expires January 8, 2009 [Page 4] Internet-Draft GMPLS revertive protection signalling July 2008 desired WTR value as well. Takacs & Tremblay Expires January 8, 2009 [Page 5] Internet-Draft GMPLS revertive protection signalling July 2008 2. PROTECTION object extension In [RFC4872] and [RFC4873] the PROTECTION object is specified to support end-to-end and segment recovery. This document introduces a new bit: "V" Revertive; to signal that the protection requested is to be revertive. The "V" bit can only be set if the "N" Notification is set as well. Once the data plane autonomously initiated reversion, it notifies the control plane which then can invoke the signalling specified in [RFC4872] to syncronise control plane LSP states to reflect the actual path taken by normal traffic. In order that traffic is not switched back and fort between worker and protection LSPs during transients, a wait to restore (WTR) timer is usually applied delaying the reversion until the recovered path is considered stable again. To support autonomous data plane recovery, the wait to restore time can be signalled in the new WTR field. The WTR field defines the wait to restore delay in minutes. The additions to the PROTECTION object are depicted below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|P|N|O|V| Reserved| LSP Flags | Reserved | WTR | Link Flags| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V - Revertive bit, when set the protection is to be revertive, and if supported the data plane should be configured to autonomously execute reversion. WTR - Wait to Restore, it specifies the WTR delay before reversion in minutes. Takacs & Tremblay Expires January 8, 2009 [Page 6] Internet-Draft GMPLS revertive protection signalling July 2008 3. IANA Considerations This document specifies a new bit "V" and a new field "WTR" to be carried in the PROTECTION object. Takacs & Tremblay Expires January 8, 2009 [Page 7] Internet-Draft GMPLS revertive protection signalling July 2008 4. Security Considerations This document introduces no new security issues. The considerations in [RFC4872] and [RFC4873] apply. Takacs & Tremblay Expires January 8, 2009 [Page 8] Internet-Draft GMPLS revertive protection signalling July 2008 5. References [IEEE-PBBTE] "IEEE 802.1Qay Draft Standard for Provider Backbone Bridging Traffic Engineering", work in progress. [RFC4426] "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, March 2006. [RFC4427] "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006. [RFC4872] "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007. [RFC4873] "GMPLS Segment Recovery", RFC 4873, May 2007. Takacs & Tremblay Expires January 8, 2009 [Page 9] Internet-Draft GMPLS revertive protection signalling July 2008 Authors' Addresses Attila Takacs Ericsson Laborc u. 1. Budapest, 1037 Hungary Email: attila.takacs@ericsson.com Benoit Tremblay Ericsson 8400 Decarie. Montreal, Quebec H4P 2N2 Canada Email: benoit.c.tremblay@ericsson.com Takacs & Tremblay Expires January 8, 2009 [Page 10] Internet-Draft GMPLS revertive protection signalling July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Takacs & Tremblay Expires January 8, 2009 [Page 11]