Internet Engineering Task Force H. Chen Internet-Draft R. Li Intended status: Informational Huawei Technologies Expires: January 5, 2015 G. Cauchie N. So Tata Communications V. Liu China Mobile L. Liu UC Davis July 4, 2014 Applicability of OSPF Topology-Transparent Zone draft-chen-ospf-ttz-app-05.txt Abstract This document discusses the applicability of "OSPF Topology- Transparent Zone". It briefs the protocol and its operations first, and then illustrates the application scenarios of OSPF Topology- Transparent Zone. This document is intended for accompanying "OSPF Topology-Transparent Zone" to the Internet standards track. 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 January 5, 2015. 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 Chen, et al. Expires January 5, 2015 [Page 1] Internet-Draft Applicability of TTZ July 2014 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. Overview of Topology-Transparent Zone . . . . . . . . . . . . 3 2.1. Definitions of Topology-Transparent Zone . . . . . . . . . 3 2.2. An Example of TTZ . . . . . . . . . . . . . . . . . . . . 4 3. Applicability of Topology-Transparent Zone . . . . . . . . . . 6 3.1. One Area Network . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Issues on Splitting Network into Areas . . . . . . . . 6 3.1.2. Use of TTZ in One Area Network . . . . . . . . . . . . 7 3.2. Multi-Area Network . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Issues on Splitting Network into More Areas . . . . . 9 3.2.2. Use of TTZ in Multi-Area Network . . . . . . . . . . . 10 3.3. Use of TTZ on Routers in POP . . . . . . . . . . . . . . . 11 3.4. Use of TTZ on Routers in IPRAN . . . . . . . . . . . . . . 11 3.5. Use of TTZ on Routers from Same Vendor . . . . . . . . . . 12 3.6. Use of TTZ on Routers in a Power Saving Group . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Chen, et al. Expires January 5, 2015 [Page 2] Internet-Draft Applicability of TTZ July 2014 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 an AS or an area into multiple areas is a very challenging task 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 from one area into multiple areas or from a number of existing areas into even more areas. Moreover, it is complex for a Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switching Path (LSP) crossing multiple areas to be setup. In one option, a TE path crossing multiple areas is computed by using collaborating Path Computation Elements (PCEs) [RFC5441] through the PCE Communication Protocol (PCEP)[RFC5440], which is not easy to configure by operators since the manual configuration of the sequence of domains is required. Although this issue can be addressed by using the Hierarchical PCE, this solution may further increase the complexity of network design. Especially, the current PCE standard method may not guarantee that the path found is optimal. This document introduces a technology called Topology-Transparent Zone (TTZ), presents a number of application scenarios of TTZ and illustrates that TTZ can resolve the issues above. 2. Overview of Topology-Transparent Zone This section briefs the concept of Topology-Transparent Zone (TTZ) and explains the TTZ in some details through an example. 2.1. Definitions of Topology-Transparent Zone A Topology-Transparent Zone (TTZ) comprises an Identifier (ID), a group of routers and a number of links connecting the routers. A Topology-Transparent Zone is in an OSPF area. The ID of a Topology-Transparent Zone (TTZ) or TTZ ID for short is a number that is unique for identifying a node in an OSPF domain. It is not zero in general. Chen, et al. Expires January 5, 2015 [Page 3] Internet-Draft Applicability of TTZ July 2014 A TTZ may be virtualized as a different object in a different way. Two typical ways are given below. In a first way, a TTZ may be virtualized as a group of TTZ edge routers fully connected. From a router outside of the TTZ, a TTZ is seen as a group of TTZ edge routers, which are fully connected. In a second way, a TTZ may be seen as a single router. From a router outside of the TTZ, a TTZ is seen as a special single router. This router has a router ID, which is the TTZ ID or the maximum ID among all the router IDs of the routers in the TTZ. For every connection between a TTZ edge router and a router outside of TTZ, there is a connection between the special router and the router outside of TTZ. The virtualization of TTZ in the first way is described and used below. 2.2. An Example of TTZ The figure below illustrates an example of a routing area containing a topology-transparent zone: TTZ 600. 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 Chen, et al. Expires January 5, 2015 [Page 4] Internet-Draft Applicability of TTZ July 2014 The routing area comprises routers R15, R17, R23, R25, R29 and R31. It also contains a topology-transparent zone 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 Topology-Transparent Zone (TTZ): TTZ internal routers and TTZ edge routers. A TTZ internal router is a router inside the TTZ and every adjacent router of the TTZ internal router is a router inside 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 and at least one adjacent router that is inside 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 inside the TTZ. A TTZ may hide the information inside the TTZ from the outside. It may not 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 R61 and R65 to any router outside of the TTZ. In order to create a TTZ, we MUST configure the same TTZ ID on the edge routers and identify the TTZ internal links on them. In addition, we SHOULD configure the TTZ ID on every TTZ internal router which indicates that every link of the router is a TTZ internal link. 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. 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 Chen, et al. Expires January 5, 2015 [Page 5] Internet-Draft Applicability of TTZ July 2014 respectively. 3. Applicability of Topology-Transparent Zone Topology-Transparent Zone (TTZ) may be used in different cases. This section presents a number of application scenarios of TTZ and illustrates the benefits that TTZ brings in each scenario. 3.1. One Area Network Many networks start with one area. A network with only one area is easy to operate and maintain. As a network with one area becomes bigger and bigger because the increasing traffic in the network drives the expansion of the network, it needs to be split into multiple areas in general. 3.1.1. Issues on Splitting Network into Areas Splitting a network with only one area into multiple areas is a very challenging task and may raise a number of issues. 1. Significant Changes on Network Architecture There are significant changes on network architecture when splitting a network with one area into multiple areas. Originally the network has only one area, which is backbone area. This original backbone area will be split into a new backbone area and a number of non backbone areas. In general, each of the non backbone areas is connected to the new backbone area through the area border routers between the non backbone area and the backbone area. There is not any direct connection between any two non backbone areas. Each area border router summarizes the topology of its attached non backbone area for transmission on the backbone area, and hence to all other area border routers. Before splitting the network into areas, every router in the network has the information about the network topology. However, after splitting the network into areas, each router in an area has the information of the topology of the area, and it does not have the information of the topology of any other area. It has only the summary information about the other areas. 2. Service Interruptions The services carried by the network may be interrupted while the Chen, et al. Expires January 5, 2015 [Page 6] Internet-Draft Applicability of TTZ July 2014 network is being split from one area into multiple areas. 3. Complex for MPLS TE Tunnel Setup Each of the MPLS TE LSP tunnels originally in one area, which has its ingress and egress in different areas after the network splitting, needs to be re-configured and re-established. It is very complex for a MPLS TE LSP tunnel crossing areas to be set up. In order to reduce the manual configurations for a MPLS TE LSP tunnel crossing multiple areas, we use PCEs to compute the path for the tunnel. Thus we must configure PCEs for the network split into multiple areas. In addition, we need to provide a sequence of areas for the tunnel through manual configurations. The tunnel will go through the sequence of areas provided. More critically, there are some issues on using PCEs. One of them is that the path computed by PCEs for the tunnel may not be optimal. If the optimal path for the tunnel is not in the sequence of areas configured by users, the path found by PCEs for the tunnel will not be optimal. 3.1.2. Use of TTZ in One Area Network The issues mentioned above on splitting network into areas disappear if we do not split network into areas and use OSPF Topology Transparent Zone (TTZ) instead. TTZ may be applied to a group of routers and links in the network directly. For a group of routers and links connecting the routers in the group in the network, no matter where it resides in the network, we may configure it as an OSPF TTZ as long as each router in the group can reach the other routers in the group through those links. 1. No Significant Changes on Network Architecture There is not any significant changes on network architecture when an OSPF TTZ is applied to a group of routers and links in the network directly. At first, we do not add any new connection to the network, or remove any existing connection from the network. Secondly, every router outside of the TTZ is not aware of the TZZ. Even the router directly connecting to the TTZ is not aware of the TTZ. Chen, et al. Expires January 5, 2015 [Page 7] Internet-Draft Applicability of TTZ July 2014 Furthermore, every router in the network still has a topology view of the network. Except for those internal TTZ routers and links, which are hidden, every router outside of the TTZ has the link state information about all the routers and links in the network. 2. No Service Interruption For a group of routers and a number of links connecting the routers in an area, they can transfer to work as a TTZ without any service interruptions. There is not any route change while these routers are migrating to work as a TTZ. Every router in the TTZ "sees" the same network topology (the TTZ topology and the topology outside of the TTZ) and uses it to compute the routes. Thus the routing table on the router will not change. For every router outside of the TTZ, its routing table will not change either while those routers are migrating to work as a TTZ. Even though there are some new router LSAs for virtualizing TTZ, these LSAs will not change any routes. Each link in any of these LSAs represents a shortest path between two TTZ edge routers within the TTZ. 3. Easy for MPLS TE Tunnel Setup After a group of routers and links in the network is configured as an OSPF TTZ, a MPLS TE LSP tunnel with an ingress router and an egress router, which are anywhere in the network, can be configured in a way, which is the same as or similar to the way in which a MPLS TE LSP tunnel in one area network is configured. For example, in the network in Figure 1 above, a MPLS TE LSP tunnel from ingress router R15 to egress router R29 can be configured in the same way as a MPLS TE LSP tunnel in one area network through provisioning the ingress router R15's IP address, the egress router R29's IP address and some constraints for the tunnel on the ingress router R15. We do not need any PCEs for computing the constrained path for a MPLS TE LSP tunnel in the network with OSPF Topology Transparent Zones (TTZs). After a MPLS TE LSP tunnel with an ingress and egress anywhere in the network with OSPF TTZs is configured, the ingress computes the constrained path for the tunnel from the ingress to the egress in the same way as it computes the constrained path for the tunnel in one area network. The constrained path computed may go through some OSPF TTZs. Chen, et al. Expires January 5, 2015 [Page 8] Internet-Draft Applicability of TTZ July 2014 For example, in the network in Figure 1 above, the constrained path computed for the tunnel from ingress router R15 to egress router R29 may be from ingress router R15, to edge router R61 of TTZ 600, to edge router R63 of TTZ 600 and then to egress router R29. As soon as the constrained path for a MPLS TE LSP tunnel is computed or given through configuration, the LSP can be established along the path by the signaling protocol RSVP-TE. 3.2. Multi-Area Network For a network with multiple areas, it typically needs to be split into more areas when the size of the network becomes larger and larger as the traffic in the network keeps growing. 3.2.1. Issues on Splitting Network into More Areas What would happen when we split a network with multiple areas into even more areas? 1. Significant Changes on Network Architecture The changes on network architecture are significant when a network with multiple areas is split into even more areas. In the network before splitting, there is one backbone area, which is surrounded by a number of non backbone areas. Each of the non backbone areas is connected to the backbone area. There is not any direct connection between any two non backbone areas in general. Splitting the network into more areas is involved in re-arranging a number of routers and links to create new areas and make some of the existing areas to become smaller. Some of the routers and links in a new area may be from the backbone area, and the other from some of the non backbone areas. In the network after splitting, there is still one backbone area, which must be changed and be surrounded by the new non backbone areas and the existing non backbone areas some of which have been changed. Each of the non backbone areas is connected to the backbone area. 2. Service Interruptions The services carried by the network may be interrupted while the network is being split from a number of existing areas into even more areas. 3. More Configurations for Tunnel Setup Chen, et al. Expires January 5, 2015 [Page 9] Internet-Draft Applicability of TTZ July 2014 For reducing the manual configurations for a MPLS TE LSP tunnel crossing multiple areas, we use PCEs to compute the path for the tunnel. Thus more configurations for tunnel setup is needed. We must configure PCEs for each of the new areas and peer relations among the PCEs for the new areas and the PCEs for the existing areas. 3.2.2. Use of TTZ in Multi-Area Network The issues described above on splitting network into even more areas disappear if we do not split network into more areas and use OSPF TTZ instead. A TTZ may be applied to a group of routers and links in any area in the network directly. For a group of routers and links connecting the routers in the group in an area, no matter where it resides in the area, we may configure it as an OSPF TTZ as long as each router in the group can reach the other routers in the group through those links. 1. No Significant Changes on Network Architecture We can see that there is not any significant change on network architecture when an OSPF TTZ is applied to a group of routers and links in an area in the network directly. At first, we do not add any new connection to the network, or remove any existing connection from the network. Secondly, every router outside of the TTZ is not aware of the TZZ. Even the router directly connecting to the TTZ is not aware of the TTZ. Furthermore, every router in the area still has a topology view of the area. Except for those internal TTZ routers and links, which are hidden, every router outside of the TTZ has the link state information about all the routers and links in the area. 2. No Service Interruption For a group of routers and a number of links connecting the routers in an area, they can transfer to work as a TTZ without any service interruptions. There is not any route change in the network while those routers are transferring to work as a TTZ. 3. No Extra Configurations for Tunnel Setup Chen, et al. Expires January 5, 2015 [Page 10] Internet-Draft Applicability of TTZ July 2014 After a group of routers and links in an area in the network is configured as an OSPF TTZ, there is not any extra configuration for supporting setup of a MPLS TE tunnel. We do not need to configure any new PCE since there is not any new area generated after applying a TTZ to a group of routers and links in an area. 3.3. Use of TTZ on Routers in POP A Point of Presence (POP) comprises the routers in a room, a floor, a building or a group of buildings. These routers are normally in an AS or OSPF area. We may increase the network scalability significantly through configuring a POP as an OSPF TTZ. When a POP becomes a TTZ, the link state information about every link and every router inside the POP is hidden from a router outside of the POP. Only very small amount of link state information virtualizing the TTZ for the POP is distributed to the router outside of the POP. Thus, the size of the LSDB on every router in the network is reduced significantly, and the speed for the router to compute the shortest path to every destination is increased dramatically. We may also improve the network availability when we use a TTZ for a POP. In the case that a link or a router in the POP is down, the traffic may be interrupted without using any TTZ for the POP. The link state information about the link or router down needs to be distributed to every router in the network, and every router needs to compute the shortest path to every destination and download the path to its FIB. The traffic is forwarded according to the latest FIB on every router. During this process, there may be inconsist views on the network topology on different routers. The traffic interruption is minimized if we use a TTZ for the POP. The link state information about the link or router down is hidden from every router outside of the POP, which is not aware of the link or router down in the POP. Thus every router outside of the POP has the same topology view when the link or router is down. It does not compute the shortest path or download the path to its FIB. 3.4. Use of TTZ on Routers in IPRAN The IP RAN provides connectivity for IP-based mobile broadband (MBB) from LTE and 4G base stations. The ratio of MBB subscribers to total mobile subscribers keeps growing fast. It is expected to grow to nearly 40% in 2016 from 15% in 2011. At the end of 2012, China Mobile had deployed more than 500,000 nodes to support MBB services according to PTN Market Research 2013 Frost & Chen, et al. Expires January 5, 2015 [Page 11] Internet-Draft Applicability of TTZ July 2014 Sullivan. The size of the IP RAN network must seamlessly scale from tens of thousands to hundreds of thousands of nodes. OSPF TTZ may be used in a big IP RAN network for reducing the partition of the network into more OSPF areas. Thus, the network can smoothly scale to hundreds of thousands of nodes. In addition, OSPF TTZ can make the operation and maintenance of the network easier. 3.5. Use of TTZ on Routers from Same Vendor In a network, we may separate the routers from different vendors through using TTZ in order to alleviate the possible multi-vendor inter-operability issue. For example, the routers from a same vendor can be configured as a TTZ, and the routers outside of this TTZ are developed by different vendors. 3.6. Use of TTZ on Routers in a Power Saving Group A power saving group is a set of routers and links, wherein the routers are connected through the links and there is a redundant route or path from a router in the group to another router in the group. The redundant path is within the group. That is that every hop in the redundant path is within the group. In a power saving group, when the usage of a link within the group between two routers crosses a given threshold value for shutting down the link to save energy, the link will be shut down. This link down in the power saving group will not be distributed to any router outside of the group. The traffic outside of the group will not be affected by the link down inside the group. From the characteristics of a power saving group, we can see that a power saving group is very suitable to be configured as a TTZ. 4. Security Considerations This document does not introduce any new security issues. 5. Contributors Yuanbin Yin Huawei Technologies Beijing, China Email: yinyuanbin@huawei.com Chen, et al. Expires January 5, 2015 [Page 12] Internet-Draft Applicability of TTZ July 2014 6. Acknowledgement The authors would like to thank Alvaro Retana, Acee Lindem, and Dean Cheng for their valuable comments on this draft. 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. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. 7.2. Informative References [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions", RFC 5786, March 2010. [OSPF-TTZ] Chen, H., Li, R., Cauchie, G., So, N., and L. Liu, "OSPF Topology-Transparent Zone", draft-chen-ospf-ttz, Work in Progress, July 2012. Authors' Addresses Huaimo Chen Huawei Technologies Boston, MA USA Email: huaimo.chen@huawei.com Chen, et al. Expires January 5, 2015 [Page 13] Internet-Draft Applicability of TTZ July 2014 Renwei Li Huawei Technologies 2330 Central expressway Santa Clara, CA USA Email: renwei.li@huawei.com Gregory Cauchie FRANCE Email: greg.cauchie@gmail.com Ning So Tata Communications 2613 Fairbourne Cir. Plano, TX 75082 USA Email: ningso01@gmail.com Vic Liu China Mobile No.32 Xuanwumen West Street, Xicheng District Beijing, 100053 China Email: liuzhiheng@chinamobile.com Lei Liu UC Davis USA Email: liulei.kddi@gmail.com Chen, et al. Expires January 5, 2015 [Page 14]