Internet Engineering Task Force H. Chen
Internet-Draft R. Li
Intended status: Standards Track Huawei Technologies
Expires: August 22, 2013 G. Cauchie
France Telecom
N. So
Tata Communications
A. Retana
Cisco Systems
February 18, 2013
IS-IS Topology-Transparent Zone
draft-chen-isis-ttz-00.txt
Abstract
This document presents a topology-transparent zone in a domain. A
topology-transparent zone comprises a group of routers and a number
of circuits connecting these routers. Any router outside of the zone
is not aware of the zone. The information about the circuits and
routers inside the zone is not distributed to any router outside of
the zone. Any link state change such as a circuit down inside the
zone is not seen by any router outside of the zone.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 22, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Chen, et al. Expires August 22, 2013 [Page 1]
Internet-Draft Topology-Transparent Zone February 2013
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 5
4.1. Overview of Topology-Transparent Zone . . . . . . . . . . 5
4.2. An Example of TTZ . . . . . . . . . . . . . . . . . . . . 5
4.2.1. Creation of a TTZ . . . . . . . . . . . . . . . . . . 5
4.2.2. TTZ as a Group of Edge Routers Connected . . . . . . . 8
4.2.3. TTZ as a Single Router . . . . . . . . . . . . . . . . 8
5. Changes to IS-IS Protocols in LSP . . . . . . . . . . . . . . 9
5.1. New Sub-TLV for TTZ ID . . . . . . . . . . . . . . . . . . 9
5.2. One Bit to Indicate an Internal TTZ Circuit . . . . . . . 10
6. Constructing LSP . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Constructing LSP for a Router in TTZ . . . . . . . . . . . 11
6.2. Constructing LSP for TTZ as a Group of Edge Routers . . . 12
6.3. Constructing LSP for TTZ as a Router . . . . . . . . . . . 12
6.3.1. Selection of TTZ-DR for TTZ . . . . . . . . . . . . . 12
6.3.2. Constructing LSP for TTZ as a Router . . . . . . . . . 13
7. Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 14
7.1. Group of Edge Routers for TTZ . . . . . . . . . . . . . . 14
7.2. Single Router for TTZ . . . . . . . . . . . . . . . . . . 15
8. Distribution of LSPs . . . . . . . . . . . . . . . . . . . . . 16
8.1. Distribution of LSPs within TTZ . . . . . . . . . . . . . 16
8.2. Distribution of LSPs through TTZ . . . . . . . . . . . . . 16
9. Computation of Routing Table . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Normative References . . . . . . . . . . . . . . . . . . . 18
13.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Chen, et al. Expires August 22, 2013 [Page 2]
Internet-Draft Topology-Transparent Zone February 2013
1. Introduction
The number of routers in an Autonomous System (AS) becomes larger and
larger as the Internet traffic keeps growing. Thus the Intermediate
System To Intermediate System (IS-IS) Link State Database (LSDB) and
IS-IS routing table are bigger and bigger. Any link state change in
an AS leads to a number of link state distributions to every router
in the AS. This triggers every router in the AS to re-calculate its
IS-IS routes, update its Routing Information Base (RIB) and
Forwarding Information Base (FIB). All these will consume network
resource including network bandwidth and Central Process Unit (CPU)
time. This blocks further expansions of a network.
RFC 1142 "OSI IS-IS Intra-domain Routing Protocol", which is a
republication of ISO/IEC 10589, describes IS-IS areas or levels in an
Autonomous System (AS). Each level 1 area has a number of level 1
and level 2 routers connected to the level 2 area. Each level 1 and
level 2 router may summarize the topology of its attached level 1
areas to the level 2 area or vice versa.
Through splitting a network into multiple areas, we can extend the
network further. However, there are a number of issues when a
network is split further into more areas.
At first, dividing an AS or an area into multiple areas is a very
challenging task since it is involved in significant network
architecture changes.
Secondly, it is complex for a Multi-Protocol Label Switching (MPLS)
Traffic Engineering (TE) Label Switching Path (LSP) crossing multiple
areas to be setup. In general, a TE path crossing multiple areas is
computed by using collaborating Path Computation Elements (PCEs)
[RFC5441] through the PCE Communication Protocol (PCEP)[RFC5440],
which is not easy to configure by operators since the manual
configuration of the sequence of domains is required. Although this
issue can be addressed by using the Hierarchical PCE, this solution
may further increase the complexity of network design. Especially,
the current PCE standard method may not guarantee that the path found
is optimal.
Thirdly, some policies need to be configured on level 1 and level 2
routers for sumarizing the routes from a level 1 area to level 2 area
or vice versa.
Furthermore, route convergence may be slower. A router in an IS-IS
area can see all other routers in the same area. A link-state change
anywhere in an IS-IS area will be populated everywhere in the same
area, and may even be distributed to other areas in the same AS
Chen, et al. Expires August 22, 2013 [Page 3]
Internet-Draft Topology-Transparent Zone February 2013
indirectly. For example, all the routers and circuits in a Point-Of-
Presence (POP) in an IS-IS area will be seen by all the other routers
in the same area. Any link state change in the POP will be
distributed to all the other routers in the same area and may be
distributed to routers in other areas indirectly.
A link state change in an area will lead to every router in the same
area to re-calculate its IS-IS routes, update its RIB and FIB. It
may also lead to a number of link state distributions to other areas.
This will trigger routers in other areas to re-calculate their IS-IS
routes, update their RIBs and FIBs. Thus the route convergence is
slower.
This document presents a topology-transparent zone in a domain or an
area and describes extensions to IS-IS for supporting the topology-
transparent zone, which may resolve the issues above.
A topology-transparent zone comprises a group of routers and a number
of circuits connecting these routers. Any router outside of the zone
is not aware of the zone. The information about the circuits and
routers inside the zone is not distributed to any router outside of
the zone. Any link state change such as a circuit down inside the
zone is not seen by any router outside of the zone.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
3. Requirements
Topology-Transparent Zone (TTZ) may be deployed for resolving some
ctricial issues such as scalability in existing networks and future
networks. The requirements for TTZ are listed as follows:
o TTZ MUST be backward compitable. When a TTZ is deployed on a set
of routers in a network, the routers outside of the TTZ in the
network do not need to know or support TTZ.
o TTZ MUST support at least one more levels of network hierarchies,
in addition to the hierarchies supported by existing routing
protocols.
o Users SHOULD be able to easily set up an end to end service
crossing TTZs.
Chen, et al. Expires August 22, 2013 [Page 4]
Internet-Draft Topology-Transparent Zone February 2013
o The configuration for a TTZ in a network SHOULD be minimum.
o The changes on the existing protocols for supporting TTZ SHOULD be
minimum.
4. Topology-Transparent Zone
4.1. Overview of Topology-Transparent Zone
A Topology-Transparent Zone (TTZ) comprises an Identifier (ID), a
group of routers and a number of circuits connecting the routers. A
Topology-Transparent Zone is in an IS-IS sub domain (area).
The ID of a Topology-Transparent Zone (TTZ) or TTZ ID is a number
that is unique for identifying an entity such as a node in an IS-IS
sub domain (area). It is not zero in general.
In addition to having the functions of an IS-IS level or area, an
IS-IS TTZ makes some improvements on an IS-IS level or area, which
include:
o An IS-IS TTZ is virtualized as an object, which may be a group of
TTZ edge routers connected or a single router.
o An IS-IS TTZ receives the link state information about the
topology outside of the TTZ, stores the information in the TTZ and
floods the information through the TTZ to the routers outside of
TTZ.
o No Policy configuration is needed on any edge router of a TTZ.
4.2. An Example of TTZ
4.2.1. Creation of a TTZ
The figure below illustrates an example of a routing domain
containing a topology-transparent zone: TTZ 600.
Chen, et al. Expires August 22, 2013 [Page 5]
Internet-Draft Topology-Transparent Zone February 2013
TTZ 600
/
/
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
( )
===[R15]========(==[R61]-----------------[R63]==)========[R29]===
|| ( | \ / | ) ||
|| ( | \ / | ) ||
|| ( | \ / | ) ||
|| ( | \ / | ) ||
|| ( | \ / | ) ||
|| ( | \ / | ) ||
|| ( | \ / | ) ||
|| ( | _____[R71] | ) ||
|| ( | / / \ | ) ||
|| ( | [R73] / \ | ) ||
|| ( | / \ | ) ||
|| ( | / \ | ) ||
|| ( | / \ | ) ||
|| ( | / \ | ) ||
|| ( | / \ | ) ||
===[R17]========(==[R65]-----------------[R67]==)========[R31]===
\\ (// \\ ) //
|| //v~v~v~v~v~v~v~v~v~v~v~v~v~\\ ||
|| // \\ ||
|| // \\ ||
|| // \\ ||
|| // \\ ||
|| // \\ ||
\\ // \\ //
=====[R23]======================================[R25]=====
// \\
// \\
// \\
Figure 1: An Example of TTZ
The routing domain comprises routers R15, R17, R23, R25, R29 and R31.
It also contains a topology-transparent zone TTZ 600. The TTZ 600
comprises routers R61, R63, R65, R67, R71 and R73, and the circuits
connecting them.
There are two types of routers in a Topology-Transparent Zone (TTZ):
TTZ internal routers and TTZ edge routers. A TTZ internal router is
a router inside the TTZ and every adjacent router of the TTZ internal
router is a router inside the TTZ. A TTZ edge router is a router
Chen, et al. Expires August 22, 2013 [Page 6]
Internet-Draft Topology-Transparent Zone February 2013
inside the TTZ and has at least one adjacent router that is outside
of the TTZ.
The TTZ in the figure above comprises four TTZ edge routers R61, R63,
R65 and R67. Each TTZ edge router is connected to at least one
router outside of the TTZ. For instance, router R61 is a TTZ edge
router since it is connected to router R15, which is outside of the
TTZ.
In addition, the TTZ comprises two TTZ internal routers R71 and R73.
A TTZ internal router is not connected to any router outside of the
TTZ. For instance, router R71 is a TTZ internal router since it is
not connected to any router outside of the TTZ. It is just connected
to routers R61, R63, R65, R67 and R73 inside the TTZ.
A TTZ MUST hide the information inside the TTZ from the outside. It
MUST NOT directly distribute any internal information about the TTZ
to a router outside of the TTZ.
For instance, the TTZ in the figure above MUST NOT send the
information about TTZ internal router R71 to any router outside of
the TTZ in the routing domain; it MUST NOT send the information about
the circuit between TTZ router R61 and R65 to any router outside of
the TTZ.
In order to create a Topology-Transparent Zone (TTZ), we MUST
configure the same TTZ ID on every circuit that connects routers
inside the TTZ and every router in the TTZ MUST support TTZ feature.
For example, the same TTZ ID is configured on the nine circuits
below:
o the circuit between router R61 and R65,
o the circuit between router R65 and R67,
o the circuit between router R67 and R63,
o the circuit between router R63 and R61,
o the circuit between router R71 and R61,
o the circuit between router R71 and R63,
o the circuit between router R71 and R65,
o the circuit between router R71 and R67 and
Chen, et al. Expires August 22, 2013 [Page 7]
Internet-Draft Topology-Transparent Zone February 2013
o the circuit between router R71 and R73.
Thus six routers R61, R63, R65, R67, R71 and R73, and nine circuits
among these six routers form a topology-transparent zone TTZ 600 in
the figure above.
The configuration of a TTZ can be simplified by just provisioning a
TTZ ID on every TTZ internal router instead of on each circuit of
every TTZ internal router. The configuration of the TTZ ID on a
router indicates that every circuit of the router is a TTZ internal
circuit. On every edge router of the TTZ, the TTZ ID is still
configured on each circuit connecting to a TTZ router.
4.2.2. TTZ as a Group of Edge Routers Connected
From a router outside of the TTZ, a TTZ is seen as a group of TTZ
edge routers fully connected when the TTZ is virtualized as the group
of TTZ edge routers connected. For instance, router R15 in the
figure above, which is outside of TTZ 600, sees TTZ 600 as a group of
TTZ edge routers: R61, R63, R65 and R67. These four TTZ edge routers
are fully connected.
In addition, a router outside of the TTZ sees TTZ edge routers having
normal connections to the routers outside of the TTZ. For example,
router R15 sees four TTZ edge routers R61, R63, R65 and R67, which
have the normal connections to R15, R29, R17 and R23, R25 and R31
respectively.
4.2.3. TTZ as a Single Router
A TTZ is seen as a single router from a router outside of the TTZ
when the TTZ is virtualized as a single router. For instance, router
R15 in the figure above, which is outside of TTZ 600 and connected to
TTZ 600 through TTZ edge router R61, sees TTZ 600 as a single router.
A router outside of a TTZ sees a number of circuits connected to the
TTZ as a single router, each of which is connected to a router
outside of the TTZ. For instance, router R15 sees TTZ 600 as a
single router with six circuits, connecting to router R15, R17, R23,
R25, R29 and R31 respectively.
A TTZ as a special single router considers every connection between a
router outside of the TTZ and an edge router of the TTZ as a circuit.
The Router ID of the virtualized representation of the TTZ SHOULD be
the largest or smallest interface IP address of the TTZ-DR (TTZ-DIS)
(see Section 6.3.1).
Chen, et al. Expires August 22, 2013 [Page 8]
Internet-Draft Topology-Transparent Zone February 2013
5. Changes to IS-IS Protocols in LSP
There are a number of ways to extend the existing IS-IS protocols to
support TTZ in a Link State Packet (LSP). This section describes a
few of them.
o One way is to use a new sub-TLV for a TTZ ID to indicate that the
circuit described belongs to which TTZ.
o Alternatively, a bit in an existing sub-TLV indicates that a
circuit is a TTZ circuit or an internal circuit of a TTZ.
5.1. New Sub-TLV for TTZ ID
The format of extended IS reachability TLV is illustrated in the
figure below.
Length in Byte
+----------------------+
| Type = 22 | 1
+----------------------+
| Length | 1
+----------------------+
| Neighbor ID | 7
+----------------------+
| Default Metric | 3
+----------------------+
| Length of Sub-TLVs | 1
+----------------------+
| Sub-TLVs | Length of Sub-TLVs
+----------------------+
| |
| . . . |
| |
+----------------------+
| Neighbor ID | 7
+----------------------+
| Default Metric | 3
+----------------------+
| Length of Sub-TLVs | 1
+----------------------+
| Sub-TLVs | Length of Sub-TLVs
+----------------------+
Figure 2: Extended IS Reachability TLV
An extended IS reachability TLV may contain information about a
Chen, et al. Expires August 22, 2013 [Page 9]
Internet-Draft Topology-Transparent Zone February 2013
number of neighbors. There may be a series of sub-TLVs for each
neighbor in the TLV.
A new sub-TLV may be added into the sub-TLVs for a neighbor within
the Extended IS Reachability TLV in the figure above. This new sub-
TLV has the same format as the sub-TLV for the Traffic Engineering
Extensions in RFC 5305, which is shown in the figure below.
Length in Byte
+----------------------+
| Sub-Type = 30 | 1
+----------------------+
| Length | 1
+----------------------+
| TTZ ID | 4
+----------------------+
Figure 3: Sub-TLV for TTZ ID
The sub-TLV for TTZ ID has 1 byte of Sub-Type, 1 byte of Length of
the value field of the sub-TLV, which is followed by 4 bytes of value
field for TTZ ID.
The sub-TLV for TTZ ID is OPTIONAL and MUST appear at most once for
an IS neighbor. If this kind of sub-TLV appears more than once under
the same IS neighbor in a received Link State Packet (LSP), only the
first one SHOULD be considered and the others should be ingored.
For a circuit connecting to an neighboring router outside of a TTZ
from a TTZ edge router, there is not any TTZ ID sub-TLV under the
neighbor or the value field of the sub-TLV for TTZ ID is zero,
indicating that this circuit is an external TTZ circuit.
For a circuit connecting to an neighboring router inside a TTZ, there
is a TTZ ID sub-TLV under the neighbor, the value field for TTZ ID in
the sub-TLV is not zero and is a TTZ ID, indicating that this circuit
is an internal TTZ circuit to the neighbor and the circuit belongs to
the TTZ given by the TTZ ID.
5.2. One Bit to Indicate an Internal TTZ Circuit
The existing link-attribute sub-TLV within the extended IS
reachability TLV has 16-bit flags of value field. One of 16-bit
flags may be used to indicate an Internal TTZ circuit as follows:
Chen, et al. Expires August 22, 2013 [Page 10]
Internet-Draft Topology-Transparent Zone February 2013
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 19 | Length | |I| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I bit flag:
1: This indicates that the router circuit/link is an internal circuit
to a router inside the TTZ.
0: This indicates that the router circuit/link is an external circuit.
Figure 4: Bit to Indicate Internal TTZ Link
The link attribute sub-TLV is OPTIONAL and MUST appear at most once
for an IS neighbor. If this kind of sub-TLV appears more than once
under the same IS neighbor in a received Link State Packet (LSP),
only the first one SHOULD be considered and the others should be
ingored.
For a circuit connecting to an neighboring router inside a TTZ, there
is a link attribute sub-TLV under the neighbor and the value of I bit
flag in the sub-TLV for the neighbor is set to one, indicating that
this circuit is an internal TTZ circuit to the neighbor.
For a circuit connecting to an neighboring router outside of a TTZ
from a TTZ edge router, there is not any link attribute sub-TLV for
the neighbor or the value of I bit flag in the sub-TLV for the
neighbor is zero, indicating that this circuit is an external TTZ
circuit.
6. Constructing LSP
Two types of Link State Packets(LSPs) are generated. One is
constructed by every router in a TTZ for the router to describe the
circuits connecting to it. The other is generated by some routers in
the TTZ to virtualize the TTZ as a group of edge routers connected or
a single router.
6.1. Constructing LSP for a Router in TTZ
Every router in a TTZ constructs a LSP for the router that comprises
both the circuits connecting to the routers inside the TTZ and the
circuits connecting to the routers outside of the TTZ. It sends this
Chen, et al. Expires August 22, 2013 [Page 11]
Internet-Draft Topology-Transparent Zone February 2013
LSP to its neighboring routers in the TTZ. For each of the circuits
in the LSP, it can be represented in one of the ways described in the
previous section.
For example, when "One Bit to Indicate an Internal TTZ circuit" is
used as an extension, for each of the router circuits in the LSP, the
value of I bit flag is set to one for an internal circuit inside the
TTZ; and the value of I bit flag is set to zero for an external
circuit connecting to a router outside of the TTZ.
When a router inside a TTZ receives a link state packet (LSP) from a
neighboring router in the TTZ, it stores the link state and floods
the link state to the other neighboring routers in the TTZ.
When a TTZ edge router receives a TTZ internal link state packet for
a router inside the TTZ from a neighboring router in the TTZ, it
stores the link state and floods the link state to the other
neighboring routers inside the TTZ. It does not flood the link state
to any of its neighboring routers outside of the TTZ.
6.2. Constructing LSP for TTZ as a Group of Edge Routers
For every edge router of a TTZ, in addition to generate a LSP
described above, it constructs a second LSP for the router and sends
this second LSP to its neighboring routers. The second LSP comprises
two groups of circuits.
The first group of circuits are the circuits connecting the routers
outside of the TTZ from this TTZ edge router. These circuits are
normal circuits. There is a circuit for every adjacency between this
TTZ edge router and a router outside of the TTZ.
The second group of circuits are the "virtual" circuits. For each of
the other TTZ edge routers, there is a "virtual" circuit to it from
this TTZ edge router. The cost of the circuit from this TTZ router
to one of the other TTZ edge routers may be the cost of the shortest
path from this TTZ edge router to it.
6.3. Constructing LSP for TTZ as a Router
6.3.1. Selection of TTZ-DR for TTZ
Every TTZ has a TTZ Designated Router (TTZ-DR). The TTZ-DR
originates LSPs for the TTZ.
The TTZ-DR for a TTZ is elected as follows: When a TTZ router first
becomes functional, it checks to see whether there is currently a
TTZ-DR for the TTZ. If there is, it accepts that TTZ-DR, regardless
Chen, et al. Expires August 22, 2013 [Page 12]
Internet-Draft Topology-Transparent Zone February 2013
of its router ID. Otherwise, the router itself becomes TTZ-DR if it
has the highest router ID among all the TTZ routers.
6.3.2. Constructing LSP for TTZ as a Router
For the TTZ-DR in a TTZ, in addition to generate a LSP described
above, it constructs a second LSP or special LSP for the TTZ as a
special single router and sends this second LSP to its neighboring
routers.
The second LSP comprises all the circuits connecting the routers
outside of the TTZ from any TTZ edge router. The LSP ID is the ID of
the special router for the TTZ.
When the TTZ-DR in the TTZ constructs and sends an IS-IS packet to
its neighboring routers, it sets the Source ID in the packet header
of the packet to the ID of the special router for the TTZ.
The ID of the special router can be derived from the largest
interface IP address of the TTZ-DR if it is not the ID of the TTZ-DR;
otherwise, it can be dereived the smallest interface IP address of
the TTZ-DR.
A procedure for constructing all the circuits of a Special LSP (SL)
on the TTZ-DR is described below in pseudo code. From the point of
view of the router outside of the TTZ, this Special LSP (SL) does not
contain any TTZ specific information, it is just a normal LSP
containing indormation about circuits from the router for the TTZ to
the routers outside of the TTZ.
For each router LSP in the TTZ
{
For each router circuit in the LSP
{
If the circuit is an external circuit
{
Add the circuit into router LSP SL as a normal circuit;
}
}
}
Figure 5: Procedure for Constructing LSP for TTZ
Each LSP in the TTZ is a LSP that is generated by a router inside the
Chen, et al. Expires August 22, 2013 [Page 13]
Internet-Draft Topology-Transparent Zone February 2013
TTZ and is sent to routers inside the TTZ.
In the case of that "One Bit to Indicate an Internal TTZ circuit" is
used as an extension to the link attribute sub-TLV, the condition of
the If statement is true if there is not any link attribute sub-TLV
for the neighbor or the value of I bit flag in the sub-TLV for the
neighbor is zero.
In the body of the If statement, the circuit for the external circuit
is added into the LSP SL as a normal circuit.
7. Establishing Adjacencies
A router in a TTZ forms an adjacency with another router in the TTZ
in the same way as a normal router when these two routers have a
common connection.
An alternative way for forming an adjacency between two routers in a
TTZ is to extend hello protocol. Hello protocol is extended to
include TTZ ID in hello packets. The procedure for handling hellos
is changed to consider TTZ ID. When two routers have the same TTZ
IDs in their hellos, an adjacency between these two routers is to be
formed.
For an edge router in a TTZ, in addtion to establishing adjacencies
with other routers in the TTZ that have connections with the edge
routerk, it forms an adjacency with any router outside of the TTZ
that has a connection with the edge router.
When the edge router in the TTZ forms the adjacency with the router
outside of the TTZ, there are a few of options. A first option is
that it acts as a TTZ edge router, which is one of the group of edge
routers for TTZ; A second option is that it acts as a special single
router for the TTZ.
7.1. Group of Edge Routers for TTZ
An edge router of a TTZ, acting as one of the group of edge routers
for the TTZ, forms an adjacency with a router outside of the TTZ in a
way descibed below.
During and after the adjacency establishment, every IS-IS protocol
packet such as CSNP, which is sent to the router outside of the TTZ
by the edge router, contains the edge router identifier (ID) as
Source ID.
When the edge router synchronizes its link state database with the
Chen, et al. Expires August 22, 2013 [Page 14]
Internet-Draft Topology-Transparent Zone February 2013
router outside of the TTZ, it sends the router outside of the TTZ the
information about all the LSPs except for the LSPs belong to the TTZ
that are hidden from any router outside of the TTZ.
At the end of the link state database synchronization, the edge
router originates its own LSP and sends this LSP to the router
outside of the TTZ. This LSP contains two groups of circuits.
The first group of circuits are the circuits connecting to the
routers outside of the TTZ from this TTZ edge router. The second
group of circuits are the "virtual" circuits connecting to the other
TTZ edge routers from this TTZ edge router.
From the point of view of the router outside of the TTZ, it sees the
other end as a normal router and forms the adjacency in the same way
as a normal router. It is not aware of anything about its
neighboring TTZ. From the LSPs related to the TTZ edge router in the
other end, it knows that the TTZ edge router is connected to each of
the other TTZ edge routers and some routers outside of the TTZ.
7.2. Single Router for TTZ
An edge router of a TTZ, acting as a special single router for the
TTZ, forms an adjacency with a router outside of the TTZ in a way
descibed below.
During and after the adjacency establishment, every IS-IS protocol
packet such as CSNP, which is sent to the router outside of the TTZ
by the edge router, contains the special single router ID as Source
ID.
When the edge router synchronizes its link state database with the
router outside of the TTZ, it sends the router outside of the TTZ the
information about all the LSPs except for the LSPs belong to the TTZ
that are hidden from any router outside of the TTZ.
At the end of the link state database synchronization, the LSP for
the TTZ is originated and sent to the router outside of the TTZ.
This LSP contains the router circuits from every TTZ edge router to
routers outside of the TTZ.
From the point of view of the router outside of the TTZ, it sees the
other end as a normal single router and forms the adjacency in the
same way as a normal router. It is not aware of anything about its
neighboring TTZ. From the LSPs related to the special router in the
other end, it knows that the special router for the TTZ is connected
to the routers outside of the TTZ having connections to edge routers
of the TTZ.
Chen, et al. Expires August 22, 2013 [Page 15]
Internet-Draft Topology-Transparent Zone February 2013
8. Distribution of LSPs
LSPs can be divided into two classes according to their
distributions. One class of LSPs is distributed within a TTZ. The
other is distributed through a TTZ.
8.1. Distribution of LSPs within TTZ
Any LSP generated for a router in a TTZ is distributed within the
TTZ. It will not be distributed to any router outside of the TTZ.
For example, any router LSP generated for a router in a TTZ is
distributed within the TTZ. It will not be distributed to any router
outside of the TTZ.
Any pseudonode LSP generated for a broadcast network inside a TTZ, is
distributed within the TTZ. It will not be distributed to any router
outside of the TTZ.
8.2. Distribution of LSPs through TTZ
Any LSP about a link state outside of a TTZ received by an edge
router of the TTZ is distributed through the TTZ; and any LSP about a
link state for the TTZ is distributed through the TTZ.
For example, when an edge router of a TTZ receives an LSP for a link
state outside of the TTZ from a router outside of the TTZ, it floods
it to its neighboring routers both inside the TTZ and outside of the
TTZ. This LSP may be any LSP such as a router LSP that is
distributed in a domain.
The routers in the TTZ continue to flood the LSP. When another edge
router of the TTZ receives the LSP, it floods the LSP to its
neighboring routers both outside of the TTZ and inside the TTZ.
In the case that a TTZ is virtualized as a group of edge routers of
the TTZ connected, every edge router of the TTZ generates a router
LSP for the TTZ. This LSP is distributed to the routers outside of
the TTZ and to the routers inside the TTZ.
9. Computation of Routing Table
The computation of the routing table on a router outside of a TTZ is
the same as that described in RFC 1142. On a router in a TTZ, the
computation of the routing table has the same procedure flow as that
described in RFC 1142, but extends the meaning of a circuit and an
association between two vertexes. In this section, we specify the
Chen, et al. Expires August 22, 2013 [Page 16]
Internet-Draft Topology-Transparent Zone February 2013
extensions, and describe the routing table computation on a router
inside the TTZ.
A link between two vertexes can be a TTZ circuit. It can also be a
normal circuit.
When examining the LSP associated with vertex V, for each described
circuit in the LSP, supposing that vertex W is the other end of the
link,
o if it is a normal circuit, then vertex W is an adjacent vertex of
vertex V;
o if it is an internal TTZ circuit and the LSP is generated by a
router in a TTZ, then vertex W can be considered as an adjacent
vertex of vertex V;
o if it is an external TTZ circuit and the LSP is generated by a TTZ
edge router, then vertex W, which is the other end of the external
TTZ circuit and outside of the TTZ, can be considered as an
adjacent vertex of vertex V.
When a TTZ is virtualized as a group of TTZ edge routers fully
connected, the routing table on a router inside the TTZ is computed
through using the link state database (LSDB) containing the LSPs for
the topology of the TTZ and the LSPs for the topology outside of the
TTZ. That is that the shortest path to every destination both inside
the TTZ and outside of the TTZ is computed over all the circuits
including the circuits inside the TTZ and the circuits outside of the
TTZ.
10. Security Considerations
The mechanism described in this document does not raise any new
security issues for the IS-IS protocols.
11. IANA Considerations
12. Acknowledgement
The author would like to thank Dean Cheng, Acee Lindem for their
valuable comments on this draft.
13. References
Chen, et al. Expires August 22, 2013 [Page 17]
Internet-Draft Topology-Transparent Zone February 2013
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol",
RFC 1142, February 1990.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008.
[RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link
Attribute Sub-TLV", RFC 5029, September 2007.
13.2. Informative References
[RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 5307, October 2008.
Authors' Addresses
Huaimo Chen
Huawei Technologies
Boston, MA
US
Email: huaimo.chen@huawei.com
Renwei Li
Huawei Technologies
2330 Central expressway
Santa Clara, CA
US
Email: renwei.li@huawei.com
Chen, et al. Expires August 22, 2013 [Page 18]
Internet-Draft Topology-Transparent Zone February 2013
Gregory Cauchie
France Telecom
38-40 avenue du General LECLERC
Issy-les-Moulineaux 92130,
FRANCE
Email: greg.cauchie@gmail.com
Ning So
Tata Communications
2613 Fairbourne Cir.
Plano, TX 75082
USA
Email: ning.so@tatacommunications.com
Alvaro Retana
Cisco Systems
2610 Wycliff Road
Raleigh, NC 27607
USA
Email: aretana@cisco.com
Chen, et al. Expires August 22, 2013 [Page 19]