Internet Engineering Task Force H. Chen
Internet-Draft R. Li
Intended status: Standards Track Huawei Technologies
Expires: January 17, 2013 G. Cauchie
France Telecom
N. So
Tata Communications
L. Liu
KDDI R&D Lab Inc.
A. Retana
Hewlett-Packard Co.
July 16, 2012
OSPF Topology-Transparent Zone
draft-chen-ospf-ttz-02.txt
Abstract
This document presents a topology-transparent zone in a domain. A
topology-transparent zone comprises a group of routers and a number
of links connecting these routers. Any router outside of the zone is
not aware of the zone. The information about the links and routers
inside the zone is not distributed to any router outside of the zone.
Any link state change such as a link down inside the zone is not seen
by any router outside of the zone.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 17, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Chen, et al. Expires January 17, 2013 [Page 1]
Internet-Draft Topology-Transparent Zone July 2012
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
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 OSPF Protocols in Router LSA . . . . . . . . . . . 8
5.1. One Bit to Indicate an Internal TTZ Link . . . . . . . . . 8
6. Constructing Router LSA . . . . . . . . . . . . . . . . . . . 10
6.1. Router LSA for a Router in TTZ . . . . . . . . . . . . . . 10
6.2. Router LSAs for TTZ as a Group of Edge Routers . . . . . . 11
6.3. Router LSA for TTZ as a Router . . . . . . . . . . . . . . 11
6.3.1. Selection of TTZ-DR for TTZ . . . . . . . . . . . . . 12
6.3.2. Constructing Router LSA for TTZ as a Router . . . . . 12
7. Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 14
7.1. Group of Edge Routers for TTZ . . . . . . . . . . . . . . 14
7.2. Single Router for TTZ . . . . . . . . . . . . . . . . . . 15
8. Distribution of LSAs . . . . . . . . . . . . . . . . . . . . . 16
8.1. Distribution of LSAs within TTZ . . . . . . . . . . . . . 16
8.2. Distribution of LSAs through TTZ . . . . . . . . . . . . . 16
9. Computation of Routing Table . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Normative References . . . . . . . . . . . . . . . . . . . 18
13.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Chen, et al. Expires January 17, 2013 [Page 2]
Internet-Draft Topology-Transparent Zone 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
further expansions of a network.
RFC 2328 "OSPF Version 2" describes OSPF areas in an AS. Each area
has a number of area border routers connected to the backbone area.
Each area border router summarizes the topology of its attached non
backbone areas for transmission on the backbone, and hence to all
other area border routers.
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 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
Chen, et al. Expires January 17, 2013 [Page 3]
Internet-Draft Topology-Transparent Zone July 2012
indirectly. For example, all the routers and links in a Point-Of-
Presence (POP) in an OSPF area will be seen by all the other routers
in the same area. Any link state change in the POP will be
distributed to all the other routers in the same area and may be
distributed to routers in other areas indirectly.
A link state change in an area will lead to every router in the same
area to re-calculate its OSPF routes, update its RIB and FIB. It may
also lead to a number of link state distributions to other areas.
This will trigger routers in other areas to re-calculate their OSPF
routes, update their RIBs and FIBs. Thus the route convergence is
slower.
This document presents a topology-transparent zone in a domain or an
area and describes extensions to OSPFv2 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 links connecting these routers. Any router outside of the zone is
not aware of the zone. The information about the links and routers
inside the zone is not distributed to any router outside of the zone.
Any link state change such as a link down inside the zone is not seen
by any router outside of the zone.
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 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.
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.
Chen, et al. Expires January 17, 2013 [Page 4]
Internet-Draft Topology-Transparent Zone July 2012
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 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 an entity such as a node in an OSPF
domain. It is not zero in general.
In addition to having the functions of an OSPF area, an OSPF TTZ
makes some improvements on an OSPF area, which include:
o An OSPF TTZ is virtualized as an object, which may be a group of
TTZ edge routers connected or a single router.
o An OSPF 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.
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 January 17, 2013 [Page 5]
Internet-Draft Topology-Transparent Zone July 2012
TTZ 600
/
/
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
( )
===[R15]========(==[R61]-----------------[R63]==)========[R29]===
|| ( | \ / | ) ||
|| ( | \ / | ) ||
|| ( | \ / | ) ||
|| ( | \ / | ) ||
|| ( | \ / | ) ||
|| ( | \ / | ) ||
|| ( | \ / | ) ||
|| ( | _____[R71] | ) ||
|| ( | / / \ | ) ||
|| ( | [R73] / \ | ) ||
|| ( | / \ | ) ||
|| ( | / \ | ) ||
|| ( | / \ | ) ||
|| ( | / \ | ) ||
|| ( | / \ | ) ||
===[R17]========(==[R65]-----------------[R67]==)========[R31]===
\\ (// \\ ) //
|| //v~v~v~v~v~v~v~v~v~v~v~v~v~\\ ||
|| // \\ ||
|| // \\ ||
|| // \\ ||
|| // \\ ||
|| // \\ ||
\\ // \\ //
=====[R23]======================================[R25]=====
// \\
// \\
// \\
Figure 1: An Example of TTZ
The routing domain comprises routers R15, R17, R23, R25, R29 and R31.
It also contains a topology-transparent zone TTZ 600. The TTZ 600
comprises routers R61, R63, R65, R67, R71 and R73, and the links
connecting them.
There are two types of routers in a Topology-Transparent Zone (TTZ):
TTZ internal routers and TTZ edge routers. A TTZ internal router is
a router inside the TTZ and every adjacent router of the TTZ internal
router is a router inside the TTZ. A TTZ edge router is a router
Chen, et al. Expires January 17, 2013 [Page 6]
Internet-Draft Topology-Transparent Zone July 2012
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 link between TTZ router R61 and R65 to any router outside of the
TTZ.
In order to create a Topology-Transparent Zone (TTZ), we MUST
configure the same TTZ ID on every link that connects routers inside
the TTZ and every router in the TTZ MUST support TTZ feature.
For example, the same TTZ ID is configured on the nine links below:
o the link between router R61 and R65,
o the link between router R65 and R67,
o the link between router R67 and R63,
o the link between router R63 and R61,
o the link between router R71 and R61,
o the link between router R71 and R63,
o the link between router R71 and R65,
o the link between router R71 and R67 and
Chen, et al. Expires January 17, 2013 [Page 7]
Internet-Draft Topology-Transparent Zone July 2012
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.
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 links connected to the TTZ
as a single router, each of which is connected to a router outside of
the TTZ. For instance, router R15 sees TTZ 600 as a single router
with six links, connecting to router R15, R17, R23, R25, R29 and R31
respectively.
A TTZ as a special single router considers every connection between a
router outside of the TTZ and an edge router of the TTZ as a link.
The Router ID of the virtualized representation of the TTZ SHOULD be
the largest or smallest interface IP address of the TTZ-DR (see
Section 6.3.1).
5. Changes to OSPF Protocols in Router LSA
5.1. One Bit to Indicate an Internal TTZ Link
A router LSA contains the description of a number of router links.
The existing format of a router LSA is illustrated as follows:
Chen, et al. Expires January 17, 2013 [Page 8]
Internet-Draft Topology-Transparent Zone July 2012
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # TOS | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | TOS metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Figure 2: Format of Router LSA
For a router link, the value of an eight bit Type field indicates the
kind of the link. The value of the Type field may be 1, 2, 3 or 4,
which indicates that the kind of the link is a point-to-point
connection to another router, a connection to a transit network, a
connection to a stub network, or a virtual link respectively.
The existing eight bit Type field for a router link may be split into
two fields as follows:
Chen, et al. Expires January 17, 2013 [Page 9]
Internet-Draft Topology-Transparent Zone July 2012
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| I | Type-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I bit flag:
1: This indicates that the router link is an internal link
to a router inside the TTZ.
0: This indicates that the router link is an external link.
Type-1:
The kind of the link.
Figure 3: Bit to Indicate Internal TTZ Link
For a link inside a TTZ, the value of I bit flag is set to one,
indicating that this link is an internal TTZ link. For a link
connecting to a router outside of a TTZ from a TTZ edge router, the
value of I bit flag is set to zero, indicating that this link is an
external TTZ link.
The value of Type-1 field may have value 1, 2, 3, or 4, which
indicates that the kind of a link being described is a point-to-point
connection to another router, a connection to a transit network, a
connection to a stub network, or a virtual link respectively.
6. Constructing Router LSA
Two types of router LSAs are generated. One is constructed by every
router in a TTZ for the router to describe the links connecting to
it. The other is generated by some routers in the TTZ to virtualize
the TTZ as a group of edge routers connected or a single router.
6.1. Router LSA for a Router in TTZ
Every router in a TTZ constructs a router LSA for the router that
comprises both the router links connecting the routers inside the TTZ
and the router links connecting to the routers outside of the TTZ.
It sends this router LSA to its neighboring routers in the TTZ. For
each of the router links in the router LSA, it can be represented in
one of the ways described in the previous section.
Chen, et al. Expires January 17, 2013 [Page 10]
Internet-Draft Topology-Transparent Zone July 2012
For example, when "One Bit to Indicate an Internal TTZ Link" is used
as an extension to the link type, for each of the router links in the
router LSA, the value of I bit flag is set to one for an internal
link inside the TTZ; and the value of I bit flag is set to zero for
an external link connecting to a router outside of the TTZ; the value
of Type-1 field may have value 1, 2, 3, or 4, which indicates that
the kind of a link being described is a point-to-point connection to
another router, a connection to a transit network, a connection to a
stub network, or a virtual link respectively.
When a router inside a TTZ receives a TTZ internal link state such as
a router LSA from a neighboring router in the TTZ, it stores the link
state and floods the link state to the other neighboring routers in
the TTZ.
When a TTZ edge router receives a TTZ internal link state such as a
router LSA for a router inside the TTZ from a neighboring router in
the TTZ, it stores the link state and floods the link state to the
other neighboring routers inside the TTZ. It does not flood the link
state to any of its neighboring routers outside of the TTZ.
6.2. Router LSAs for TTZ as a Group of Edge Routers
For every edge router of a TTZ, in addition to generate a router LSA
described above, it constructs a second router LSA and sends this
second router LSA to its neighboring routers. The second router LSA
comprises two groups of links.
The first group of links are the router links connecting the routers
outside of the TTZ from this TTZ edge router. These router links are
normal router links. There is a router link for every adjacency
between this TTZ edge router and a router outside of the TTZ.
The second group of links are the "virtual" router links. For each
of the other TTZ edge routers, there is a "virtual" router link to it
from this TTZ edge router. The cost of the router link from this TTZ
router to one of the other TTZ edge routers may be the cost of the
shortest path from this TTZ edge router to it.
In addition, the LSA may contain a third group of links, which are
stub links for the routes in the TTZ to be distributed to outside of
the TTZ.
6.3. Router LSA for TTZ as a Router
Chen, et al. Expires January 17, 2013 [Page 11]
Internet-Draft Topology-Transparent Zone July 2012
6.3.1. Selection of TTZ-DR for TTZ
Every TTZ has a TTZ Designated Router (TTZ-DR). The TTZ-DR
originates LSAs for the TTZ.
The TTZ-DR for a TTZ is elected as follows: When a TTZ router first
becomes functional, it checks to see whether there is currently a
TTZ-DR for the TTZ. If there is, it accepts that TTZ-DR, regardless
of its router ID. Otherwise, the router itself becomes TTZ-DR if it
has the highest router ID among all the TTZ routers.
The procedure for selecting a TTZ-DR for a TTZ is described as
follows: Call the TTZ router doing the selection Router X. The TTZ
routers in the TTZ are considered.
1. Set TTZ-DR and TTZ-BDR to 0.
2. Set TTZ-BDR to the router ID of the TTZ router that has the
highest router ID among all the TTZ routers and is not the
TTZ-DR.
3. Set TTZ-DR to TTZ-BDR if there is not a TTZ-DR in the TTZ.
4. If router X becomes a newly elected TTZ-DR or TTZ-BDR, or is now
no longer the TTZ-DR or the TTZ-BDR, then repeat step 2. and 3.
above.
5. If router X becomes the TTZ-DR, then it originates LSAs for the
TTZ.
The procedure for selecting the TTZ-DR is triggered by the events: a
new TTZ router becomes functional or an existing TTZ router leaves
the TTZ.
6.3.2. Constructing Router LSA for TTZ as a Router
For the TTZ-DR in a TTZ, in addition to generate a router LSA
described above, it constructs a second router LSA or special router
LSA for the TTZ as a special single router and sends this second
router LSA to its neighboring routers.
The second router LSA comprises all the router links connecting the
routers outside of the TTZ from any TTZ edge router. The Link State
ID and Advertising Router of the router LSA is the ID of the special
router for the TTZ.
When the TTZ-DR in the TTZ constructs and sends an OSPF packet to its
neighboring routers, it sets the Router ID in the packet header of
Chen, et al. Expires January 17, 2013 [Page 12]
Internet-Draft Topology-Transparent Zone July 2012
the packet to the router ID of the special router for the TTZ.
The router ID of the special router can be the largest interface IP
address of the TTZ-DR if it is not the router ID of the TTZ-DR;
otherwise, it can be the smallest interface IP address of the TTZ-DR.
A procedure for constructing all the router links of a Special Router
LSA (SRL) on the TTZ-DR is described below in pseudo code. From the
point of view of the router outside of the TTZ, this Special Router
LSA (SRL) does not contain any TTZ specific information, it is just a
normal router LSA containing router links from the router for the TTZ
to the routers outside of the TTZ.
N = 0;
For each router LSA in the TTZ
{
For each router link in the router LSA
{
If the router link is an external link
{
N = N + 1;
Add the router link into router LSA SRL as a normal link;
}
Else If the router link is a stub link
{
N = N + 1;
Add the router link into router LSA SRL and set cost to 0;
}
}
}
Set the value of Number of Links field in router LSA SRL to N;
Figure 4: Procedure for Constructing Router LSA for TTZ
In the procedure above, N is a variable for counting the number of
links that the TTZ as a single router has. Each router LSA in the
TTZ is a router LSA that is generated by a router inside the TTZ and
is sent to routers inside the TTZ.
When "One Bit to Indicate an Internal TTZ Link" is used as an
extension to the link type, the value of I bit flag is set to one for
an internal link inside the TTZ, and the value of I bit flag is set
to zero for an external link connecting to a node outside of the TTZ.
Thus the condition of the If statement is true if the I bit flag in
the router link is zero.
Chen, et al. Expires January 17, 2013 [Page 13]
Internet-Draft Topology-Transparent Zone July 2012
In the body of the If statement, the router link for the external
link is added into the router LSA SRL as a normal link. The value of
Type field for the router link is set to the kind of the link, which
may be 1, 2, 3, or 4, indicating the kind of the link being described
is a point-to-point connection to another router, a connection to a
transit network, a connection to a stub network, or a virtual link
respectively.
7. Establishing Adjacencies
A router in a TTZ forms an adjacency with another router in the TTZ
in the same way as a normal router when these two routers have a
connection.
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 addition to establishing adjacencies
with other routers in the TTZ that have connections with the edge
router, it forms an adjacency with any router outside of the TTZ that
has a connection with the edge router.
When the edge router in the TTZ forms the adjacency with the router
outside of the TTZ, there are 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 OSPF protocol
packet such as Database Decription, which is sent to the router
outside of the TTZ by the edge router, contains the edge router
identifier (ID) as Router ID.
When the edge router synchronizes its link state database with the
router outside of the TTZ, it sends the router outside of the TTZ the
information about all the LSAs except for the LSAs belong to the TTZ
that are hidden from any router outside of the TTZ.
Chen, et al. Expires January 17, 2013 [Page 14]
Internet-Draft Topology-Transparent Zone July 2012
At the end of the link state database synchronization, the edge
router originates its own router LSA and sends this LSA to the router
outside of the TTZ. This router LSA contains two groups of links.
The first group of links are the router links connecting to the
routers outside of the TTZ from this TTZ edge router. The second
group of links are the "virtual" router links connecting to the other
TTZ edge routers from this TTZ edge router.
From the point of view of the router outside of the TTZ, it sees the
other end as a normal router and forms the adjacency in the same way
as a normal router. It is not aware of anything about its
neighboring TTZ. From the LSAs related to the TTZ edge router in the
other end, it knows that the TTZ edge router is connected to each of
the other TTZ edge routers and some routers outside of the TTZ.
7.2. Single Router for TTZ
An edge router of a TTZ, acting as a special single router for the
TTZ, forms an adjacency with a router outside of the TTZ in a way
descibed below.
During and after the adjacency establishment, every OSPF protocol
packet such as Database Decription, which is sent to the router
outside of the TTZ by the edge router, contains the special single
router ID as Router ID.
When the edge router synchronizes its link state database with the
router outside of the TTZ, it sends the router outside of the TTZ the
information about all the LSAs except for the LSAs belong to the TTZ
that are hidden from any router outside of the TTZ.
At the end of the link state database synchronization, th router LSA
for the TTZ is originated and sent to the router outside of the TTZ.
This router LSA contains the router links from every TTZ edge router
to routers outside of the TTZ.
From the point of view of the router outside of the TTZ, it sees the
other end as a normal single router and forms the adjacency in the
same way as a normal router. It is not aware of anything about its
neighboring TTZ. From the LSAs related to the special router in the
other end, it knows that the special router for the TTZ is connected
to the routers outside of the TTZ having connections to edge routers
of the TTZ.
Chen, et al. Expires January 17, 2013 [Page 15]
Internet-Draft Topology-Transparent Zone July 2012
8. Distribution of LSAs
LSAs can be divided into two classes according to their
distributions. One class of LSAs is distributed within a TTZ. The
other is distributed through a TTZ.
8.1. Distribution of LSAs within TTZ
Any LSA about a link state in a TTZ is distributed within the TTZ.
It will not be distributed to any router outside of the TTZ.
For example, any router LSA generated for a router in a TTZ is
distributed within the TTZ. It will not be distributed to any router
outside of the TTZ.
Any network LSA generated for a broadcast or NBMA network inside a
TTZ is distributed within the TTZ. It will not be distributed to any
router outside of the TTZ.
Any opaque LSA generated for a TTZ internal TE link is distributed
within the TTZ. It will not be distributed to any router outside of
the TTZ.
8.2. Distribution of LSAs through TTZ
Any LSA about a link state outside of a TTZ received by an edge
router of the TTZ is distributed through the TTZ; and any LSA about a
link state for the TTZ is distributed through the TTZ.
For example, when an edge router of a TTZ receives an LSA for a link
state outside of the TTZ from a router outside of the TTZ, it floods
it to its neighboring routers both inside the TTZ and outside of the
TTZ. This LSA may be any LSA such as a router LSA and an opaque LSA
that is distributed in a domain.
The routers in the TTZ continue to flood the LSA. When another edge
router of the TTZ receives the LSA, it floods the LSA to its
neighboring routers both outside of the TTZ and inside the TTZ.
In the case that a TTZ is virtualized as a group of edge routers of
the TTZ connected, every edge router of the TTZ generates a router
LSA for the TTZ. This LSA is distributed to the routers outside of
the TTZ and to the routers inside the TTZ.
In the case that a single router is for a TTZ, the special router LSA
generated for the TTZ is distributed through the TTZ.
When an edge router in a TTZ, acting as a special router for the TTZ,
Chen, et al. Expires January 17, 2013 [Page 16]
Internet-Draft Topology-Transparent Zone July 2012
generates a network LSA for a broadcast or NBMA network connecting
the TTZ edge router to a router outside of the TTZ, it sends the
network LSA to its neighboring routers outside of the TTZ. It also
sends this network LSA to its neighboring routers inside the TTZ.
When another TTZ edge router in the same TTZ receives the network LSA
generated by the TTZ edge router, it acting as the special router for
the TTZ sends the network LSA to its neighboring routers outside of
the TTZ.
9. Computation of Routing Table
The computation of the routing table on a router outside of a TTZ is
the same as that described in RFC 2328. On a router inside the TTZ,
it has the same procedure flow as that described in RFC 2328, but
extends the meaning of a link and an association between two
vertexes. In this section, we specify the extensions, and describe
the routing table computation on a router inside the TTZ.
A link between two vertexes can be a TTZ link. It can also be a
normal link.
When examining the LSA associated with vertex V, for each link
described in the LSA, supposing that vertex W is the other end of the
link,
o if it is a normal link, then vertex W is an adjacent vertex of
vertex V;
o if it is an internal TTZ link and the LSA is generated by a router
in a TTZ, then vertex W can be considered as an adjacent vertex of
vertex V;
o if it is an external TTZ link and the LSA is generated for the
TTZ, then vertex W, which is the other end of the external TTZ
link and outside of the TTZ, can be considered as an adjacent
vertex of vertex V.
When a TTZ is virtualized as a group of TTZ edge routers fully
connected, the routing table on a router inside the TTZ is computed
through using the link state database (LSDB) containing the LSAs for
the topology of the TTZ and the LSAs 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 links
including the links inside the TTZ and the links outside of the TTZ.
When a TTZ is virtualized as a special single router, the routing
Chen, et al. Expires January 17, 2013 [Page 17]
Internet-Draft Topology-Transparent Zone July 2012
table on a router inside the TTZ is computed in the following way.
The cost/metric of a link (including external TTZ link) outside of
the TTZ is considered as a special type of metrics. This type of
metrics is an order of magnitude larger than that of metrics of a
link inside the TTZ. That is that any metric of this special type is
considered greater than the cost of any path internal to the TTZ.
The path to every destination is computed through constructing a
shortest path tree from the router in the TTZ to every destination.
10. Security Considerations
The mechanism described in this document does not raise any new
security issues for the OSPF protocols.
11. IANA Considerations
12. Acknowledgement
The author would like to thank Acee Lindem, Dean Cheng, Lin Han and
Yang Yu for their valuable comments on this draft.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
13.2. Informative References
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,
July 1998.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
Chen, et al. Expires January 17, 2013 [Page 18]
Internet-Draft Topology-Transparent Zone July 2012
September 2003.
[RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's
Local Addresses in OSPF Traffic Engineering (TE)
Extensions", RFC 5786, March 2010.
[RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A
Backward-Recursive PCE-Based Computation (BRPC) Procedure
to Compute Shortest Constrained Inter-Domain Traffic
Engineering Label Switched Paths", RFC 5441, April 2009.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
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 17, 2013 [Page 19]
Internet-Draft Topology-Transparent Zone 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
Alvaro Retana
Hewlett-Packard Co.
2610 Wycliff Road
Raleigh, NC 27607
USA
Email: alvaro.retana@hp.com
Chen, et al. Expires January 17, 2013 [Page 20]