draft-ietf-rsvp-spec-03.txt   draft-ietf-rsvp-spec-04.txt 
Internet Draft L. Zhang Internet Draft L. Zhang
Expires: January 1995 PARC Expiration: May 95 PARC
File: draft-ietf-rsvp-spec-03.txt R. Braden File: draft-ietf-rsvp-spec-04.txt R. Braden
ISI ISI
D. Estrin D. Estrin
ISI ISI
S. Herzog S. Herzog
ISI ISI
S. Jamin S. Jamin
USC USC
Resource ReSerVation Protocol (RSVP) -- Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification Version 1 Functional Specification
**DRAFT**
November 3, 1994
Status of Memo Status of Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow linebreak "1id-abstracts.txt" listing contained in the Internet-
Directories on ds.internic.net (US East Coast), nic.nordu.net Drafts Shadow Directories on ds.internic.net (US East Coast),
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au
Rim). (Pacific Rim).
Abstract Abstract
This memo describes version 1 of RSVP, a resource reservation setup This memo describes version 1 of RSVP, a resource reservation setup
protocol designed for an integrated services Internet. RSVP provides protocol designed for an integrated services Internet. RSVP provides
receiver-initiated setup of resource reservations for multicast or receiver-initiated setup of resource reservations for multicast or
unicast data flows, with good scaling and robustness properties. unicast data flows, with good scaling and robustness properties.
What's Changed Since Seattle IETF What's Changed Since Seattle IETF
skipping to change at page 2, line 31 skipping to change at page 2, line 31
3). 3).
o Add short discussion of local repair (Section 3.3.3). o Add short discussion of local repair (Section 3.3.3).
o Editorial nits. o Editorial nits.
1. Introduction 1. Introduction
This memo describes RSVP, a resource reservation setup protocol This memo describes RSVP, a resource reservation setup protocol
designed for an integrated services Internet [RSVP93,ISInt93]. An designed for an integrated services Internet [RSVP93,ISInt93]. An
application invokes RSVP to request a specific quality of service application invokes RSVP to request a specific quality of service (
(QoS) for a data stream. Hosts and routers use RSVP to deliver these QoS) for a data stream. Hosts and routers use RSVP to deliver these
requests to the routers along the path(s) of the data stream and to requests to the routers along the path(s) of the data stream and to
maintain router and host state to provide the requested service. maintain router and host state to provide the requested service.
This generally requires reserving resources in those nodes. This generally requires reserving resources in those nodes.
At each "node" (i.e., router or host) along the path, RSVP passes a At each "node" (i.e., router or host) along the path, RSVP passes a
new resource reservation request to an admission control routine, to new resource reservation request to an admission control routine, to
determine whether there are sufficient resources available. If there determine whether there are sufficient resources available. If there
are, the node reserves the resources and updates its packet scheduler are, the node reserves the resources and updates its packet scheduler
and classifier control parameters to provide the requested QoS and classifier control parameters to provide the requested QoS
[ISInt93]. It is expected that RSVP implementations will execute in [ISInt93]. It is expected that RSVP implementations will execute in
skipping to change at page 5, line 17 skipping to change at page 5, line 17
a particular session (hence, session socket) is always implied a particular session (hence, session socket) is always implied
even if not stated. even if not stated.
Depending upon the reservation style and the session state already Depending upon the reservation style and the session state already
in place, a new or modified reservation request may or may not in place, a new or modified reservation request may or may not
result in a call to admission control at each node [ISInt93]. If result in a call to admission control at each node [ISInt93]. If
an admission control call fails, the reservation is rejected and an admission control call fails, the reservation is rejected and
an RSVP error message is sent to the receiver(s) responsible for an RSVP error message is sent to the receiver(s) responsible for
it. it.
A single RSVP resource reservation request is defined by a A single RSVP resource reservation request is defined by a "
"flowspec" together with a "filterspec"; this pair is called a flowspec" together with a "filterspec"; this pair is called a "
"Flow Descriptor". The flowspec specifies the desired QoS in a Flow Descriptor". The flowspec specifies the desired QoS in a
quantitative manner, e.g., the tolerable delay, the average quantitative manner, e.g., the tolerable delay, the average
throughput, the maximum burstiness, etc [Partridge92, ISInt93, throughput, the maximum burstiness, etc [Partridge92, ISInt93,
IServ93]; it is used to set parameters to the packet scheduling IServ93]; it is used to set parameters to the packet scheduling
mechanism in the node (router or host). The filterspec (plus the mechanism in the node (router or host). The filterspec (plus the
DestAddress) defines the set of data packets to receive this DestAddress) defines the set of data packets to receive this
service; it is used to set parameters in the packet classifier service; it is used to set parameters in the packet classifier
component of the node. For all packets that are addressed to a component of the node. For all packets that are addressed to a
particular session, only those that can match the filter spec(s) particular session, only those that can match the filter spec(s)
of that session will be forwarded according to the flowspec; the of that session will be forwarded according to the flowspec; the
rest will be either dropped or sent as best-effort traffic. rest will be either dropped or sent as best-effort traffic.
skipping to change at page 44, line 13 skipping to change at page 44, line 13
the beginning of the IP header. The minimum length of the beginning of the IP header. The minimum length of
this format of sender template is 7 octets (FiltSLen = 2). this format of sender template is 7 octets (FiltSLen = 2).
A wildcard Filterspec, which will match any sender host, A wildcard Filterspec, which will match any sender host,
has zero for the Sender IP Address [If VM part zero also, has zero for the Sender IP Address [If VM part zero also,
could shorten to FiltSLen = 2]. could shorten to FiltSLen = 2].
To speed RSVP processing, a filterspec that appears in an To speed RSVP processing, a filterspec that appears in an
RSVP message use the following "canonical form". RSVP message use the following "canonical form".
o The high-order octet of the mask M must be non-zero o
The high-order octet of the mask M must be non-zero
(this can always be achieved by adjusting VFoffset). (this can always be achieved by adjusting VFoffset).
o The (V,M) part must not include either the sender or o The (V,M) part must not include either the sender or
receiver address of the IP header; these are carried receiver address of the IP header; these are carried
explicitly. explicitly.
ISSUE: ISSUE:
There are many possible filter rules that cannot be There are many possible filter rules that cannot be
expressed using a simple mask and value pair. A expressed using a simple mask and value pair. A
compact and general filter encoding is for further compact and general filter encoding is for further
study. study.
o Authenticator Format o Authenticator Format
The following simple form of authenticator is defined: The following simple form of authenticator is defined:
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/