Network Working Group D. Awduche Request for Comments: 3210 Movaz Networks Category: Informational A. Hannan Routingloop X. Xiao Photuris December 2001 Applicability Statement for Extensions to RSVP for LSP-Tunnels Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved.
AbstractThis memo discusses the applicability of "Extensions to RSVP (Resource ReSerVation Protocol) for LSP Tunnels". It highlights the protocol's principles of operation and describes the network context for which it was designed. Guidelines for deployment are offered and known protocol limitations are indicated. This document is intended to accompany the submission of "Extensions to RSVP for LSP Tunnels" onto the Internet standards track. 2]. There is, therefore, a requirement for an open, non- proprietary, standards based signaling and label distribution protocol for the MPLS traffic engineering application that will allow label switching routers from different vendors to interoperate. The "Extensions to RSVP for LSP tunnels" (RSVP-TE) specification  was developed by the IETF MPLS working group to address this requirement. RSVP-TE is a composition of several related proposals
submitted to the IETF MPLS working group. It contains all the necessary objects, packet formats, and procedures required to establish and maintain explicit label switched paths (LSPs). Explicit LSPs are foundational to the traffic engineering application in MPLS based IP networks. Besides the traffic engineering application, the RSVP-TE specification may have other uses within the Internet. This memo describes the applicability of the RSVP-TE specifications . 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. 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  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 signaling and label distribution protocols for the traffic engineering application in MPLS based networks. Service providers are free to deploy whatever signaling protocol that meets their needs. In particular, CR-LDP  and RSVP-TE  are two signaling protocols that perform similar functions in MPLS networks. There is currently no consensus on which protocol is technically superior. Therefore, network administrators should make a choice between the two based upon their needs and particular situation.
(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-TE specification introduces several new RSVP objects, including the LABEL-REQUEST object, the RECORD-ROUTE object, the LABEL object, the EXPLICIT-ROUTE object, and new SESSION objects. New error messages are defined to provide notification of exception conditions. All of the new objects defined in RSVP-TE are optional with respect to the RSVP protocol, except the LABEL-REQUEST and LABEL objects, which are both mandatory for the establishment of LSP- tunnels. Two fundamental aspects distinguish the RSVP-TE specification  from the original RSVP protocol . The first distinguishing aspect is the fact that the RSVP-TE specification  is intended for use by label switching routers (as well as hosts) to establish and maintain LSP-tunnels and to reserve network resources for such LSP-tunnels. The original RSVP specification , on the other hand, was intended for use by hosts to request and reserve network resources for micro-flows. The second distinguishing aspect is the fact that the RSVP-TE specification generalizes the concept of "RSVP flow." The RSVP-TE specification essentially allows an RSVP session to consist of an arbitrary aggregation of traffic (based on local policies) between the originating node of an LSP-tunnel and the egress node of the tunnel. To be definite, in the original RSVP protocol , a session was defined as a data flow with a particular destination and transport layer protocol. In the RSVP-TE specification, however, a session is implicitly defined as the set of packets that are assigned 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 the endpoints of the LSP-tunnel. Because traffic is aggregated, the number of LSP-tunnels (hence the number of RSVP sessions) does not increase proportionally with the number of flows in the network. Therefore, the RSVP-TE specification  addresses a major scaling issue with the original RSVP protocol , namely the large amount of system resources that would otherwise be required to manage reservations and maintain state for potentially thousands or even millions of RSVP sessions at the micro-flow granularity. The reader is referred to  for a technical description of the RSVP-TE protocol specification.
It is significant that the MPLS architecture  states clearly that no single label distribution protocol is assumed for the MPLS technology. Therefore, as noted in the introduction, this applicability statement does not (and should not be construed to) prevent a label switching router from implementing other signaling and label distribution protocols that also support establishment of explicit LSPs and traffic engineering in MPLS networks. 5]).
applicable in contexts in which the original RSVP protocol would have been inappropriate. One context in which the RSVP-TE specification is particularly applicable is in traffic engineering in MPLS based IP networks.  Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G. and V. Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 2001.  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS," RFC 2702, September 1999.  Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997.  Rosen, E., Viswanathan, A. and R. Callon, "A Proposed Architecture for MPLS", RFC 3031, January 2001.  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.  Jamoussi, B. et al, "Constraint-Based LSP Setup using LDP," Work in Progress.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.