< draft-awduche-mpls-rsvp-tunnel-applicability-00.txt   draft-awduche-mpls-rsvp-tunnel-applicability-01.txt >
Internet Engineering Task Force Internet Engineering Task Force
INTERNET-DRAFT INTERNET-DRAFT
MPLS Working Group Daniel O. Awduche MPLS Working Group Daniel O. Awduche
Expiration Date: January 2000 UUNET (MCI Worldcom) Expiration Date: March 2000 UUNET (MCI Worldcom)
Alan Hannan Alan Hannan
Xipeng Xiao Xipeng Xiao
Frontier Globalcenter Frontier Globalcenter
July, 1999 September, 1999
Applicability Statement for Extensions to RSVP for LSP-Tunnels Applicability Statement for Extensions to RSVP for LSP-Tunnels
draft-awduche-mpls-rsvp-tunnel-applicability-00.txt draft-awduche-mpls-rsvp-tunnel-applicability-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This memo discusses the applicability of "Extensions to RSVP for LSP This memo discusses the applicability of "Extensions to RSVP for LSP
Tunnels" [1]. It highlights the protocol's principles of operation Tunnels" [1]. It highlights the protocol's principles of operation
and describes the network context for which it was designed. It and describes the network context for which it was designed.
offers guidelines for deployment and indicates known protocol Guidelines for deployment are offered and known protocol limitations
limitations. This document is intended to accompany the submission of are indicated. This document is intended to accompany the submission
"Extensions to RSVP for LSP Tunnels" onto the Internet standards of "Extensions to RSVP for LSP Tunnels" onto the Internet standards
track. track.
1.0 Introduction 1.0 Introduction
Service providers and users have expressed a strong need for traffic Service providers and users have indicated that there is a great need
engineering capabilities in IP networks (based on Multiprotocol Label for traffic engineering capabilities in IP networks. These traffic
Switching -MPLS-) that can be implemented on label switching routers engineering capabilities can be based on Multiprotocol Label
Switching (MPLS) and can be implemented on label switching routers
(LSRs) from different vendors that interoperate using a common (LSRs) from different vendors that interoperate using a common
signaling and label distribution protocol. A description of the signaling and label distribution protocol. A description of the
requirements for traffic engineering in MPLS based IP networks can be requirements for traffic engineering in MPLS based IP networks can be
found in [2]. There is, therefore, a requirement for an open, non- found in [2]. There is, therefore, a requirement for an open, non-
proprietary, standards based signaling and label distribution proprietary, standards based signaling and label distribution
protocol for the MPLS traffic engineering application that will be protocol for the MPLS traffic engineering application that may be
available from all label switching router vendors, allowing such available from all label switching router vendors, which allow such
devices to interoperate. devices to interoperate.
The "Extensions to RSVP for LSP tunnels" (RSVP-Tunnel) specification The "Extensions to RSVP for LSP tunnels" (RSVP-Tunnel) specification
[1] was developed by the IETF MPLS working group to address this [1] was developed by the IETF MPLS working group to address this
requirement. RSVP-Tunnel is a composition of several related requirement. RSVP-Tunnel is a composition of several related
proposals submitted to the IETF MPLS working group. It contains all proposals submitted to the IETF MPLS working group. It contains all
the necessary objects, packet formats, and procedures required to the necessary objects, packet formats, and procedures required to
establish and maintain explicit label switched paths (LSPs). Explicit establish and maintain explicit label switched paths (LSPs). Explicit
LSPs are foundational to the traffic engineering application in MPLS LSPs are foundational to the traffic engineering application in MPLS
based IP networks. Besides the traffic engineering application, the based IP networks. Besides the traffic engineering application, the
RSVP-Tunnel specification may have other uses within the Internet. RSVP-Tunnel specification may have other uses within the Internet.
This memo describes the applicability of the RSVP-Tunnel
specifications [1]. The protocol's principles of operation are
highlighted, the network context for which it was developed is
described, guidelines for deployment are offered, and known protocol
limitations are indicated.
Two fundamental aspects distinguish the RSVP-Tunnel specification [1] Two fundamental aspects distinguish the RSVP-Tunnel specification [1]
from the original RSVP protocol [3]. from the original RSVP protocol [3].
The first is the fact that the RSVP-Tunnel specification [1] is The first distinguishing aspect is the fact that the RSVP-Tunnel
intended for use by label switching routers (as well as hosts) to specification [1] is intended for use by label switching routers (as
establish and maintain LSP-tunnels and to reserve network resources well as hosts) to establish and maintain LSP-tunnels and to reserve
for such LSP-tunnels; whereas the original RSVP specification [3] was network resources for such LSP-tunnels. The original RSVP
intended for use by hosts to request and reserve network resources specification [3], on the other hand, was intended for use by hosts
for micro-flows. to request and reserve network resources for micro-flows.
The second distinguishing aspect is the fact that the RSVP-Tunnel The second distinguishing aspect is the fact that the RSVP-Tunnel
specification generalizes the concept of "RSVP flow." The RSVP-Tunnel specification generalizes the concept of "RSVP flow." The RSVP-Tunnel
specification essentially allows an RSVP session to consist of an specification essentially allows an RSVP session to consist of an
arbitrary aggregation of traffic (based on local policies) between arbitrary aggregation of traffic (based on local policies) between
the origination node of an LSP-tunnel and the egress node of the the origination node of an LSP-tunnel and the egress node of the
tunnel. To be definite, in the original RSVP protocol [3], a session tunnel. To be definite, in the original RSVP protocol [3], a session
was defined as a data flow with a particular destination and was defined as a data flow with a particular destination and
transport layer protocol. In the RSVP-Tunnel specification, however, transport layer protocol. In the RSVP-Tunnel specification, however,
a session is implicitly defined as the set of packets that are a session is implicitly defined as the set of packets that are
skipping to change at page 3, line 12 skipping to change at page 3, line 19
thereof) between the endpoints of the LSP-tunnel. Because traffic is thereof) between the endpoints of the LSP-tunnel. Because traffic is
aggregated, the number of LSP-tunnels (hence the number of RSVP aggregated, the number of LSP-tunnels (hence the number of RSVP
sessions) does not increase proportionally with the number of flows sessions) does not increase proportionally with the number of flows
in the network. Therefore, the RSVP-Tunnel specification [1] in the network. Therefore, the RSVP-Tunnel specification [1]
addresses a major scaling issue with the original RSVP protocol [3], addresses a major scaling issue with the original RSVP protocol [3],
namely the large amount of system resources that would otherwise be namely the large amount of system resources that would otherwise be
required to manage reservations and maintain state for potentially required to manage reservations and maintain state for potentially
thousands or even millions of RSVP sessions at the micro-flow thousands or even millions of RSVP sessions at the micro-flow
granularity. granularity.
This applicability statement concerns only the use of RSVP to set up
unicast LSP-tunnels. It is noted that not all of the features
described in RFC2205 [3] are required to support the instantiation
and maintenance of LSP-tunnels. Aspects related to the support of
other features and capabilities of RSVP by an implementation that
also supports LSP-tunnels are beyond the scope of this document.
However, support of such additional features and capabilities should
not introduce new security vulnerabilities in environments that only
use RSVP to set up LSP-tunnels.
This applicability statement does not preclude the use of other This applicability statement does not preclude the use of other
signaling and label distribution protocols for the traffic signaling and label distribution protocols for the traffic
engineering application in MPLS based IP networks. Service providers engineering application in MPLS based IP networks. Service providers
are free to deploy whatever signaling protocol that meets their are free to deploy whatever signaling protocol that meets their
needs. needs.
2.0 Technical Overview of Extensions to RSVP for LSP Tunnels 2.0 Technical Overview of Extensions to RSVP for LSP Tunnels
The RSVP-Tunnel specification extends the original RSVP protocol with The RSVP-Tunnel specification extends the original RSVP protocol by
new capabilities that support the following functions in an MPLS giving it new capabilities that support the following functions in an
domain: (1) downstream-on-demand label distribution, (2) MPLS domain:
instantiation of explicit label switched paths, (3) allocation of
network resources (such as bandwidth) to explicit LSPs, (4) rerouting (1) downstream-on-demand label distribution
of established LSP-tunnels in a smooth fashion using the concept of (2) instantiation of explicit label switched paths
make-before-break, (5) tracking of the actual route traversed by an (3) allocation of network resources (e.g., bandwidth) to explicit
LSP-tunnel, (6) diagnostics on LSP-tunnels, (7) the concept of node LSPs
abstraction, and (8) preemption options that are administratively (4) rerouting of established LSP-tunnels in a smooth fashion using
controllable. the concept of make-before-break
(5) tracking of the actual route traversed by an LSP-tunnel
(6) diagnostics on LSP-tunnels
(7) the concept of nodal abstraction
(8) preemption options that are administratively controllable
The RSVP-Tunnel specification introduces several new RSVP objects, The RSVP-Tunnel specification introduces several new RSVP objects,
including: LABEL-REQUEST object, RECORD-ROUTE object, LABEL object, including the LABEL-REQUEST object, the RECORD-ROUTE object, the
EXPLICIT-ROUTE object, and new SESSION objects. New error messages LABEL object, the EXPLICIT-ROUTE object, and new SESSION objects. New
are defined to provide notification of exception conditions. All the error messages are defined to provide notification of exception
new objects defined in RSVP-Tunnel are optional with respect to the conditions. All of the new objects defined in RSVP-Tunnel are
RSVP protocol, except the LABEL-REQUEST and LABEL objects, which are optional with respect to the RSVP protocol, except the LABEL-REQUEST
both mandatory for the establishment of LSP-tunnels. and LABEL objects, which are both mandatory for the establishment of
LSP-tunnels.
Informally, establishment of an LSP-tunnel proceeds in the following Informally, establishment of an LSP-tunnel proceeds in the following
way: First, the origination node of the LSP-tunnel creates an RSVP way: First, the origination node of the LSP-tunnel creates an RSVP
Path message and inserts a LABEL-REQUEST object into it. Optionally, Path message and inserts a LABEL-REQUEST object into it. Optionally,
an EXPLICIT-ROUTE object, a RECORD-ROUTE object, and a an EXPLICIT-ROUTE object, a RECORD-ROUTE object, and a
SESSION_ATTRIBUTE object may also be inserted into the path message. SESSION_ATTRIBUTE object may also be inserted into the path message.
The LABEL-REQUEST object indicates that a label binding is requested; The LABEL-REQUEST object indicates that a label binding is requested;
the EXPLICIT-ROUTE object depicts the explicit route for the LSP- the EXPLICIT-ROUTE object depicts the explicit route for the LSP-
tunnel as a sequence of abstract nodes; the RECORD-ROUTE object tunnel as a sequence of abstract nodes; the RECORD-ROUTE object
specifies that a path vector record of the route traversed is specifies that a path vector record of the route traversed is
required; finally, the SESSION_ATTRIBUTE object is used for session required; finally, the SESSION_ATTRIBUTE object is used for session
identification and diagnosis. When the Path message reaches the identification and diagnosis.
egress node of the LSP-tunnel, a Resv message is created and a LABEL
object containing an MPLS label is inserted into the Resv message. As When the Path message reaches the egress node of the LSP-tunnel, a
the Resv message propagates to the origination node, in reverse Resv message is created and a LABEL object containing an MPLS label
direction along the path traversed by the Path message, each node is inserted into the Resv message. As the Resv message propagates to
uses the MPLS label in the LABEL object from its downstream neighbor the origination node (in the reverse direction along the path
as outgoing label for the LSP-tunnel, and inserts its own LABEL traversed by the Path message), each node uses the MPLS label in the
object before propagating the Resv message upstream. In this way, LABEL object from its downstream neighbor as outgoing label for the
labels are allocated sequentially all the way from the egress node of LSP-tunnel. Each node inserts its own LABEL object before propagating
the LSP-tunnel to the origination node, whence the LSP-tunnel becomes the Resv message upstream. This way, labels are allocated
established. sequentially all the way from the egress node of the LSP-tunnel to
the origination node. It is when the Resv message reaches the
origination node that the LSP-tunnel becomes established.
3.0 Applicability of Extensions to RSVP for LSP Tunnels 3.0 Applicability of Extensions to RSVP for LSP Tunnels
Use of RSVP-Tunnel is appropriate in contexts where it is useful to Use of RSVP-Tunnel is appropriate in contexts where it is useful to
establish and maintain explicit label switched paths in an MPLS establish and maintain explicit label switched paths in an MPLS
network. LSP-tunnels may be instantiated for measurement purposes, network. LSP-tunnels may be instantiated for measurement purposes
or for control purposes, or for both. and/or for control purposes. They may also be instantiated for other
administrative reasons.
For the measurement application, an LSP-tunnel can be used to capture For the measurement application, an LSP-tunnel can be used to capture
various path statistics between its endpoints. For example, an LSP- various path statistics between its endpoints. This can be
tunnel can be instantiated, with or without bandwidth allocation, accomplished by associating various performance management and fault
purely for the purpose of monitoring traffic flow statistics between management functions with an LSP-tunnel, such as packet and byte
two label switching routers. counters. For example, an LSP-tunnel can be instantiated, with or
without bandwidth allocation, solely for the purpose of monitoring
traffic flow statistics between two label switching routers.
For the control application, LSP-tunnels can be used to forward For the control application, LSP-tunnels can be used to forward
subsets of traffic through paths that are independent of routes subsets of traffic through paths that are independent of routes
computed by conventional IGP SPF algorithms. This provides computed by conventional Interior Gateway Protocol (IGP) Shortest
significant control over the routing function, allowing policies to Path First (SPF) algorithms. This feature provides significant
be implemented that result in the performance optimization of control over the routing function and allows policies to be
implemented that result in the performance optimization of
operational networks. For example, using LSP-tunnels, traffic can be operational networks. For example, using LSP-tunnels, traffic can be
routed away from congested network resources onto relatively routed away from congested network resources onto relatively
underutilized ones. More generally, load balancing policies can be underutilized ones. More generally, load balancing policies can be
actualized that increase the effective capacity of the network. actualized that increase the effective capacity of the network.
To further enhance the control application, RSVP-Tunnel may be To further enhance the control application, RSVP-Tunnel may be
augmented with an ancillary constraint-based routing entity that augmented with an ancillary constraint-based routing entity. This
computes explicit routes based on certain traffic attributes, while entity may compute explicit routes based on certain traffic
taking network constraints into account. Additionally, IGP link state attributes, while taking network constraints into account.
advertisements may be extended to propagate new topology state Additionally, IGP link state advertisements may be extended to
information, which can be used by the constraint-based routing entity propagate new topology state information. This information can be
to compute feasible routes. Furthermore, the IGP routing algorithm used by the constraint-based routing entity to compute feasible
may itself be enhanced to take pre-established LSP-tunnels into routes. Furthermore, the IGP routing algorithm may itself be enhanced
consideration while building the routing table. All these to take pre-established LSP-tunnels into consideration while building
augmentations are useful, but not mandatory. Indeed, the RSVP-Tunnel the routing table. All these augmentations are useful, but not
specification may be deployed in certain contexts without any of mandatory. In fact, the RSVP-Tunnel specification may be deployed in
these additional components. certain contexts without any of these additional components.
The capability to monitor point to point traffic statistics between The capability to monitor point to point traffic statistics between
two routers and the capability to control the forwarding paths of two routers and the capability to control the forwarding paths of
subsets of traffic through a given network topology together make the subsets of traffic through a given network topology together make the
RSVP-Tunnel specifications applicable and useful for traffic RSVP-Tunnel specifications applicable and useful for traffic
engineering within service provider networks. engineering within service provider networks.
These capabilities also make the RSVP-Tunnel applicable, in some These capabilities also make the RSVP-Tunnel applicable, in some
contexts, as a component of an MPLS based VPN provisioning framework. contexts, as a component of an MPLS based VPN provisioning framework.
It is to be noted that the MPLS architecture [4] states clearly that It is significant that the MPLS architecture [4] states clearly that
no single label distribution protocol is assumed for the MPLS no single label distribution protocol is assumed for the MPLS
technology. Therefore, this applicability statement does not (and technology. Therefore, this applicability statement does not (and
should not be construed to) prevent a label switching router from should not be construed to) prevent a label switching router from
implementing other signaling and label distribution protocols that implementing other signaling and label distribution protocols that
also support establishment of explicit LSPs and traffic engineering also support establishment of explicit LSPs and traffic engineering
in MPLS networks. in MPLS networks.
4.0 Deployment and Policy Considerations 4.0 Deployment and Policy Considerations
When deploying RSVP-Tunnel, there should be well defined When deploying RSVP-Tunnel, there should be well defined
administrative policies governing the selection of nodes that will administrative policies governing the selection of nodes that will
serve as endpoints for LSP-tunnels. Furthermore, in devising a serve as endpoints for LSP-tunnels. Furthermore, when devising a
virtual topology for LSP-tunnels, special consideration should be virtual topology for LSP-tunnels, special consideration should be
given to the tradeoff between the operational complexity associated given to the tradeoff between the operational complexity associated
with a large number of LSP-tunnels and the control granularity that with a large number of LSP-tunnels and the control granularity that
large numbers of LSP-tunnels allow. Stated otherwise, a large number large numbers of LSP-tunnels allow. Stated otherwise, a large number
of LSP-tunnels allows greater control over the distribution of of LSP-tunnels allows greater control over the distribution of
traffic across the network, but increases network operational traffic across the network, but increases network operational
complexity. In large networks, it may be advisable to start with a complexity. In large networks, it may be advisable to start with a
simple LSP-tunnel virtual topology and then introduce additional simple LSP-tunnel virtual topology and then introduce additional
complexity based on observed or anticipated traffic flow patterns. complexity based on observed or anticipated traffic flow patterns.
Administrative policies should also guide the amount of bandwidth Administrative policies should also guide the amount of bandwidth to
that should be allocated (if any) to each LSP-tunnel. Such policies be allocated (if any) to each LSP-tunnel. Policies of this type may
may take into account traffic statistics derived from the operational take into consideration traffic statistics derived from the
network as well as other factors. operational network in addition to other factors.
5.0 Limitations 5.0 Limitations
The RSVP-Tunnel specification supports only unicast LSP-tunnels. The RSVP-Tunnel specification supports only unicast LSP-tunnels.
Multicast LSP-tunnels are not supported. Multicast LSP-tunnels are not supported.
The RSVP-Tunnel specification supports only unidirectional LSP- The RSVP-Tunnel specification supports only unidirectional LSP-
tunnels. Bidirectional LSP-tunnels are not supported. tunnels. Bidirectional LSP-tunnels are not supported.
The soft state nature of RSVP remains a source of concern because of The soft state nature of RSVP remains a source of concern because of
the need to generate refresh messages periodically to maintain the the need to generate refresh messages periodically to maintain the
state of established LSP-tunnels. This issue is addressed in several state of established LSP-tunnels. This issue is addressed in several
proposals that have been submitted to the RSVP working group (see proposals that have been submitted to the RSVP working group (see
e.g. [6]). e.g. [6]).
6.0 Conclusion 6.0 Conclusion
This document discussed the applicability of the "Extensions to RSVP The applicability of the "Extensions to RSVP for LSP Tunnels"
for LSP Tunnels" specification. The specification introduced several specification has been discussed in this document. The specification
enhancements to the RSVP protocol, making it applicable in contexts introduced several enhancements to the RSVP protocol, which make it
in which the original RSVP protocol would have been inappropriate. applicable in contexts in which the original RSVP protocol would have
One context in which the RSVP-Tunnel specification is particularly been inappropriate. One context in which the RSVP-Tunnel
applicable is in traffic engineering in MPLS based IP networks. specification is particularly applicable is in traffic engineering in
MPLS based IP networks.
7.0 Security Considerations 7.0 Security Considerations
This document does not introduce new security issues. The RSVP-Tunnel This document does not introduce new security issues. The RSVP-Tunnel
specification adds new opaque objects to RSVP, hence the security specification adds new opaque objects to RSVP and so the security
considerations pertaining to the original RSVP protocol remain considerations pertaining to the original RSVP protocol remain
relevant. When deployed in service provider networks, it is mandatory relevant. When deployed in service provider networks, it is mandatory
to ensure that only authorized entities are permitted to initiate to ensure that only authorized entities are permitted to initiate
establishment of LSP-tunnels. establishment of LSP-tunnels.
8.0 References 8.0 Acknowledgments
The authors gratefully acknowledge the useful comments received from
the following individuals during initial review of this memo in the
MPLS WG mailing list: Eric Gray, John Renwick, and George Swallow.
9.0 References
[1] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, [1] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow,
V. Srinivasan, "Extensions to RSVP for LSP Tunnels," V. Srinivasan, "Extensions to RSVP for LSP Tunnels,"
Work in Progress. Work in Progress.
[2] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, [2] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus,
"Requirements for Traffic Engineering Over MPLS," "Requirements for Traffic Engineering Over MPLS,"
Work in Progress. Work in Progress.
[3] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- [3] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) --
skipping to change at page 7, line 16 skipping to change at page 8, line 16
Daniel O. Awduche Daniel O. Awduche
UUNET (MCI Worldcom) UUNET (MCI Worldcom)
3060 Williams Drive 3060 Williams Drive
Fairfax, VA 22031 Fairfax, VA 22031
Email: awduche@uu.net Email: awduche@uu.net
Voice: +1 703-208-5277 Voice: +1 703-208-5277
Alan Hannan Alan Hannan
Frontier Globalcenter Frontier Globalcenter
1154 E. Arques Ave. 141 Caspian Court,
Sunnyvale, CA 94086 Sunnyvale, CA 94089
Email: alan@globalcenter.net, Email: alan@globalcenter.net,
Voice: +1 408-328-4891 Voice: +1 408-543-4891
Xipeng Xiao Xipeng Xiao
Frontier Globalcenter Frontier Globalcenter
1154 E. Arques Ave. 141 Caspian Court,
Sunnyvale, CA 94086 Sunnyvale, CA 94089
Email: xipeng@globalcenter.net, Email: xipeng@globalcenter.net,
Voice: +1 408-328-480 Voice: +1 408-543-4801
 End of changes. 26 change blocks. 
84 lines changed or deleted 119 lines changed or added

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