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