Network Working Group J. Dong Internet-Draft X. Wei Intended status: Standards Track Huawei Technologies Expires: July 2, 2015 V. Lopez O. Gonzalez de Dios Telefonica I+D December 29, 2014 RSVP-TE Extensions for Abstract Error Report in Multi-Layer Traffic Engineered Networks draft-dong-teas-inter-layer-abstract-error-report-00 Abstract This document provides extensions to the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) to support the report of abstract error information across the multi-layer network boundary using Generalized Multiprotocol Label Switching (GMPLS) User Network Interface (UNI). Such abstract error information is useful for efficient protection and restoration of multi-layer Label Switched Paths (LSPs), and is helpful in fault localization and diagnostics in the multi-layer networks. 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 July 2, 2015. Dong, et al. Expires July 2, 2015 [Page 1] Internet-Draft GMPLS UNI Abstract Error Report December 2014 Copyright Notice Copyright (c) 2014 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. RSVP-TE Extensions for Abstract Error Report . . . . . . . . 4 3. Operation Procedures . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4.1. IF_ID ERROR_SPEC TLVs . . . . . . . . . . . . . . . . . . 6 4.2. RSVP Error Value Sub-codes . . . . . . . . . . . . . . . 7 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 In multi-layer Traffic Engineered (TE) networks, end-to-end Traffic Engineered (TE) LSPs are established across more than one network layers. If some failure occurs in the network, according to the type and location of the failure, different recovery mechanisms could be used to provide efficient inter-layer protection and restoration for the end-to-end TE LSPs. Such error information is also helpful for fault localization, diagnostics and troubleshooting in the multi- layer networks. However, in the multi-layer networks, the exchange of detailed error information across the layer boundary should be avoided due to concerns about confidentiality, scalability and stability. This document defines RSVP-TE extensions for the abstract error information report for inter-layer TE LSPs, which can meet the requirement of efficient protection and fault localization, and the constraints of information exchange across the network boundaries are not violated . Dong, et al. Expires July 2, 2015 [Page 2] Internet-Draft GMPLS UNI Abstract Error Report December 2014 In multi-layer TE networks, several protection mechanisms could be deployed to protect the end-to-end inter-layer LSPs, such as local protection in the server layer, end-to-end protection/restoration in server layer, and end-to-end protection/restoration initiated in the client layer. In order to achieve efficient multi-layer protection and save network resources, appropriate protection mechanism should be invoked according to the type and location of the failure. Client Client Network +----------------------------------+ Network +---------+ | | +---------+ | +----+ | | +-----+ +-----+ +-----+ | | +----+ | | | | | | | | | | | | |UNI-1| | | | | -+ EN1+-+-----+--+ CN1 +----+ CN3 +----+ CN4 +---+-----+-+ EN3+- | | | | | +--+--| | | | | |---+-----+-| | | | +----+ | | | +--+--+ +--+--+ +--+--+ |UNI-2| +----+ | | | | | | | | | | | +---------+ | | | | | | +---------+ | | | | | | +---------+ | | | | | | +---------+ | | | | +--+--+ | +--+--+ | | | | +----+ | | | | | +-------+ | | | +----+ | | | +-+--+ | | CN2 +---------------+ CN5 | | | | | | | -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- | | | | | | +-----+ +-----+ | | | | | | +----+ | | | | +----+ | | | +----------------------------------+ | | +---------+ Core Network +---------+ Client Client Network Network Legend: EN - Edge Node CN - Core Node Figure 1: Multi-layer Network Topology Figure 1 shows a multi-layer network topology which is modified based on the overlay reference model in [RFC4208] to describe the different failure and protection scenarios of an inter-layer LSP. Assume in normal state there is an end-to-end LSP from EN2 to EN3 which traverses the path: EN2-CN1-CN3-CN4-EN3. There are several failure cases in which different protection and report behavior should be performed. o If a failure occurs in the server layer link CN3-CN4, and the server layer protection/restoration could recover this by setting up a new path between CN3 and CN4, then the end-to-end LSP between EN2 and EN3 will traverse a new path: EN2-CN1-CN3-CN5-CN4-EN3. In this case the client layer protection or restoration is not Dong, et al. Expires July 2, 2015 [Page 3] Internet-Draft GMPLS UNI Abstract Error Report December 2014 needed, while the client layer SHOULD be informed of the failure and restoration happened in the server layer for fault localization and diagnostics, and the characteristics of the new server layer path may be changed and need to be updated to the client layer. o If a failure occurs in the server layer link CN3-CN4, and the server layer protection/restoration mechanism cannot recover this failure, then the client layer MUST be informed of this situation to trigger the client layer protection/restoration mechanism. o If the UNI interface UNI-1 between the edge node EN3 and the server layer node CN4 fails, it may be restored efficiently by using a stand-by UNI interface UNI-2 along with the existing resources in the server layer. Such restoration may be initiated either by the ingress edge node of the end-to-end LSP (EN2 in figure 1), or by the nodes adjacent to the failed UNI link (CN4 and EN3). In both cases the client layer SHOULD be informed of the failure and recovery happened on the UNI link of the end-to- end LSP. o If a failure occurs on the UNI link between EN3 and CN4, and stand-by UNI interface recovery is not available, the client layer node EN2 SHOULD be informed of this failure and trigger the client layer protection/restoration mechanism. In summary, information about the failure happens in the end-to-end inter-layer LSPs SHOULD be exchanged between different network layers for appropriate protection/restoration, fault localization and diagnostics. The confidentiality concerns in multi-layer networks SHOULD also be considered. 2. RSVP-TE Extensions for Abstract Error Report This section specifies the RSVP-TE extensions for abstracted error information report on the end-to-end inter-layer TE LSPs. In the IF_ID ERROR_SPEC Object defined in [RFC3473], one new Interface_ID TLV "ABSTRACT_LOC" is defined to indicate the abstracted failure location: Type Length Format Description ------------------------------------- TBD 4 See below ABSTRACT_LOC The value field of the "ABSTRACT_LOC" TLV is 32 bit flags numbered from the most significant bit as bit zero. Two flags are defined in this document: Dong, et al. Expires July 2, 2015 [Page 4] Internet-Draft GMPLS UNI Abstract Error Report December 2014 o Server Layer Internal (I): When set, it indicates the failure happens inside the server layer. o UNI (U): When set, it indicates the failure happens in an UNI interface between the server layer and the client layer. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |U|I| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Besides, two new Error Values are defined for Error Code 34 "Reroute" in [RFC5710] : o Error Value = TBD1, reroute accomplished o Error Value = TBD2, upper layer reroute required 3. Operation Procedures This section describes the procedures of exchanging the abstracted error report between interconnected server and client network layers. When a failure occurs in the server layer network, and the server layer protection/restoration could recover the failure by setting up a new server layer path, the ingress client layer edge node of the end-to-end LSP does not need to trigger client layer protection mechanisms, but it SHOULD be aware of the event happened on the end- to-end path. The server layer node which recovered the failure MUST send a PathErr message which carries the ABSTRACT_LOC TLV in the IF_ID ERROR_SPEC Object, in which the "I" bit is set. The error node address field MUST be set to zero to indicate this is not to identify an error of a particular node. The error code SHOULD be "Reroute (34)" and the Error Value SHOULD be "reroute accomplished". The upstream server layer nodes SHOULD propagate the received PathErr message to the previous hop, until the PathErr message reaches the client layer edge node. Upon receipt of this PathErr message, the client layer edge node SHOULD not trigger any client layer protection/restoration mechanism, as it is indicated in the message that the reroute is accomplished. In this case, the client layer edge node and the server layer edge node may also exchange the characteristics of the updated server layer path, details of which is outside the scope of this document. When a failure occurs in the server layer network, and the server layer protection/restoration mechanism cannot recover this failure, the server layer edge node which connects to the ingress client layer Dong, et al. Expires July 2, 2015 [Page 5] Internet-Draft GMPLS UNI Abstract Error Report December 2014 edge node MUST send a PathErr message which carries the ABSTRACT_LOC TLV in the IF_ID ERROR_SPEC Object, in which the "I" bit is set. The error node address field MUST be set to zero to indicate this is not to identify an error of a particular node. The Error Code SHOULD be "Reroute (34)" and the Error Value SHOULD be "upper layer reroute required". Upon receipt of this PathErr message, the ingress client layer edge node SHOULD trigger the client layer protection/ restoration mechanism to recover the end-to-end LSP. When the UNI interface which connects the remote server layer edge and the remote client layer edge fails, and is recovered by a stand- by UNI interface, the server layer edge node which connects to the recovered UNI interface MUST send a PathErr message which carries the ABSTRACT_LOC TLV in the IF_ID ERROR_SPEC Object, in which the "U" bit is set. The error node address field MUST be set to zero to indicate this is not to identify an error of a particular node. The Error Code SHOULD be "Reroute (34)", the Error Value SHOULD be "reroute accomplished". The upstream server layer nodes SHOULD propagate the received PathErr message to the previous hop, until the PathErr message reaches the client layer edge node. Upon receipt of this PathErr message, the ingress client layer edge node may send a new Path message to refresh the end-to-end inter-layer LSP. When a failure happens on the UNI link between the remote server layer and client layer edge nodes, and the stand-by UNI interface recovery is not available, the server layer edge node which connects to the failed UNI interface MUST send a PathErr message which carries the ABSTRACT_LOC TLV in the IF_ID ERROR_SPEC Object, in which the "U" bit is set. The error node address field MUST be set to zero to indicate this is not to identify an error of a particular node. The Error Code SHOULD be "Reroute (34)" and the Error Value SHOULD be "upper layer reroute required". The upstream server layer nodes SHOULD propagate the received PathErr message to the previous hop, until the PathErr message reaches the client layer edge node. The client layer edge node SHOULD trigger the client layer protection/ restoration mechanism based on the received PathErr message. 4. IANA Considerations IANA is requested to administer the assignment of new values defined in this document and summarized in this section. 4.1. IF_ID ERROR_SPEC TLVs IANA maintains a registry called "GMPLS Signaling Parameters" with a sub-registry called "Interface_ID Types". Dong, et al. Expires July 2, 2015 [Page 6] Internet-Draft GMPLS UNI Abstract Error Report December 2014 IANA is requested to assign a new TLV type for the "ABSTRACT_LOC" TLV defined in 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 two new Error Value sub-codes for the "Reroute" Error Code: Value | Description | Reference -----------+--------------------------------+-------------- TBA | reroute accomplished | this document TBA | upper layer reroute required | this document 5. Security Considerations This document does not introduce any new security issues above those identified in [RFC3209] and [RFC3473]. For a more comprehensive discussion of GMPLS security and attack mitigation techniques, please see the Security Framework for MPLS and GMPLS Networks [RFC5920]. 6. Acknowledgements TBD 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 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. [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 July 2, 2015 [Page 7] Internet-Draft GMPLS UNI Abstract Error Report December 2014 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User- Network Interface (UNI): Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005. [RFC5710] Berger, L., Papadimitriou, D., and JP. Vasseur, "PathErr Message Triggered MPLS and GMPLS LSP Reroutes", RFC 5710, January 2010. 7.2. Informative References [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. Authors' Addresses Jie Dong Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: jie.dong@huawei.com Xiugang Wei Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: weixiugang@huawei.com Victor Lopez Telefonica I+D Don Ramon de la Cruz 82-84 Madrid 28045 Spain Email: victor.lopezalvarez@telefonica.com Dong, et al. Expires July 2, 2015 [Page 8] Internet-Draft GMPLS UNI Abstract Error Report December 2014 Oscar Gonzalez de Dios Telefonica I+D Don Ramon de la Cruz 82-84 Madrid 28045 Spain Email: oscar.gonzalezdedios@telefonica.com Dong, et al. Expires July 2, 2015 [Page 9]