Skip to main content

Applicability of OSPF Topology-Transparent Zone
draft-chen-ospf-ttz-app-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Huaimo Chen , Richard Li , Gregory Cauchie , Ning So , Lei Liu
Last updated 2012-07-09
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-chen-ospf-ttz-app-00
Internet Engineering Task Force                                  H. Chen
Internet-Draft                                                     R. Li
Intended status: Informational                       Huawei Technologies
Expires: January 10, 2013                                     G. Cauchie
                                                          France Telecom
                                                                   N. So
                                                     Tata Communications
                                                                  L. Liu
                                                       KDDI R&D Lab Inc.
                                                            July 9, 2012

            Applicability of OSPF Topology-Transparent Zone
                     draft-chen-ospf-ttz-app-00.txt

Abstract

   This document discusses the applicability of "OSPF Topology-
   Transparent Zone".  It briefs the protocol and its operations first,
   and then illustrates the application scenarios of OSPF Topology-
   Transparent Zone.  In addition, guidelines for deployment are
   presented and limitations of the protocol are indicated.  This
   document is intended for accompanying "OSPF Topology-Transparent
   Zone" to the Internet standards track.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 10, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal

Chen, et al.            Expires January 10, 2013                [Page 1]
Internet-Draft            Applicability of TTZ                 July 2012

   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.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
   4.  Overview of Topology-Transparent Zone  . . . . . . . . . . . .  4
     4.1.  Definitions of Topology-Transparent Zone . . . . . . . . .  4
     4.2.  An Example of TTZ  . . . . . . . . . . . . . . . . . . . .  5
   5.  Applicability of Topology-Transparent Zone . . . . . . . . . .  7
     5.1.  One Area Network . . . . . . . . . . . . . . . . . . . . .  7
       5.1.1.  Issues on Splitting Network into Areas . . . . . . . .  7
       5.1.2.  Use of TTZ in One Area Network . . . . . . . . . . . .  9
     5.2.  Multi-Area Network . . . . . . . . . . . . . . . . . . . . 10
       5.2.1.  Issues on Splitting Network into More Areas  . . . . . 11
       5.2.2.  Use of TTZ in Multi-Area Network . . . . . . . . . . . 12
     5.3.  Use of TTZ on Routers in IPRAN . . . . . . . . . . . . . . 13
     5.4.  Use of TTZ on Routers in POP . . . . . . . . . . . . . . . 14
     5.5.  Use of TTZ on Routers from Same Vendor . . . . . . . . . . 14
   6.  Deployment Considerations  . . . . . . . . . . . . . . . . . . 15
   7.  Limitations  . . . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   9.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 15
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     10.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

Chen, et al.            Expires January 10, 2013                [Page 2]
Internet-Draft            Applicability of TTZ                 July 2012

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.  This blocks
   the further expansion of a network.

   The current solution for this is to divide a big AS into a number of
   OSPF areas.  However, there are a number of issues when an AS is
   split further into multiple areas.

   At first, dividing an AS into more areas is a very challenging task
   since it is involved in 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 established.  In general, a TE path crossing multiple
   areas is computed by using collaborating Path Computation Elements
   (PCEs) through the PCE Communication Protocol (PCEP), which is not
   easy to configure by operators since the manual configuration of the
   sequence for PCE chain 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 area border routers
   for reducing the number of link states such as summary Link-State
   Advertisements (LSAs) to be distributed to other routers in other
   areas.

   Furthermore, route convergence may be slower.  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.

   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.

Chen, et al.            Expires January 10, 2013                [Page 3]
Internet-Draft            Applicability of TTZ                 July 2012

   This document introduces a technology called Topology-Transparent
   Zone (TTZ), presents a number of application scenarios of TTZ and
   illustrates that TTZ can resolve the issues above.  In addition,
   guidelines for deployment are presented and limitations of the
   protocol are indicated.

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.  Overview of Topology-Transparent Zone

   This section briefs the concept of Topology-Transparent Zone (TTZ)
   and explains the TTZ in some details through an example.

4.1.  Definitions of Topology-Transparent Zone

   A Topology-Transparent Zone (TTZ) comprises an Identifier (ID), a
   group of routers and a number of links connecting the routers.  A
   Topology-Transparent Zone is in an OSPF 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.

   A TTZ may be virtualized as a different object in a different way.
   Two typical ways are given below.

   In a first way, a TTZ may be virtualized as a group of TTZ edge
   routers fully connected.  That is that from a router outside of the
   TTZ, a TTZ is seen as a group of TTZ edge routers, which are fully
   connected.

   In a second way, a TTZ may be seen as a single router.  That is that
   from a router outside of the TTZ, a TTZ is seen as a special single
   router.  This router has a router ID, which is the TTZ ID or the
   maximum ID among all the router IDs of the routers in the TTZ.  For
   every connection between a TTZ edge router and a router outside of
   TTZ, there is a connection between the special router and the router

Chen, et al.            Expires January 10, 2013                [Page 4]
Internet-Draft            Applicability of TTZ                 July 2012

   outside of TTZ.

   The virtualization of TTZ in the first way is described and used
   below.

4.2.  An Example of TTZ

   The figure below illustrates an example of a routing domain
   containing a topology-transparent zone: TTZ 600.

                                        TTZ 600
                                        /
                                       /

                      ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
                     (                             )
    ===[R15]========(==[R61]-----------------[R63]==)========[R29]===
        ||         (   |   \                /   |    )        ||
        ||         (   |    \              /    |    )        ||
        ||         (   |     \            /     |    )        ||
        ||         (   |      \          /      |    )        ||
        ||         (   |       \        /       |    )        ||
        ||         (   |        \      /        |    )        ||
        ||         (   |         \    /         |    )        ||
        ||         (   |    _____[R71]          |    )        ||
        ||         (   |   /     /    \         |    )        ||
        ||         (   | [R73]  /      \        |    )        ||
        ||         (   |       /        \       |    )        ||
        ||         (   |      /          \      |    )        ||
        ||         (   |     /            \     |    )        ||
        ||         (   |    /              \    |    )        ||
        ||         (   |   /                \   |    )        ||
    ===[R17]========(==[R65]-----------------[R67]==)========[R31]===
         \\          (//                        \\ )         //
          ||         //v~v~v~v~v~v~v~v~v~v~v~v~v~\\         ||
          ||        //                            \\        ||
          ||       //                              \\       ||
          ||      //                                \\      ||
          ||     //                                  \\     ||
          ||    //                                    \\    ||
           \\  //                                      \\  //
       =====[R23]======================================[R25]=====
             //                                          \\
            //                                            \\
           //                                              \\

                        Figure 1: An Example of TTZ

Chen, et al.            Expires January 10, 2013                [Page 5]
Internet-Draft            Applicability of TTZ                 July 2012

   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
   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,

Chen, et al.            Expires January 10, 2013                [Page 6]
Internet-Draft            Applicability of TTZ                 July 2012

   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

   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.

   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.

5.  Applicability of Topology-Transparent Zone

   Topology-Transparent Zone (TTZ) may be used in different cases.  This
   section presents a number of application scenarios of TTZ and
   illustrates the benefits that TTZ brings in each scenario.

5.1.  One Area Network

   Many networks start with one area.  A network with only one area is
   easy to operate and maintain.  As a network with one area becomes
   bigger and bigger because the increasing traffic in the network
   drives the expansion of the network, it needs to be split into
   multiple areas in general.

5.1.1.  Issues on Splitting Network into Areas

   Splitting a network with only one area into multiple areas is a very
   challenging task and may raise a number of issues.

   1.  Significant Changes on Network Architecture

   There are significant changes on network architecture when splitting
   a network with one area into multiple areas.  Originally the network
   has only one area, which is backbone area.  This original backbone
   area will be split into a new backbone area and a number of non
   backbone areas.

Chen, et al.            Expires January 10, 2013                [Page 7]
Internet-Draft            Applicability of TTZ                 July 2012

   In general, each of the non backbone areas is connected to the new
   backbone area through the area border routers between the non
   backbone area and the backbone area.  There is not any direct
   connection between any two non backbone areas.  Each area border
   router summarizes the topology of its attached non backbone area for
   transmission on the backbone area, and hence to all other area border
   routers.

   Before splitting the network into areas, every router in the network
   has the information about the network topology.  However, after
   splitting the network into areas, each router in an area has the
   information of the topology of the area, and it does not have the
   information of the topology of any other area.  It has only the
   summary information about the other areas.

   2.  Complex for MPLS TE Tunnel Setup

   Each of the MPLS TE LSP tunnels originally in one area, which has its
   ingress and egress in different areas after the network splitting,
   needs to be re-configured and re-established.  It is very complex for
   a MPLS TE LSP tunnel crossing areas to be set up.

   In order to reduce the manual configurations for a MPLS TE LSP tunnel
   crossing multiple areas, we use PCEs to compute the path for the
   tunnel.  Thus we must configure PCEs for the network split into
   multiple areas.

   In addition, we need to provide a sequence of areas for the tunnel
   through manual configurations.  The tunnel will go through the
   sequence of areas provided.

   More critically, there are some issues on using PCEs.  One of them is
   that the path computed by PCEs for the tunnel may not be optimal.  If
   the optimal path for the tunnel is not in the sequence of areas
   configured by uesrs, the path found by PCEs for the tunnel will not
   be optimal.

   3.  Policy Configurations and Slow Convergence

   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.

   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

Chen, et al.            Expires January 10, 2013                [Page 8]
Internet-Draft            Applicability of TTZ                 July 2012

   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.  All these will consume network
   resource including network bandwidth and Central Process Unit (CPU)
   time.  Thus route convergence is slow.

5.1.2.  Use of TTZ in One Area Network

   The issues mentioned above on splitting network into areas disappear
   if we do not split network into areas and use OSPF Topology
   Transparent Zone (TTZ) instead.

   TTZ may be applied to a group of routers and links in the network
   directly.  For a group of routers and links connecting the routers in
   the group in the network, no matter where it localtes in the network,
   we may configure it as an OSPF TTZ as long as each router in the
   group can reach the other routers in the group through those links.

   1.  No Significant Changes on Network Architecture

   There is not any significant changes on network architecture when an
   OSPF TTZ is applied to a group of routers and links in the network
   directly.

   At first, we do not add any new connection to the network, or remove
   any existing connection from the network.

   Secondly, every router outside of the TTZ is not aware of the TZZ.
   Even the router directly connecting to the TTZ is not aware of the
   TTZ.

   Furthermore, every router in the network still has a topology view of
   the network.  Except for those internal TTZ routers and links, which
   are hidden, every router outside of the TTZ has the link state
   information about all the routers and links in the network.

   2.  Easy for MPLS TE Tunnel Setup

   After a group of routers and links in the network is configured as an
   OSPF TTZ, a MPLS TE LSP tunnel with an ingress router and an egress
   router, which are anywhere in the network, can be configured in a
   way, which is the same as or similar to the way in which a MPLS TE

Chen, et al.            Expires January 10, 2013                [Page 9]
Internet-Draft            Applicability of TTZ                 July 2012

   LSP tunnel in one area network is configured.

   For example, in the network in Figure 1 above, a MPLS TE LSP tunnel
   from ingress router R15 to egress router R29 can be configured in the
   same way as a MPLS TE LSP tunnel in one area network through
   provisioning the ingress router R15's IP address, the egress router
   R29's IP address and some constraints for the tunnel on the ingress
   router R15.

   We do not need any PCEs for computing the constrained path for a MPLS
   TE LSP tunnel in the network with OSPF Topology Transparent Zones
   (TTZs).  After a MPLS TE LSP tunnel with an ingress and egress
   anywhere in the network with OSPF TTZs is configured, the ingress
   computes the contrained path for the tunnel from the ingress to the
   egress in the same way as it computes the constrained path for the
   tunnel in one area network.  The constrained path computed may go
   through some OSPF TTZs.

   For example, in the network in Figure 1 above, the constrained path
   computed for the tunnel from ingress router R15 to egress router R29
   may be from ingress router R15, to edge router R61 of TTZ 600, to
   edge router R63 of TTZ 600 and then to egress router R29.

   As soon as the constrained path for a MPLS TE LSP tunnel is computed
   or given through configuration, the LSP can be established along the
   path by the signalling protocol RSVP-TE.

   3.  No Policy Configurations and Fast Convergence

   There is not any policy configuration for the use of TTZ in one area
   network.  When we apply a TTZ to a group of routers and links
   connecting the routers, we just configure a TTZ link attribute TTZ ID
   on each of the links.

   Link state changes such as a link down or a router down inside a TTZ
   is only advertised internally inside the TTZ.  The routers inside the
   TTZ will do internal routing table re-calculation.  The routers
   outside of the TTZ will not see any topology change, and thus the
   routing table is not re-calculated and route convergence is fast.

5.2.  Multi-Area Network

   For a network with mutiple areas, it typically needs to be split into
   more areas when the size of the network becomes larger and larger as
   the traffic in the network keeps growing.

Chen, et al.            Expires January 10, 2013               [Page 10]
Internet-Draft            Applicability of TTZ                 July 2012

5.2.1.  Issues on Splitting Network into More Areas

   What would happen when we split a network with multiple areas into
   even more areas?

   1.  Significant Changes on Network Architecture

   The changes on network architecture are significant when a network
   with multiple areas is split into even more areas.  In the network
   before splitting, there is one backbone area, which is surrouned by a
   number of non backbone areas.  Each of the non backbone areas is
   connected to the backbone area.  There is not any direct connection
   between any two non backbone areas in general.

   Splitting the network into more areas is involved in re-arranging a
   number of routers and links to create new areas and make some of the
   existing areas to become smaller.  Some of the routers and links in a
   new area may be from the backbone area, and the other from some of
   the non backbone areas.

   In the network after splitting, there is still one backbone area,
   which must be changed and be surrounded by the new non backbone areas
   and the existing non backbone areas some of which have been changed.
   Each of the non backbone areas is connected to the backbone area.

   2.  More Configurations for Tunnel Setup

   For reducing the manual configurations for a MPLS TE LSP tunnel
   crossing multple areas, we use PCEs to compute the path for the
   tunnel.  Thus more configurations for tunnel setup is needed.  We
   must configure PCEs for each of the new areas and peer relations
   among the PCEs for the new areas and the PCEs for the existing areas.

   3.  More Policy Configurations and Slow Convergence

   More policy configurations may be needed.  For each of the new non
   backbone areas and each of the existing non backbone areas that have
   been changed, some policies may need to be configured on the area
   border router connecting it to the backbone area to aggregate the
   routes in the non backbone area for transmisstion to the backbone
   area.

   A link state change in every area including any of the new areas and
   the existing areas 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.  All these will consume network resource

Chen, et al.            Expires January 10, 2013               [Page 11]
Internet-Draft            Applicability of TTZ                 July 2012

   including network bandwidth and CPU time.  Thus route re-convergence
   is slow.

5.2.2.  Use of TTZ in Multi-Area Network

   The issues described above on splitting network into even more areas
   disappear if we do not split network into more areas and use OSPF TTZ
   instead.

   A TTZ may be applied to a group of routers and links in any area in
   the network directly.  For a group of routers and links connecting
   the routers in the group in an area, no matter where it localtes in
   the area, we may configure it as an OSPF TTZ as long as each router
   in the group can reach the other routers in the group through those
   links.

   1.  No Significant Changes on Network Architecture

   We can see that there is not any significant changes on network
   architecture when an OSPF TTZ is applied to a group of routers and
   links in an area in the network directly.

   At first, we do not add any new connection to the network, or remove
   any existing connection from the network.

   Secondly, every router outside of the TTZ is not aware of the TZZ.
   Even the router directly connecting to the TTZ is not aware of the
   TTZ.

   Furthermore, every router in the area still has a topology view of
   the area.  Except for those internal TTZ routers and links, which are
   hidden, every router outside of the TTZ has the link state
   information about all the routers and links in the area.

   2.  No Extra Configurations for Tunnel Setup

   After a group of routers and links in an area in the network is
   configured as an OSPF TTZ, there is not any extra configuration for
   supporting setup of a MPLS TE tunnel.  We do not need to configure
   any new PCE since there is not any new area generated after applying
   a TTZ to a group of routers and links in an area.

   3.  No More Policy Configurations and Fast Convergence

   The architecture of areas is not changed after applying a TTZ to a
   group of routers and links in an area.  Thus there is no more policy
   configuration on the existing area border routers connecting existing
   non backbone areas to the existing backbone area to aggregate the

Chen, et al.            Expires January 10, 2013               [Page 12]
Internet-Draft            Applicability of TTZ                 July 2012

   routes in the non backbone area for transmission to the backbone area
   in general.

   Link state changes such as a link down or a router down inside a TTZ
   is only advertised internally inside the TTZ.  And thus, routers
   inside the TTZ will do internal routing table re-calculation.  The
   routers outside of the TTZ will not see any topology change, and thus
   the routing table is not re-calculated.

5.3.  Use of TTZ on Routers in IPRAN

   In an IP RAN network, a connection between a cell site Base Station
   (BS) and a Radio Network Controller (RNC) may cross over a number of
   OSPF areas or ASes.  The upper part of the figure below illustrates
   that a connection between a BS and a RNC crosses over two OSPF areas:
   area 1 and area 0.

                                          RNC
                                         //
                               ^~^~^~^~^~^~^
                ^~^~^~^~^     (             )
               (         )   (               )
              (           [R2]               )
              (  Area 1   )  (     Area 0    )
              (           )  (               )
               (         )   (               )
                v~v~v~v~v     (             )
              //               v~v~v~v~v~v~v
             BS
                            ||
                            ||
                            \/             RNC
                                         //
                 ^~^~^~^~^~^~^~^~^~^~^~^~^~^
                (  ^~^~^~^~^                )
               (  (         )                )
               ( (          [R2]             )
               ( (    TTZ    )      Area 0   )
               ( (           )               )
               (  (         )                )
                (  v~v~v~v~v                )
              // v~v~v~v~v~v~v~v~v~v~v~v~v~v
             BS

                       Figure 2: TTZ for IP RAN Case

   The lower part of the figure shows that applying an OSPF TTZ for area

Chen, et al.            Expires January 10, 2013               [Page 13]
Internet-Draft            Applicability of TTZ                 July 2012

   1 converts the network into only one backbone area, which is area 0.
   It is easy to provide a MPLS LSP connection within one area between a
   BS and a RNC.  In addoition, a MPLS TE LSP within one area can be
   protected using FRR.  Thus the service over the connection is
   protected.  Moreover, operating the network with one area is easier
   than operating one with multiple areas.

5.4.  Use of TTZ on Routers in POP

   A Point of Presence (POP) comprises the routers in a room, a floor, a
   building or a group of buildings.  These routers are normally in an
   AS or OSPF area.

   We may increase the network scalability significantly through
   configuring a POP as an OSPF TTZ.  When a POP becomes a TTZ, the link
   state information about every link and every router inside the POP is
   hidden from a router outside of the POP.  Only very small amount of
   link state information virtualizing the TTZ for the POP is
   distributed to the router outside of the POP.  Thus, the size of the
   LSDB on every router in the network is reduced significantly, and the
   speed for the router to compute the shortest path to every
   destionation is increased dramatically.

   We may also improve the network availability when we use a TTZ for a
   POP.  In the case that a link or a router in the POP is down, the
   traffic may be interrupted without using any TTZ for the POP.  The
   link state information about the link or router down needs to be
   distributed to every router in the network, and every router needs to
   compute the shortest path to every destination and download the path
   to its FIB.  The traffic is forwarded according to the latest FIB on
   every router.  During this process, there may be inconsist views on
   the network topology on different routers.

   The traffic interruption is minimized if we use a TTZ for the POP.
   The link state information about the link or router down is hidden
   from every router outside of the POP, which is not aware of the link
   or router down in the POP.  Thus every router outside of the POP has
   the same topology view when the link or router is down.  It does not
   compute the shortest path or download the path to its FIB.

5.5.  Use of TTZ on Routers from Same Vendor

   In a network, we may separate the routers from different vendors
   through using TTZ in order to alleviate the possible multi-vendor
   inter-operability issue.  For example, the routers from a same vendor
   can be configured as a TTZ, and the routers outside of this TTZ are
   developed by different vendors.

Chen, et al.            Expires January 10, 2013               [Page 14]
Internet-Draft            Applicability of TTZ                 July 2012

6.  Deployment Considerations

   When deploying a topology transparent zone, there should be well
   defined administrative policies governing the selection of routers
   belonging to the zone.  Furthermore, special considerations should be
   given to the number of edge routers of the zone.  In general, the
   number of edge routers of a topology transparent zone should be
   small.

7.  Limitations

   A topology transparent zone is within an OSPF area.  It can not be in
   more than one OSPF areas.

   A router may belong to a topology transparent zone.  It can not
   belong to more than one topology transparent zones.

8.  Security Considerations

   This document does not introduce any new security issues.

9.  Acknowledgement

   The author would like to thank people for their valuable comments on
   this draft.

10.  References

10.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.

10.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 January 10, 2013               [Page 15]
Internet-Draft            Applicability of TTZ                 July 2012

              (TE) Extensions to OSPF Version 2", RFC 3630,
              September 2003.

   [RFC5786]  Aggarwal, R. and K. Kompella, "Advertising a Router's
              Local Addresses in OSPF Traffic Engineering (TE)
              Extensions", RFC 5786, March 2010.

   [OSPF-TTZ]
              Chen, H., Li, R., Cauchie, G., So, N., and L. Liu, "OSPF
              Topology-Transparent Zone", draft-chen-ospf-ttz, Work in
              Progress, July 2012.

Authors' Addresses

   Huaimo Chen
   Huawei Technologies
   Boston, MA
   USA

   Email: 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: greg.cauchie@gmail.com

Chen, et al.            Expires January 10, 2013               [Page 16]
Internet-Draft            Applicability of TTZ                 July 2012

   Ning So
   Tata Communications
   2613 Fairbourne Cir.
   Plano, TX  75082
   USA

   Email: ning.so@tatacommunications.com

   Lei Liu
   KDDI R&D Lab Inc.
   2-1-15
   Ohara Fujimino-shi, Saitama
   Japan

   Email: le-liu@kddilabs.jp

Chen, et al.            Expires January 10, 2013               [Page 17]