As per Relevance of the word reservation, we have this rfc below:
Network Working Group A. Mankin, Ed
Request for Comments: 2208 USC/
Category: Informational F.
Cisco
B.
USC/
S.
M. O`
UUNET
A.
Sun
A.
Intel
L.
September 1997
Resource ReSerVation Protocol (RSVP
Version 1 Applicability
Some Guidelines on
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
This document describes the applicability of RSVP along with
Integrated Services protocols and other components of
reservation and offers guidelines for deployment of
reservation at this time. This document accompanies the
submission of RSVP and integrated services specifications onto
Internet standards track
Mankin, Ed., et. al. Informational [Page 1]
RFC 2208 RSVP Applicability and Deployment September 1997
1.
RSVP [RFC 2205] is a unicast and multicast signalling protocol
designed to install and maintain reservation state information
each router along the path of a stream of data. The state handled
RSVP is defined by services [RFC 2211] and [RFC 2212] specified
the Integrated Services WG. These services and RSVP are
introduced to the IETF's standards track jointly. From henceforth
the acronym RSVP on its own is used as a shorthand for the
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
1. Message formats in which parameters for desired services can
expressed. A proposed standard set of these formats is
in [RFC 2210].
2. Router and host mechanisms (e.g. packet classification
scheduling, admission control algorithms) to implement one
both of the models [RFC 2211] and [RFC 2212], which are
in the standards track
3. Message formats in which parameters for desired policies
admission control and resource use can be expressed. A
common subset of these formats for standards track is in
RSVP WG's charter. The Policy objects in the RSVP
Specification are optional only at this time
4. Diversely located mechanisms implementing desired
control policy functions, including authorization and
security mechanisms
In the presence of some form of each component in Table 1, RSVP
enabled applications can achieve differentiated qualities of
across IP networks. Networked multimedia applications, many of
require (or will benefit from) a predictable end-user experience,
likely to be initial users of RSVP-signalled services
Because RSVP and the integrated services and other components
in Table 1 mark a significant change to the service model of
networks, RSVP has received considerable interest and press
advance of its release as a standards track RFC. At present,
vendors of operating systems and routers are incorporating RSVP
integrated services into their products for near-future availability
The goal of this applicability statement is to describe those uses
Mankin, Ed., et. al. Informational [Page 2]
RFC 2208 RSVP Applicability and Deployment September 1997
the current RSVP specification that are known to be feasible, and
identify areas of limitation and ongoing chartered work
some of these limitations
2. Issues Affecting Deployment of
Wide scale deployment of RSVP must be approached with care, as
remains a number of outstanding issues that may affect the success
deployment
2.1.
The resource requirements (processing and storage) for running
on a router increase proportionally with the number of
sessions (i.e., RSVP reservations). Thus, supporting numerous
reservations on a high-bandwidth link may easily overly tax
routers and is inadvisable. Furthermore, implementing the
classification and scheduling capabilities currently used to
differentiated services for reserved flows may be very difficult
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
to deploy RSVP on high-bandwidth backbones at the present time
Looking forward, the operators of such backbones will probably
choose to naively implement RSVP for each separate stream. Rather
techniques are being developed that will, at the "edge" of
backbone, aggregate together the streams that require
treatment. Within the backbone, various less costly approaches
then be used to set aside resources for the aggregate as a whole,
a way of meeting end-to-end requirements of individual flows
In the near term, various vendors are likely to use
approaches to the aggregation of reservations. There is
currently chartered work in the IETF for development of standards
this space. A BOF, Future Directions of Differential Services,
April 7, 1997, at the Memphis IETF, is to consider the IETF's
steps on this, among other issues. Public documentation
aggregation techniques and experience is encouraged
2.2. Security
The RSVP WG submission for Proposed Standard includes two security
related documents [Baker96, RFC 2207]. [Baker96] addresses denial
hijacking or theft of service attacks. [RFC 2207] addresses
mechanisms for data flows that themselves use IPSEC
Mankin, Ed., et. al. Informational [Page 3]
RFC 2208 RSVP Applicability and Deployment September 1997
The first document is proposed to protect against spoofed
requests arriving at RSVP routers; such requests might be used
obtain service to unauthorized parties or to lock up
resources in a denial of service attack. Modified and
reservation requests are detected by use of hop-by-hop MD5
(in an Integrity Object) between RSVP neighbor routers.
described, RSVP hop-by-hop authentication assumes that key
and distribution for routers is resolved and deployed. Until
effective key infrastructure is in place, manually keyed
integrity might be used. In addition, [Baker96] may be updated
RFC 2085.
That RSVP needs an effective key infrastructure among routers is
unique to RSVP: it is widely acknowledged that there are
denial of service attacks on the routing infrastructure (
independent of RSVP) that will only be resolved by deployment of
key infrastructure
Theft of service risks will require the user to deploy with caution
An elementary precaution is to configure management logging of
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
policy control, as will be described in 2.3.
The second security-related document provides a mechanism
carrying flows in which the transport and user octets have
encrypted (RFC 1827). Although such encryption is highly
to certain applications, it is not relevant to the
security of RSVP or reservations
The following section on Policy Control includes
discussion of RSVP authorization security
2.3. Policy
Policy control addresses the issue of who can, or cannot,
reservations once a reservation protocol can be used to set
unequal services
Currently, the RSVP specification defines a mechanism
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
implement proprietary policies
Mankin, Ed., et. al. Informational [Page 4]
RFC 2208 RSVP Applicability and Deployment September 1997
The RSVP WG is chartered to specify a simple standardized
object and complete simple mechanisms for session use of
Integrity object in the near future. This applicability
may be updated at the completion of the WG's charter
Before any decision to deploy RSVP, it would be wise to ensure
the policy control available from a vendor is adequate for
intended usage. In addition to the lack of documented
mechanisms in any of the policy areas (such as access control
authorization, and accounting), the community has little
with describing, setting and controlling policies that limit
service. Therefore it is likely that vendor solutions will
revised often, particularly before the IETF has developed any
specification
3.
Given the current form of the RSVP specifications,
applications to be run within an intranet are likely to be the
to benefit from RSVP. SNA/DLSW is another "application"
likely to benefit. Within the single or small number of
administrative domains of an intranet, scalability, security
access policy will be more manageable than in the global Internet
and risk will be more controllable. Use of RSVP and
components for small numbers of flows within a single
Service Provider is similar to an intranet use
Current experience with RSVP has been collected only from test
in limited testbeds and intranet deployment. We recommend
people begin to use RSVP in production intranet or limited
environments (as mentioned above), in which benefits can be
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
specifications. It is desirable to implement them in order to
experience and to validate, test, and clarify the specification
However, since the content of Proposed Standards may be changed
problems are found or better solutions are identified,
implementations of such standards into a disruption-
environment is not recommended
General issues of scalability, security and policy control
outlined in Section 2 are the subjects of active research
development, as are a number of topics beyond this
statement, such as third-party setup of either reservations
differentiated service
Mankin, Ed., et. al. Informational [Page 5]
RFC 2208 RSVP Applicability and Deployment September 1997
4.
[Baker96] Baker, F., "RSVP Cryptographic Authentication", Work
Progress
[RFC 2206], Baker, F. and J. Krawczyk, "RSVP Management
Base", RFC 2206, September 1997.
[RFC 2207] Berger, L. and T. O'Malley, "RSVP Extensions for
Data Flows", RFC 2207, September 1997.
[RFC 2211] Wroclawski, J., "Specification of Controlled-
Network Element Service", RFC 2211, September 1997.
[RFC 2212] Shenker, S., C. Partridge and R. Guerin, "
of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC 2205] Braden, R. Ed. et al, "Resource ReserVation
-- Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC 2210] Wroclawski, J., "The Use of RSVP with IETF
Services", RFC 2210, September 1997.
5. Authors'
Fred Baker Abel
Cisco Systems Intel
Phone: 408-526-4257 Phone: 503-264-8972
EMail: fred@cisco.com EMail: aweinrib@ibeam.intel.
Bob
USC/ISI Lixia
4676 Admiralty Way UCLA Computer Science
Marina Del Rey, CA 90292 4531G Boelter
Phone: 310-822-1511 Los Angeles, CA 90095-1596
EMail: braden@isi.edu Phone: 310-825-2695
EMail: lixia@cs.ucla.
Scott Bradner Allyn
Harvard University Sun
Phone: 617-495-3864 Phone: 415-786-5179
EMail: sob@harvard.edu EMail: allyn@eng.sun.
Michael O'Dell Allison Mankin
UUNET Technologies mankin@east.isi.
Phone: 703-206-5471
EMail: mo@uu.
Mankin, Ed., et. al. Informational [Page 6]
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
