Internet DRAFT - draft-chen-teas-rsvp-ttz
draft-chen-teas-rsvp-ttz
Internet Engineering Task Force H. Chen
Internet-Draft R. Li
Intended status: Standards Track Huawei Technologies
Expires: December 3, 2017 G. Cauchie
A. Retana
Cisco Systems, Inc.
N. So
Tata Communications
F. Xu
M. Toy
Verizon
V. Liu
China Mobile
L. Liu
Fijitsu
June 1, 2017
TE LSP Crossing Topology-Transparent Zones
draft-chen-teas-rsvp-ttz-02.txt
Abstract
A topology-transparent zone is virtualized as the edges of the zone
fully connected. This document presents the procedures for the
establishment of Traffic Engineering (TE) LSPs crossing Topology-
Transparent Zones.
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 December 3, 2017.
Copyright Notice
Chen, et al. Expires December 3, 2017 [Page 1]
Internet-Draft TE LSP x TTZs June 2017
Copyright (c) 2017 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
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 . . . . . . . . . . . . . . . 3
3. Overview of Topology-Transparent Zone (TTZ) . . . . . . . . . . 3
4. Set up TE LSPs crossing TTZs . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Chen, et al. Expires December 3, 2017 [Page 2]
Internet-Draft TE LSP x TTZs June 2017
1. Introduction
The number of routers in a network becomes larger and larger as the
Internet traffic keeps growing. Through splitting the network into
multiple areas, we can extend the network further. However, there
are a number of issues when a network is split further into more
areas.
At first, dividing a network into more areas is a very challenging
and time consuming since it is involved in significant network
architecture changes.
Secondly, the services carried by the network may be interrupted
while the network is being split into more areas.
Furthermore, it is complex for a TE LSP crossing areas to be setup.
In one option, a TE path crossing areas is computed by using
collaborating PCEs [RFC5441] through PCEP[RFC5440], which is not easy
to configure.
Topology-transparent zone (TTZ) resolves these issues. This document
briefs TTZ and presents the procedures for the establishment of TE
LSPs crossing TTZs.
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. Overview of Topology-Transparent Zone (TTZ)
A Topology-Transparent Zone (TTZ) is identified by an Identifier (ID)
called TTZ ID, and it includes a group of routers and a number of
links connecting the routers. A TTZ is in an IGP area.
In addition to having the functions of an IGP area, an IGP TTZ makes
some improvements on an IGP area, which include:
o An IGP TTZ is virtualized as the TTZ edge routers connected.
o An IGP 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 the TTZ.
The figure below shows an area containing a TTZ: TTZ 600.
Chen, et al. Expires December 3, 2017 [Page 3]
Internet-Draft TE LSP x TTZs June 2017
TTZ 600
\
\ ^~^~^~^~^~^~^~^~^~^~^~^~
( )
===[R15]========(==[R61]------------[R63]==)======[R29]===
|| ( | \ / | ) ||
|| ( | \ / | ) ||
|| ( | \ / | ) ||
|| ( | ___\ / | ) ||
|| ( | / [R71] | ) ||
|| ( | [R73] / \ | ) ||
|| ( | / \ | ) ||
|| ( | / \ | ) ||
|| ( | / \ | ) ||
===[R17]========(==[R65]------------[R67]==)======[R31]===
\\ (// \\) //
|| //v~v~v~v~v~v~v~v~v~v~v~\\ ||
|| // \\ ||
|| // \\ ||
\\ // \\ //
======[R23]==============================[R25]=====
// \\
// \\
Figure 1: An Example of TTZ
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
R73, and the links connecting them.
There are two types of routers in a TTZ: TTZ internal routers and TTZ
edge routers. A TTZ internal router is a router inside the TTZ and
its adjacent routers are in the TTZ. A TTZ edge router is a router
inside the TTZ and has at least one adjacent router that is outside
of the TTZ.
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 in the TTZ.
Chen, et al. Expires December 3, 2017 [Page 4]
Internet-Draft TE LSP x TTZs June 2017
A TTZ hides the information inside the TTZ from the outside. It does
not directly distribute any internal information about the TTZ to a
router outside of the TTZ.
For instance, the TTZ in the figure above does not send the
information about TTZ internal router R71 to any router outside of
the TTZ in the routing domain; it does not send the information about
the link between TTZ router R61 and R65 to any router outside of the
TTZ.
From a router outside of the TTZ, a TTZ is seen as a group of routers
fully connected. For instance, router R15 in the figure above, which
is outside of TTZ 600, sees TTZ 600 as a group of TTZ edge routers:
R61, R63, R65 and R67. These four TTZ edge routers are fully
connected.
The cost of the "link" from one edge router to another edge router is
the cost of the shortest path between these two routers. The
bandwidth of the "link" is the maximum bandwidth of a path between
the two routers.
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. Set up TE LSPs crossing TTZs
On a source node, we can configure a TE LSP from the source to a
destination crossing TTZs in the same way as we configure it without
any TTZs. This is because the source node is not aware of any TTZs.
For example, on node R15 in Figure 1, to set up a TE LSP from R15 to
R31, we just configure the TE LSP by giving its source R15, its
destination R31, and some constraints such as bandwidth as needed.
On the source node, it computes the path to the destination based on
the configuration of the TE LSP. It just sees a full mess connection
of edge nodes for every TTZ. Thus the computation of the path is
done in the same way as it is done without any TTZ. After the path
is computed, the source node starts to signal the LSP automatically
along the path.
For example, on node R15 in Figure 1, it computes the path to the
destination R31. It sees the full mess connection of four TTZ edge
nodes R61, R63, R65 and R67 in its topology. It computes the path in
Chen, et al. Expires December 3, 2017 [Page 5]
Internet-Draft TE LSP x TTZs June 2017
the same way as before and may get the path: R15 - R61 - R67 - R31.
And then it signals the TE LSP along this path. It sends a RSVP-TE
PATH message to R61.
When an edge node of a TTZ receives a PATH message, it checks if the
next hop in the ERO in the message is another edge node of the TTZ.
If so, it computes the path segment to the other edge node and
continues to signal the TE LSP along the path segment computed.
For instance, when R61, which is an edge node of a TTZ, receives the
PATH message, it computes the path segment to the other edge node R67
(Supposed that the path segment is: R61 - R71 - R67) and continues to
signal the TE LSP to R67 along the path segment computed. It sends a
PATH message to R71, which sends a PATH message to R67, which sends a
PATH message to R31.
TTZ 600
\
\ ^~^~^~^~^~^~^~^~^~^~^~^~
Source 51 ( )
===[R15]========(==[R61]------------[R63]==)======[R29]===
|| ( | \ / | ) ||
|| ( | \ / | ) ||
|| ( | \11 / | ) ||
|| ( | ___\ / | ) ||
|| ( | / [R71] | ) ||
|| ( | [R73] / \ | ) ||
|| ( | / \ | ) ||
|| ( | / \17 | ) ||
|| ( | / \ | ) 71 ||
===[R17]========(==[R65]------------[R67]==)======[R31]===
\\ (// \\) //Destination
|| //v~v~v~v~v~v~v~v~v~v~v~\\ ||
|| // \\ ||
|| // \\ ||
\\ // \\ //
======[R23]==============================[R25]=====
// \\
// \\
Figure 2: LSP from R15 to R31
When R31 receives the PATH message from R67, it allocates a label
(e.g., 71), reserves the bandwidth as needed, and sends a RESV
message with the label (71) to R67. It sets the forwarding entry for
the TE LSP using label 71 as inbound label.
Chen, et al. Expires December 3, 2017 [Page 6]
Internet-Draft TE LSP x TTZs June 2017
When R67 receives the RESV message from R31, it allocates a label
(e.g., 17), and sends a RESV message with the label (17) to R71. It
also sets the cross connect for the TE LSP using labels 17 and 71 as
inbound label and outbound label respectively.
When R71 receives the RESV message with the label (17) from R67, it
allocates a label (e.g., 11), and sends a RESV message with the label
(11) to R61. It sets the cross connect for the TE LSP using labels
11 and 17 as inbound label and outbound label respectively.
When R61 receives the RESV message with the label (11) from R71, it
allocates a label (e.g., 51), and sends a RESV message with the label
(51) to R15. It sets the cross connect for the TE LSP using labels
51 and 11 as inbound label and outbound label respectively.
When R15 receives the RESV message with the label (51) from R61, it
sets the forwarding entry for the TE LSP using label 51 as outbound
label. At this point, the set up of TE LSP from R15 to R31 is done.
The source node (i.e., head-end LSR) sets the "label recording
requested" flag in the SESSION_ATTRIBUTE object for LSPs requesting
local protection. This will cause all LSRs to record their INBOUND
labels.
For a TE LSP crossing a TTZ, we may assume that it goes into the TTZ
through an in edge node of the TTZ and goes out of the TTZ from a out
edge node of the TTZ.
For example, the TE LSP crossing TTZ 600 in Figure 2 is from R15 to
R61 to R71 to R67 to R31. The LSP goes into TTZ 600 through the edge
node R61, which is the in edge node. The LSP goes out of TTZ 600
from the edge node R67, which is the out edge node.
On the in edge node of the TTZ for the TE LSP, it does not record all
the INBOUND labels inside the TTZ in the RESV message to be sent to
its previous hop node. It just records the INBOUND label of the out
edge node.
For example, R61 (the in edge node of TTZ 600 for the TE LSP in
Figure 2) just keeps the INBOUND label 17 of R67 (the out edge node).
It does not record any other INBOUND labels inside TTZ 600. It will
remove the INBOUND label 11 of the TTZ internal node R71. Thus the
RESV message sent by R61 to its previous hop node R15 records two
INBOUND labels 17 and 71, which are the INBOUND labels of R67 and R31
respectively.
On the out edge node of the TTZ for the TE LSP, it does not record
all the hops inside the TTZ in the PATH message to its next hop node.
Chen, et al. Expires December 3, 2017 [Page 7]
Internet-Draft TE LSP x TTZs June 2017
It just records one hop from the in edge to the out edge.
5. Security Considerations
The mechanism described in this document does not raise any new
security issues for the RSVP-TE protocols.
6. IANA Considerations
There is not any requirement for IANA to assign a code point.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, DOI 10.17487/
RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005,
<http://www.rfc-editor.org/info/rfc4090>.
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
"A Backward-Recursive PCE-Based Computation (BRPC)
Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Paths", RFC 5441,
DOI 10.17487/RFC5441, April 2009,
<http://www.rfc-editor.org/info/rfc5441>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
Chen, et al. Expires December 3, 2017 [Page 8]
Internet-Draft TE LSP x TTZs June 2017
Authors' Addresses
Huaimo Chen
Huawei Technologies
Boston, MA
USA
Email: huaimo.chen@huawei.com
Renwei Li
Huawei Technologies
2330 Central Expressway
Santa Clara, CA
USA
Email: renwei.li@huawei.com
Gregory Cauchie
FRANCE
Email: greg.cauchie@gmail.com
Alvaro Retana
Cisco Systems, Inc.
7025 Kit Creek Rd.
Raleigh, NC 27709
USA
Email: aretana@cisco.com
Ning So
Tata Communications
USA
Email: ningso01@gmail.com
Chen, et al. Expires December 3, 2017 [Page 9]
Internet-Draft TE LSP x TTZs June 2017
Fengman Xu
Verizon
2400 N. Glenville Dr
Richardson, TX 75082
USA
Email: fengman.xu@verizon.com
Mehmet Toy
Verizon
USA
Email: mehmet.toy@verizon.com
Vic Liu
China Mobile
No.32 Xuanwumen West Street, Xicheng District
Beijing, 100053
China
Email: liu.cmri@gmail.com
Lei Liu
Fijitsu
USA
Email: liulei.kddi@gmail.com
Chen, et al. Expires December 3, 2017 [Page 10]
