TEAS Working Group Zafar Ali Internet Draft George Swallow Intended status: Standard Track Clarence Filsfils Expires: January 5, 2016 Matt Hartley Ori Gerstel Cisco Systems Kenji Kumaki KDDI Corporation Ruediger Kunze Deutsche Telekom AG July 6, 2015 Include Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) draft-ali-teas-rsvp-te-include-route-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 5, 2016. 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. Ali, Swallow, Filsfils, et al Expires Januray 2016 [Page 1] Internet-Draft draft-ali-teas-rsvp-te-include-route-00.txt Abstract There are scenarios that require two or more LSPs or segments of LSPs to follow same route in the network. This document specifies methods to communicate route inclusions along the loose hops during path setup using the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) protocol. 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 [RFC2119]. Table of Contents Copyright Notice.................................................1 1. Introduction..................................................2 2. RSVP-TE signaling extensions..................................4 2.1. IPv4 Point-to-Point Path ERO subobject................4 2.2. IPv6 Point-to-Point Path ERO subobject................5 2.3. Processing rules for Path ERO subobjects..............7 3. Security Considerations.......................................8 4. IANA Considerations...........................................8 4.1. New ERO subobject types...............................8 4.2. New RSVP error sub-codes..............................9 5. Acknowledgments...............................................9 6. References...................................................10 6.1. Normative References.................................10 6.2. Informative References...............................10 1. Introduction There are scenarios that require two or more Label Switched Paths (LSPs) to follow same route in the network. E.g., many deployments require member LSPs of a bundle/ aggregated link (or Forwarding Adjacency (FA))) follow the same route. Possible reasons for two or more LSPs to follow the same end-to-end or partial route include, but are not limited to: . Fate sharing: an application may require that two or more LSPs fail together. In the example of bundle link this would Ali, Swallow, Filsfils, et al Expires Januray 2016 [Page 2] Internet-Draft draft-ali-teas-rsvp-te-include-route-00.txt mean that if one component goes down, the entire bundle goes down. . Homogeneous Attributes: it is often required that two or more LSPs have the same TE metrics like latency, latency variation, etc. In the example of a bundle/ aggregated link this would meet the requirement that all component links (FAs) of a bundle should have same latency and latency variation. As noted in [OSPF-TE-METRIC] and [ISIS-TE-METRIC], in certain networks, such as financial information networks, network performance (e.g. latency and latency variation) is becoming critical and hence having bundles with component links (FAs) with homogeneous latency and latency variation is important. The RSVP-TE specification [RFC3209] and GMPLS extensions to RSVP-TE [RFC3473] allow abstract nodes and resources to be explicitly included in a path setup, e.g., using IPv4 prefix ERO subobject [RFC3209], IPv6 prefix ERO subobject [RFC3209] and Unnumbered Interface ID ERO subobject [RFC3477], etc. When a source node has full topological knowledge and is permitted to signal an Explicit Route Object, these methods can be used to satisfy the inclusion requirements mentioned above. However, there are scenarios when path computations are performed by remote nodes, thus there is a need for relevant inclusion requirements to be communicated to those nodes. These include (but are not limited to): . LSPs with loose hops in the Explicit Route Object (ERO), e.g. inter-domain LSPs; . Generalized Multi-Protocol Label Switching (GMPLS) User- Network Interface (UNI) where path computation may be performed by the (server layer) core node [RFC4208]. These use-cases require the relevant path-inclusion information to be communicated to the route expanding nodes. This document defines the necessary extensions to RSVP-TE protocol. This document assumes that node expanding the route is normally a hop of the included LSP. Therefore, the node calculating or expanding the route of the signaled LSP has the knowledge of the inclusion route. However, there is a race condition in which included LSP is yet to be signaled. This draft addresses this race condition, as detailed in Section 2.2. Ali, Swallow, Filsfils, et al Expires Januray 2016 [Page 3] Internet-Draft draft-ali-teas-rsvp-te-include-route-00.txt 2. RSVP-TE signaling extensions New IPv4 and IPv6 Point-to-Point (P2P) Path ERO subobject types are defined in this document. These ERO subobjects are used to communicate path inclusion requirements to the ERO expanding node(s). For this purpose, the subobjects carry RSVP-TE Forwarding Equivalence Class (FEC) of the reference LSP who's Path is be used to expand the loose hop of the LSP being signaled. 2.1. IPv4 Point-to-Point Path ERO subobject The IPv4 Point-to-Point Path ERO subobject is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel end point address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved (MUST be zero) | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved (MUST be zero) | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L The L bit is an attribute of the subobject. The L bit is set if the subobject represents a loose hop in the ERO. If the bit is not set, the subobject represents a strict hop in the explicit route. This document only defines the use of the subobject in loose hopes in the ERO, i.e., L bit MUST of set to 1. Type IPv4 Point-to-Point Path ERO subobject (to be assigned by IANA; suggested value: 38). Ali, Swallow, Filsfils, et al Expires Januray 2016 [Page 4] Internet-Draft draft-ali-teas-rsvp-te-include-route-00.txt Length The length contains the total length of the subobject in bytes, including the type and length fields. The length is always 24. M bit: When "mandatory inclusion" bit is set, the route of the LSP being signaled MUST follow the path specified by the Path ERO subobject. When mandatory inclusion is not set, the route of the LSP being signaled SHOULD follow the path specified by the Path ERO subobject. The remaining fields are used to specify RSVP-TE FEC of the reference LSP who's Path is be used to expand the route of the LSP being signaled. Specifically, Tunnel ID Tunnel ID of the reference LSP who's Path is be used to expand the route of the LSP being signaled. Extended Tunnel ID Extended Tunnel ID of the reference LSP who's Path is be used to expand the route of the LSP being signaled. IPv4 tunnel sender address IPv4 tunnel sender address of the reference LSP who's path is be used to expand the route of the LSP being signaled. LSP ID LSP ID of the reference LSP who's Path is be used to expand the route of the LSP being signaled. 2.2. IPv6 Point-to-Point Path ERO subobject The IPv6 Point-to-Point Path ERO subobject is defined as follows: Ali, Swallow, Filsfils, et al Expires Januray 2016 [Page 5] Internet-Draft draft-ali-teas-rsvp-te-include-route-00.txt 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 tunnel end point address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 tunnel end point address (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 tunnel end point address (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 tunnel end point address (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Must Be Zero | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved (MUST be zero) | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L The L bit is an attribute of the subobject. The L bit is set if the subobject represents a loose hop in the ERO. If the bit is not set, the subobject represents a strict hop in the explicit route. This document only defines the use of the subobject in loose hopes in the ERO, i.e., L bit MUST of set to 1. Type IPv6 Point-to-Point Path ERO subobject Ali, Swallow, Filsfils, et al Expires Januray 2016 [Page 6] Internet-Draft draft-ali-teas-rsvp-te-include-route-00.txt (to be assigned by IANA; suggested value: 39). Length The length contains the total length of the subobject in bytes, including the type and length fields. The length is always 48. M bit: The M bit usage is as defined for the M bit of IPv4 Point-to-Point Path ERO subobject. The remaining fields are used to specific RSVP-TE FEC of the reference LSP who's Path is be used to expand the route of the LSP being signaled, as detailed in Section 2.1. 2.3. Processing rules for Path ERO subobjects The basic processing rules of an ERO are not altered. Please refer to [RFC3209] for details. If an LSR strips all local subobjects from an ERO carried in a Path message (according to the procedures in [RFC3209]) and finds that the next subobject is an IPv4 P2P Path ERO subobject or IPv6 P2P LSP subject, it MUST attempt to resolve the Path ERO subobject as described in the following. If the L bit of the Path ERO subobject is not set, i.e., the subobject represents a strict hop in the explicit route, the processing node MUST respond with a PathErr message with the error code "Routing Problem" (24) and the error value "Bad initial subobject" (4). If the M bit is set, the processing node follows the following procedure: - If the path taken by the LSP referenced in the Path ERO subobject is known to the processing node and the path contains the loose abstract node in the ERO hop, the processing node MUST ensure that loose hop expansion to the next abstract node follows the referenced path. - If the path taken by the LSP referenced in the Path ERO subobject does not contain the loose abstract node in the ERO hop, the processing node MUST sent a PathErr message with the error code "Routing Problem" (24) and the new error value Ali, Swallow, Filsfils, et al Expires Januray 2016 [Page 7] Internet-Draft draft-ali-teas-rsvp-te-include-route-00.txt "unknown or inconsistent LSP suboject" (value to be assigned by IANA) for the signaled LSP. - If the path referenced in the LSP subobject is unknown to the processing node, the processing node SHOULD ignore the Path ERO subobject and SHOULD proceed with the signaling request. After sending the Resv for the signaled LSP, the processing node SHOULD return a PathErr with the error code "Notify Error" (25) and error sub-code "TBD" (value to be assigned by IANA, suggested value: TBD) for the signaled LSP. If the M bit is not set, the processing node follows the following procedure: - If the path taken by the LSP referenced in the Path ERO subobject is known to the processing node and the path contains the loose abstract node in the ERO hop, the processing node SHOULD ensure that loose hop expansion to the next abstract node follows the referenced path. - If the path taken by the LSP referenced in the Path ERO subobject is unknown to the processing node and/ or the referenced path does not contain the loose abstract node in the ERO hop, the processing node SHOULD ignore the route inclusion specified in the Path ERO subobject and SHOULD compute a suitable path to the loose abstract node in the ERO hop and proceed with the signaling request. After sending the Resv for the signaled LSP, the processing node SHOULD return a PathErr with the error code "Notify Error" (25) and error sub- code " unknown or inconsistent LSP suboject" (value to be assigned by IANA) for the signaled LSP. 3. Security Considerations This document does not introduce any additional security issues above those identified in [RFC5920], [RFC2205], [RFC3209], and [RFC3473] and [RFC4874]. 4. IANA Considerations 4.1. New ERO subobject types This document adds the following new subobject of the existing entry for ERO (20, EXPLICIT_ROUTE): Value Description Ali, Swallow, Filsfils, et al Expires Januray 2016 [Page 8] Internet-Draft draft-ali-teas-rsvp-te-include-route-00.txt ----- ------------ TBA IPv4 Point-to-Point Path ERO subobject TBA IPv6 Point-to-Point Path ERO subobject These subobject may be present in the Explicit Route Object, but not in the Route Record Object. 4.2. New RSVP error sub-codes IANA registry: RSVP PARAMETERS Subsection: Error Codes and Globally-Defined Error Value Sub- Codes For Error Code "Routing Problem" (24) (see [RFC3209]) the following sub-codes are defined. Sub-code Value -------- ----- Unknown or inconsistent LSP suboject To be assigned by IANA. For Error Code "Notify Error" (25) (see [RFC3209]) the following sub-codes are defined. Sub-code Value -------- ----- Unknown or inconsistent LSP suboject To be assigned by IANA. 5. Acknowledgments Authors would like to thank Gabriele Maria Galimberti, Luyuan Fang and Walid Wakim for their review comments. Ali, Swallow, Filsfils, et al Expires Januray 2016 [Page 9] Internet-Draft draft-ali-teas-rsvp-te-include-route-00.txt 6. References 6.1. Normative References [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. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 6.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", RFC 4208, October 2005. [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi- Region Networks (MLN/MRN)", RFC 6001, October 2010. [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. [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", RFC 5920, July 2010. Authors' Addresses Ali, Swallow, Filsfils, et al Expires Januray 2016 [Page 10] Internet-Draft draft-ali-teas-rsvp-te-include-route-00.txt Zafar Ali Cisco Systems, Inc. Email: zali@cisco.com George Swallow Cisco Systems, Inc. swallow@cisco.com Clarence Filsfils Cisco Systems, Inc. cfilsfil@cisco.com Matt Hartley Cisco Systems Email: mhartley@cisco.com Ori Gerstel Cisco Systems ogerstel@cisco.com Kenji Kumaki KDDI Corporation Email: ke-kumaki@kddi.com Rudiger Kunze Deutsche Telekom AG Ruediger.Kunze@telekom.de Ali, Swallow, Filsfils, et al Expires Januray 2016 [Page 11]