Internet Engineering Task Force H. Chen Internet-Draft R. Li Intended status: Standards Track Huawei Technologies Expires: April 26, 2012 G. CAUCHIE France Telecom October 24, 2011 OSPF Topology-Transparent Zone draft-chen-ospf-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 links connecting these routers. Any router outside of the zone is not aware of the zone. The information about the links and routers inside the zone is not distributed to any router outside of the zone. Any link state change such as a link 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 April 26, 2012. Copyright Notice Copyright (c) 2011 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 Chen, et al. Expires April 26, 2012 [Page 1] Internet-Draft Topology-Transparent Zone October 2011 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 4. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 4 4.1. TTZ as a Group of Edge Routers Connected . . . . . . . . . 7 4.2. TTZ as a Single Router . . . . . . . . . . . . . . . . . . 7 5. Changes to OSPF Protocols in Router LSA . . . . . . . . . . . 8 5.1. One Bit to Indicate an Internal TTZ Link . . . . . . . . . 8 5.2. A New Field for TTZ ID to Indicate a TTZ Link . . . . . . 10 6. Constructing and Maintaining Router LSA . . . . . . . . . . . 11 6.1. Router LSA for a Router in TTZ . . . . . . . . . . . . . . 11 6.2. Router LSAs for TTZ as a Group of Edge Routers . . . . . . 12 6.3. Router LSA for TTZ as a Router . . . . . . . . . . . . . . 12 6.3.1. Selection of TTZ-DR for TTZ . . . . . . . . . . . . . 12 6.3.2. Constructing Router LSA for TTZ as a Router . . . . . 13 6.3.3. Maintaining Router LSA for TTZ as a Router . . . . . . 15 7. Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 15 7.1. Group of Edge Routers for TTZ . . . . . . . . . . . . . . 16 7.2. Single Router for TTZ . . . . . . . . . . . . . . . . . . 16 8. Distribution of LSAs . . . . . . . . . . . . . . . . . . . . . 17 8.1. Distribution of LSAs within TTZ . . . . . . . . . . . . . 17 8.2. Distribution of LSAs through TTZ . . . . . . . . . . . . . 17 9. Computation of Routing Table . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Chen, et al. Expires April 26, 2012 [Page 2] Internet-Draft Topology-Transparent Zone October 2011 1. Introduction The number of routers in an Autonomous System (AS) becomes larger and larger as the Internet traffic keeps growing. Thus the Open Shortest Path First (OSPF) Link State Database (LSDB) and OSPF 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 OSPF 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. RFC 2328 "OSPF Version 2" describes OSPF areas in an AS. Each area has a number of area border routers connected to the backbone area. Each area border router summarizes the topology of its attached non backbone areas for transmission on the backbone, and hence to all other area border routers. A big AS may be divided into a number of OSPF areas. However, some policies need to be applied on area border routers for reducing the number of link states such as summary LSAs to be distributed to other routers in other areas. In this case, a router in an OSPF area can see all other routers in the same area. A link-state change anywhere in an OSPF area will be populated everywhere in the same area, and may even be distributed to other areas in the same AS indirectly. For example, all the routers and links in a Point-Of-Presence (POP) in an OSPF 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 OSPF 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 OSPF routes, update their RIBs and FIBs. This document presents a topology-transparent zone in a domain or an area and describes extensions to OSPFv2 for supporting the topology- transparent zone. A topology-transparent zone comprises a group of routers and a number of links connecting these routers. Any router outside of the zone is not aware of the zone. The information about the links and routers inside the zone is not distributed to any router outside of the zone. Any link state change such as a link down inside the zone is not seen by any router outside of the zone. Chen, et al. Expires April 26, 2012 [Page 3] Internet-Draft Topology-Transparent Zone October 2011 2. Terminology This document uses terminologies defined in RFC 2328, and RFC 2740. 3. 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. 4. 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 domain. The ID of a Topology-Transparent Zone (TTZ) or TTZ ID is a number that is unique for identifying a node in an OSPF domain. It is not zero in general. The figure below illustrates an example of a routing domain containing a topology-transparent zone: TTZ 600. Chen, et al. Expires April 26, 2012 [Page 4] Internet-Draft Topology-Transparent Zone October 2011 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 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 Chen, et al. Expires April 26, 2012 [Page 5] Internet-Draft Topology-Transparent Zone October 2011 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 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 link 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 links below: o the link between router R61 and R65, o the link between router R65 and R67, o the link between router R67 and R63, o the link between router R63 and R61, o the link between router R71 and R61, o the link between router R71 and R63, o the link between router R71 and R65, o the link between router R71 and R67 and Chen, et al. Expires April 26, 2012 [Page 6] Internet-Draft Topology-Transparent Zone October 2011 o the link between router R71 and R73. Thus six routers R61, R63, R65, R67, R71 and R73, and nine links among these six routers form a topology-transparent zone TTZ 600 in the figure above. For a router in a TTZ, there is a little bit of changes in the format of the OSPF protocol data. In addition, there are some corresponding changes in the related OSPF protocol procedures. There are a number of ways to make some of these changes. A TTZ may be virtualized as a different object in a different way. In one way, a TTZ may be virtualized as a group of edge routers fully connected. In another way, a TTZ may be seen as a single router. These virtualizations of TTZ is described below. 4.1. 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, which are 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 from one edge router to another edge router is the cost of the shortest path between these 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.2. TTZ as a Single Router A TTZ is seen as a single router from a router outside of the TTZ. 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 links 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 links, 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 link. There are a few of options for the router ID of this special router. Chen, et al. Expires April 26, 2012 [Page 7] Internet-Draft Topology-Transparent Zone October 2011 o One option is that the TTZ ID is used as the router ID of the special router. o Another option is that the biggest router ID among the router IDs of routers in the TTZ is selected as the router ID of that special router. o The third option is that the smallest router ID among the router IDs of routers in the TTZ is used as the router ID of the special router. The first option "the TTZ ID is used as the router ID of the special router" is recommended. 5. Changes to OSPF Protocols in Router LSA There are a number of ways to extend the existing OSPF protocols to support TTZ in a router LSA. This section describes a couple of them. o One way is to use one bit to indicate that a link is a TTZ link or an internal link of a TTZ in a router LSA. o A another option is that a new field for a TTZ ID may be added into a router link to indicate that the link described belongs to which TTZ. The first option "use one bit to indicate an internal TTZ link" is preferred. 5.1. One Bit to Indicate an Internal TTZ Link A router LSA contains the description of a number of router links. The existing format of a router LSA is illustrated as follows: Chen, et al. Expires April 26, 2012 [Page 8] Internet-Draft Topology-Transparent Zone October 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |V|E|B| 0 | # links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | # TOS | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | 0 | TOS metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Figure 2: Format of Router LSA For a router link, the value of an eight bit Type field indicates the kind of the link. The value of the Type field may be 1, 2, 3 or 4, which indicates that the kind of the link is a point-to-point connection to another router, a connection to a transit network, a connection to a stub network, or a virtual link respectively. The existing eight bit Type field for a router link may be split into two fields as follows: Chen, et al. Expires April 26, 2012 [Page 9] Internet-Draft Topology-Transparent Zone October 2011 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | I | Type-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I bit flag: 1: This indicates that the router link is an internal link to a router inside the TTZ. 0: This indicates that the router link is an external link. Type-1: The kind of the link. Figure 3: Bit to Indicate Internal TTZ Link For a link inside a TTZ, the value of I bit flag is set to one, indicating that this link is an internal TTZ link. For a link connecting to a router outside of a TTZ from a TTZ edge router, the value of I bit flag is set to zero, indicating that this link is an external TTZ link. The value of Type-1 field may have value 1, 2, 3, or 4, which indicates that the kind of a link being described is a point-to-point connection to another router, a connection to a transit network, a connection to a stub network, or a virtual link respectively. 5.2. A New Field for TTZ ID to Indicate a TTZ Link A new field for a TTZ ID is added into a router link to indicate that the link described belongs to which TTZ in the figure below. Chen, et al. Expires April 26, 2012 [Page 10] Internet-Draft Topology-Transparent Zone October 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | # TOS | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | 0 | TOS metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTZ ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: TTZ ID to Indicate TTZ Link If the value of the new field (TTZ ID) is zero, it indicates that the corresponding link is a link connecting to a router outside of the TTZ. If the value of the new field is not zero and is a TTZ ID, it indicates that the link described belongs to the TTZ given by the TTZ ID in the new field. 6. Constructing and Maintaining Router LSA Two types of router LSAs are generated. One is constructed by every router in a TTZ for the router to describe the links connecting to it. The other is generated by some routers in the TTZ for the TTZ to virtualize the TTZ as a group of edge routers connected or a single router. 6.1. Router LSA for a Router in TTZ Every router in a TTZ constructs a router LSA for the router that comprises the router links connecting the routers inside the TTZ and the router links connecting to the routers outside of the TTZ. It sends this router LSA to its neighboring routers in the TTZ. For each of the router links in the router LSA, it can be represented in one of the ways described in the previous section. For example, when "One Bit to Indicate an Internal TTZ Link" is used as an extension to the link type, for each of the router links in the router LSA, the value of I bit flag is set to one for an internal link inside the TTZ; and the value of I bit flag is set to zero for an external link connecting to a router outside of the TTZ; the value Chen, et al. Expires April 26, 2012 [Page 11] Internet-Draft Topology-Transparent Zone October 2011 of Type-1 field may have value 1, 2, 3, or 4, which indicates that the kind of a link being described is a point-to-point connection to another router, a connection to a transit network, a connection to a stub network, or a virtual link respectively. When a router inside a TTZ receives a link state such as a router LSA 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 such as a router LSA 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. Router LSAs for TTZ as a Group of Edge Routers For every edge router of a TTZ, in addition to generate a router LSA described above, it constructs a second router LSA and sends this second router LSA to its neighboring routers. The second router LSA comprises two groups of links. The first group of links are the router links connecting the routers outside of the TTZ from this TTZ edge router. These router links are normal router links. There is a router link for every adjacency between this TTZ edge router and a router outside of the TTZ. The second group of links are the "virtual" router links. For each of the other TTZ edge routers, there is a "virtual" router link to it from this TTZ edge router. The cost of the router link from this TTZ router to one of the other TTZ edge routers is the cost of the shortest path from this TTZ edge router to it. 6.3. Router LSA 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 LSAs 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 of its router ID. Otherwise, the router itself becomes TTZ-DR if it has the highest router ID among all the TTZ routers. The procedure for selecting a TTZ-DR for a TTZ is described as follows: Call the TTZ router doing the selection Router X. The TTZ Chen, et al. Expires April 26, 2012 [Page 12] Internet-Draft Topology-Transparent Zone October 2011 routers in the TTZ are considered. 1. Set TTZ-DR and TTZ-BDR to 0. 2. Set TTZ-BDR to the router ID of the TTZ router that has the highest router ID among all the TTZ routers and is not the TTZ-DR. 3. Set TTZ-DR to TTZ-BDR if there is not a TTZ-DR in the TTZ. 4. If router X becomes a newly elected TTZ-DR or TTZ-BDR, or is now no longer the TTZ-DR or the TTZ-BDR, then repeat step 2. and 3. above. 5. If router X becomes the TTZ-DR, then it originates LSAs for the TTZ. The procedure for selecting the TTZ-DR is tiggered by the events: a new TTZ router becomes functional or an existing TTZ router leaves the TTZ. 6.3.2. Constructing Router LSA for TTZ as a Router For the TTZ-DR in a TTZ, in addition to generate a router LSA described above, it constructs a second router LSA or special router LSA for the TTZ as a special single router and sends this second router LSA to its neighboring routers. The second router LSA comprises all the router links connecting the routers outside of the TTZ from any TTZ edge router. The Link State ID and Advertising Router of the router LSA is the ID of the special router for the TTZ. When the TTZ-DR in the TTZ constructs and sends an OSPF packet to its neighboring routers, it sets the Router ID in the packet header of the packet to the ID of the special router for the TTZ. A procedure for constructing all the router links of a Special Router LSA (SRL) on the TTZ-DR is described below in pseudo code. From the point of view of the router outside of the TTZ, this Special Router LSA (SRL) does not contain any TTZ specific information, it is just a normal router LSA containing router links from the router for the TTZ to the routers outside of the TTZ. Chen, et al. Expires April 26, 2012 [Page 13] Internet-Draft Topology-Transparent Zone October 2011 N = 0; For each router LSA in the TTZ { For each router link in the router LSA { If the router link is an external link { N = N + 1; Add the router link into router LSA SRL as a normal link; } Else If the router link is a stub link { N = N + 1; Add the router link into router LSA SRL and set cost to 0; } } } Set the value of Number of Links field in router LSA SRL to N; Figure 5: Procedure for Constructing Router LSA for TTZ In the procedure above, N is a variable for counting the number of external links that the TTZ has. Each router LSA in the TTZ is a router LSA that is generated by a router inside the TTZ and is sent to routers inside the TTZ. When "One Bit to Indicate an Internal TTZ Link" is used as an extension to the link type, the value of I bit flag is set to one for an internal link inside the TTZ, and the value of I bit flag is set to zero for an external link connecting to a node outside of the TTZ. Thus the condition of the If statement is true if the I bit flag in the router link is zero. When the value of the link type stays the same as its original definition, but a new field for a TTZ ID is added into a router link to indicate that the link described belongs to which TTZ (If the value of the new field is zero, it indicates that the corresponding link is a link connecting to a node outside of the TTZ. If the value of the new field is not zero and is a TTZ ID, it indicates that the link described belongs to the TTZ given by the TTZ ID in the new field), the condition of the If statement is true if the value of the new field for the TTZ ID in the router link is zero. In the body of the If statement, the router link for the external link is added into the router LSA SRL as a normal link. The value of Type field for the router link is set to the kind of the link for the Chen, et al. Expires April 26, 2012 [Page 14] Internet-Draft Topology-Transparent Zone October 2011 external link, which may be 1, 2, 3, or 4, indicating the kind of the link being described is a point-to-point connection to another router, a connection to a transit network, a connection to a stub network, or a virtual link respectively. 6.3.3. Maintaining Router LSA for TTZ as a Router The router LSA for a TTZ as a router is originated only by the DR in the TTZ. Since only this DR generates the router LSA for the TTZ, the sequence number of the LSA is also generated only by this DR. Thus all the router LSAs for the same TTZ as a router will have the same sequence number. When this DR receives a router LSA for the TTZ with a sequence number that is greater than the sequence number of the router LSA for the TTZ in its link state database, it re-originates a new router LSA for the TTZ with a new sequence number equal to the sequence number of the router LSA received plus one, and floods the new router LSA to all its neighboring routers. When any other router in the TTZ, including any other TTZ edge router, receives a router LSA for the TTZ with a sequence number that is greater than the sequence number of the router LSA for the TTZ in its link state database, it just accepts the router LSA into its link state database and floods the router LSA to its neighboring routers. 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 connection. For an edge router in a TTZ, in addition to establishing adjacencies with other routers in the TTZ that have connections with the edge router in the same way as a normal router, 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 two options. One option is that it acts as a TTZ edge router, which is one of the group of edge routers for TTZ; the other is that it acts as a special single router for the TTZ. Chen, et al. Expires April 26, 2012 [Page 15] Internet-Draft Topology-Transparent Zone October 2011 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 OSPF protocol packet such as Database Decription, which is sent to the router outside of the TTZ by the edge router, contains the edge router identifier (ID) as Router 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 LSAs except for the LSAs 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 router LSA and sends this LSA to the router outside of the TTZ. This router LSA contains two groups of links. The first group of links are the router links connecting to the routers outside of the TTZ from this TTZ edge router. The second group of links are the "virtual" router links 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 LSAs 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 OSPF protocol packet such as Database Decription, which is sent to the router outside of the TTZ by the edge router, contains the special single router ID as Router 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 LSAs except for the LSAs belong to the TTZ that are hidden from any router outside of the TTZ. Chen, et al. Expires April 26, 2012 [Page 16] Internet-Draft Topology-Transparent Zone October 2011 At the end of the link state database synchronization, th router LSA for the TTZ is originated and sent to the router outside of the TTZ. This router LSA contains the router links 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 LSAs 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. 8. Distribution of LSAs LSAs can be divided into two classes according to their distributions. One class of LSAs is distributed within a TTZ. The other is distributed through a TTZ. 8.1. Distribution of LSAs within TTZ Any LSA about a link state in a TTZ is distributed within the TTZ. It will not be distributed to any router outside of the TTZ. For example, any router LSA 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 network LSA generated for a broadcast or NBMA network inside a TTZ is distributed within the TTZ. It will not be distributed to any router outside of the TTZ. Any opaque LSA generated for a TTZ internal TE link is distributed within the TTZ. It will not be distributed to any router outside of the TTZ. 8.2. Distribution of LSAs through TTZ Any LSA about a link state outside of a TTZ received by an edge router of the TTZ is distributed through the TTZ; and any LSA about a link state for the TTZ is distributed through the TTZ. For example, when an edge router of a TTZ receives an LSA 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 LSA may be any LSA such as a router LSA and an opaque LSA that is distributed in a domain. Chen, et al. Expires April 26, 2012 [Page 17] Internet-Draft Topology-Transparent Zone October 2011 The routers in the TTZ continue to flood the LSA. When another edge router of the TTZ receives the LSA, it floods the LSA to its neighboring routers both outside of the TTZ and inside the TTZ. In the case that a group of edge routers is for a TTZ, every edge router of the TTZ generates a router LSA for the TTZ. This LSA is distributes through the TTZ. That is that it is distributed to routers outside of the TTZ and to the routers inside the TTZ. In the case that a single router is for a TTZ, the special router LSA generated for the TTZ is distributes through 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 2328. On a router inside the TTZ, it has the same procedure flow as that described in RFC 2328, but extends the meaning of a link and an association between two vertexes. In this section, we specify the extensions, and describe the the routing table computation on a router inside the TTZ. A link between two vertexes can be a TTZ link. It can also be a normal link. When examining the LSA associated with vertex V, for each link described in the LSA, supposing that vertex W is the other end of the link, o if it is a normal link, then vertex W is an adjacent vertex of vertex V; o if it is an internal TTZ link and the LSA 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 link and the LSA is generated by a TTZ edge router, then vertex W, which is the other end of the external TTZ link 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 in two phases. In the first phase, the shortest path to every destination inside the TTZ is computed through using the internal TTZ links (i.e., the links inside the TTZ). Then in the second phase, the shortest path to Chen, et al. Expires April 26, 2012 [Page 18] Internet-Draft Topology-Transparent Zone October 2011 every destination outside of the TTZ is computed over all the links including the links inside the TTZ and the links outside of the TTZ. When a TTZ is virtualized as a special single router, the routing table on a router inside the TTZ is computed in the following way. The cost/metric of a link (including external TTZ link) outside of the TTZ is considered as a special type of metrics. This type of metrics is an order of magnitude larger than that of metrics of a link inside the TTZ. That is that any metric of this special type is considered greater than the cost of any path internal to the TTZ. The path to every destination is computed through constructing a shortest path tree from the router in the TTZ to every destination. 10. Security Considerations The mechanism described in this document does not raise any new security issues for the OSPF protocols. 11. IANA Considerations 12. Acknowledgement The author would like to thank Acee Lindem, Dean Cheng, Lin Han and Yang Yu for their valuable comments on this draft. 13. References 13.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. 13.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 Chen, et al. Expires April 26, 2012 [Page 19] Internet-Draft Topology-Transparent Zone October 2011 (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. Authors' Addresses Huaimo Chen Huawei Technologies Boston, MA USA Email: Huaimochen@huawei.com Renwei Li Huawei Technologies 2330 Central expressway Santa Clara, CA USA Email: Renweili@huawei.com Gregory CAUCHIE France Telecom 38-40 avenue du General LECLERC Issy-les-Moulineaux 92130, FRANCE Email: gregory_pro@orange.fr Chen, et al. Expires April 26, 2012 [Page 20]