draft-ietf-ospf-ttz-01.txt   draft-ietf-ospf-ttz-02.txt 
Internet Engineering Task Force H. Chen Internet Engineering Task Force H. Chen
Internet-Draft R. Li Internet-Draft R. Li
Intended status: Experimental A. Kumar S N Intended status: Experimental Huawei Technologies
Expires: January 3, 2016 Huawei Technologies Expires: June 25, 2016 A. Retana
G. Cauchie Y. Yang
A. Retana
Cisco Systems, Inc. Cisco Systems, Inc.
N. So
Tata Communications
V. Liu V. Liu
China Mobile China Mobile
M. Toy M. Toy
Comcast Comcast
L. Liu December 23, 2015
UC Davis
July 2, 2015
OSPF Topology-Transparent Zone OSPF Topology-Transparent Zone
draft-ietf-ospf-ttz-01.txt draft-ietf-ospf-ttz-02.txt
Abstract Abstract
This document presents a topology-transparent zone in a domain. A This document presents a topology-transparent zone in a domain. A
topology-transparent zone comprises a group of routers and a number topology-transparent zone comprises a group of routers and a number
of links connecting these routers. Any router outside of the zone is of links connecting these routers. Any router outside of the zone is
not aware of the zone. The information about the links and routers 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. 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 Any link state change such as a link down inside the zone is not seen
by any router outside of the zone. by any router outside of the zone.
skipping to change at page 1, line 49 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2016. This Internet-Draft will expire on June 25, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Conventions Used in This Document . . . . . . . . . . . . . . 4
4. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Overview of Topology-Transparent Zone . . . . . . . . . . 5 5. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 5
4.2. An Example of TTZ . . . . . . . . . . . . . . . . . . . . 6 5.1. Overview of Topology-Transparent Zone . . . . . . . . . . 5
5. Extensions to OSPF Protocols . . . . . . . . . . . . . . . . . 7 5.2. Some Details on TTZ . . . . . . . . . . . . . . . . . . . 5
5.1. Opaque LSAs for TTZ . . . . . . . . . . . . . . . . . . . 7 6. Extensions to OSPF Protocols . . . . . . . . . . . . . . . . . 6
5.2. A TTZ Capability TLV in Router Information LSA . . . . . . 10 7. Constructing LSAs for TTZ . . . . . . . . . . . . . . . . . . 10
6. Constructing LSAs for TTZ . . . . . . . . . . . . . . . . . . 11 8. Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 11
7. Establishing Adjacencies . . . . . . . . . . . . . . . . . . . 12 8.1. Discover TTZ Neighbor over Normal Adjacency . . . . . . . 11
7.1. Discover TTZ Neighbor over Normal Adjacency . . . . . . . 12 8.2. Establishing TTZ Adjacencies . . . . . . . . . . . . . . . 12
7.2. Establishing TTZ Adjacencies . . . . . . . . . . . . . . . 12 8.3. Adjacency between TTZ Edge and TTZ External Router . . . . 12
7.3. Adjacency between TTZ Edge and Router outside . . . . . . 13 9. Distribution of LSAs . . . . . . . . . . . . . . . . . . . . . 13
8. Distribution of LSAs . . . . . . . . . . . . . . . . . . . . . 13 9.1. Distribution of LSAs within TTZ . . . . . . . . . . . . . 13
8.1. Distribution of LSAs within TTZ . . . . . . . . . . . . . 14 9.2. Distribution of LSAs through TTZ . . . . . . . . . . . . . 13
8.2. Distribution of LSAs through TTZ . . . . . . . . . . . . . 14 10. Computation of Routing Table . . . . . . . . . . . . . . . . . 13
9. Computation of Routing Table . . . . . . . . . . . . . . . . . 14 11. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Configuring TTZ . . . . . . . . . . . . . . . . . . . . . 14
10.1. Configuring TTZ . . . . . . . . . . . . . . . . . . . . . 14 11.2. Smooth Migration to TTZ . . . . . . . . . . . . . . . . . 14
10.2. Smooth Migration to TTZ . . . . . . . . . . . . . . . . . 15 11.3. Adding a Router into TTZ . . . . . . . . . . . . . . . . . 15
10.3. Adding a Router into TTZ . . . . . . . . . . . . . . . . . 16 12. Prototype Implementation . . . . . . . . . . . . . . . . . . . 15
11. Prototype Implementation . . . . . . . . . . . . . . . . . . . 17 12.1. What are Implemented and Tested . . . . . . . . . . . . . 16
11.1. What are Implemented and Tested . . . . . . . . . . . . . 17 12.2. Implementation Experience . . . . . . . . . . . . . . . . 17
11.2. Implementation Experience . . . . . . . . . . . . . . . . 18 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 15. Contributors and Other Authors . . . . . . . . . . . . . . . . 18
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 16. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19
15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 17.1. Normative References . . . . . . . . . . . . . . . . . . . 19
16.1. Normative References . . . . . . . . . . . . . . . . . . . 19 17.2. Informative References . . . . . . . . . . . . . . . . . . 20
16.2. Informative References . . . . . . . . . . . . . . . . . . 20 Appendix A. Constants for LSA Distribution . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The number of routers in a network becomes larger and larger as the The number of routers in a network becomes larger and larger as the
Internet traffic keeps growing. Through splitting the network into Internet traffic keeps growing. Through splitting the network into
multiple areas, we can extend the network further. However, there multiple areas, we can extend the network further. However, there
are a number of issues when a network is split further into more are a number of issues when a network is split further into more
areas. areas.
skipping to change at page 5, line 5 skipping to change at page 4, line 5
describes extensions to OSPF for supporting the topology-transparent describes extensions to OSPF for supporting the topology-transparent
zone, which is scalable and resolves the issues above. zone, which is scalable and resolves the issues above.
A topology-transparent zone comprises a group of routers and a number A topology-transparent zone comprises a group of routers and a number
of links connecting these routers. Any router outside of the zone is of links connecting these routers. Any router outside of the zone is
not aware of the zone. The information about the links and routers 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. 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 Any link state change such as a link down inside the zone is not seen
by any router outside of the zone. by any router outside of the zone.
2. Conventions Used in This Document 2. Terminology
TTZ internal link: a link between two TTZ adjacent routers in a same
TTZ.
TTZ external link: a link between a TTZ edge router and a router
outside of the TTZ.
TTZ internal router: a router in a TTZ whose adjacent routers are in
the same TTZ.
TTZ external router: a router outside of a TTZ without any TTZ
internal link.
TTZ edge router: a router in a TTZ that has one (or more) adjacent
routers which belong to the same TTZ, and one (or more) adjacent
routers which do not belong to the TTZ.
3. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
3. Requirements 4. Requirements
Topology-Transparent Zone (TTZ) may be deployed for resolving some Topology-Transparent Zone (TTZ) may be deployed for resolving some
critical issues in existing networks and future networks. The critical issues in existing networks and future networks. The
requirements for TTZ are listed as follows: requirements for TTZ are listed as follows:
o TTZ MUST be backward compatible. When a TTZ is deployed on a set o Routers outside a TTZ MUST NOT require any changes to operate with
of routers in a network, the routers outside of the TTZ in the the TTZ.
network do not need to know or support TTZ.
o TTZ MUST support at least one more levels of network hierarchies, o A TTZ MUST be in an area.
in addition to the hierarchies supported by existing routing
protocols. o A TTZ MUST hide the topology of the TTZ from any router outside of
the TTZ.
o Users SHOULD be able to easily set up an end to end service o Users SHOULD be able to easily set up an end to end service
crossing TTZs. crossing TTZs.
o The configuration for a TTZ in a network SHOULD be minimum. o The configuration for a TTZ in a network SHOULD be minimum.
o The changes on the existing protocols for supporting TTZ SHOULD be o The changes on the existing protocols for supporting TTZ SHOULD be
minimum. minimum.
4. Topology-Transparent Zone 5. Topology-Transparent Zone
4.1. Overview of Topology-Transparent Zone 5.1. Overview of Topology-Transparent Zone
A Topology-Transparent Zone (TTZ) is identified by an Identifier A Topology-Transparent Zone (TTZ) is identified by an Identifier
(ID), and it includes a group of routers and a number of links (ID), and it includes a group of routers and a number of links
connecting the routers. A TTZ is in an OSPF area. connecting the routers. A TTZ is in an OSPF area.
The ID of a TTZ or TTZ ID is a number that is unique for identifying The ID of a TTZ or TTZ ID is a 32-bit number that is unique for
an entity such as a node in an OSPF domain. It is not zero in identifying an entity such as a node in an OSPF domain. It is not
general. zero in general.
In addition to having the functions of an OSPF area, an OSPF TTZ In addition to having the functions of an OSPF area, an OSPF TTZ
makes some improvements on an OSPF area, which include: makes some improvements on an OSPF area, which include:
o An OSPF TTZ is virtualized as the TTZ edge routers connected. o An OSPF TTZ is virtualized as the TTZ edges fully connected.
o An OSPF TTZ receives the link state information about the topology o An OSPF TTZ receives the link state information about the topology
outside of the TTZ, stores the information in the TTZ and floods outside of the TTZ, stores the information in the TTZ and floods
the information through the TTZ to the routers outside of the TTZ. the information through the TTZ to the routers outside of the TTZ.
4.2. An Example of TTZ 5.2. Some Details on TTZ
The figure below shows an area containing a TTZ: TTZ 600. The figure below shows an area containing a TTZ: TTZ 600.
TTZ 600 TTZ 600
\ \
\ ^~^~^~^~^~^~^~^~^~^~^~^~ \ ^~^~^~^~^~^~^~^~^~^~^~^~
( ) ( )
===[R15]========(==[R61]------------[R63]==)======[R29]=== ===[R15]========(==[R61]------------[R63]==)======[R29]===
|| ( | \ / | ) || || ( | \ / | ) ||
|| ( | \ / | ) || || ( | \ / | ) ||
skipping to change at page 6, line 37 skipping to change at page 6, line 5
===[R17]========(==[R65]------------[R67]==)======[R31]=== ===[R17]========(==[R65]------------[R67]==)======[R31]===
\\ (// \\) // \\ (// \\) //
|| //v~v~v~v~v~v~v~v~v~v~v~\\ || || //v~v~v~v~v~v~v~v~v~v~v~\\ ||
|| // \\ || || // \\ ||
|| // \\ || || // \\ ||
\\ // \\ // \\ // \\ //
======[R23]==============================[R25]===== ======[R23]==============================[R25]=====
// \\ // \\
// \\ // \\
Figure 1: An Example of TTZ
The area comprises routers R15, R17, R23, R25, R29 and R31. It also The area comprises routers R15, R17, R23, R25, R29 and R31. It also
contains TTZ 600, which comprises routers R61, R63, R65, R67, R71 and contains TTZ 600, which comprises routers R61, R63, R65, R67, R71 and
R73, and the links connecting them. R73, and the links connecting them.
There are two types of routers in a TTZ: TTZ internal routers and TTZ There are two types of routers in a TTZ: TTZ internal and TTZ edge
edge routers. A TTZ internal router is a router inside the TTZ and routers. TTZ 600 has four TTZ edge routers R61, R63, R65 and R67.
its adjacent routers are in the TTZ. A TTZ edge router is a router Each TTZ edge router is connected to at least one router outside of
inside the TTZ and has at least one adjacent router that is outside TTZ 600. For instance, router R61 is a TTZ edge router since it is
of the TTZ. connected to router R15, which is outside of TTZ 600.
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. In addition, TTZ 600 comprises two TTZ internal routers R71 and R73.
A TTZ internal router is not connected to any router outside of the 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 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 not connected to any router outside of TTZ 600. It is just connected
to routers R61, R63, R65, R67 and R73 in the TTZ. to routers R61, R63, R65, R67 and R73 in the TTZ.
A TTZ MUST hide the information inside the TTZ from the outside. It A TTZ hides the internal topology of the TTZ from the outside. It
MUST NOT directly distribute any internal information about the TTZ does not directly distribute any internal information about the TTZ
to a router outside of the TTZ. to a router outside of the TTZ.
For instance, the TTZ in the figure above MUST NOT send the For instance, TTZ 600 does not send the information about TTZ
information about TTZ internal router R71 to any router outside of internal router R71 to any router outside of TTZ 600; it does not
the TTZ in the routing domain; it MUST NOT send the information about send the information about the link between TTZ router R61 and R65 to
the link between TTZ router R61 and R65 to any router outside of the any router outside of TTZ 600.
TTZ.
In order to create a TTZ, we MUST configure the same TTZ ID on the In order to create a TTZ, we may assign the same TTZ ID to the TTZ
edge routers and identify the TTZ internal links on them. In edge routers and identify the TTZ internal links on them through CLI.
addition, we SHOULD configure the TTZ ID on every TTZ internal router In addition, we assign the TTZ ID to every TTZ internal router which
which indicates that every link of the router is a TTZ internal link. 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 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 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: 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 R61, R63, R65 and R67, which are fully connected.
connected.
In addition, a router outside of the TTZ sees TTZ edge routers having In addition, a router outside of the TTZ sees TTZ edge routers having
normal connections to the routers outside of the TTZ. For example, normal connections to the routers outside of the TTZ. For example,
router R15 sees four TTZ edge routers R61, R63, R65 and R67, which 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 have the normal connections to R15, R29, R17 and R23, R25 and R31
respectively. respectively.
5. Extensions to OSPF Protocols 6. Extensions to OSPF Protocols
5.1. Opaque LSAs for TTZ
The link state information about a TTZ includes router LSAs and The link state information about a TTZ includes router LSAs and
network LSAs describing the TTZ topology. These LSAs can be network LSAs. Router LSAs can be contained and distributed in opaque
contained and distributed in opaque LSAs within the TTZ. Some LSAs [RFC5250] within the TTZ. Some control information on a TTZ can
control information on a TTZ can also be contained and distributed in also be contained and distributed in opaque LSAs within the TTZ.
opaque LSAs within the TTZ. These opaque LSAs are called TTZ opaque
LSAs or TTZ LSAs for short.
The following is a general form of a TTZ LSA. It has an LS type = 10 These opaque LSAs are called TTZ opaque LSAs or TTZ LSAs for short.
and TTZ-LSA-Type, and contains a number of TLVs.
The following is a general form of a TTZ LSA. It has an LS type =
10/9 and TTZ-LSA-Type, and contains a number of TLVs.
0 1 2 3 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 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 | LS Type = 10 | | LS age | Options | LS Type = 10/9|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTZ-LSA-type | Opaque ID | |TTZ-LSA-type(5)| Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number | | LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length | | LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where TTZ-LSA-type may be TBD1 (TTZ-RT-LSA-type) for TTZ Router LSA, Where TTZ-LSA-type is 5, the exact number for it is to be assigned by
TBD2 (TTZ-NW-LSA-type) for TTZ Network LSA, and TBD3 (TTZ-CT-LSA- IANA.
type) for TTZ Control LSA.
There are four types of TLVs: TTZ ID TLV, TTZ Router TLV, TTZ network There are three top-level TLVs defined: TTZ ID TLV, TTZ Router TLV,
TLV and TTZ Options TLV. A TTZ ID TLV has the following format. It and TTZ Options TLV. A TTZ LSA of LS Type 10 contains a mandatory
contains a TTZ ID. TTZ ID TLV, which is followed by one of the other top-level TLVs.
A TTZ LSA containing a TTZ Router TLV is called TTZ Router LSA. A
TTZ LSA containing a TTZ Options TLV is called TTZ Control LSA.
A TTZ ID TLV has the following format. It contains a TTZ ID and some
flags.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTZ-ID-TLV-type | Length = 4 | | TTZ-ID-TLV-type (1) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTZ ID | | TTZ ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |E|Z|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E = 1: Indicating a router is a TTZ Edge router
Z = 1: Indicating a router has migrated to TTZ
When a TTZ router originates a TTZ LSA containing a TTZ ID TLV, it
sets flag E to 1 in the TTZ ID TLV if it is a TTZ edge router, and to
0 if it is a TTZ internal router. It sets flag Z to 1 after it has
migrated to TTZ.
The format of a TTZ Router TLV is as follows. It contains the The format of a TTZ Router TLV is as follows. It contains the
contents of a normal router LSA. A TTZ router LSA includes a TTZ ID contents of a router LSA.
TLV and a TTZ Router TLV.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTZ-RT-TLV-type | TLV-Length | | TTZ-RT-TLV-type (2) | TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G| 0 |V|E|B| 0 | # links | | 0 |V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID | | Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data | | Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # TOS | metric | | Type | # TOS | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
Where G = 1/0 indicates that the router is an edge/internal router of For a router link, the existing eight bit Type field for a router
TTZ. For a router link, the existing eight bit Type field for a link is split into two fields as follows:
router link may be split into two fields as follows:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| I | Type-1 | | I | Type-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I bit flag: I bit flag:
1: Router link is an internal link to a router inside TTZ. 1: Router link is a TTZ internal link.
0: This indicates that the router link is an external link. 0: Router link is a TTZ external link.
Type-1: The kind of the link. Type-1: The kind of the link.
For a link inside a TTZ, I bit flag is set to one, indicating that For a link inside a TTZ, I bit flag is set to one, indicating that
this link is an internal TTZ link. For a link connecting to a router this link is a TTZ internal link. For a link connecting to a router
outside of a TTZ from a TTZ edge router, I bit flag is set to zero, outside of a TTZ from a TTZ edge router, I bit flag is set to zero,
indicating that this link is an external TTZ link. indicating that this link is a TTZ external link.
The value of Type-1 may be 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.
A TTZ Network TLV has the following format. It contains the contents
of a normal network LSA. A TTZ network LSA includes a TTZ ID TLV and
a TTZ network TLV.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTZ-NW-TLV-type | TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attached Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
Where Network ID is the interface address of the DR, which is The value of Type-1 is 1, 2, 3, or 4, which indicates that the kind
followed by the contents of a network LSA. 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.
The format of TTZ Options TLV is as follows. A TTZ control LSA The format of TTZ Options TLV is as follows.
contains a TTZ ID TLV and a TTZ Options TLV.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTZ-OP-TLV-type | Length = 4 | | TTZ-OP-TLV-type (3) | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|M|N|R| 0 | |T|M|N|R| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T = 1: Distributing TTZ Topology Information for Migration T = 1: Distributing TTZ Topology Information for Migration
M = 1: Migrating to TTZ M = 1: Migrating to TTZ
N = 1: Distributing Normal Topology Information for Rollback N = 1: Distributing Normal Topology Information for Rollback
R = 1: Rolling back from TTZ R = 1: Rolling back from TTZ
5.2. A TTZ Capability TLV in Router Information LSA Flags T, M, N and R are exclusive. When one of them is set to 1, the
others MUST be set to 0.
A new bit such as bit 6 for TTZ capability may be defined in the After a user triggers a TTZ router in a way such as issuing a CLI
Router Informational Capabilities TLV as follows: command to distribute TTZ topology information, the TTZ router
originates a TTZ Control LSA having a TTZ Options TLV with flag T set
to 1. It also originates its TTZ router LSA. When another TTZ
router receives the LSA with T = 1, it originates its TTZ router LSA
as needed.
Bit Capabilities After a user asks a TTZ router in a way such as a CLI command to
0 OSPF graceful restart capable [GRACE] migrate to TTZ, the TTZ router originates a TTZ Control LSA having a
: ... TTZ Options TLV with flag M set to 1 and migrates to TTZ. When
5 OSPF Experimental TE [EXP-TE] another TTZ router receives the LSA with M = 1, it also migrates to
6 OSPF TTZ capable [OSPF-TTZ] TTZ.
7-31 Unassigned (Standards Action)
When the OSPF TTZ capable bit is set to one, a TTZ capability TLV After a user triggers a TTZ router to distribute normal topology
must follow the Router Informational Capabilities TLV to indicate a information, the TTZ router originates a TTZ Control LSA having a TTZ
link/router's TTZ capability and the TTZ to which the link/router Options TLV with flag N set to 1. It also distributes its normal
belongs. It has the following format. LSAs such as its normal router LSA and stops distributing its other
TTZ LSAs. When another TTZ router receives the LSA with N = 1, it
distributes its normal LSAs and stops distributing its TTZ LSAs.
After a user asks a TTZ router to roll back from TTZ, the TTZ router
originates a TTZ Control LSA having a TTZ Options TLV with flag R set
to 1 and rolls back from TTZ. When another TTZ router receives the
LSA with R = 1, it also rolls back from TTZ.
If two CLI trigger commands are issued on a TTZ router, two TTZ
Control LSAs having a same instance ID are originated by the TTZ
router.
A TTZ LSA of LS Type 9 with a TTZ ID TLV below is used to discover a
TTZ neighbor.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTZ-CAP-TLV-Type = 2 | Length = 8 | | LS age | Options | LS Type = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTZ ID | |TTZ-LSA-type(5)| Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| 0 | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TTZ ID TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It contains a TTZ ID and a number of TTZ bits. The following bits in 7. Constructing LSAs for TTZ
the TLV are assigned:
Bit Meaning
M Have Migrated to TTZ (i.e., works as TTZ)
1-31 Unassigned (Standards Action)
A link scope RI LSA with a OSPF TTZ capable bit set to one and a TTZ
Capability TLV will be used to discover a TTZ neighbor.
6. Constructing LSAs for TTZ
There are three types of LSAs for representing a TTZ: TTZ router LSA, The LSAs for representing a TTZ include TTZ router LSAs and normal
TTZ network LSA and Router LSA for virtualizing TTZ. The first two router LSAs for virtualizing the TTZ.
may be generated by a TTZ router, and the third by a TTZ edge router.
A TTZ router LSA generated by a TTZ router has a TTZ ID TLV and a TTZ A TTZ router LSA generated by a TTZ edge router has a TTZ ID TLV and
Router TLV. The former includes the ID of the TTZ to which the a TTZ Router TLV. The former includes the ID of the TTZ to which the
router belongs. The latter contains the links to the router. router belongs and flag E set to 1, which indicates the originator of
the LSA is a TTZ Edge router. The latter contains the links to the
router.
A TTZ network LSA for a broadcast link is generated by the DR for the A TTZ router LSA generated by a TTZ internal router has a TTZ ID TLV
link. It contains a TTZ ID TLV and a TTZ network TLV. The former containing the ID of the TTZ to which the router belongs and flag E
has the ID of the TTZ to which the link belongs. The latter includes set to 0, which indicates the originator of the LSA is a TTZ internal
the DR's address, the network mask, and the routers attached. router. This LSA implies that all the links connected to the router
are TTZ internal links. In other words, all the router links in the
normal router LSA generated by the TTZ internal router are TTZ
internal links. Thus a TTZ internal router can choose one of two
options: 1) generating a TTZ router LSA with a TTZ ID TLV and a TTZ
Router TLV and 2) generating its normal router LSA and a TTZ router
LSA with just a TTZ ID TLV. These two options are compatible.
A router LSA for virtualizing a TTZ generated by an edge router of After receiving a trigger to migrate to TTZ such as a TTZ Control LSA
the TTZ comprises three groups of links in general. with flag M = 1, a TTZ edge router originates a normal router LSA for
virtualizing a TTZ, which comprises three groups of links in general.
The first group are the router links connecting the routers outside The first group are the router links connecting the TTZ external
of the TTZ. These router links are normal router links. There is a routers. These router links are normal router links. There is a
router link for every adjacency between this TTZ edge router and a router link for every adjacency between this TTZ edge router and a
router outside of the TTZ. TTZ external router.
The second group are the "virtual" router links. For each of the The second group are the "virtual" router links. For each of the
other TTZ edge routers, there is a point-to-point router link to it. other TTZ edge routers, there is a point-to-point router link to it.
The cost of the link is the cost of the shortest path from this TTZ
The cost of the link may be the cost of the shortest path from this edge router to it within the TTZ.
TTZ edge router to it within the TTZ.
In addition, the LSA may contain a third group of links, which are In addition, the LSA may contain a third group of links, which are
stub links for other destinations inside the TTZ. They may be the stub links for other destinations inside the TTZ. They may be the
loopback addresses to be accessed by a node outside of the TTZ. loopback addresses to be accessed by a node outside of the TTZ.
7. Establishing Adjacencies To migrate to TTZ smoothly, a TTZ edge router virtualizes the TTZ in
two steps. At first, the router updates its normal router LSA by
adding a point-to-point link to each of the other edge routers of the
TTZ and a stub link for each of the loopback addresses in the TTZ to
be leaked. And then it removes the links configured as TTZ links
from its updated router LSA after sending its updated router LSA and
receiving the updated router LSAs originated by the other TTZ edge
routers for MaxLSADistTime or after sending its updated router LSA
for MaxLSAGenDistTime.
8. Establishing Adjacencies
This section describes the adjacencies in some different cases. This section describes the adjacencies in some different cases.
7.1. Discover TTZ Neighbor over Normal Adjacency 8.1. Discover TTZ Neighbor over Normal Adjacency
For two routers A and B connected by a P2P link and having a normal For two routers A and B connected by a P2P link and having a normal
adjacency, they discover TTZ each other through a link scope RI LSA adjacency, they discover TTZ each other through a TTZ LSA of LS Type
with an OSPF TTZ capable bit and a TTZ ID. We call this LSA D-LSA 9 with a TTZ ID TLV. We call this LSA D-LSA for short. If two ends
for short. If two ends of the link have the same TTZ ID, A and B are of the link have the same TTZ ID, A and B are TTZ neighbors. The
TTZ neighbors. The following is a sequence of events related to TTZ. following is a sequence of events related to TTZ.
A B A B
Configure TTZ Configure TTZ Configure TTZ Configure TTZ
D-LSA (TTZ-ID=100) D-LSA (TTZ-ID=100)
---------------------------> Same TTZ ID ---------------------------> Same TTZ ID
A is B's TTZ Neighbor A is B's TTZ Neighbor
D-LSA (TTZ-ID=100) D-LSA (TTZ-ID=100)
Same TTZ ID <--------------------------- Same TTZ ID <---------------------------
B is A's TTZ Neighbor B is A's TTZ Neighbor
A sends B a D-LSA with TTZ-ID after the TTZ is configured on it. B A sends B a D-LSA with TTZ-ID after the TTZ is configured on it. B
sends A a D-LSA with TTZ-ID after the TTZ is configured on it. When sends A a D-LSA with TTZ-ID after the TTZ is configured on it. When
A receives the D-LSA from B and determines they have the same TTZ ID, A receives the D-LSA from B and determines they have the same TTZ ID,
B is A's TTZ neighbor. When B receives the D-LSA from A and B is A's TTZ neighbor. When B receives the D-LSA from A and
determines they have the same TTZ ID, A is B's TTZ neighbor. determines they have the same TTZ ID, A is B's TTZ neighbor.
For a number of routers connected through a broadcast link and having For a number of routers connected through a broadcast link and having
normal adjacencies among them, they also discover TTZ each other normal adjacencies among them, they also discover TTZ each other
through D-LSAs. The DR for the link "forms" TTZ adjacency with each through D-LSAs. The DR for the link "forms" TTZ adjacency with each
of the other routers if all the routers attached to the link have the of the other routers if all the routers attached to the link have the
same TTZ ID configured on the connections to the link. same TTZ ID configured on the connections to the link. Otherwise,
the DR does not "form" any TTZ adjacency with any router attached to
the link.
7.2. Establishing TTZ Adjacencies 8.2. Establishing TTZ Adjacencies
When a router (say A) is connected via a P2P link to another router When a router (say A) is connected via a P2P link to another router
(say B) and there is not any adjacency between them over the link, a (say B) and there is not any adjacency between them over the link, a
user configures TTZ on two ends of the link to form a TTZ adjacency. user configures TTZ on two ends of the link to form a TTZ adjacency.
They start to discover TTZ each other through D-LSAs in the same way
While A and B are forming an adjacency, they start to discover TTZ as described above after the normal adjacency is formed.
each other through D-LSAs in the same way as described above after
the normal adjacency is greater than ExStart. When the normal
adjacency is full and B becomes A's TTZ neighbor, A forms a TTZ
adjacency with B. Similarly, B forms a TTZ adjacency with A.
For a number of routers connected through a broadcast link and having For a number of routers connected through a broadcast link and having
no adjacency among them, they start to form TTZ adjacencies after TTZ no adjacency among them, they start to form TTZ adjacencies after TTZ
is configured on the link. While forming adjacencies, they discover is configured on the link. While forming adjacencies, they discover
TTZ each other through D-LSAs in the same way as described above TTZ each other through D-LSAs in the same way as described above
after the normal adjacency is greater than ExStart. The DR for the after the normal adjacency is formed.
link forms TTZ adjacency with each of the other routers if all the
routers attached to the link have the same TTZ ID configured on the
connections to the link. Otherwise, the DR does not form any
adjacency with any router attached to the link.
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 LLS of a hello packet. The procedure for handling
hellos is changed to consider TTZ ID. If two routers have the same
TTZ IDs in their hellos, an adjacency between these two routers is to
be formed; otherwise, no adjacency is formed.
7.3. Adjacency between TTZ Edge and Router outside 8.3. Adjacency between TTZ Edge and TTZ External Router
For an edge router in a TTZ, it forms an adjacency with any router For an edge router in a TTZ, it forms an adjacency with any TTZ
outside of the TTZ that has a connection with it. external router that has a connection with it.
When the edge router synchronizes its link state database with the 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 TTZ external router, it sends the TTZ external router the information
information about all the LSAs except for the LSAs belonging to the about all the LSAs except for the LSAs belonging to the TTZ that are
TTZ that are hidden from any router outside of the TTZ. hidden from any router outside of the TTZ.
At the end of the link state database synchronization, the edge At the end of the link state database synchronization, the edge
router originates its own router LSA for virtualizing the TTZ and router originates its own router LSA for virtualizing the TTZ and
sends this LSA to the router outside of the TTZ. sends this LSA to the TTZ external router.
From the point of view of the router outside of the TTZ, it sees the From the point of view of the TTZ external router, which is outside
other end as a normal router and forms the adjacency in the same way of the TTZ, it sees the other end as a normal router and forms the
as a normal router. It is not aware of anything about its adjacency in the same way as a normal router. It is not aware of
neighboring TTZ. From the LSAs related to the TTZ edge router in the anything about its neighboring TTZ. From the LSAs related to the TTZ
other end, it knows that the TTZ edge router is connected to each of edge router in the other end, it knows that the TTZ edge router is
the other TTZ edge routers and some routers outside of the TTZ. connected to each of the other TTZ edge routers and some routers
outside of the TTZ.
8. Distribution of LSAs 9. Distribution of LSAs
LSAs can be divided into a couple of classes according to their LSAs can be divided into a couple of classes according to their
distributions. The first class of LSAs is distributed within a TTZ. distributions. The first class of LSAs is distributed within a TTZ.
The second is distributed through a TTZ. The second is distributed through a TTZ.
8.1. Distribution of LSAs within TTZ 9.1. Distribution of LSAs within TTZ
Any LSA about a link state in a TTZ is distributed within the TTZ. Any LSA about a link state in a TTZ is distributed within the TTZ.
It is not distributed to any router outside of the TTZ. For example, It is not distributed to any router outside of the TTZ. For example,
a router LSA generated for a router in a TTZ is distributed within a router LSA generated for a router in a TTZ is distributed within
the TTZ and not distributed to any router outside of the TTZ. the TTZ and not distributed to any router outside of the TTZ.
Any network LSA generated for a broadcast or NBMA network in a TTZ is Any network LSA generated for a broadcast or NBMA network in a TTZ is
distributed in the TTZ and not sent to a router outside of the TTZ. distributed in the TTZ and not sent to a router outside of the TTZ.
Any opaque LSA generated for a TTZ internal TE link is distributed Any opaque LSA generated for a TTZ internal TE link is distributed
within the TTZ and not distributed to any router outside of the TTZ. within the TTZ and not distributed to any router outside of the TTZ.
8.2. Distribution of LSAs through TTZ After migrating to TTZ, every edge router of a TTZ MUST NOT
distribute any LSA about a link state in the TTZ to any router
outside of the TTZ.
For any TTZ LSA originated by a router within the TTZ, every edge
router of the TTZ MUST NOT distribute it to any router outside of the
TTZ.
9.2. Distribution of LSAs through TTZ
Any LSA about a link state outside of a TTZ received by an edge Any LSA about a link state outside of a TTZ received by an edge
router of the TTZ is distributed through the TTZ. For example, when router of the TTZ is distributed through the TTZ. For example, when
an edge router of a TTZ receives an LSA from a router outside of the an edge router of a TTZ receives an LSA from a router outside of the
TTZ, it floods it to its neighboring routers both inside the TTZ and 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 outside of the TTZ. This LSA may be any LSA such as a router LSA
that is distributed in a domain. that is distributed in a domain.
The routers in the TTZ continue to flood the LSA. When another edge 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 router of the TTZ receives the LSA, it floods the LSA to its
neighboring routers both outside of the TTZ and inside the TTZ. neighboring routers both outside of the TTZ and inside the TTZ.
9. Computation of Routing Table 10. Computation of Routing Table
The computation of the routing table on a router is the same as that When a router migrates to TTZ, the computation of the routing table
described in RFC 2328, with one exception. A router in a TTZ MUST on the router is the same as that described in RFC 2328, with one
ignore the router LSAs generated by the edge routers of the TTZ for exception. The router in a TTZ ignores the router LSAs generated by
virtualizing the TTZ. It computes routes through using the TTZ the TTZ edge routers for virtualizing the TTZ. It computes routes
topology represented by TTZ LSAs and the topology outside of the TTZ. through using the TTZ topology and the topology outside of the TTZ.
10. Operations 11. Operations
10.1. Configuring TTZ 11.1. Configuring TTZ
This section proposes some options for configuring a TTZ. This section proposes some options for configuring a TTZ.
1. Configuring TTZ on Every Link in TTZ 1. Configuring TTZ on Every Link in TTZ
If every link in a TTZ is configured with a same TTZ ID as a TTZ If every link in a TTZ is configured with a same TTZ ID as a TTZ
link, the TTZ is determined. A router with some TTZ links and some link, the TTZ is determined. A router with some TTZ links and some
normal links is a TTZ edge router. A router with only TTZ links is a normal links is a TTZ edge router. A router with only TTZ links is a
TTZ internal router. TTZ internal router.
2. Configuring TTZ on Every Router in TTZ 2. Configuring TTZ on Every Router in TTZ
We may configure a same TTZ ID on every router in the TTZ, and on We may configure a same TTZ ID on every router in the TTZ, and on
every edge router's links connecting to the routers in the TTZ. every edge router's links connecting to the routers in the TTZ.
A router configured with the TTZ ID on some of its links is a TTZ A router configured with the TTZ ID on some of its links is a TTZ
edge router. A router configured with the TTZ ID only is a TTZ edge router. A router configured with the TTZ ID only is a TTZ
internal router. All the links on a TTZ internal router are TTZ internal router. All the links on a TTZ internal router are TTZ
links. This option is simpler than the above one. links. This option is simpler than the above one.
10.2. Smooth Migration to TTZ 11.2. Smooth Migration to TTZ
For a group of routers and a number of links connecting the routers For a group of routers and a number of links connecting the routers
in an area, making them transfer to work as a TTZ without any service in an area, making them transfer to work as a TTZ without any service
interruption may take a few of steps or stages. interruption takes a few of steps or stages.
At first, users configure the TTZ feature on every router in the TTZ. At first, a user configures the TTZ feature on every router in the
In this stage, a router does not originate its TTZ router LSA or TTZ TTZ. In this stage, a router does not originate its TTZ router LSA.
network LSAs. It will discover its TTZ neighbors. It will discover its TTZ neighbors.
Secondly, after configuring the TTZ, users may issue a CLI command on Secondly, after configuring the TTZ, a user issues a CLI command on
one router in the TTZ, which triggers every router in the TTZ to one router in the TTZ, which triggers every router in the TTZ to
generate and distribute TTZ information among the routers in the TTZ. generate and distribute TTZ information among the routers in the TTZ.
When the router receives the command, it originates its TTZ router When the router receives the command, it originates a TTZ control LSA
LSA and TTZ network LSAs as needed, and distributes them to its TTZ with T=1 (indicating TTZ information generation and distribution for
neighbors. It also originates a TTZ control LSA with T=1 (indicating migration). It also originates its TTZ router LSA, and distributes
TTZ information generation and distribution for migration). When a the LSA to its TTZ neighbors. When a router in the TTZ receives the
router in the TTZ receives the LSA with T=1, it originates its TTZ LSA with T=1, it originates its TTZ router LSA. In this stage, every
router LSA and TTZ network LSAs as needed. In this stage, every
router in the TTZ has dual roles. One is to function as a normal router in the TTZ has dual roles. One is to function as a normal
router. The other is to generate and distribute TTZ information. router. The other is to generate and distribute TTZ information.
Thirdly, users SHOULD check whether every router in the TTZ is ready Thirdly, a user checks whether every router in the TTZ is ready for
for transferring to work as a TTZ router. A router in the TTZ is migration to TTZ. A router in the TTZ is ready after it has received
ready after it has received all the necessary information from all all the necessary information from all the routers in the TTZ. This
the routers in the TTZ. This information may be displayed on a information may be displayed on a router through a CLI command.
router through a CLI command.
And then users may activate the TTZ through using a CLI command such
as migrate to TTZ on one router in the TTZ. The router transfers to
work as a TTZ router, generates and distributes a TTZ control LSA
with M=1 (indicating Migrating to TTZ) after it receives the command.
After a router in the TTZ receives the TTZ control LSA with M=1, it And then a user activates the TTZ through using a CLI command such as
also transfers to work as a TTZ router. Thus, activating the TTZ on migrate to TTZ on one router in the TTZ. The router migrates to TTZ,
one TTZ router makes every router in the TTZ transfer to work as a generates and distributes a TTZ control LSA with M = 1 (indicating
TTZ router, which flushes its normal router LSA and network LSAs, Migrating to TTZ) after it receives the command.
computes routes through using the TTZ topology represented by TTZ
LSAs and the topology outside of the TTZ.
The old normal LSAs should be flushed by TTZ routers after the After a router in the TTZ receives the TTZ control LSA with M = 1, it
migration to TTZ is complete for some time such as one minute. A TTZ also migrates to TTZ. Thus, activating the TTZ on one TTZ router
router may determine if the migration to TTZ is complete through makes every router in the TTZ migrate to TTZ, which computes routes
checking whether it has received all the new TTZ LSAs and the LSAs through using the TTZ topology and the topology outside of the TTZ.
for virtualizing the TTZ. Optionally, it may just let the old normal
LSAs age out.
For an edge router of the TTZ, transferring to work as a TTZ router For an edge router of the TTZ, migrating to work as a TTZ router
comprises generating a router LSA to virtualize the TTZ and flooding comprises generating a router LSA to virtualize the TTZ and flooding
this LSA to all its neighboring routers. this LSA to all its neighboring routers in two steps described in
section 7.
Virtualizing the TTZ by an edge router should be done in two steps. In normal operations for migration to TTZ and rollback from TTZ, a
At first, the router updates its normal router LSA by adding a point- user issues a series of commands according to certain procedures. In
to-point link to each of the other edge routers of the TTZ and a stub an abnormal case, for example two conflict commands are issued on two
link for each of the loopback addresses in the TTZ to be leaked. And TTZ routers in a TTZ at the same time, a TTZ router gives a warning
then it removes the links configured as TTZ links from its updated when it detects the abnormal case.
router LSA after sending its updated router LSA and receiving the
updated router LSAs originated by the other TTZ edge routers for a
short time such as 0.1 second. Alternatively, it may remove the
links from its updated router LSA after sending the LSA for a short
time such as 0.3 second.
10.3. Adding a Router into TTZ 11.3. Adding a Router into TTZ
When a non TTZ router (say R1) is connected via a P2P link to a TTZ When a non TTZ router (say R1) is connected via a P2P link to a TTZ
router (say T1) working as TTZ and there is a normal adjacency router (say T1) working as TTZ and there is a normal adjacency
between them over the link, a user can configure TTZ on two ends of between them over the link, a user can configure TTZ on two ends of
the link to add R1 into the TTZ to which T1 belongs. They discover the link to add R1 into the TTZ to which T1 belongs. They discover
TTZ each other in the same way as described in section 7.1. TTZ each other in the same way as described in section 8.
When a number of non TTZ routers are connected via a broadcast link When a number of non TTZ routers are connected via a broadcast link
to a TTZ router (say T1) working as TTZ and there are normal to a TTZ router (say T1) working as TTZ and there are normal
adjacencies among them, a user configures TTZ on the connection to adjacencies among them, a user configures TTZ on the connection to
the link on every router to add the non TTZ routers into the TTZ to the link on every router to add the non TTZ routers into the TTZ to
which T1 belongs. The DR for the link "forms" TTZ adjacency with which T1 belongs. The DR for the link "forms" TTZ adjacency with
each of the other routers if all the routers have the same TTZ ID each of the other routers if all the routers have the same TTZ ID
configured on the connections to the link. configured on the connections to the link.
When a router (say R1) is connected via a P2P link to a TTZ router When a router (say R1) is connected via a P2P link to a TTZ router
(say T1) and there is not any adjacency between them over the link, a (say T1) and there is not any adjacency between them over the link, a
user can configure TTZ on two ends of the link to add R1 into the TTZ user can configure TTZ on two ends of the link to add R1 into the TTZ
to which T1 belongs. R1 and T1 will form an adjacency in the same to which T1 belongs. R1 and T1 will form an adjacency in the same
way as described in section 7.2. way as described in section 8.
When a router (say R1) is connected via a broadcast link to a group
of TTZ routers on the link and there is not any adjacency between R1
and any over the link, a user can configure TTZ on the connection to
the link on R1 to add R1 into the TTZ to which the TTZ routers
belong. R1 starts to form an adjacency with the DR for the link
after the configuration.
11. Prototype Implementation
11.1. What are Implemented and Tested 12. Prototype Implementation
12.1. What are Implemented and Tested
1. CLI Commands for TTZ 1. CLI Commands for TTZ
The CLIs implemented and tested include: The CLIs implemented and tested include:
o the CLIs of the simpler option for configuring TTZ, and o the CLIs of the simpler option for configuring TTZ, and
o the CLIs for controlling migration to TTZ. o the CLIs for controlling migration to TTZ.
2. Extensions to OSPF Protocols for TTZ 2. Extensions to OSPF Protocols for TTZ
skipping to change at page 18, line 30 skipping to change at page 17, line 18
the TTZ, but it is a part of the TTZ. the TTZ, but it is a part of the TTZ.
5. Leak TTZ Loopbacks Outside 5. Leak TTZ Loopbacks Outside
Leaking loopback addresses in a TTZ to routers outside of the TTZ is Leaking loopback addresses in a TTZ to routers outside of the TTZ is
implemented and tested. The testing results illustrate: implemented and tested. The testing results illustrate:
o The loopback addresses inside the TTZ are distributed to the o The loopback addresses inside the TTZ are distributed to the
routers outside of the TTZ. routers outside of the TTZ.
o The loopback addresses are accessable from a router outside of the o The loopback addresses are accessible from a router outside of the
TTZ. TTZ.
11.2. Implementation Experience 12.2. Implementation Experience
The implementation of TTZ is relatively easy compared to other The implementation of TTZ is relatively easy compared to other
features of OSPF. Re-using the existing OSPF code along with features of OSPF. Re-using the existing OSPF code along with
additional simple logic does the work. A couple of engineers started additional simple logic does the work. A couple of engineers started
to work on implementing the TTZ from the middle of June, 2014 and to work on implementing the TTZ from the middle of June, 2014 and
finished coding it just before IETF 90. After some testing and bug finished coding it just before IETF 90. After some testing and bug
fixes, it works as expected. fixes, it works as expected.
In our implementation, the link state information in a TTZ opaque LSA In our implementation, the link state information in a TTZ opaque LSA
is stored in the same link state database as the link state is stored in the same link state database as the link state
information in a normal LSA. For each TTZ link in the TTZ opaque LSA information in a normal LSA. For each TTZ link in the TTZ opaque LSA
stored, there is an additional flag, which is used to differentiate stored, there is an additional flag, which is used to differentiate
between a TTZ link and a Normal link. between a TTZ link and a Normal link.
Before migration to TTZ, every router in the TTZ computes its routing Before migration to TTZ, every router in the TTZ computes its routing
table using the normal links. After migration to TTZ, every router table using the normal links. After migration to TTZ, every router
in the TTZ computes its routing table using the TTZ links and normal in the TTZ computes its routing table using the TTZ links and normal
links. In the case that there are one TTZ link and one normal link links. In the case that there are one TTZ link and one normal link
to select, the TTZ link is used. In SPF calculation, the back-link to select, the TTZ link is used.
check passes if and only if the corresponding new additional bit
matches. If link type bit is TTZ link, then the lookup is for
corresponding TTZ LSA. In case of normal link, the lookup is based
on normal link.
12. Security Considerations 13. Security Considerations
The mechanism described in this document does not raise any new The mechanism described in this document does not raise any new
security issues for the OSPF protocols. security issues for the OSPF protocols.
13. IANA Considerations 14. IANA Considerations
TBD Under Registry Name: Opaque Link-State Advertisements (LSA) Option
Types [RFC5250], IANA is requested to assign a new Opaque type
registry value for Topology-Transparent Zone (TTZ) LSA as follows:
14. Contributors +====================+===============+=======================+
| Registry Value | Opaque Type | reference |
+====================+===============+=======================+
| 5 | TTZ LSA | This document |
+--------------------+---------------+-----------------------+
IANA is requested to assign Types for new TLVs in the new TTZ LSA as
follows:
Type Name Allowed in
1 TTZ ID TLV TTZ LSA of LS Type 10 and 9
2 TTZ Router TLV TTZ LSA of LS Type 10
3 TTZ Options TLV TTZ LSA of LS Type 10
15. Contributors and Other Authors
1. Other Authors
Gregory Cauchie
FRANCE
Email: greg.cauchie@gmail.com
Anil Kumar S N
Huawei Technologies
Banglore
India
Email: anil.sn@huawei.com
Ning So
Tata Communications
2613 Fairbourne Cir.
Plano, TX 75082
USA
Email: ningso01@gmail.com
Lei Liu
Fujitsu
USA
Email: lliu@us.fujitsu.com
2. Contributors
Veerendranatha Reddy Vallem Veerendranatha Reddy Vallem
Huawei Technologies Huawei Technologies
Banglore Banglore
India India
Email: veerendranatharv@huawei.com Email: veerendranatharv@huawei.com
William McCall William McCall
cisco Systems, Inc. Cisco Systems, Inc.
Bellevue, WA Bellevue, WA
USA USA
wimccall@cisco.com wimccall@cisco.com
15. Acknowledgement 16. Acknowledgement
The author would like to thank Acee Lindem, Abhay Roy, Dean Cheng, The author would like to thank Acee Lindem, Abhay Roy, Dean Cheng,
Russ White, Tony Przygienda, Lin Han and Yang Yu for their valuable Russ White, Tony Przygienda, Wenhu Lu, Lin Han and Yang Yu for their
comments on this draft. valuable comments on this draft.
16. References 17. References
16.1. Normative References 17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/
Shaffer, "Extensions to OSPF for Advertising Optional RFC2328, April 1998,
Router Capabilities", RFC 4970, July 2007. <http://www.rfc-editor.org/info/rfc2328>.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, July 2008. OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250,
July 2008, <http://www.rfc-editor.org/info/rfc5250>.
[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. Yeung, "OSPF Link-Local Signaling", RFC 5613,
DOI 10.17487/RFC5613, August 2009,
<http://www.rfc-editor.org/info/rfc5613>.
16.2. Informative References 17.2. Informative References
[RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
Backward-Recursive PCE-Based Computation (BRPC) Procedure "A Backward-Recursive PCE-Based Computation (BRPC)
to Compute Shortest Constrained Inter-Domain Traffic Procedure to Compute Shortest Constrained Inter-Domain
Engineering Label Switched Paths", RFC 5441, April 2009. Traffic Engineering Label Switched Paths", RFC 5441,
DOI 10.17487/RFC5441, April 2009,
<http://www.rfc-editor.org/info/rfc5441>.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
(PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009. DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
Appendix A. Constants for LSA Distribution
MaxLSADistTime: The maximum time for an LSA to be distributed to all
the routers in an area. The value of MaxLSADistTime is set to 0.1
second.
MaxLSAGenDistTime: The maximum time for all TTZ router LSAs to be
generated by all TTZ edge routers and distributed to all the routers
in an area after a first TTZ router LSA is generated. The value of
MaxLSAGenDistTime is set to 0.3 second.
Authors' Addresses Authors' Addresses
Huaimo Chen Huaimo Chen
Huawei Technologies Huawei Technologies
Boston, MA Boston, MA
USA USA
Email: huaimo.chen@huawei.com Email: huaimo.chen@huawei.com
Renwei Li Renwei Li
Huawei Technologies Huawei Technologies
2330 Central expressway 2330 Central expressway
Santa Clara, CA Santa Clara, CA
USA USA
Email: renwei.li@huawei.com Email: renwei.li@huawei.com
Anil Kumar S N
Huawei Technologies
Banglore
India
Email: anil.sn@huawei.com
Gregory Cauchie
FRANCE
Email: greg.cauchie@gmail.com
Alvaro Retana Alvaro Retana
Cisco Systems, Inc. Cisco Systems, Inc.
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Raleigh, NC 27709 Raleigh, NC 27709
USA USA
Email: aretana@cisco.com Email: aretana@cisco.com
Ning So Yi Yang
Tata Communications Cisco Systems, Inc.
2613 Fairbourne Cir. 7025 Kit Creek Rd.
Plano, TX 75082 Raleigh, NC 27709
USA USA
Email: ningso01@gmail.com Email: yiya@cisco.com
Vic Liu Vic Liu
China Mobile China Mobile
No.32 Xuanwumen West Street, Xicheng District No.32 Xuanwumen West Street, Xicheng District
Beijing, 100053 Beijing, 100053
China China
Email: liuzhiheng@chinamobile.com Email: liuzhiheng@chinamobile.com
Mehmet Toy Mehmet Toy
Comcast Comcast
1800 Bishops Gate Blvd. 1800 Bishops Gate Blvd.
Mount Laurel, NJ 08054 Mount Laurel, NJ 08054
USA USA
Email: mehmet_toy@cable.comcast.com Email: mehmet_toy@cable.comcast.com
Lei Liu
UC Davis
CA
USA
Email: liulei.kddi@gmail.com
 End of changes. 116 change blocks. 
349 lines changed or deleted 388 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/