Network Working Group J. Dong Internet-Draft M. Chen Intended status: Standards Track Huawei Technologies Expires: August 30, 2015 Z. Li China Mobile D. Ceccarelli Ericsson February 26, 2015 GMPLS RSVP-TE Extensions for Lock Instruct and Loopback draft-ietf-teas-rsvp-te-li-lb-04 Abstract This document specifies extensions to Resource Reservation Protocol- Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies which use Generalized Multi-Protocol Label Switching (GMPLS) for the 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 August 30, 2015. Dong, et al. Expires August 30, 2015 [Page 1] Internet-Draft RSVP-TE Extensions for LI&LB February 2015 Copyright Notice Copyright (c) 2015 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Flag Definitions for LI and LB . . . . . . . . . . . . . . . 3 2.1. Lock Instruct Indication . . . . . . . . . . . . . . . . 3 2.2. Extensions for Loopback . . . . . . . . . . . . . . . . . 3 3. Operational Procedures . . . . . . . . . . . . . . . . . . . 4 3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4.1. Attribute Flags . . . . . . . . . . . . . . . . . . . . . 6 4.2. RSVP Error Value Sub-codes . . . . . . . . . . . . . . . 6 4.3. Allocation Rule for ERO Subobjects . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The requirements for Lock Instruct (LI) and Loopback (LB) in the Multiprotocol Label Switching Transport Profile (MPLS-TP) are specified in [RFC5860], and the framework of LI and LB is specified in [RFC6371]. An LSP that is locked, using LI, is prevented from carrying user data traffic. The LB function can only be applied to an LSP that has been previously locked. In general the LI and LB are useful Operations, Administration and Maintenance (OAM) functions for technologies which use Generalized Multi-Protocol Label Switching (GMPLS) for the control plane, e.g., time-division multiplexing, wavelength-division multiplexing and Dong, et al. Expires August 30, 2015 [Page 2] Internet-Draft RSVP-TE Extensions for LI&LB February 2015 packet switching. It is natural to use and extend the GMPLS control plane protocol to provide a unified approach for LI and LB provisioning in all these technologies. [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] specifies the RSVP-TE extensions for the configuration of pro-active MPLS-TP OAM functions, such as Continuity Check (CC), Connectivity Verification (CV), Delay Measurement (DM) and Loss Measurement (LM). The provisioning of on- demand OAM functions such as LI and LB are not covered in that document. This document specifies extensions to Resource Reservation Protocol- Traffic Engineering (RSVP-TE) to support lock instruct and loopback mechanisms for Label Switched Paths (LSPs). The mechanisms are applicable to technologies which use GMPLS for the control plane. For a network supporting MPLS-TP, the mechanisms defined in this document are complementary to [RFC6435]. 2. Flag Definitions for LI and LB 2.1. Lock Instruct Indication In order to indicate the lock/unlock status of the LSP, the A (Administratively down) bit in the Administrative Status (ADMIN_STATUS) object [RFC3471] [RFC3473] is used. 2.2. Extensions for Loopback In order to indicate the loopback mode of LSP, a new bit flag is defined in the Attribute Flags TLV [RFC5420]. Loopback flag: This flag indicates a particular node on the LSP is required to enter loopback mode. This can also be used for specifying the loopback state of the node. - Bit number: TBA-1 - Attribute flag carried in Path message: Yes - Attribute flag carried in Resv message: No - Attribute flag carried in RRO Attributes subobject: Yes Dong, et al. Expires August 30, 2015 [Page 3] Internet-Draft RSVP-TE Extensions for LI&LB February 2015 3. Operational Procedures 3.1. Lock Instruct When an ingress node intends to put an LSP into lock mode, it MUST send a Path message with the Administratively down (A) bit used as specified above and the Reflect (R) bit in the ADMIN_STATUS Object set. On receipt of this Path message, the egress node SHOULD try to take the LSP out of service. If the egress node locks the LSP successfully, it MUST send a Resv message with the A bit in the ADMIN_STATUS object set. Otherwise, it MUST send a PathErr message with the Error Code "OAM Problem" [RFC7260] and the new Error Value "Lock Failure", and the following Resv messages MUST be sent with the A bit cleared. When an LSP is put in lock mode, the subsequent Path and Resv messages MUST keep the A bit in the ADMIN_STATUS Object set. When the ingress node intends to take the LSP out of the lock mode, it MUST send a Path message with the A bit in the ADMIN_STATUS Object cleared. On receipt of this Path message, the egress node SHOULD try to bring the LSP back to service. If the egress node unlocks the LSP successfully, it MUST send a Resv message with the A bit in the ADMIN_STATUS Object cleared. Otherwise, it MUST send a PathErr message with the Error Code "OAM Problem" [RFC7260] and the new Error Value "Unlock Failure", and the following Resv messages MUST be sent with the A bit set. When an LSP is taken out of lock mode, the subsequent Path and Resv messages MUST keep the A bit in the ADMIN_STATUS Object cleared. 3.2. Loopback The loopback request can be sent either to the egress node or to a particular intermediate node. The mechanism defined in [I-D.ietf-teas-lsp-attribute-ro] is used for addressing the loopback request to a particular node on the LSP. The ingress node MUST ensure that the LSP is in lock mode before it requests setting a particular node on the LSP into loopback mode. When a ingress node intends to put a particular node on the LSP into loopback mode, it MUST send a Path message with the Loopback Attribute Flag defined above in the Attribute Flags TLV set. The mechanism defined in [I-D.ietf-teas-lsp-attribute-ro] is used to Dong, et al. Expires August 30, 2015 [Page 4] Internet-Draft RSVP-TE Extensions for LI&LB February 2015 address the loopback request to the particular node. The ingress node MUST ensure that the entity (node or interface), at which loopback is intended to occur, is marked as a strict hop in the Explicit Route Object (ERO) subobject. The Administratively down (A) bit in the ADMIN_STATUS object MUST be kept set to indicate that the LSP is still in lock mode. On receipt of this Path message, the target node of the loopback request MUST check if the LSP is in lock mode by verifying that the Administratively down (A) bit is set in the ADMIN_STATUS object. If the bit is not set, the loopback request MUST be ignored. If the bit is set, the node MUST check that the desired loopback entity is strictly identified by verifying that the L bit is set to 0 in the ERO subobject prior to the ERO Hop Attributes subobject. The prior subobject MUST also be checked to ensure that it provides strict identification. Currently, the type value MUST be verified to be less than 32, and for type values 1 and 2, the prefix length MUST be 32 and 128 respectively. If the desired loopback entity is not strictly identified, the request MUST be ignored and a "Bad EXPLICIT_ROUTE object" error SHOULD be generated. Otherwise, the node SHOULD try to put the LSP into loopback mode. If the node puts the LSP into loopback mode successfully, it MUST set the Loopback Attribute Flag if it adds, per [I-D.ietf-teas-lsp-attribute-ro], an RRO Hop Attributes subobject to the RECORD_ROUTE Object (RRO) of a Path or Resv message. The Administratively down (A) bit in the ADMIN_STATUS object MUST be kept set in the message. If the node cannot put the LSP into loopback mode, it MUST send a PathErr message with the Error Code "OAM Problem" [RFC7260] and the new Error Value "Loopback Failure". When the ingress node intends to take the particular node out of loopback mode, it MUST send a Path message with the Loopback Attribute Flag in the Attribute Flags TLV cleared. The mechanism defined in [I-D.ietf-teas-lsp-attribute-ro] is used to indicate that the particular node SHOULD exit loopback mode for this LSP. The Administratively down (A) bit in the ADMIN_STATUS object MUST be kept set to indicate the LSP is still in lock mode. 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 MUST clear the Loopback Attribute Flag in the RRO Hop Attributes subobject and push this subobject onto the RRO object in the corresponding Path or Resv message. The Administratively down (A) Bit in the ADMIN_STATUS Object MUST be kept set in the message. Otherwise, the node MUST send a PathErr message with the Error Code "OAM Problem" [RFC7260] and the new Error Value "Exit Loopback Failure". Dong, et al. Expires August 30, 2015 [Page 5] Internet-Draft RSVP-TE Extensions for LI&LB February 2015 After the loopback mode is cleared successfully, the ingress node MAY remove the Lock Instruct using the mechanism defined in section 3.1. The ingress node MUST NOT request to exit lock mode if the LSP is still in loopback mode. The egress node MUST ignore such request when the LSP is still in loopback mode. 4. IANA Considerations IANA is requested to administer the assignment of new values defined in this document and summarized in this section. 4.1. Attribute Flags IANA maintains a registry called "Resource Reservation Protocol- Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called "Attribute Flags". IANA is requested to assign a new bit flag as follows: Bit | | Attribute | Attribute | | | No. | Name | Flags Path | Flags Resv | RRO | ERO | Reference -----+-----------+------------+------------+-----+-----+------------- TBA-1| Loopback | Yes | No | Yes | Yes |this document 4.2. RSVP Error Value Sub-codes IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a sub-registry called "Error Codes and Globally-Defined Error Value Sub-Codes". IANA is requested to assign four new Error Value sub-codes for the "OAM Problem" Error Code: Value | Description | Reference -----------+-----------------------------+-------------- TBA-2 | Lock Failure | this document TBA-3 | Unlock Failure | this document TBA-4 | Loopback Failure | this document TBA-5 | Exit Loopback Failure | this document 4.3. Allocation Rule for ERO Subobjects IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a sub-registry called "Class Names, Class Numbers, and Class Types". For Explicit Route Object , the allocation rule for subobject types in the range 5 - 31 (0x05 - 0x1F) needs to be updated as: Dong, et al. Expires August 30, 2015 [Page 6] Internet-Draft RSVP-TE Extensions for LI&LB February 2015 5-31 Unassigned (For explicit resource identification) 5. Security Considerations This document does not introduce any new security issues above those identified in [RFC3209] [RFC3473] and [I-D.ietf-teas-lsp-attribute-ro]. For a more comprehensive discussion of GMPLS security and attack mitigation techniques, please see the Security Framework for MPLS and GMPLS Networks [RFC5920]. In addition, the reporting of the loopback status using the RRO may reveal details about the node that the operator wishes to remain confidential. The privacy considerations as described in section 5, paragraph 3 of [I-D.ietf-teas-lsp-attribute-ro] also apply to this document. 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-teas-lsp-attribute-ro] Margaria, C., Martinelli, G., Balls, S., and B. Wright, "LSP Attribute in ERO", draft-ietf-teas-lsp-attribute- ro-02 (work in progress), February 2015. [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. [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. Dong, et al. Expires August 30, 2015 [Page 7] Internet-Draft RSVP-TE Extensions for LI&LB February 2015 [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. [RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration", RFC 7260, June 2014. 7.2. Informative References [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] Bellagamba, E., Takacs, A., Mirsky, G., Andersson, L., Skoldstrom, P., and D. Ward, "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-16 (work in progress), January 2015. [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011. [RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., and X. Dai, "MPLS Transport Profile Lock Instruct and Loopback Functions", RFC 6435, November 2011. Authors' Addresses Jie Dong Huawei Technologies Huawei Campus, No.156 Beiqing Rd. Beijing 100095 China Email: jie.dong@huawei.com Dong, et al. Expires August 30, 2015 [Page 8] Internet-Draft RSVP-TE Extensions for LI&LB February 2015 Mach(Guoyi) Chen Huawei Technologies Huawei Campus, 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 Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: daniele.ceccarelli@ericsson.com Dong, et al. Expires August 30, 2015 [Page 9]