Extensions to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) for Error Notication in Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI)
Author(s): Kenji Kumaki, Matt Hartley, Zafar Ali, Clarence Filsfils, George Swallow
There are many scenarios in which extensions to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) are required for error notication in Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI). This document outlines these scenarios and specifies the required extensions to...
CCAMP Working Group Zafar Ali Internet Draft George Swallow Intended status: Standard Track Matt Hartley Expires: January 11, 2014 Clarence Filsfils Cisco Systems Kenji Kumaki KDDI Corporation July 12, 2013 Extensions to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) for Error Notication in Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI) draft-ali-ccamp-gmpls-uni-error-notification-00.txt 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 January 11, 2014. Copyright Notice Copyright (c) 2013 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. Ali, Swallow, Hartley, et al Expires January 2014 [Page 1] Internet Draft draft-ali-ccamp-gmpls-uni-error-notification-00.txt Abstract There are many scenarios in which extensions to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) are required for error notication in Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI). This document outlines these scenarios and specifies the required extensions to RSVP-TE. Although the GMPLS-UNI reference model is used to describe requirements and solutions in the document, the proposed extensions are equally applicable to other deployment scenarios such as inter-domain RSVP- TE. Conventions used in this document 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 [RFC 2119]. Table of Contents 1. Introduction...............................................3 2. Requirements...............................................4 2.1. Error Node Address in ERROR_SPEC object ...............4 2.2. Restoration Notification..............................4 3. RSVP-TE extensions for Error Notication....................5 3.1. Error Node Address Modification in ERROR_SPEC object ..5 3.1.1. Error Node Address Modification Flag ................ 5 3.1.2. Processing rules................................ 5 3.1.3. Example......................................... 6 3.2. Restoration Notification..............................6 3.2.1. Error sub-code.................................. 6 3.2.2. Processing rules................................ 6 4. Security Considerations....................................6 5. IANA Considerations........................................6 5.1. New ERROR_SPEC.Flags..................................6 Ali, Swallow, Hartley, et al Expires January 2014 [Page 2] Internet Draft draft-ali-ccamp-gmpls-uni-error-notification-00.txt 5.2. New RSVP error sub-codes..............................7 6. Acknowledgements...........................................7 7. References.................................................7 7.1. Normative References..................................7 7.2. Informative References................................8 1. Introduction [RFC4208] provides mechanisms for GMPLS UNI signaling. Figure 1 borrows the reference network model of [RFC4208]. Overlay Overlay Network +----------------------------------+ Network +---------+ | | +---------+ | +----+ | | +-----+ +-----+ +-----+ | | +----+ | | | | | UNI | | | | | | | | UNI | | | | | -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- | | | | | +--+--+ | | | | | | | | | | | +----+ | | | +--+--+ +--+--+ +--+--+ | | +----+ | +---------+ | | | | | | +---------+ | | | | | | +---------+ | | +--+--+ | +--+--+ | +---------+ | +----+ | | | | | +-------+ | | | +----+ | | | +-+--+ | | CN4 +---------------+ CN5 | | | | | | | -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- | | | | | UNI | +-----+ +-----+ | UNI | | | | | +----+ | | | | +----+ | +---------+ +----------------------------------+ +---------+ Overlay Core Network Overlay Network Network Legend: EN - Edge Node CN - Core Node Figure 1: GMPLS UNI Reference Model For convenience, some terms used in [RFC4208] are re-stated below: - "source EN": the edge node which initiates the connection (e.g., EN1); - "destination EN": the edge node where the connection is terminated (e.g., EN3); - "ingress CN": the core node to which the source EN is attached Ali, Swallow, Hartley, et al Expires January 2014 [Page 3] Internet Draft draft-ali-ccamp-gmpls-uni-error-notification-00.txt (e.g., CN1); - "egress CN": the core node to which the destination EN is attached (e.g., CN3). [RFC4208] provides mechanisms for UNI signaling whereby a single end-to-end RSVP session between source EN and destination EN is used for the user connection, just as it would be for connection creation between two core nodes. However, when considering policy considerations such as a requirement to preserve the confidentiality of topological information of the core network, additional requirements for UNI signaling exist that are not addressed by [RFC4208]. This document focuses on error notification aspects of these additional requirements. 2. Requirements This sections outlines addition requirements related to error notification in GMPLS UNI. For the purpose of illustration, an end- to-end UNI connection that passes through EN1-CN1-CN2-CN3-EN3 is used as an example. 2.1. Error Node Address in ERROR_SPEC object The IPv4 and IPv6 ERROR_SPEC objects are defined in [RFC2205]; both objects contain an Error Node Address of the appropriate type, defined as the IP address of the error originating node [RFC2205]. However, for confidentiality reasons, service provider of the core network may not wish to expose addresses used in the core network (other than the UNI link addresses) to edge nodes. To meet this requirement, a core node should be allowed to change the Error Node Address in the ERROR_SPEC. When such an address modification is made by a core node, the edge node should be informed that Error Node Address field in the ERROR_SPEC has been modified. 2.2. Restoration Notification The ability to dynamically restore a Label Switched Path (LSP) is one of the fundamental features of GMPLS, including GMPLS UNI. In the context of GMPLS UNI, restoration of an LSP after a failure may be performed by the core network alone, or may be triggered by the edge nodes. There is a requirement that the two methods of restoration co-exist. Ali, Swallow, Hartley, et al Expires January 2014 [Page 4] Internet Draft draft-ali-ccamp-gmpls-uni-error-notification-00.txt When the core network restores an LSP, in many cases there is no need to re-signal the LSP. However, in order to avoid a concurrent restoration process triggered by an edge node, it is required that the core network notify the edge network that the LSP has been restored. 3. RSVP-TE extensions for Error Notication 3.1. Error Node Address Modification in ERROR_SPEC object 3.1.1. Error Node Address Modification Flag To allow a core node to change the Error Node Address in the ERROR_SPEC object, the following new flag value is defined for the Flags field of the IPv4 and IPv6 ERROR_SPEC objects [RFC2205], and for the IPv4 IF_ID and IPv6 IF_ID objects [RFC3477]. ERROR_SPEC.Flags = 0x08 (value to be assigned by IANA): Error Node Address Modified. The "Error Node Address Modified" flag is applicable to all RSVP-TE messages that use the ERROR_SPEC object. 3.1.2. Processing rules When processing an ERROR_SPEC object received in a message from another node, the processing node MAY replace the IPv4 or IPv6 address in the ERROR_SPEC object with another address relating to itself if its local policy requires it to do so. When making an address substitution in this manner, the processing node SHOULD set the Error Node Address Modified flag in the Flags field of the ERROR_SPEC object to indicate that a change has been made. When processing a received ERROR_SPEC object, a node SHOULD examine the ERROR_SPEC.Flags field and check for the "Error Node Address Modified" flag before processing the ERROR_SPEC.Error_Node_Address field. The processing node MAY alter its handling of the ERROR_SPEC object if this flag is set, but any such variation in handling is implementation-dependent and beyond the scope of this document. Ali, Swallow, Hartley, et al Expires January 2014 [Page 5] Internet Draft draft-ali-ccamp-gmpls-uni-error-notification-00.txt 3.1.3. Example To illustrate usage of this flag, consider an example connection EN1-CN1-CN2-CN3-EN3 in the network specified by figure 1. In this example, the CN2 detects a failure and sends a PathErr message towards EN1, using a local address associated with the failed resource in the ERROR_SPEC. However, CN1's local policy is to conceal the topology of the core network from edge nodes. When CN1 processes the PathErr message, it changes the address in the ERROR_SPEC to CN1's address of the EN1- CN1 UNI link. It also sets the Error Node Address Modified flag in the Flags field of the ERROR_SPEC to indicate that a change has been made. The PathErr message is then sent to EN1. 3.2. Restoration Notification 3.2.1. Error sub-code In order to satisfy restoration notification requirement mentioned above, a new path error sub-code "LSP restored" (value to be assigned by IANA; suggested value: 16) for the error code "Notify Error" (25) is defined. 3.2.2. Processing rules When a core node restores an existing LSP after a failure, it SHOULD send a PathErr message with the error code "Notify Error" (25) and error sub-code "LSP restored" (suggested: 16) for the LSP. When an edge node receives a PathErr message with the error code "Notify Error" (25) and error sub-code "LSP restored" (suggested: 16), it MAY avoid triggering any other restoration process. 4. Security Considerations This document does not introduce any additional security issues above those identified in [RFC5920], [RFC2205], [RFC3209], [RFC3473] and [RFC4874]. 5. IANA Considerations 5.1. New ERROR_SPEC.Flags This document defines the following new flag value for the Flags field of the IPv4 and IPv6 ERROR_SPEC object defined in [RFC2205]. Ali, Swallow, Hartley, et al Expires January 2014 [Page 6] Internet Draft draft-ali-ccamp-gmpls-uni-error-notification-00.txt ERROR_SPEC.Flags: Error Node Address Modified. Value is to be assigned by IANA (suggested value: 0x08). 5.2. New RSVP error sub-codes IANA registry: RSVP PARAMETERS Subsection: Error Codes and Globally-Defined Error Value Sub- Codes For Error Code "Notify Error" (25) (see [RFC3209]) the following sub-code is defined. Sub-code Value -------- ----- LSP Restored To be assigned by IANA. Suggested value: 16 6. Acknowledgements TBD. 7. References 7.1. Normative References [RFC 2119] 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", RFC3209, December 2001. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC3473, January 2003. [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol- Traffic Engineering (RSVP-TE)", RFC4874, April 2007. Ali, Swallow, Hartley, et al Expires January 2014 [Page 7] Internet Draft draft-ali-ccamp-gmpls-uni-error-notification-00.txt 7.2. Informative References [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", RFC4208, October 2005. [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997. [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC5920, July 2010. Authors' Addresses Zafar Ali Cisco Systems. Email: email@example.com George Swallow Cisco Systems firstname.lastname@example.org Matt Hartley Cisco Systems Email: email@example.com Clarence Filsfils Cisco Systems, Inc. firstname.lastname@example.org Kenji Kumaki KDDI Corporation Email: email@example.com Ali, Swallow, Hartley, et al Expires January 2014 [Page 8]