RSVP Applicability: Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment
Guidance on when and how to deploy RSVP for quality-of-service reservations
Mankin, A., Ed., Baker, F., Braden, B., Bradner, S., O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment", RFC 2208, DOI 10.17487/RFC2208, September 1997, <https://www.rfc-editor.org/info/rfc2208>.
@misc{rfc2208,
series = {Request for Comments},
number = 2208,
howpublished = {RFC 2208},
publisher = {RFC Editor},
doi = {10.17487/RFC2208},
url = {https://www.rfc-editor.org/info/rfc2208},
author = {A. Mankin and F. Baker and B. Braden and S. Bradner and M. O'Dell and A. Romanow and A. Weinrib and L. Zhang},
title = {{Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment}},
pagetotal = 6,
year = 1997,
month = sep,
} RFC text
Contents
Network Working Group A. Mankin, Ed.
Request for Comments: 2208 USC/ISI
Category: Informational F. Baker
Cisco Systems
B. Braden
USC/ISI
S. Bradner
Harvard
M. O`Dell
UUNET Technologies
A. Romanow
Sun Microsystems
A. Weinrib
Intel Corporation
L. Zhang
UCLA
September 1997
Resource ReSerVation Protocol (RSVP)
Version 1 Applicability Statement
Some Guidelines on Deployment
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.
Abstract
This document describes the applicability of RSVP along with the
Integrated Services protocols and other components of resource
reservation and offers guidelines for deployment of resource
reservation at this time. This document accompanies the first
submission of RSVP and integrated services specifications onto the
Internet standards track.
1. Introduction
RSVP [RFC 2205] is a unicast and multicast signalling protocol,
designed to install and maintain reservation state information at
each router along the path of a stream of data. The state handled by
RSVP is defined by services [RFC 2211] and [RFC 2212] specified by
the Integrated Services WG. These services and RSVP are being
introduced to the IETF's standards track jointly. From henceforth,
the acronym RSVP on its own is used as a shorthand for the signalling
protocol combined with the integrated service specifications.
RSVP must be used in conjunction with several additional components,
described in Table 1.
Table 1 Additional Components of Resource Reservation
1. Message formats in which parameters for desired services can be
expressed. A proposed standard set of these formats is specified
in [RFC 2210].
2. Router and host mechanisms (e.g. packet classification and
scheduling, admission control algorithms) to implement one or
both of the models [RFC 2211] and [RFC 2212], which are also
in the standards track.
3. Message formats in which parameters for desired policies for
admission control and resource use can be expressed. A small
common subset of these formats for standards track is in the
RSVP WG's charter. The Policy objects in the RSVP Protocol
Specification are optional only at this time.
4. Diversely located mechanisms implementing desired admission
control policy functions, including authorization and other
security mechanisms.
In the presence of some form of each component in Table 1, RSVP-
enabled applications can achieve differentiated qualities of service
across IP networks. Networked multimedia applications, many of which
require (or will benefit from) a predictable end-user experience, are
likely to be initial users of RSVP-signalled services.
Because RSVP and the integrated services and other components listed
in Table 1 mark a significant change to the service model of IP
networks, RSVP has received considerable interest and press in
advance of its release as a standards track RFC. At present, many
vendors of operating systems and routers are incorporating RSVP and
integrated services into their products for near-future availability.
The goal of this applicability statement is to describe those uses of
the current RSVP specification that are known to be feasible, and to
identify areas of limitation and ongoing chartered work addressing
some of these limitations.
2. Issues Affecting Deployment of RSVP
Wide scale deployment of RSVP must be approached with care, as there
remains a number of outstanding issues that may affect the success of
deployment.
2.1. Scalability
The resource requirements (processing and storage) for running RSVP
on a router increase proportionally with the number of separate
sessions (i.e., RSVP reservations). Thus, supporting numerous small
reservations on a high-bandwidth link may easily overly tax the
routers and is inadvisable. Furthermore, implementing the packet
classification and scheduling capabilities currently used to provide
differentiated services for reserved flows may be very difficult for
some router products or on some of their high-speed interfaces (e.g.
OC-3 and above).
These scaling issues imply that it will generally not be appropriate
to deploy RSVP on high-bandwidth backbones at the present time.
Looking forward, the operators of such backbones will probably not
choose to naively implement RSVP for each separate stream. Rather,
techniques are being developed that will, at the "edge" of the
backbone, aggregate together the streams that require special
treatment. Within the backbone, various less costly approaches would
then be used to set aside resources for the aggregate as a whole, as
a way of meeting end-to-end requirements of individual flows.
In the near term, various vendors are likely to use diverse
approaches to the aggregation of reservations. There is not
currently chartered work in the IETF for development of standards in
this space. A BOF, Future Directions of Differential Services, on
April 7, 1997, at the Memphis IETF, is to consider the IETF's next
steps on this, among other issues. Public documentation of
aggregation techniques and experience is encouraged.
2.2. Security Considerations
The RSVP WG submission for Proposed Standard includes two security-
related documents [Baker96, RFC 2207]. [Baker96] addresses denial and
hijacking or theft of service attacks. [RFC 2207] addresses RSVP
mechanisms for data flows that themselves use IPSEC.
The first document is proposed to protect against spoofed reservation
requests arriving at RSVP routers; such requests might be used to
obtain service to unauthorized parties or to lock up network
resources in a denial of service attack. Modified and spoofed
reservation requests are detected by use of hop-by-hop MD5 checksums
(in an Integrity Object) between RSVP neighbor routers. As
described, RSVP hop-by-hop authentication assumes that key management
and distribution for routers is resolved and deployed. Until an
effective key infrastructure is in place, manually keyed session
integrity might be used. In addition, [Baker96] may be updated with
RFC 2085.
That RSVP needs an effective key infrastructure among routers is not
unique to RSVP: it is widely acknowledged that there are numerous
denial of service attacks on the routing infrastructure (quite
independent of RSVP) that will only be resolved by deployment of a
key infrastructure.
Theft of service risks will require the user to deploy with caution.
An elementary precaution is to configure management logging of new
and changed filter specifications in RSVP-enabled infrastructure,
e.g. the newFlow trap [RFC 2206].
The Integrity object defined by [Baker96] may also play a role in
policy control, as will be described in 2.3.
The second security-related document provides a mechanism for
carrying flows in which the transport and user octets have been
encrypted (RFC 1827). Although such encryption is highly beneficial
to certain applications, it is not relevant to the functional
security of RSVP or reservations.
The following section on Policy Control includes additional
discussion of RSVP authorization security.
2.3. Policy Control
Policy control addresses the issue of who can, or cannot, make
reservations once a reservation protocol can be used to set up
unequal services.
Currently, the RSVP specification defines a mechanism for
transporting policy information along with reservations. However,
the specification does not define policies themselves. At present,
vendors have stated that they will use the RSVP-defined mechanism to
implement proprietary policies.
The RSVP WG is chartered to specify a simple standardized policy
object and complete simple mechanisms for session use of the
Integrity object in the near future. This applicability statement
may be updated at the completion of the WG's charter.
Before any decision to deploy RSVP, it would be wise to ensure that
the policy control available from a vendor is adequate for the
intended usage. In addition to the lack of documented policy
mechanisms in any of the policy areas (such as access control,
authorization, and accounting), the community has little experience
with describing, setting and controlling policies that limit Internet
service. Therefore it is likely that vendor solutions will be
revised often, particularly before the IETF has developed any policy
specification.
3. Recommendations
Given the current form of the RSVP specifications, multimedia
applications to be run within an intranet are likely to be the first
to benefit from RSVP. SNA/DLSW is another "application" considered
likely to benefit. Within the single or small number of related
administrative domains of an intranet, scalability, security and
access policy will be more manageable than in the global Internet,
and risk will be more controllable. Use of RSVP and supporting
components for small numbers of flows within a single Internet
Service Provider is similar to an intranet use.
Current experience with RSVP has been collected only from test runs
in limited testbeds and intranet deployment. We recommend that
people begin to use RSVP in production intranet or limited ISP
environments (as mentioned above), in which benefits can be realized
without having to resolve some of the issues described in Section 2.
To quote RFC 2026 about the use of Proposed Standard technology:
Implementors should treat Proposed Standards as immature
specifications. It is desirable to implement them in order to gain
experience and to validate, test, and clarify the specification.
However, since the content of Proposed Standards may be changed if
problems are found or better solutions are identified, deploying
implementations of such standards into a disruption-sensitive
environment is not recommended.
General issues of scalability, security and policy control as
outlined in Section 2 are the subjects of active research and
development, as are a number of topics beyond this applicability
statement, such as third-party setup of either reservations or
differentiated service.
4. References
[Baker96] Baker, F., "RSVP Cryptographic Authentication", Work in
Progress.
[RFC 2206], Baker, F. and J. Krawczyk, "RSVP Management Information
Base", RFC 2206, September 1997.
[RFC 2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
Data Flows", RFC 2207, September 1997.
[RFC 2211] Wroclawski, J., "Specification of Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RFC 2212] Shenker, S., C. Partridge and R. Guerin, "Specification
of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC 2205] Braden, R. Ed. et al, "Resource ReserVation Protocol
-- Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
5. Authors' Addresses
Fred Baker Abel Weinrib
Cisco Systems Intel Corporation
Phone: 408-526-4257 Phone: 503-264-8972
EMail: fred@cisco.com EMail: aweinrib@ibeam.intel.com
Bob Braden
USC/ISI Lixia Zhang
4676 Admiralty Way UCLA Computer Science Department
Marina Del Rey, CA 90292 4531G Boelter Hall
Phone: 310-822-1511 Los Angeles, CA 90095-1596 USA
EMail: braden@isi.edu Phone: 310-825-2695
EMail: lixia@cs.ucla.edu
Scott Bradner Allyn Romanow
Harvard University Sun Microsystems
Phone: 617-495-3864 Phone: 415-786-5179
EMail: sob@harvard.edu EMail: allyn@eng.sun.com
Michael O'Dell Allison Mankin
UUNET Technologies mankin@east.isi.edu
Phone: 703-206-5471
EMail: mo@uu.net
AI ELI5
On this page
§1RSVP: A New Service Model for the Internet
RSVP (Resource ReSerVation Protocol) is a signaling protocol that allows applications to tell routers along a network path that they need a certain quality of service: guaranteed bandwidth, bounded delay, or low loss. Paired with Integrated Services, it promised to deliver differentiated service qualities on the Internet, breaking from the original IP model of best-effort delivery where all packets were treated equally. Multimedia applications—video conferences, streaming audio, online games—could potentially use RSVP to reserve bandwidth for interactive quality. The protocol was standardized as a Proposed Standard alongside related specifications, making it the first coordinated attempt to add quality-of-service guarantees to IP networks.
RSVP is like raising your hand on a busy highway to tell drivers 'I'm coming through here and I need clear lanes.' Without RSVP, all traffic mixes together and important stuff gets delayed.
§2Scalability Limitations
Every RSVP reservation requires routers to store state information and make scheduling decisions for that flow. On a high-bandwidth backbone (OC-3 and above), supporting thousands or millions of individual reservations becomes computationally expensive and difficult to implement in hardware. Worse, implementing per-flow packet classification and scheduling at high line rates was technically challenging for the hardware of the mid-1990s. The RFC notes that backbone operators would not want to create a separate reservation for each stream; instead, they would need to aggregate many small flows into larger reservations. However, aggregation standards did not exist at the time, and vendors were developing proprietary solutions. The document recommends not deploying RSVP on high-bandwidth backbones initially, and suggests that future aggregation techniques might help.
If millions of cars each reserve their own lane, the highway becomes impossible to manage. You need a way to group reservations together, but nobody had figured that out yet.
§3Security and Authentication Concerns
RSVP is vulnerable to spoofed reservation requests: a malicious host could send fake reservation messages to lock up router resources or obtain unauthorized service. The security documents in the RSVP submission describe hop-by-hop MD5 checksums using an Integrity object to detect modified or spoofed messages between neighboring routers, but this requires a key infrastructure for managing and distributing keys among routers. At the time, no such key infrastructure was deployed. The RFC acknowledges that denial-of-service risks on the routing layer are not unique to RSVP but apply broadly to routing security, and that addressing them requires solving the larger problem of router key management.
Someone could pretend to make a reservation and mess things up, like a fake person claiming they need the highway reserved. You need a way for routers to trust each other, which was still being figured out.
§4Policy Control: Who Can Reserve What
RSVP itself provides a mechanism for transporting policy information—rules about who can make reservations and what they can reserve—but the RFC does not define specific policies. Vendors said they would implement proprietary policies in their products, meaning a customer deploying RSVP across multiple vendors would face compatibility headaches. The RSVP Working Group was chartered to develop a standardized simple policy object, but at the time of this RFC, policies remained undefined. Before deploying RSVP, operators should carefully evaluate whether vendor policies meet their needs, knowing that they would likely change as standards developed.
The rules for who gets to reserve bandwidth need to be set, but nobody had standard rules. Each company had their own rules, so putting different companies' equipment together was messy.
§5Recommended Deployment Approach
Given the limitations, the RFC recommends that organizations start with RSVP in controlled environments: intranets (networks within a single organization), multimedia applications within a single administrative domain, or limited ISP environments with a small number of flows. Within an intranet, scalability, security, and policy control are more manageable. The RFC quotes RFC 2026's guidance on Proposed Standards: implementors should use them to gain experience and validate the specification, but deploying Proposed Standards into disruption-sensitive environments is risky because the specification may change.
Try RSVP in your office's internal network first, where you control everything. Don't use it on the global internet until the problems are solved.
§6Limitations and Future Work
The RFC identifies three areas of active research and development needed before wide-scale deployment: scalability through aggregation techniques, security through key infrastructure, and policy control through standardized mechanisms. These are not technical defects but rather recognition that the initial specification addresses core RSVP functionality while deferring larger architectural questions. The document encourages the community to document aggregation techniques and gain experience in limited deployments, with updates to the applicability statement expected as work on these issues progresses. It also mentions other topics beyond RSVP itself, such as third-party setup of reservations and differentiated service approaches.
The smart engineers knew RSVP needed help in three areas and were already working on it. They told people to be patient and learn from trying it in safe places.