Network Working Group A. Takacs Internet-Draft B. Tremblay Intended status: Standards Track Ericsson Expires: January 14, 2009 July 13, 2008 GMPLS RSVP-TE recovery extension for data plane initiated reversion draft-takacs-ccamp-revertive-ps-01 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 14, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Takacs & Tremblay Expires January 14, 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 two new fields to specify a wait-to- restore and hold-off intervals. Takacs & Tremblay Expires January 14, 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 . . . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Takacs & Tremblay Expires January 14, 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. Takacs & Tremblay Expires January 14, 2009 [Page 4] Internet-Draft GMPLS revertive protection signalling July 2008 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. Although WTR intervals may be pre- configured, it may be beneficial to signal the desired WTR value as well. There is another timer not yet supported by RSVP-TE recovery extensions. The Hold-off (HOFF) time is applied to protection switching to allow lower layer mechanisms to recover from the failure before switching to the protection path. Adding the HOFF timer may be also considered when extending RSVP-TE recovery signalling. Applying different HOFF intervals to LSPs is motivated when the protection capability of the underlying layer varies from LSP to LSP. Further, the GMPLS extensions for multi-layer/multi-region networks may also reveal the need for more flexible configuration of protection switching timers. Takacs & Tremblay Expires January 14, 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. Next we discuss how new fields for HOFF timer and revertive protection with WTR timer can be introduced. Often hold-off and WTR intervals are pre-configured in network elements and the same default value is used for all the LSPs. In this case, there is no need to signal these parameters, only a new bit (V) needs to be added to the PROTECTION object to signal that revertive protection is requested. The PROTECTION object defined in [RFC4872] and amended in [RFC4873] is depicted bellow with the proposed placement of the new V bit. 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 | Link Flags| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|R| Reserved | Seg.Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1) First alternative with a new revertive protection bit. V - Revertive bit, when set the protection is to be revertive, and if supported the data plane should be configured to autonomously execute reversion. Alternatively, when instead of a default value the WTR time is to be set independently for each LSP, a new field needs to be defined. A default WTR value can be used to signal that no reversion is desired. Hence, no new bit is needed to select revertive protection. This alternative is 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|Res| WTR | LSP Flags | Reserved | Link Flags| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|R| Reserved | Seg.Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2) Second alternative with new WTR field. WTR - Wait to Restore, it specifies the WTR delay before reversion. Takacs & Tremblay Expires January 14, 2009 [Page 6] Internet-Draft GMPLS revertive protection signalling July 2008 In the general case, if both WTR and HOFF intervals should be set independently for each LSP, two new fields need to be defined. To fit the size of the two fields the last 16 bits of the PROTECTION object needs to be utilised. This is 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| Reserved | LSP Flags | Reserved | Link Flags| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|R| Reserved | Seg.Flags | Resv. | WTR | HOFF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3) Third alternative with new WTR and HOFF fields. WTR - Wait to Restore, it specifies the WTR delay before reversion. HOFF - Hold-off, it specifies the HOFF delay before switching to the protection path. Takacs & Tremblay Expires January 14, 2009 [Page 7] Internet-Draft GMPLS revertive protection signalling July 2008 3. IANA Considerations TBD. Takacs & Tremblay Expires January 14, 2009 [Page 8] 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 14, 2009 [Page 9] Internet-Draft GMPLS revertive protection signalling July 2008 5. Acknowledgements The authors would like to thank Francesco Fondelli. Takacs & Tremblay Expires January 14, 2009 [Page 10] Internet-Draft GMPLS revertive protection signalling July 2008 6. 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 14, 2009 [Page 11] 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 14, 2009 [Page 12] 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 14, 2009 [Page 13]