As per Relevance of the word extensions, we have this rfc below:
Network Working Group D.
Request for Comments: 3210 Movaz
Category: Informational A.
X.
December 2001
Applicability Statement for Extensions to RSVP for LSP-
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This memo discusses the applicability of "Extensions to
(Resource ReSerVation Protocol) for LSP Tunnels". It highlights
protocol's principles of operation and describes the network
for which it was designed. Guidelines for deployment are offered
known protocol limitations are indicated. This document is
to accompany the submission of "Extensions to RSVP for LSP Tunnels
onto the Internet standards track
1.0
Service providers and users have indicated that there is a great
for traffic engineering capabilities in IP networks. These
engineering capabilities can be based on Multiprotocol
Switching (MPLS) and can be implemented on label switching
(LSRs) from different vendors that interoperate using a
signaling and label distribution protocol. A description of
requirements for traffic engineering in MPLS based IP networks can
found in [2]. There is, therefore, a requirement for an open, non
proprietary, standards based signaling and label
protocol for the MPLS traffic engineering application that will
label switching routers from different vendors to interoperate
The "Extensions to RSVP for LSP tunnels" (RSVP-TE) specification [1]
was developed by the IETF MPLS working group to address
requirement. RSVP-TE is a composition of several related
Awduche, et. al. Informational [Page 1]
RFC 3210 Applicability Statement for Extensions December 2001
submitted to the IETF MPLS working group. It contains all
necessary objects, packet formats, and procedures required
establish and maintain explicit label switched paths (LSPs).
Explicit LSPs are foundational to the traffic engineering
in MPLS based IP networks. Besides the traffic
application, the RSVP-TE specification may have other uses within
Internet
This memo describes the applicability of the RSVP-TE
[1]. The protocol's principles of operation are highlighted,
network context for which it was developed is described,
for deployment are offered, and known protocol limitations
indicated
This applicability statement concerns only the use of RSVP to set
unicast LSP-tunnels. It is noted that not all of the
described in RFC2205 [3] are required to support the
and maintenance of LSP-tunnels. Aspects related to the support
other features and capabilities of RSVP by an implementation
also supports LSP-tunnels are beyond the scope of this document
However, support of such additional features and capabilities
not introduce new security vulnerabilities in environments that
use RSVP to set up LSP-tunnels
This applicability statement does not preclude the use of
signaling and label distribution protocols for the
engineering application in MPLS based networks. Service
are free to deploy whatever signaling protocol that meets
needs
In particular, CR-LDP [6] and RSVP-TE [1] are two signaling
that perform similar functions in MPLS networks. There is
no consensus on which protocol is technically superior. Therefore
network administrators should make a choice between the two
upon their needs and particular situation
2.0 Technical Overview of Extensions to RSVP for LSP
The RSVP-TE specification extends the original RSVP protocol
giving it new capabilities that support the following functions in
MPLS domain
(1) downstream-on-demand label
(2) instantiation of explicit label switched
(3) allocation of network resources (e.g., bandwidth)
explicit
(4) rerouting of established LSP-tunnels in a smooth
using the concept of make-before-
Awduche, et. al. Informational [Page 2]
RFC 3210 Applicability Statement for Extensions December 2001
(5) tracking of the actual route traversed by an LSP-
(6) diagnostics on LSP-
(7) the concept of nodal
(8) preemption options that are administratively
The RSVP-TE specification introduces several new RSVP objects
including the LABEL-REQUEST object, the RECORD-ROUTE object,
LABEL object, the EXPLICIT-ROUTE object, and new SESSION objects
New error messages are defined to provide notification of
conditions. All of the new objects defined in RSVP-TE are
with respect to the RSVP protocol, except the LABEL-REQUEST and
objects, which are both mandatory for the establishment of LSP
tunnels
Two fundamental aspects distinguish the RSVP-TE specification [1]
from the original RSVP protocol [3].
The first distinguishing aspect is the fact that the RSVP-
specification [1] is intended for use by label switching routers (
well as hosts) to establish and maintain LSP-tunnels and to
network resources for such LSP-tunnels. The original
specification [3], on the other hand, was intended for use by
to request and reserve network resources for micro-flows
The second distinguishing aspect is the fact that the RSVP-
specification generalizes the concept of "RSVP flow." The RSVP-
specification essentially allows an RSVP session to consist of
arbitrary aggregation of traffic (based on local policies)
the originating node of an LSP-tunnel and the egress node of
tunnel. To be definite, in the original RSVP protocol [3], a
was defined as a data flow with a particular destination
transport layer protocol. In the RSVP-TE specification, however,
session is implicitly defined as the set of packets that are
the same MPLS label value at the originating node of an LSP-tunnel
The assignment of labels to packets can be based on various criteria
and may even encompass all packets (or subsets thereof) between
endpoints of the LSP-tunnel. Because traffic is aggregated,
number of LSP-tunnels (hence the number of RSVP sessions) does
increase proportionally with the number of flows in the network
Therefore, the RSVP-TE specification [1] addresses a major
issue with the original RSVP protocol [3], namely the large amount
system resources that would otherwise be required to
reservations and maintain state for potentially thousands or
millions of RSVP sessions at the micro-flow granularity
The reader is referred to [1] for a technical description of
RSVP-TE protocol specification
Awduche, et. al. Informational [Page 3]
RFC 3210 Applicability Statement for Extensions December 2001
3.0 Applicability of Extensions to RSVP for LSP
Use of RSVP-TE is appropriate in contexts where it is useful
establish and maintain explicit label switched paths in an
network. LSP-tunnels may be instantiated for measurement
and/or for routing control purposes. They may also be
for other administrative reasons
For the measurement application, an LSP-tunnel can be used to
various path statistics between its endpoints. This can
accomplished by associating various performance management and
management functions with an LSP-tunnel, such as packet and
counters. For example, an LSP-tunnel can be instantiated, with
without bandwidth allocation, solely for the purpose of
traffic flow statistics between two label switching routers
For the routing control application, LSP-tunnels can be used
forward subsets of traffic through paths that are independent
routes computed by conventional Interior Gateway Protocol (IGP
Shortest Path First (SPF) algorithms. This feature
significant flexibility into the routing function and allows
to be implemented that can result in the performance optimization
operational networks. For example, using LSP-tunnels, traffic can
routed away from congested network resources onto
underutilized ones. More generally, load balancing policies can
actualized that increase the effective capacity of the network
To further enhance the control application, RSVP-TE may be
with an ancillary constraint-based routing entity. This entity
compute explicit routes based on certain traffic attributes,
taking network constraints into account. Additionally, IGP
state advertisements may be extended to propagate new topology
information. This information can be used by the constraint-
routing entity to compute feasible routes. Furthermore, the
routing algorithm may itself be enhanced to take pre-
LSP-tunnels into consideration while building the routing table.
these augmentations are useful, but not mandatory. In fact,
RSVP-TE specification may be deployed in certain contexts without
of these additional components
The capability to monitor point to point traffic statistics
two routers and the capability to control the forwarding paths
subsets of traffic through a given network topology together make
RSVP-TE specifications applicable and useful for traffic
within service provider networks
These capabilities also make the RSVP-TE applicable, in
contexts, as a component of an MPLS based VPN provisioning framework
Awduche, et. al. Informational [Page 4]
RFC 3210 Applicability Statement for Extensions December 2001
It is significant that the MPLS architecture [4] states clearly
no single label distribution protocol is assumed for the
technology. Therefore, as noted in the introduction,
applicability statement does not (and should not be construed to
prevent a label switching router from implementing other
and label distribution protocols that also support establishment
explicit LSPs and traffic engineering in MPLS networks
4.0 Deployment and Policy
When deploying RSVP-TE, there should be well defined
policies governing the selection of nodes that will serve
endpoints for LSP-tunnels. Furthermore, when devising a
topology for LSP-tunnels, special consideration should be given
the tradeoff between the operational complexity associated with
large number of LSP-tunnels and the control granularity that
numbers of LSP-tunnels allow. Stated otherwise, a large number
LSP-tunnels allows greater control over the distribution of
across the network, but increases network operational complexity.
large networks, it may be advisable to start with a simple LSP-
virtual topology and then introduce additional complexity based
observed or anticipated traffic flow patterns
Administrative policies may also guide the amount of bandwidth to
allocated (if any) to each LSP-tunnel. Policies of this type
take into consideration empirical traffic statistics derived from
operational network in addition to other factors
5.0
The RSVP-TE specification supports only unicast LSP-tunnels
Multicast LSP-tunnels are not supported
The RSVP-TE specification supports only unidirectional LSP-tunnels
Bidirectional LSP-tunnels are not supported
The soft state nature of RSVP remains a source of concern because
the need to generate refresh messages periodically to maintain
state of established LSP-tunnels. This issue is addressed in
proposals that have been submitted to the RSVP working group (
e.g. [5]).
6.0
The applicability of the "Extensions to RSVP for LSP Tunnels
specification has been discussed in this document. The
introduced several enhancements to the RSVP protocol, which make
Awduche, et. al. Informational [Page 5]
RFC 3210 Applicability Statement for Extensions December 2001
applicable in contexts in which the original RSVP protocol would
been inappropriate. One context in which the RSVP-TE
is particularly applicable is in traffic engineering in MPLS based
networks
7.0 Security
This document does not introduce new security issues. The RSVP-
specification adds new opaque objects to RSVP. Therefore,
security considerations pertaining to the original RSVP
remain relevant. When deployed in service provider networks, it
mandatory to ensure that only authorized entities are permitted
initiate establishment of LSP-tunnels
8.0
The authors gratefully acknowledge the useful comments received
the following individuals during initial review of this memo in
MPLS WG mailing list: Eric Gray, John Renwick, and George Swallow
9.0
[1] Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G. and V
Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels,"
3209, December 2001.
[2] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J
McManus, "Requirements for Traffic Engineering Over MPLS,"
2702, September 1999.
[3] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin
"Resource ReSerVation Protocol (RSVP) -- Version 1,
Specification", RFC 2205, September 1997.
[4] Rosen, E., Viswanathan, A. and R. Callon, "A
Architecture for MPLS", RFC 3031, January 2001.
[5] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S
Molendini, "RSVP Refresh Overhead Reduction Extensions",
2961, April 2001.
[6] Jamoussi, B. et al, "Constraint-Based LSP Setup using LDP,"
Work in Progress
Awduche, et. al. Informational [Page 6]
RFC 3210 Applicability Statement for Extensions December 2001
10.0 Authors'
Daniel O.
Movaz
7926 Jones Branch Drive, Suite 615
McLean, VA 22102
EMail: awduche@movaz.
Voice: +1 703-298-5291
Alan
112 Falkirk
Sunnyvale, CA 94087
EMail: alan@routingloop.
Voice: +1 408 666-2326
XiPeng
Photuris Inc
2025 Stierlin Ct
Mountain View, CA 94043
EMail: xxiao@photuris.
Voice: +1 650-919-3215
Awduche, et. al. Informational [Page 7]
RFC 3210 Applicability Statement for Extensions December 2001
11.0 Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Awduche, et. al. Informational [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
