[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/