Internet Engineering Task Force H. Chen Internet-Draft R. Li Intended status: Standards Track Huawei Technologies Expires: August 22, 2013 G. Cauchie France Telecom N. So Tata Communications A. Retana Cisco Systems February 18, 2013 IS-IS Topology-Transparent Zone draft-chen-isis-ttz-00.txt Abstract This document presents a topology-transparent zone in a domain. A topology-transparent zone comprises a group of routers and a number of circuits connecting these routers. Any router outside of the zone is not aware of the zone. The information about the circuits and routers inside the zone is not distributed to any router outside of the zone. Any link state change such as a circuit down inside the zone is not seen by any router outside of the zone. 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 August 22, 2013. 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 Chen, et al. Expires August 22, 2013 [Page 1] Internet-Draft Topology-Transparent Zone February 2013 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 . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 5 4.1. Overview of Topology-Transparent Zone . . . . . . . . . . 5 4.2. An Example of TTZ . . . . . . . . . . . . . . . . . . . . 5 4.2.1. Creation of a TTZ . . . . . . . . . . . . . . . . . . 5 4.2.2. TTZ as a Group of Edge Routers Connected . . . . . . . 8 4.2.3. TTZ as a Single Router . . . . . . . . . . . . . . . . 8 5. Changes to IS-IS Protocols in LSP . . . . . . . . . . . . . . 9 5.1. New Sub-TLV for TTZ ID . . . . . . . . . . . . . . . . . . 9 5.2. One Bit to Indicate an Internal TTZ Circuit . . . . . . . 10 6. Constructing LSP . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Constructing LSP for a Router in TTZ . . . . . . . . . . . 11 6.2. Constructing LSP for TTZ as a Group of Edge Routers . . . 12 6.3. Constructing LSP for TTZ as a Router . . . . . . . . . . . 12 6.3.1. Selection of TTZ-DR for TTZ . . . . . . . . . . . . . 12 6.3.2. Constructing LSP for TTZ as a Router . . . . . . . . . 13 7. Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 14 7.1. Group of Edge Routers for TTZ . . . . . . . . . . . . . . 14 7.2. Single Router for TTZ . . . . . . . . . . . . . . . . . . 15 8. Distribution of LSPs . . . . . . . . . . . . . . . . . . . . . 16 8.1. Distribution of LSPs within TTZ . . . . . . . . . . . . . 16 8.2. Distribution of LSPs through TTZ . . . . . . . . . . . . . 16 9. Computation of Routing Table . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Chen, et al. Expires August 22, 2013 [Page 2] Internet-Draft Topology-Transparent Zone February 2013 1. Introduction The number of routers in an Autonomous System (AS) becomes larger and larger as the Internet traffic keeps growing. Thus the Intermediate System To Intermediate System (IS-IS) Link State Database (LSDB) and IS-IS routing table are bigger and bigger. Any link state change in an AS leads to a number of link state distributions to every router in the AS. This triggers every router in the AS to re-calculate its IS-IS routes, update its Routing Information Base (RIB) and Forwarding Information Base (FIB). All these will consume network resource including network bandwidth and Central Process Unit (CPU) time. This blocks further expansions of a network. RFC 1142 "OSI IS-IS Intra-domain Routing Protocol", which is a republication of ISO/IEC 10589, describes IS-IS areas or levels in an Autonomous System (AS). Each level 1 area has a number of level 1 and level 2 routers connected to the level 2 area. Each level 1 and level 2 router may summarize the topology of its attached level 1 areas to the level 2 area or vice versa. Through splitting a 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, it is complex for a Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switching Path (LSP) crossing multiple areas to be setup. In general, 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. Thirdly, some policies need to be configured on level 1 and level 2 routers for sumarizing the routes from a level 1 area to level 2 area or vice versa. Furthermore, route convergence may be slower. A router in an IS-IS area can see all other routers in the same area. A link-state change anywhere in an IS-IS area will be populated everywhere in the same area, and may even be distributed to other areas in the same AS Chen, et al. Expires August 22, 2013 [Page 3] Internet-Draft Topology-Transparent Zone February 2013 indirectly. For example, all the routers and circuits in a Point-Of- Presence (POP) in an IS-IS area will be seen by all the other routers in the same area. Any link state change in the POP will be distributed to all the other routers in the same area and may be distributed to routers in other areas indirectly. A link state change in an area will lead to every router in the same area to re-calculate its IS-IS routes, update its RIB and FIB. It may also lead to a number of link state distributions to other areas. This will trigger routers in other areas to re-calculate their IS-IS routes, update their RIBs and FIBs. Thus the route convergence is slower. This document presents a topology-transparent zone in a domain or an area and describes extensions to IS-IS for supporting the topology- transparent zone, which may resolve the issues above. A topology-transparent zone comprises a group of routers and a number of circuits connecting these routers. Any router outside of the zone is not aware of the zone. The information about the circuits and routers inside the zone is not distributed to any router outside of the zone. Any link state change such as a circuit down inside the zone is not seen by any router outside of the zone. 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. Requirements Topology-Transparent Zone (TTZ) may be deployed for resolving some ctricial issues such as scalability in existing networks and future networks. The requirements for TTZ are listed as follows: o TTZ MUST be backward compitable. When a TTZ is deployed on a set of routers in a network, the routers outside of the TTZ in the network do not need to know or support TTZ. o TTZ MUST support at least one more levels of network hierarchies, in addition to the hierarchies supported by existing routing protocols. o Users SHOULD be able to easily set up an end to end service crossing TTZs. Chen, et al. Expires August 22, 2013 [Page 4] Internet-Draft Topology-Transparent Zone February 2013 o The configuration for a TTZ in a network SHOULD be minimum. o The changes on the existing protocols for supporting TTZ SHOULD be minimum. 4. Topology-Transparent Zone 4.1. Overview of Topology-Transparent Zone A Topology-Transparent Zone (TTZ) comprises an Identifier (ID), a group of routers and a number of circuits connecting the routers. A Topology-Transparent Zone is in an IS-IS sub domain (area). The ID of a Topology-Transparent Zone (TTZ) or TTZ ID is a number that is unique for identifying an entity such as a node in an IS-IS sub domain (area). It is not zero in general. In addition to having the functions of an IS-IS level or area, an IS-IS TTZ makes some improvements on an IS-IS level or area, which include: o An IS-IS TTZ is virtualized as an object, which may be a group of TTZ edge routers connected or a single router. o An IS-IS 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 TTZ. o No Policy configuration is needed on any edge router of a TTZ. 4.2. An Example of TTZ 4.2.1. Creation of a TTZ The figure below illustrates an example of a routing domain containing a topology-transparent zone: TTZ 600. Chen, et al. Expires August 22, 2013 [Page 5] Internet-Draft Topology-Transparent Zone February 2013 TTZ 600 / / ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^ ( ) ===[R15]========(==[R61]-----------------[R63]==)========[R29]=== || ( | \ / | ) || || ( | \ / | ) || || ( | \ / | ) || || ( | \ / | ) || || ( | \ / | ) || || ( | \ / | ) || || ( | \ / | ) || || ( | _____[R71] | ) || || ( | / / \ | ) || || ( | [R73] / \ | ) || || ( | / \ | ) || || ( | / \ | ) || || ( | / \ | ) || || ( | / \ | ) || || ( | / \ | ) || ===[R17]========(==[R65]-----------------[R67]==)========[R31]=== \\ (// \\ ) // || //v~v~v~v~v~v~v~v~v~v~v~v~v~\\ || || // \\ || || // \\ || || // \\ || || // \\ || || // \\ || \\ // \\ // =====[R23]======================================[R25]===== // \\ // \\ // \\ Figure 1: An Example of TTZ The routing domain comprises routers R15, R17, R23, R25, R29 and R31. It also contains a topology-transparent zone TTZ 600. The TTZ 600 comprises routers R61, R63, R65, R67, R71 and R73, and the circuits 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 Chen, et al. Expires August 22, 2013 [Page 6] Internet-Draft Topology-Transparent Zone February 2013 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 inside the TTZ. A TTZ MUST hide the information inside the TTZ from the outside. It MUST NOT directly distribute any internal information about the TTZ to a router outside of the TTZ. For instance, the TTZ in the figure above MUST NOT send the information about TTZ internal router R71 to any router outside of the TTZ in the routing domain; it MUST NOT send the information about the circuit between TTZ router R61 and R65 to any router outside of the TTZ. In order to create a Topology-Transparent Zone (TTZ), we MUST configure the same TTZ ID on every circuit that connects routers inside the TTZ and every router in the TTZ MUST support TTZ feature. For example, the same TTZ ID is configured on the nine circuits below: o the circuit between router R61 and R65, o the circuit between router R65 and R67, o the circuit between router R67 and R63, o the circuit between router R63 and R61, o the circuit between router R71 and R61, o the circuit between router R71 and R63, o the circuit between router R71 and R65, o the circuit between router R71 and R67 and Chen, et al. Expires August 22, 2013 [Page 7] Internet-Draft Topology-Transparent Zone February 2013 o the circuit between router R71 and R73. Thus six routers R61, R63, R65, R67, R71 and R73, and nine circuits among these six routers form a topology-transparent zone TTZ 600 in the figure above. The configuration of a TTZ can be simplified by just provisioning a TTZ ID on every TTZ internal router instead of on each circuit of every TTZ internal router. The configuration of the TTZ ID on a router indicates that every circuit of the router is a TTZ internal circuit. On every edge router of the TTZ, the TTZ ID is still configured on each circuit connecting to a TTZ router. 4.2.2. TTZ as a Group of Edge Routers Connected From a router outside of the TTZ, a TTZ is seen as a group of TTZ edge routers fully connected when the TTZ is virtualized as the group of TTZ edge routers 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 respectively. 4.2.3. TTZ as a Single Router A TTZ is seen as a single router from a router outside of the TTZ when the TTZ is virtualized as a single router. For instance, router R15 in the figure above, which is outside of TTZ 600 and connected to TTZ 600 through TTZ edge router R61, sees TTZ 600 as a single router. A router outside of a TTZ sees a number of circuits connected to the TTZ as a single router, each of which is connected to a router outside of the TTZ. For instance, router R15 sees TTZ 600 as a single router with six circuits, connecting to router R15, R17, R23, R25, R29 and R31 respectively. A TTZ as a special single router considers every connection between a router outside of the TTZ and an edge router of the TTZ as a circuit. The Router ID of the virtualized representation of the TTZ SHOULD be the largest or smallest interface IP address of the TTZ-DR (TTZ-DIS) (see Section 6.3.1). Chen, et al. Expires August 22, 2013 [Page 8] Internet-Draft Topology-Transparent Zone February 2013 5. Changes to IS-IS Protocols in LSP There are a number of ways to extend the existing IS-IS protocols to support TTZ in a Link State Packet (LSP). This section describes a few of them. o One way is to use a new sub-TLV for a TTZ ID to indicate that the circuit described belongs to which TTZ. o Alternatively, a bit in an existing sub-TLV indicates that a circuit is a TTZ circuit or an internal circuit of a TTZ. 5.1. New Sub-TLV for TTZ ID The format of extended IS reachability TLV is illustrated in the figure below. Length in Byte +----------------------+ | Type = 22 | 1 +----------------------+ | Length | 1 +----------------------+ | Neighbor ID | 7 +----------------------+ | Default Metric | 3 +----------------------+ | Length of Sub-TLVs | 1 +----------------------+ | Sub-TLVs | Length of Sub-TLVs +----------------------+ | | | . . . | | | +----------------------+ | Neighbor ID | 7 +----------------------+ | Default Metric | 3 +----------------------+ | Length of Sub-TLVs | 1 +----------------------+ | Sub-TLVs | Length of Sub-TLVs +----------------------+ Figure 2: Extended IS Reachability TLV An extended IS reachability TLV may contain information about a Chen, et al. Expires August 22, 2013 [Page 9] Internet-Draft Topology-Transparent Zone February 2013 number of neighbors. There may be a series of sub-TLVs for each neighbor in the TLV. A new sub-TLV may be added into the sub-TLVs for a neighbor within the Extended IS Reachability TLV in the figure above. This new sub- TLV has the same format as the sub-TLV for the Traffic Engineering Extensions in RFC 5305, which is shown in the figure below. Length in Byte +----------------------+ | Sub-Type = 30 | 1 +----------------------+ | Length | 1 +----------------------+ | TTZ ID | 4 +----------------------+ Figure 3: Sub-TLV for TTZ ID The sub-TLV for TTZ ID has 1 byte of Sub-Type, 1 byte of Length of the value field of the sub-TLV, which is followed by 4 bytes of value field for TTZ ID. The sub-TLV for TTZ ID is OPTIONAL and MUST appear at most once for an IS neighbor. If this kind of sub-TLV appears more than once under the same IS neighbor in a received Link State Packet (LSP), only the first one SHOULD be considered and the others should be ingored. For a circuit connecting to an neighboring router outside of a TTZ from a TTZ edge router, there is not any TTZ ID sub-TLV under the neighbor or the value field of the sub-TLV for TTZ ID is zero, indicating that this circuit is an external TTZ circuit. For a circuit connecting to an neighboring router inside a TTZ, there is a TTZ ID sub-TLV under the neighbor, the value field for TTZ ID in the sub-TLV is not zero and is a TTZ ID, indicating that this circuit is an internal TTZ circuit to the neighbor and the circuit belongs to the TTZ given by the TTZ ID. 5.2. One Bit to Indicate an Internal TTZ Circuit The existing link-attribute sub-TLV within the extended IS reachability TLV has 16-bit flags of value field. One of 16-bit flags may be used to indicate an Internal TTZ circuit as follows: Chen, et al. Expires August 22, 2013 [Page 10] Internet-Draft Topology-Transparent Zone February 2013 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-Type = 19 | Length | |I| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I bit flag: 1: This indicates that the router circuit/link is an internal circuit to a router inside the TTZ. 0: This indicates that the router circuit/link is an external circuit. Figure 4: Bit to Indicate Internal TTZ Link The link attribute sub-TLV is OPTIONAL and MUST appear at most once for an IS neighbor. If this kind of sub-TLV appears more than once under the same IS neighbor in a received Link State Packet (LSP), only the first one SHOULD be considered and the others should be ingored. For a circuit connecting to an neighboring router inside a TTZ, there is a link attribute sub-TLV under the neighbor and the value of I bit flag in the sub-TLV for the neighbor is set to one, indicating that this circuit is an internal TTZ circuit to the neighbor. For a circuit connecting to an neighboring router outside of a TTZ from a TTZ edge router, there is not any link attribute sub-TLV for the neighbor or the value of I bit flag in the sub-TLV for the neighbor is zero, indicating that this circuit is an external TTZ circuit. 6. Constructing LSP Two types of Link State Packets(LSPs) are generated. One is constructed by every router in a TTZ for the router to describe the circuits connecting to it. The other is generated by some routers in the TTZ to virtualize the TTZ as a group of edge routers connected or a single router. 6.1. Constructing LSP for a Router in TTZ Every router in a TTZ constructs a LSP for the router that comprises both the circuits connecting to the routers inside the TTZ and the circuits connecting to the routers outside of the TTZ. It sends this Chen, et al. Expires August 22, 2013 [Page 11] Internet-Draft Topology-Transparent Zone February 2013 LSP to its neighboring routers in the TTZ. For each of the circuits in the LSP, it can be represented in one of the ways described in the previous section. For example, when "One Bit to Indicate an Internal TTZ circuit" is used as an extension, for each of the router circuits in the LSP, the value of I bit flag is set to one for an internal circuit inside the TTZ; and the value of I bit flag is set to zero for an external circuit connecting to a router outside of the TTZ. When a router inside a TTZ receives a link state packet (LSP) from a neighboring router in the TTZ, it stores the link state and floods the link state to the other neighboring routers in the TTZ. When a TTZ edge router receives a TTZ internal link state packet for a router inside the TTZ from a neighboring router in the TTZ, it stores the link state and floods the link state to the other neighboring routers inside the TTZ. It does not flood the link state to any of its neighboring routers outside of the TTZ. 6.2. Constructing LSP for TTZ as a Group of Edge Routers For every edge router of a TTZ, in addition to generate a LSP described above, it constructs a second LSP for the router and sends this second LSP to its neighboring routers. The second LSP comprises two groups of circuits. The first group of circuits are the circuits connecting the routers outside of the TTZ from this TTZ edge router. These circuits are normal circuits. There is a circuit for every adjacency between this TTZ edge router and a router outside of the TTZ. The second group of circuits are the "virtual" circuits. For each of the other TTZ edge routers, there is a "virtual" circuit to it from this TTZ edge router. The cost of the circuit from this TTZ router to one of the other TTZ edge routers may be the cost of the shortest path from this TTZ edge router to it. 6.3. Constructing LSP for TTZ as a Router 6.3.1. Selection of TTZ-DR for TTZ Every TTZ has a TTZ Designated Router (TTZ-DR). The TTZ-DR originates LSPs for the TTZ. The TTZ-DR for a TTZ is elected as follows: When a TTZ router first becomes functional, it checks to see whether there is currently a TTZ-DR for the TTZ. If there is, it accepts that TTZ-DR, regardless Chen, et al. Expires August 22, 2013 [Page 12] Internet-Draft Topology-Transparent Zone February 2013 of its router ID. Otherwise, the router itself becomes TTZ-DR if it has the highest router ID among all the TTZ routers. 6.3.2. Constructing LSP for TTZ as a Router For the TTZ-DR in a TTZ, in addition to generate a LSP described above, it constructs a second LSP or special LSP for the TTZ as a special single router and sends this second LSP to its neighboring routers. The second LSP comprises all the circuits connecting the routers outside of the TTZ from any TTZ edge router. The LSP ID is the ID of the special router for the TTZ. When the TTZ-DR in the TTZ constructs and sends an IS-IS packet to its neighboring routers, it sets the Source ID in the packet header of the packet to the ID of the special router for the TTZ. The ID of the special router can be derived from the largest interface IP address of the TTZ-DR if it is not the ID of the TTZ-DR; otherwise, it can be dereived the smallest interface IP address of the TTZ-DR. A procedure for constructing all the circuits of a Special LSP (SL) on the TTZ-DR is described below in pseudo code. From the point of view of the router outside of the TTZ, this Special LSP (SL) does not contain any TTZ specific information, it is just a normal LSP containing indormation about circuits from the router for the TTZ to the routers outside of the TTZ. For each router LSP in the TTZ { For each router circuit in the LSP { If the circuit is an external circuit { Add the circuit into router LSP SL as a normal circuit; } } } Figure 5: Procedure for Constructing LSP for TTZ Each LSP in the TTZ is a LSP that is generated by a router inside the Chen, et al. Expires August 22, 2013 [Page 13] Internet-Draft Topology-Transparent Zone February 2013 TTZ and is sent to routers inside the TTZ. In the case of that "One Bit to Indicate an Internal TTZ circuit" is used as an extension to the link attribute sub-TLV, the condition of the If statement is true if there is not any link attribute sub-TLV for the neighbor or the value of I bit flag in the sub-TLV for the neighbor is zero. In the body of the If statement, the circuit for the external circuit is added into the LSP SL as a normal circuit. 7. Establishing Adjacencies A router in a TTZ forms an adjacency with another router in the TTZ in the same way as a normal router when these two routers have a common connection. An alternative way for forming an adjacency between two routers in a TTZ is to extend hello protocol. Hello protocol is extended to include TTZ ID in hello packets. The procedure for handling hellos is changed to consider TTZ ID. When two routers have the same TTZ IDs in their hellos, an adjacency between these two routers is to be formed. For an edge router in a TTZ, in addtion to establishing adjacencies with other routers in the TTZ that have connections with the edge routerk, it forms an adjacency with any router outside of the TTZ that has a connection with the edge router. When the edge router in the TTZ forms the adjacency with the router outside of the TTZ, there are a few of options. A first option is that it acts as a TTZ edge router, which is one of the group of edge routers for TTZ; A second option is that it acts as a special single router for the TTZ. 7.1. Group of Edge Routers for TTZ An edge router of a TTZ, acting as one of the group of edge routers for the TTZ, forms an adjacency with a router outside of the TTZ in a way descibed below. During and after the adjacency establishment, every IS-IS protocol packet such as CSNP, which is sent to the router outside of the TTZ by the edge router, contains the edge router identifier (ID) as Source ID. When the edge router synchronizes its link state database with the Chen, et al. Expires August 22, 2013 [Page 14] Internet-Draft Topology-Transparent Zone February 2013 router outside of the TTZ, it sends the router outside of the TTZ the information about all the LSPs except for the LSPs belong to the TTZ that are hidden from any router outside of the TTZ. At the end of the link state database synchronization, the edge router originates its own LSP and sends this LSP to the router outside of the TTZ. This LSP contains two groups of circuits. The first group of circuits are the circuits connecting to the routers outside of the TTZ from this TTZ edge router. The second group of circuits are the "virtual" circuits connecting to the other TTZ edge routers from this TTZ edge router. From the point of view of the router outside of the TTZ, it sees the other end as a normal router and forms the adjacency in the same way as a normal router. It is not aware of anything about its neighboring TTZ. From the LSPs related to the TTZ edge router in the other end, it knows that the TTZ edge router is connected to each of the other TTZ edge routers and some routers outside of the TTZ. 7.2. Single Router for TTZ An edge router of a TTZ, acting as a special single router for the TTZ, forms an adjacency with a router outside of the TTZ in a way descibed below. During and after the adjacency establishment, every IS-IS protocol packet such as CSNP, which is sent to the router outside of the TTZ by the edge router, contains the special single router ID as Source ID. When the edge router synchronizes its link state database with the router outside of the TTZ, it sends the router outside of the TTZ the information about all the LSPs except for the LSPs belong to the TTZ that are hidden from any router outside of the TTZ. At the end of the link state database synchronization, the LSP for the TTZ is originated and sent to the router outside of the TTZ. This LSP contains the router circuits from every TTZ edge router to routers outside of the TTZ. From the point of view of the router outside of the TTZ, it sees the other end as a normal single router and forms the adjacency in the same way as a normal router. It is not aware of anything about its neighboring TTZ. From the LSPs related to the special router in the other end, it knows that the special router for the TTZ is connected to the routers outside of the TTZ having connections to edge routers of the TTZ. Chen, et al. Expires August 22, 2013 [Page 15] Internet-Draft Topology-Transparent Zone February 2013 8. Distribution of LSPs LSPs can be divided into two classes according to their distributions. One class of LSPs is distributed within a TTZ. The other is distributed through a TTZ. 8.1. Distribution of LSPs within TTZ Any LSP generated for a router in a TTZ is distributed within the TTZ. It will not be distributed to any router outside of the TTZ. For example, any router LSP generated for a router in a TTZ is distributed within the TTZ. It will not be distributed to any router outside of the TTZ. Any pseudonode LSP generated for a broadcast network inside a TTZ, is distributed within the TTZ. It will not be distributed to any router outside of the TTZ. 8.2. Distribution of LSPs through TTZ Any LSP about a link state outside of a TTZ received by an edge router of the TTZ is distributed through the TTZ; and any LSP about a link state for the TTZ is distributed through the TTZ. For example, when an edge router of a TTZ receives an LSP for a link state outside of the TTZ from a router outside of the TTZ, it floods it to its neighboring routers both inside the TTZ and outside of the TTZ. This LSP may be any LSP such as a router LSP that is distributed in a domain. The routers in the TTZ continue to flood the LSP. When another edge router of the TTZ receives the LSP, it floods the LSP to its neighboring routers both outside of the TTZ and inside the TTZ. In the case that a TTZ is virtualized as a group of edge routers of the TTZ connected, every edge router of the TTZ generates a router LSP for the TTZ. This LSP is distributed to the routers outside of the TTZ and to the routers inside the TTZ. 9. Computation of Routing Table The computation of the routing table on a router outside of a TTZ is the same as that described in RFC 1142. On a router in a TTZ, the computation of the routing table has the same procedure flow as that described in RFC 1142, but extends the meaning of a circuit and an association between two vertexes. In this section, we specify the Chen, et al. Expires August 22, 2013 [Page 16] Internet-Draft Topology-Transparent Zone February 2013 extensions, and describe the routing table computation on a router inside the TTZ. A link between two vertexes can be a TTZ circuit. It can also be a normal circuit. When examining the LSP associated with vertex V, for each described circuit in the LSP, supposing that vertex W is the other end of the link, o if it is a normal circuit, then vertex W is an adjacent vertex of vertex V; o if it is an internal TTZ circuit and the LSP is generated by a router in a TTZ, then vertex W can be considered as an adjacent vertex of vertex V; o if it is an external TTZ circuit and the LSP is generated by a TTZ edge router, then vertex W, which is the other end of the external TTZ circuit and outside of the TTZ, can be considered as an adjacent vertex of vertex V. When a TTZ is virtualized as a group of TTZ edge routers fully connected, the routing table on a router inside the TTZ is computed through using the link state database (LSDB) containing the LSPs for the topology of the TTZ and the LSPs for the topology outside of the TTZ. That is that the shortest path to every destination both inside the TTZ and outside of the TTZ is computed over all the circuits including the circuits inside the TTZ and the circuits outside of the TTZ. 10. Security Considerations The mechanism described in this document does not raise any new security issues for the IS-IS protocols. 11. IANA Considerations 12. Acknowledgement The author would like to thank Dean Cheng, Acee Lindem for their valuable comments on this draft. 13. References Chen, et al. Expires August 22, 2013 [Page 17] Internet-Draft Topology-Transparent Zone February 2013 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142, February 1990. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008. [RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link Attribute Sub-TLV", RFC 5029, September 2007. 13.2. Informative References [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008. Authors' Addresses Huaimo Chen Huawei Technologies Boston, MA US Email: huaimo.chen@huawei.com Renwei Li Huawei Technologies 2330 Central expressway Santa Clara, CA US Email: renwei.li@huawei.com Chen, et al. Expires August 22, 2013 [Page 18] Internet-Draft Topology-Transparent Zone February 2013 Gregory Cauchie France Telecom 38-40 avenue du General LECLERC Issy-les-Moulineaux 92130, FRANCE Email: greg.cauchie@gmail.com Ning So Tata Communications 2613 Fairbourne Cir. Plano, TX 75082 USA Email: ning.so@tatacommunications.com Alvaro Retana Cisco Systems 2610 Wycliff Road Raleigh, NC 27607 USA Email: aretana@cisco.com Chen, et al. Expires August 22, 2013 [Page 19]