Internet Engineering Task Force H. Chen Internet-Draft R. Li Intended status: Standards Track Huawei Technologies Expires: September 9, 2015 G. Cauchie A. Retana Cisco Systems, Inc. N. So Tata Communications F. Xu Verizon V. Liu China Mobile M. Toy Comcast L. Liu UC Davis March 8, 2015 TE LSP Crossing Topology-Transparent Zones draft-chen-teas-rsvp-ttz-00.txt Abstract A topology-transparent zone is virtualized as the edges of the zone fully connected. This document presents the procedures for the establishment of Traffic Engineering (TE) LSPs crossing Topology- Transparent Zones. Status of this Memo This Internet-Draft is submitted to IETF 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 September 9, 2015. Copyright Notice Chen, et al. Expires September 9, 2015 [Page 1] Internet-Draft TE LSP x TTZs March 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 3. Overview of Topology-Transparent Zone (TTZ) . . . . . . . . . . 3 4. Set up TE LSPs crossing TTZs . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Chen, et al. Expires September 9, 2015 [Page 2] Internet-Draft TE LSP x TTZs March 2015 1. Introduction The number of routers in a network becomes larger and larger as the Internet traffic keeps growing. Through splitting the network into multiple areas, we can extend the network further. However, there are a number of issues when a network is split further into more areas. At first, dividing a network into more areas is a very challenging and time consuming since it is involved in significant network architecture changes. Secondly, the services carried by the network may be interrupted while the network is being split into more areas. Furthermore, it is complex for a TE LSP crossing areas to be setup. In one option, a TE path crossing areas is computed by using collaborating PCEs [RFC5441] through PCEP[RFC5440], which is not easy to configure. Topology-transparent zone (TTZ) resolves these issues. This document briefs TTZ and presents the procedures for the establishment of TE LSPs crossing TTZs. 2. 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. 3. Overview of Topology-Transparent Zone (TTZ) A Topology-Transparent Zone (TTZ) is identified by an Identifier (ID) called TTZ ID, and it includes a group of routers and a number of links connecting the routers. A TTZ is in an IGP area. In addition to having the functions of an IGP area, an IGP TTZ makes some improvements on an IGP area, which include: o An IGP TTZ is virtualized as the TTZ edge routers connected. o An IGP TTZ receives the link state information about the topology outside of the TTZ, stores the information in the TTZ and floods the information through the TTZ to the routers outside of the TTZ. The figure below shows an area containing a TTZ: TTZ 600. Chen, et al. Expires September 9, 2015 [Page 3] Internet-Draft TE LSP x TTZs March 2015 TTZ 600 \ \ ^~^~^~^~^~^~^~^~^~^~^~^~ ( ) ===[R15]========(==[R61]------------[R63]==)======[R29]=== || ( | \ / | ) || || ( | \ / | ) || || ( | \ / | ) || || ( | ___\ / | ) || || ( | / [R71] | ) || || ( | [R73] / \ | ) || || ( | / \ | ) || || ( | / \ | ) || || ( | / \ | ) || ===[R17]========(==[R65]------------[R67]==)======[R31]=== \\ (// \\) // || //v~v~v~v~v~v~v~v~v~v~v~\\ || || // \\ || || // \\ || \\ // \\ // ======[R23]==============================[R25]===== // \\ // \\ Figure 1: An Example of TTZ The area comprises routers R15, R17, R23, R25, R29 and R31. It also contains TTZ 600, which comprises routers R61, R63, R65, R67, R71 and R73, and the links connecting them. There are two types of routers in a TTZ: TTZ internal routers and TTZ edge routers. A TTZ internal router is a router inside the TTZ and its adjacent routers are in the TTZ. A TTZ edge router is a router inside the TTZ and has at least one adjacent router that is outside of the TTZ. The TTZ in the figure above comprises four TTZ edge routers R61, R63, R65 and R67. Each TTZ edge router is connected to at least one router outside of the TTZ. For instance, router R61 is a TTZ edge router since it is connected to router R15, which is outside of the TTZ. In addition, the TTZ comprises two TTZ internal routers R71 and R73. A TTZ internal router is not connected to any router outside of the TTZ. For instance, router R71 is a TTZ internal router since it is not connected to any router outside of the TTZ. It is just connected to routers R61, R63, R65, R67 and R73 in the TTZ. Chen, et al. Expires September 9, 2015 [Page 4] Internet-Draft TE LSP x TTZs March 2015 A TTZ hides the information inside the TTZ from the outside. It does not directly distribute any internal information about the TTZ to a router outside of the TTZ. For instance, the TTZ in the figure above does not send the information about TTZ internal router R71 to any router outside of the TTZ in the routing domain; it does not send the information about the link between TTZ router R61 and R65 to any router outside of the TTZ. From a router outside of the TTZ, a TTZ is seen as a group of routers fully connected. For instance, router R15 in the figure above, which is outside of TTZ 600, sees TTZ 600 as a group of TTZ edge routers: R61, R63, R65 and R67. These four TTZ edge routers are fully connected. The cost of the "link" from one edge router to another edge router is the cost of the shortest path between these two routers. The bandwidth of the "link" is the maximum bandwidth of a path between the two routers. In addition, a router outside of the TTZ sees TTZ edge routers having normal connections to the routers outside of the TTZ. For example, router R15 sees four TTZ edge routers R61, R63, R65 and R67, which have the normal connections to R15, R29, R17 and R23, R25 and R31 respectively. 4. Set up TE LSPs crossing TTZs On a source node, we can configure a TE LSP from the source to a destination crossing TTZs in the same way as we configure it without any TTZs. This is because the source node is not aware of any TTZs. For example, on node R15 in Figure 1, to set up a TE LSP from R15 to R31, we just configure the TE LSP by giving its source R15, its destination R31, and some constraints such as bandwidth as needed. On the source node, it computes the path to the destination based on the configuration of the TE LSP. It just sees a full mess connection of edge nodes for every TTZ. Thus the computation of the path is done in the same way as it is done without any TTZ. After the path is computed, the source node starts to signal the LSP automatically along the path. For example, on node R15 in Figure 1, it computes the path to the destination R31. It sees the full mess connection of four TTZ edge nodes R61, R63, R65 and R67 in its topology. It computes the path in Chen, et al. Expires September 9, 2015 [Page 5] Internet-Draft TE LSP x TTZs March 2015 the same way as before and may get the path: R15 - R61 - R67 - R31. And then it signals the TE LSP along this path. It sends a RSVP-TE PATH message to R61. When an edge node of a TTZ receives a PATH message, it checks if the next hop in the ERO in the message is another edge node of the TTZ. If so, it computes the path segment to the other edge node and continues to signal the TE LSP along the path segment computed. For instance, when R61, which is an edge node of a TTZ, receives the PATH message, it computes the path segment to the other edge node R67 (Supposed that the path segment is: R61 - R71 - R67) and continues to signal the TE LSP to R67 along the path segment computed. It sends a PATH message to R71, which sends a PATH message to R67, which sends a PATH message to R31. TTZ 600 \ \ ^~^~^~^~^~^~^~^~^~^~^~^~ Source 51 ( ) ===[R15]========(==[R61]------------[R63]==)======[R29]=== || ( | \ / | ) || || ( | \ / | ) || || ( | \11 / | ) || || ( | ___\ / | ) || || ( | / [R71] | ) || || ( | [R73] / \ | ) || || ( | / \ | ) || || ( | / \17 | ) || || ( | / \ | ) 71 || ===[R17]========(==[R65]------------[R67]==)======[R31]=== \\ (// \\) //Destination || //v~v~v~v~v~v~v~v~v~v~v~\\ || || // \\ || || // \\ || \\ // \\ // ======[R23]==============================[R25]===== // \\ // \\ Figure 2: LSP from R15 to R31 When R31 receives the PATH message from R67, it allocates a label (e.g., 71), reserves the bandwidth as needed, and sends a RESV message with the label (71) to R67. It sets the forwarding entry for the TE LSP using label 71 as inbound label. Chen, et al. Expires September 9, 2015 [Page 6] Internet-Draft TE LSP x TTZs March 2015 When R67 receives the RESV message from R31, it allocates a label (e.g., 17), and sends a RESV message with the label (17) to R71. It also sets the cross connect for the TE LSP using labels 17 and 71 as inbound label and outbound label respectively. When R71 receives the RESV message with the label (17) from R67, it allocates a label (e.g., 11), and sends a RESV message with the label (11) to R61. It sets the cross connect for the TE LSP using labels 11 and 17 as inbound label and outbound label respectively. When R61 receives the RESV message with the label (11) from R71, it allocates a label (e.g., 51), and sends a RESV message with the label (51) to R15. It sets the cross connect for the TE LSP using labels 51 and 11 as inbound label and outbound label respectively. When R15 receives the RESV message with the label (51) from R61, it sets the forwarding entry for the TE LSP using label 51 as outbound label. At this point, the set up of TE LSP from R15 to R31 is done. The source node (i.e., head-end LSR) sets the "label recording requested" flag in the SESSION_ATTRIBUTE object for LSPs requesting local protection. This will cause all LSRs to record their INBOUND labels. For a TE LSP crossing a TTZ, we may assume that it goes into the TTZ through an in edge node of the TTZ and goes out of the TTZ from a out edge node of the TTZ. For example, the TE LSP crossing TTZ 600 in Figure 2 is from R15 to R61 to R71 to R67 to R31. The LSP goes into TTZ 600 through the edge node R61, which is the in edge node. The LSP goes out of TTZ 600 from the edge node R67, which is the out edge node. On the in edge node of the TTZ for the TE LSP, it does not record all the INBOUND labels inside the TTZ in the RESV message to be sent to its previous hop node. It just records the INBOUND label of the out edge node. For example, R61 (the in edge node of TTZ 600 for the TE LSP in Figure 2) just keeps the INBOUND label 17 of R67 (the out edge node). It does not record any other INBOUND labels inside TTZ 600. It will remove the INBOUND label 11 of the TTZ internal node R71. Thus the RESV message sent by R61 to its previous hop node R15 records two INBOUND labels 17 and 71, which are the INBOUND labels of R67 and R31 respectively. On the out edge node of the TTZ for the TE LSP, it does not record all the hops inside the TTZ in the PATH message to its next hop node. Chen, et al. Expires September 9, 2015 [Page 7] Internet-Draft TE LSP x TTZs March 2015 It just records one hop from the in edge to the out edge. 5. Security Considerations The mechanism described in this document does not raise any new security issues for the RSVP-TE protocols. 6. IANA Considerations There is not any requirement for IANA to assign a code point. 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [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. [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. Chen, et al. Expires September 9, 2015 [Page 8] Internet-Draft TE LSP x TTZs March 2015 Authors' Addresses Huaimo Chen Huawei Technologies Boston, MA USA Email: huaimo.chen@huawei.com Renwei Li Huawei Technologies 2330 Central Expressway Santa Clara, CA USA Email: renwei.li@huawei.com Gregory Cauchie FRANCE Email: greg.cauchie@gmail.com Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Raleigh, NC 27709 USA Email: aretana@cisco.com Ning So Tata Communications 2613 Fairbourne Cir. Plano, TX 75082 USA Email: ningso01@gmail.com Chen, et al. Expires September 9, 2015 [Page 9] Internet-Draft TE LSP x TTZs March 2015 Fengman Xu Verizon 2400 N. Glenville Dr Richardson, TX 75082 USA Email: fengman.xu@verizon.com Vic Liu China Mobile No.32 Xuanwumen West Street, Xicheng District Beijing, 100053 China Email: liuzhiheng@chinamobile.com Mehmet Toy Comcast 1800 Bishops Gate Blvd. Mount Laurel, NJ 08054 USA Email: mehmet_toy@cable.comcast.com Lei Liu UC Davis CA USA Email: liulei.kddi@gmail.com Chen, et al. Expires September 9, 2015 [Page 10]