Network Working Group J. Dong Internet-Draft M. Chen Intended status: Standards Track Huawei Technologies Expires: April 25, 2013 Z. Li China Mobile October 22, 2012 RSVP-TE Extensions for Lock Instruct and Loopback in MPLS Transport Profile draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-04 Abstract This document specifies extensions to RSVP-TE to support lock instruct and loopback mechanism for MPLS-TP LSPs. The mechanisms are intended to be applicable to other technologies which use GMPLS/ RSVP-TE as control plane. 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 RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 25, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Dong, et al. Expires April 25, 2013 [Page 1] Internet-Draft RSVP-TE Extensions for LI&LB October 2012 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Extensions to RSVP-TE . . . . . . . . . . . . . . . . . . . . . 3 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Dong, et al. Expires April 25, 2013 [Page 2] Internet-Draft RSVP-TE Extensions for LI&LB October 2012 1. Introduction The requirements for Lock Instruct (LI) and Loopback (LB) are specified in [RFC5860], and the framework of LI and LB is specified in [RFC6371]. [RFC6435] defines management plane based Lock Instruct (LI) and Loopback (LB) mechanisms, and an LI OAM message can be used for additional lock coordination between the MEPs. Management plane based LI and LB is suitable for scenarios where dynamic control plane is not available. When a control plane is used for establishing MPLS-TP LSPs, it is natural to use and extend the control plane protocol to implement LI and LB functions. Since LI and LB would modify the forwarding plane of an LSP, without the involvement of control plane this may result in inconsistency of the LSP information between control plane and data plane. Besides, with control plane mechanisms, it does not need to rely on the TTL expiration to make the OAM requests reach particular MIP or MEP. There are some existing control plane based OAM provisioning mechanisms for MPLS-TP. For example, [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] specifies the RSVP-TE extensions for the configuration of proactive OAM functions for MPLS-TP LSPs when control plane is used. This document specifies extensions to RSVP-TE to implement LI and LB functions for MPLS-TP LSPs when MPLS-TP control plane is used. The mechanisms defined in this document are complementary to [RFC6435]. 2. Extensions to RSVP-TE The A (Administratively down) bit in ADMIN_STATUS object [RFC3471] [RFC3473] is used to indicate the lock/unlock of the LSP. Format of ADMIN_STATUS Object is as 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num(196)| C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Reserved |H|L|I|C|T|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dong, et al. Expires April 25, 2013 [Page 3] Internet-Draft RSVP-TE Extensions for LI&LB October 2012 Reflect (R): 1 bit - see [RFC3471] Handover (H): 1 bit - see [RFC5852] Lockout (L): 1 bit - see [RFC4872] Inhibit Alarm Indication (I): 1 bit - see [RFC4783] Call Control (C): 1 bit - see [RFC4974] Testing (T): 1 bit - see [RFC3471] Administratively down (A): 1 bit - see [RFC3471], reused for Lock Deletion in progress (D): 1 bit - see [RFC3471] A new bit is defined in Attribute Flags TLV [RFC5420] to indicate the loopback mode. The bit number is TBA. Bit Number Name and Usage TBA Loopback mode desired. This flag indicates a particular node on the LSP is required to enter loopback mode. This MAY also be used for specifying the loopback state of the node. 3. Operations 3.1. Lock Instruct When a MEP wants to put an LSP into lock mode, it MUST send a Path message with the Administratively down (A) bit and the Reflect (R) bit in ADMIN_STATUS Object set. The intermediate nodes SHOULD forward the message with the A bit unchanged to the downstream . On receipt of this Path message, the receiving MEP node SHOULD try to take the LSP out of service. If the receiving MEP locks the LSP successfully, it SHOULD send a Resv message with the A bit in ADMIN_STATUS object set. Otherwise, it SHOULD send a PathErr message with the Error Code "OAM Problem" and the new Error Value "Lock Failure", and the following Resv message SHOULD be sent with the A bit cleared. During this procedure, the intermediate nodes would be aware of whether the LSP is in Lock mode or not. When an LSP is put in lock mode, the subsequent Path and Resv messages SHOULD keep the A bit in ADMIN_STATUS Object set. When a MEP wants to take the LSP out of the lock mode, it MUST send a Path message with the A bit in ADMIN_STATUS Object cleared. The intermediate nodes SHOULD forward this message with the A bit unchanged to the downstream. On receipt of this Path message, the receiving MEP node SHOULD try to bring the LSP back to service. If the receiving MEP unlocks the LSP Dong, et al. Expires April 25, 2013 [Page 4] Internet-Draft RSVP-TE Extensions for LI&LB October 2012 successfully, it SHOULD send a Resv message with the A bit in ADMIN_STATUS Object cleared. Otherwise, it SHOULD send a PathErr message with the Error Code "OAM Problem" and the new Error Value "Unlock Failure", and the following Resv message SHOULD be sent with the A bit set. When an LSP is taken out of lock mode, the subsequent Path and Resv messages SHOULD keep the A bit in ADMIN_STATUS Object cleared. 3.2. Loopback The loopback request can be sent either to the remote MEP or to a particular MIP node. The mechanism defined in [I-D.margaria-ccamp-lsp-attribute-ero] is used for addressing the loopback request to a particular node on the LSP. The loopback request is acceptable only when the LSP is in lock mode. When a MEP wants to put a particular LSR on the LSP into loopback mode, it MUST send a Path message with the Loopback bit in the Attribute Flags TLV set. The mechansim defined in [I-D.margaria-ccamp-lsp-attribute-ero] is used to address the loopback request to the particular LSR. The Administratively down (A) bit in ADMIN_STATUS object SHOLUD be set to keep the LSP in lock mode. On receipt of this Path message, the target LSR of the loopback request SHOULD try to put the LSP into loopback mode. If the node puts the LSP into loopback mode successfully, it SHOULD set the the Loopback (B) Bit in the RRO Attribute subobject [RFC5420] and push this subobject onto the RRO object in the corresponding Resv message. The Administratively down (A) bit in ADMIN_STATUS object SHOULD be set in the Resv message. If the node cannot put the LSP into loopback mode, it SHOULD send a PathErr message with the Error Code "OAM Problem" and the new Error Value "Loopback Failure". When a MEP wants to take the LSP out of loopback mode, it MUST send a Path message with the Loopback bit in the Attribute Flags TLV cleared. The mechansim defined in [I-D.margaria-ccamp-lsp-attribute-ero] is used to indicate that the particular LSR SHOULD exit loopback mode for this LSP. The Administratively down (A) bit in ADMIN_STATUS object SHOULD be set. On receipt of this Path message, the target node SHOULD try to take the LSP out of loopback mode. If the node takes the LSP out of loopback mode successfully, it SHOULD clear the the Loopback (B) Bit in the RRO Attribute subobject and push this subobject onto the RRO object in the corresponding Resv message. The Administratively down (A) Bit in ADMIN_STATUS Object SHOULD be set. Otherwise, the node Dong, et al. Expires April 25, 2013 [Page 5] Internet-Draft RSVP-TE Extensions for LI&LB October 2012 SHOULD send a PathErr message with the Error Code "OAM Problem" and the new Error Value "Exit Loopback Failure". 4. IANA Considerations One bit number Loopback needs to be assigned in the Attribute Flags registry. Four new Error Values need to be allocated for Error Code "OAM Problem": "Lock Failure", "Unlock Failure", "Loopback Failure", "Exit Loopback Failure". 5. Security Considerations This document does not introduce any new security issues above those identified in [RFC3209] and [RFC3473]. 6. Acknowledgements The authors would like to thank Greg Mirsky, Lou Berger and Francesco Fondelli for their comments and suggestions. 7. References 7.1. Normative References [I-D.ietf-ccamp-oam-configuration-fwk] Takacs, A., Fedyk, D., and H. Jia, "GMPLS RSVP-TE extensions for OAM Configuration", draft-ietf-ccamp-oam-configuration-fwk-08 (work in progress), July 2012. [I-D.margaria-ccamp-lsp-attribute-ero] Margaria, C., Schroetter, D., Martinelli, G., Balls, S., and B. Wright, "LSP Attribute in ERO", draft-margaria-ccamp-lsp-attribute-ero-01 (work in progress), July 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. Dong, et al. Expires April 25, 2013 [Page 6] Internet-Draft RSVP-TE Extensions for LI&LB October 2012 [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. [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009. [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010. [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011. 7.2. Informative References [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] Bellagamba, E., Andersson, L., Skoldstrom, P., Ward, D., and A. Takacs, "Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS- based Transport Networks using RSVP-TE", draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-10 (work in progress), October 2012. [RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., and X. Dai, "MPLS Transport Profile Lock Instruct and Loopback Functions", RFC 6435, November 2011. Dong, et al. Expires April 25, 2013 [Page 7] Internet-Draft RSVP-TE Extensions for LI&LB October 2012 Authors' Addresses Jie Dong Huawei Technologies Huawei Building, No.156 Beiqing Rd. Beijing 100095 China Email: jie.dong@huawei.com Mach Chen Huawei Technologies Huawei Building, No.156 Beiqing Rd. Beijing 100095 China Email: mach.chen@huawei.com Zhenqiang Li China Mobile Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave. Beijing 100053 China Email: lizhenqiang@chinamobile.com Dong, et al. Expires April 25, 2013 [Page 8]