draft-ietf-rsvp-spec-05.txt   draft-ietf-rsvp-spec-06.txt 
Internet Draft R. Braden, Ed. Internet Draft R. Braden, Ed.
Expiration: September 1995 ISI Expiration: December 1995 ISI
File: draft-ietf-rsvp-spec-05.txt L.Zhang File: draft-ietf-rsvp-spec-06.txt L. Zhang
PARC PARC
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
March 24, 1995 June 21, 1995
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
skipping to change at page 2, line 5 skipping to change at page 2, line 5
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au
(Pacific 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 Toronto IETF What's Changed Since Boston IETF
This version of the document incorporates many of the protocol changes The most important changes in this document from the rsvp-spec-05 draft
agreed to at the December 1994 IETF meeting in San Jose. The most major are:
changes are:
o The RSVP packet format has been reorganized to carry most data o Added SE (Shared Explicit) style to all parts of the document.
as typed variable-length objects.
o This generality includes provision for 16-byte IP6 addresses. o Further clarified reservation options and added table in Figure
3. Defined option vector in STYLE object.
o Filter specs have been simplified. o Renamed CREDENTIAL object class to POLICY_DATA object class, and
rewrote section 2.5 to more fully express its intended usage.
o DF style has been moved to an Appendix, as experimental. o Clarified the relationship between the wildcard scope
reservation option and wildcards in individual FILTER_SPEC
objects: wildcard is as wildcard does.
o UDP encapsulation has been included. o Added SCOPE object definition and define the rules for its use
to prevent looping of wildcard-scope messages.
o OPWA has been included. o Added TAG object. This is needed to do semantic fragmentation
in certain cases; however, the rules for its use are not yet
written down. Furthermore, there has been some debate about
semantic fragmentation.
o The Drop flag has been eliminated. o Added some mechanisms for handling backwards compatibility for
future protocol extensions: (1) High bit of object class number;
(2) unmerged FLOWSPEC C-Type; (3) unmerged POLICY_DATA C-Type.
o Session groups have been added. o Rewrote Section 4.3 on preventing looping. Included rules for
SCOPE object.
o The routing of RERR messages has been changed. o Specified rules for local repair upon route change notification
(Section 4.4).
o Specified for each error type whether or not the state
information in the erroneous packet is to be stored and
forwarded.
o Deleted the discussion of retransmitting a Teardown message Q
times; assume Q=1 is sufficient.
o Moved Session Groups to Appendix D, "Experimental and Open
Issues". Session Groups should be revisited as part of a larger
context of cross-session reservations.
o Changed common header format, removing Object Count (which was
redundant) and rearranging the remaining fields. Moved the two
common header flags into objects: Entry-Police into SESSION
object and LUB-used into ERROR_SPEC object.
o Revised the rules for state timeout (Section 4.5) and redefined
the TIME_VALUES object format.
o Changed the error message format: (1) removed required RSVP_HOP
object from PERR and RERR messages; (2) removed CREDENTIAL
(i.e., POLICY_DATA) object from RERR messages; (3) specified
more carefully what may appear in flow descriptor list of RERR
messages.
o Revised the definitions of error codes and error values, and
moved them into a separate Appendix B.
o No longer require CREDENTIAL (i.e., POLICY_DATA) match for
teardown.
o Revised routing of RERR messages to use SCOPE objects to avoid
wildcard-induced looping.
o Added LIH (logical interface handle) to RSVP_HOP object, for IP
multicast tunnels.
o Added two new upcall event types in the API: reservation event
and policy data event.
o Generalized the generic traffic control calls slightly to allow
multiple filter specs per flowspec, for SE style. This
introduced a new set of handles, called FHandle. Also added a
preemption upcall.
o Added route change notification to the generic interface to
routing.
o Updated the message processing rules (Section 5).
o Rewrote Appendix C on UDP encapsulation.
o Removed specification of FLOWSPEC object format (but int-serv
working group has since reneged on promise to specify it).
1. Introduction 1. Introduction
This document defines RSVP, a resource reservation setup protocol This document defines RSVP, a resource reservation setup protocol
designed for an integrated services Internet [RSVP93,ISInt93]. designed for an integrated services Internet [RSVP93,ISInt93].
A host uses the RSVP protocol to request a specific quality of A host uses the RSVP protocol to request a specific quality of
service (QoS) from the network, on behalf of an application data service (QoS) from the network, on behalf of an application data
stream. RSVP is also used to deliver QoS requests to routers along stream. RSVP is also used to deliver QoS requests to routers along
the path(s) of the data stream and to maintain router and host state the path(s) of the data stream and to maintain router and host state
skipping to change at page 3, line 37 skipping to change at page 5, line 29
| |=> ifier|=> Packet =============> ifier|==> Packet |======> | |=> ifier|=> Packet =============> ifier|==> Packet |======>
| |______| |Scheduler|| | |______| |Scheduler|| | |______| |Scheduler|| | |______| |Scheduler||
| |_________|| | |_________|| | |_________|| | |_________||
|_________________________| |______________________| |_________________________| |______________________|
Figure 1: RSVP in Hosts and Routers Figure 1: RSVP in Hosts and Routers
Each router that is capable of resource reservation passes incoming Each router that is capable of resource reservation passes incoming
data packets to a packet classifier and then queues them as necessary data packets to a packet classifier and then queues them as necessary
in a packet scheduler. The packet classifier determines the route in a packet scheduler. The packet classifier determines the route
and the QoS class for each packet. The scheduler allocates a and the QoS class for each packet. The scheduler allocates resources
particular outgoing link for packet transmission, and it may also for transmission on the particular link-layer medium used by each
interface. If the link-layer medium is QoS-active, i.e., if it has
its own QoS management capability, then the packet scheduler is
responsible for negotiation with the link layer to obtain the QoS
requested by RSVP. There are many possible ways this might be
accomplished, and the details will be medium-dependent. The
scheduler itself allocates packet transmission capacity on a QoS-
passive medium such as a leased line. The scheduler may also
allocate other system resources such as CPU time or buffers. allocate other system resources such as CPU time or buffers.
In order to efficiently accommodate heterogeneous receivers and In order to efficiently accommodate heterogeneous receivers and
dynamic group membership and to be consistent with IP multicast, RSVP dynamic group membership and to be consistent with IP multicast, RSVP
makes receivers responsible for requesting resource reservations makes receivers responsible for requesting resource reservations
[RSVP93]. A QoS request, typically originating in a receiver host [RSVP93]. A QoS request, typically originating in a receiver host
application, will be passed to the local RSVP implementation, shown application, will be passed to the local RSVP implementation, shown
as a user daemon in Figure 1. The RSVP protocol is then used to pass as a user daemon in Figure 1. The RSVP protocol is then used to pass
the request to all the nodes (routers and hosts) along the reverse the request to all the nodes (routers and hosts) along the reverse
data path(s) to the data source(s). data path(s) to the data source(s).
skipping to change at page 6, line 16 skipping to change at page 8, line 4
_____________________ _____________________
( ) ===> R1 ( ) ===> R1
S1 ===> ( Multicast ) S1 ===> ( Multicast )
( ) ===> R2 ( ) ===> R2
( distribution ) ( distribution )
S2 ===> ( ) S2 ===> ( )
( by Internet ) ===> R3 ( by Internet ) ===> R3
(_____________________) (_____________________)
Figure 2: Multicast Distribution Session Figure 2: Multicast Distribution Session
Even if the destination address is unicast, there may be multiple
receivers, distinguished by the generalized port. There may also
be multiple senders for a unicast destination, i.e., RSVP can set
up reservations for multipoint-to-point transmission.
1.2 Reservation Model 1.2 Reservation Model
An elementary RSVP reservation request consists of a "flowspec" An elementary RSVP reservation request consists of a "flowspec"
together with a "filter spec"; this pair is called a "flow together with a "filter spec"; this pair is called a "flow
descriptor". The flowspec specifies a desired QoS. The filter descriptor". The flowspec specifies a desired QoS. The filter
spec (together with the DestAddress and the generalized spec (together with the DestAddress and the generalized
destination port defining the session) defines the set of data destination port defining the session) defines the set of data
packets -- the "flow" -- to receive the QoS defined by the packets -- the "flow" -- to receive the QoS defined by the
flowspec. The flowspec is used to set parameters to the packet flowspec. The flowspec is used to set parameters to the node's
scheduler in the node (assuming that admission control succeeds), packet scheduler (assuming that admission control succeeds), while
while the filter spec is used to set parameters in the packet the filter spec is used to set parameters in the packet
classifier. classifier. Note that the action to control the QoS occurs at the
place where the data enters the medium, i.e., at the upstream end
of the link, although the RSVP reservation request originates from
receiver(s) downstream.
The flowspec in a reservation request will generally include a The flowspec in a reservation request will generally include a
service type and two sets of numeric parameters: (1) an " Rspec" service type and two sets of numeric parameters: (1) an "Rspec" (R
(R for `reserve'), which defines the desired per-hop reservation, for `reserve'), which defines the desired per-hop reservation, and
and (2) a "Tspec" (T for `traffic'), which defines the parameters (2) a "Tspec" (T for `traffic'), which defines the parameters that
that may be used to police the data flow, i.e., to ensure it does may be used to police the data flow, i.e., to ensure it does not
not exceed its promised traffic level. exceed its promised traffic level.
The general RSVP reservation model allows filter specs to select The form and contents of Tspecs and Rspecs are determined by the
arbitrary subsets of the packets in a given session. Such subsets integrated service model [ServTempl95a], and are generally opaque
might be defined in terms of senders (i.e., sender IP address and to RSVP. RSVP delivers the Tspec and Rspec, together with an
generalized source port), in terms of a higher-level protocol, or indication whether traffic policing is needed to the admission
generally in terms of any fields in any protocol headers in the control and packet scheduling components of traffic control. A
packet. For example, filter specs might be used to select service that requires traffic policing might for example apply it
different subflows in a hierarchically-encoded signal, by at the edge of the network and at data merge points; RSVP knows
selecting on fields in an application-layer header. However, when these occur and must so indicate to the traffic control
considerations of both architectural purity and practical mechanism. On the other hand, RSVP cannot interpret the service
requirements have led to the decision that RSVP should use embodied in the flowspec and therefore does not know whether
separate sessions for distinct subflows of hierarchically-encoded policing will actually be applied in a particular case.
signals. For multicast sessions, subflows can be distinguished by
multicast destination address; for unicast sessions, they must be
distinguished by destination port. As a result of these
considerations, the present RSVP version includes a quite
restricted definition of filter specs, selecting only on sender IP
address and UDP/TCP port number, and on protocol id. However, the
design of the protocol would easily handle a more general
definition in future versions.
Any packets that are addressed to a particular session but do not In the general RSVP reservation model [RSVP93], filter specs may
match any of the filter specs for that session will be sent as select arbitrary subsets of the packets in a given session. Such
best-effort traffic. Under congested conditions, such packets are subsets might be defined in terms of senders (i.e., sender IP
likely to experience long delays and may be dropped. A receiver address and generalized source port), in terms of a higher-level
may wish to conserve network resources by explicitly asking the protocol, or generally in terms of any fields in any protocol
network to drop those data packets for which there is no headers in the packet. For example, filter specs might be used to
reservation; however, such dropping should be performed by select different subflows in a hierarchically-encoded signal by
routing, not by RSVP. Determining where packets get delivered selecting on fields in an application-layer header. However, in
should be a routing function; RSVP is concerned only with the QoS the interest of simplicity (and to minimize layer violation), the
of those packets that are delivered by routing. present RSVP version uses a much more restricted form of filter
spec: select only on sender IP address, on UDP/TCP port number,
and perhaps on IP protocol id.
RSVP can distinguish subflows of a hierarchically-encoded signal
if they are assigned distinct multicast destination addresses, or,
for a unicast destination, distinct destination ports. Data
packets that are addressed to a particular session but do not
match any of the filter specs for that session are expected to be
sent as best-effort traffic, and under congested conditions, such
packets are likely to experience long delays, and they may be
dropped. When a receiver does not wish to receive a particular
(sub-)flow, it can economize on network resources by explicitly
asking the network to drop unneeded the data packets; it does so
by leaving the multicast group(s) to which these packets are
addressed. Thus, determining where packets get delivered should
be a routing function; RSVP is concerned only with the QoS of
those packets that are delivered by routing.
RSVP reservation request messages originate at receivers and are RSVP reservation request messages originate at receivers and are
passed upstream towards the sender(s). (Note that this document passed upstream towards the sender(s). (This document defines the
always uses the directional terms "upstream" vs. "downstream", directional terms "upstream" vs. "downstream", "previous hop" vs.
"previous hop" vs. "next hop", and "incoming interface" vs "next hop", and "incoming interface" vs "outgoing interface" with
"outgoing interface" with respect to the data flow direction). respect to the data flow direction.) When an elementary
When an elementary reservation request is received at a node, the reservation request is received at a node, the RSVP daemon takes
RSVP daemon takes two primary actions. two primary actions:
1. Make a reservation 1. Daemon makes a reservation
The flowspec and the filter spec are passed to traffic The flowspec and the filter spec are passed to traffic
control. Admission Control determines the admissibility of control. Admission control determines the admissibility of
the request (if it's new); if it fails this test, the the request (if it's new); if this test fails, the
reservation is rejected and RSVP sends back an error message reservation is rejected and RSVP returns an error message to
towards the responsible receiver(s). If it passes, the the appropriate receiver(s). If admission control succeeds,
flowspec is used to set up the packet scheduler for the the node uses the flowspec to set up the packet scheduler for
desired QoS and the filter spec is used to set the packet the desired QoS and the filter spec to set the packet
classifier to select the appropriate data packets. classifier to select the appropriate data packets.
2. Forward reservation upstream. 2. Daemon forwards the reservation upstream
The reservation request is propagated upstream towards the The reservation request is propagated upstream towards the
appropriate senders. The set of senders to which a given appropriate senders. The set of sender hosts to which a
reservation request is propagated is called the "scope" of given reservation request is propagated is called the "scope"
that request. of that request.
The reservation request that a node forwards upstream may differ The reservation request that a node forwards upstream may differ
from the request that it received, for two reasons. First, it is from the request that it received, for two reasons. First, it is
possible (at least in theory) for the kernel to modify the possible (in theory) for the kernel to modify the flowspec hop-
flowspec hop-by-hop (although currently no realtime services do by-hop, although currently no realtime services do this. Second,
this). Second, reservations from different downstream branches of reservations from different downstream branches of the multicast
the multicast distribution tree(s) must be "merged" as distribution tree(s) must be "merged" as reservations travel
reservations travel upstream. Merging reservations is a necessary upstream. Merging reservations is a necessary consequence of
consequence of multicast distribution, which creates a single multicast distribution, which creates a single stream of data
stream of data packets in a particular router from any Si, packets in a particular router from any Si, regardless of the set
regardless of the set of receivers downstream. The reservation of receivers downstream. The reservation for Si on a particular
for Si on a particular outgoing link L should be the "maximum" of outgoing link L should be the "maximum" of the individual
the individual flowspecs from the receivers Rj that are downstream flowspecs from the receivers Rj that are downstream via link L.
via link L. Merging is discussed further in Section 2.3. Merging is discussed further in Section 2.2.
For both of these primary actions, there are options controlled by
the receiver making the reservation. These options are combined
into a control variable called the reservation "style", which is
discussed in section 1.3. One option concerns the treatment of
reservations for different senders within the same session:
establish a "distinct" reservation for each upstream sender, or
else "mix" all senders' packets into a single reservation.
Another option controls the scope of the request: "unitary" (i.e.,
a single specified sender), an explicit sender list, or a
"wildcard" that implicitly selects all senders upstream of the
given node.
The basic RSVP reservation model is "one pass": a receiver sends a The basic RSVP reservation model is "one pass": a receiver sends a
reservation request upstream, and each node in the path can only reservation request upstream, and each node in the path can only
accept or reject the request. This scheme provides no way to make accept or reject the request. This scheme provides no way to make
end-to-end service guarantees; the QoS request is applied end-to-end service guarantees, since the QoS request must be
independently at each hop. RSVP also supports an optional applied independently at each hop. RSVP also supports an optional
reservation model, known as " One Pass With Advertising" (OPWA) reservation model, known as " One Pass With Advertising" (OPWA)
[Shenker94]. In OPWA, RSVP control packets sent downstream, [Shenker94]. In OPWA, RSVP control packets sent downstream,
following the data paths, are used to gather information on the following the data paths, are used to gather information on the
end-to-end service that would result from a variety of possible end-to-end service that would result from a variety of possible
reservation requests. The results ("advertisements") are reservation requests. The results ("advertisements") are
delivered by RSVP to the receiver host, and perhaps to the delivered by RSVP to the receiver host, and perhaps to the
receiver application. The information may then be used by the receiver application. The information may then be used by the
receiver to construct an appropriate reservation request. receiver to construct an appropriate reservation request.
1.3 Reservation Styles 1.3 Reservation Styles
Each RSVP reservation request specifies a "reservation style". A reservation request includes a set of control options. One
The following reservation styles are defined in this version of option concerns the treatment of reservations for different
the protocol. senders within the same session: establish a "distinct"
reservation for each upstream sender, or else make a single
reservation that is "shared" all senders' packets. A distinct
reservation requires that the filter spec match exactly one
sender, a wildcard reservation must match at least one. Another
option controls the scope of the request: an " explicit" sender
specification, or a "wildcard" that implicitly selects all sender
hosts upstream of the given node.
These control options are collectively called the reservation
"style", as shown in Figure 3.
|| Reservations:
Scope || Distinct | Shared
_________||__________________|____________________
|| | |
Explicit || Fixed-Filter | Shared-Explicit |
|| (FF) style | (SE) Style |
__________||__________________|____________________|
|| | |
Wildcard || (None defined) | Wildcard-Filter |
|| | (WF) Style |
__________||__________________|____________________|
Figure 3: Reservation Attributes and Styles
The styles currently defined are as follows:
1. Wildcard-Filter (WF) Style 1. Wildcard-Filter (WF) Style
The WF style specifies the options: "mixing" reservation and The WF style implies the options: "shared" reservation and "
" wildcard" reservation scope. Thus, a WF-style reservation wildcard" reservation scope. Thus, a WF-style reservation
creates a single reservation into which flows from all creates a single reservation into which flows from all
upstream senders are mixed. This reservation may be thought upstream senders are mixed; this reservation may be thought
of a shared "pipe", whose "size" is the largest of the of as a shared "pipe", whose "size" is the largest of the
resource requests for that link from all receivers, resource requests for that link from all receivers,
independent of the number of senders using it. A WF-style independent of the number of senders using it. A WF-style
reservation has wildcard scope, i.e., the reservation is reservation has wildcard scope, i.e., the reservation is
propagated upstream towards all senders. A WF-style propagated upstream towards all sender hosts. A WF-style
reservation automatically extends to new senders to the reservation automatically extends to new senders as they
session as they appear. appear.
2. Fixed-Filter (FF) Style 2. Fixed-Filter (FF) Style
The FF style specifies the options: "distinct" reservation The FF style implies the options: "distinct" reservations and
and a "unitary" reservation scope. Thus, an elementary FF- "explicit" reservation scope. Thus, an elementary FF-style
style reservation request creates a distinct reservation for reservation request creates a distinct reservation for data
data packets from a particular sender, not mixing them with packets from a particular sender, not sharing them with other
other senders' packets for the same session. senders' packets for the same session. It scope is
determined by an explicit list of senders.
The total reservation on a link for a given session is the The total reservation on a link for a given session is the
total of the FF reservations for all requested senders. On total of the FF reservations for all requested senders. On
the other hand, FF reservations requested by different the other hand, FF reservations requested by different
receivers Rj but selecting the same sender Si must receivers Rj but selecting the same sender Si must
necessarily be merged to share a single reservation in a necessarily be merged to share a single reservation in a
given node. given node.
WF reservations are appropriate for those multicast applications 3. Shared Explicit (SE) Style
whose application-specific constraints make it unlikely that
multiple data sources will transmit simultaneously. One example is
audio conferencing, where a limited number of people talk at once;
each receiver might issue a WF reservation request for twice one
audio channel (to allow some over-speaking). On the other hand,
the FF style, which creates independent reservations for the flows
from different senders, is appropriate for video signals.
The WF and FF styles are incompatible and cannot be combined The SE style implies the options: "shared" reservation and "
within a session. Other reservation styles may be defined in the explicit" reservation scope. Thus, an SE-style reservation
future (see Appendix C). creates a single reservation into which flows from all
upstream senders are mixed. However, like a FF reservation
the set of senders (and therefore its scope (and therefore
the scope) is specified explicitly by the receiver making the
reservation.
WF and SE are both shared reservations, appropriate for those
multicast applications whose application-specific constraints make
it unlikely that multiple data sources will transmit
simultaneously. One example is audio conferencing, where a limited
number of people talk at once; each receiver might issue a WF or
SE reservation request for twice one audio channel (to allow some
over-speaking). On the other hand, the FF style, which creates
independent reservations for the flows from different senders, is
appropriate for video signals.
It is not possible to merge shared reservations with distinct
reservations. Therefore, WF and SE styles are incompatible with
FF, but are compatible with each other. Merging a WF style
reservation with an SE style reservation results in a WF
reservation.
Other reservation options and styles may be defined in the future
(see Appendix D.4, for example).
2. RSVP Protocol Mechanisms 2. RSVP Protocol Mechanisms
2.1 RSVP Messages 2.1 RSVP Messages
There are two fundamental RSVP message types, RESV messages and There are two fundamental RSVP message types: RESV and PATH .
PATH messages.
Each receiver host sends RSVP reservation request (RESV) messages Each receiver host sends RSVP reservation request (RESV) messages
towards the senders. These reservation messages must follow in towards the senders. These reservation messages must follow in
reverse the routes the data packets will use, all the way upstream reverse the routes the data packets will use, all the way upstream
to the senders within the scope. RESV messages are delivered to to the sender hosts included in the scope. RESV messages must be
the sender hosts, so that the hosts can set up appropriate traffic delivered to the sender hosts so that the hosts can set up
control parameters for the first hop. If a reservation request appropriate traffic control parameters for the first hop.
fails at any node, an RSVP error message is returned to the
receiver; however, RSVP sends no positive acknowledgment messages
to indicate success.
Also note that RSVP sends no positive acknowledgment messages to
indicate success (although the delivery of a reservation request
to a sender could be used to trigger an acknowledgement at a
higher level of protocol.)
Sender Receiver Sender Receiver
_____________________ _____________________
Path --> ( ) Path --> ( )
Si =======> ( Multicast ) Path --> Si =======> ( Multicast ) Path -->
<-- Resv ( ) =========> Rj <-- Resv ( ) =========> Rj
( distribution ) <-- Resv ( distribution ) <-- Resv
(_____________________) (_____________________)
Figure 3: RSVP Messages Figure 4: RSVP Messages
Each sender transmits RSVP PATH messages forward along the uni- Each sender transmits RSVP PATH messages forward along the uni-
/multicast routes provided by the routing protocol(s); see Figure /multicast routes provided by the routing protocol(s); see Figure
3. These "Path" messages store path state in each node. Path 4. These "Path" messages store path state in each node. Path
state is used by RSVP to route the RESV messages hop-by-hop in the state is used by RSVP to route the RESV messages hop-by-hop in the
reverse direction. (In the future, some routing protocols may reverse direction. (In the future, some routing protocols may
supply reverse path forwarding information directly, without path supply reverse path forwarding information directly, replacing the
state). reverse-routing function of path state).
PATH messages may also carry the following information: PATH messages may also carry the following information:
o Sender Template o Sender Template
The Sender Template describes the format of data packets that The Sender Template describes the format of data packets that
the sender will originate. This template is in the form of a the sender will originate. This template is in the form of a
filter spec that could be used to select this sender's filter spec that could be used to select this sender's
packets from others in the same session on the same link. packets from others in the same session on the same link.
Like a filter spec, the Sender Template is less than fully
general at present, specifying only sender IP address,
UDP/TCP sender port, and protocol id. The port number
and/or protocol id can be wildcarded.
o Tspec o Tspec
The PATH message may optionally carry a flowspec containing PATH message may optionally carry a Tspec that defines an
only a Tspec, defining an upper bound on the traffic level upper bound on the traffic level that the sender will
that the sender will generate. This Tspec can be used by generate. This Tspec can be used by RSVP to prevent over-
RSVP to prevent over-reservation (and perhaps unnecessary reservation (and perhaps unnecessary Admission Control
Admission Control failure) on the non-shared links starting failure) on the non-shared links starting at the sender.
at the sender.
o Adspec o Adspec
The PATH message may carry a package of OPWA advertising The PATH message may carry a package of OPWA advertising
information, known as an "Adspec". information, known as an "Adspec". An Adspec received in a
PATH message is passed to the local traffic control routines,
which return an updated Adspec; the updated version is
forwarded downstream.
Previous Incoming Outgoing Next Previous Incoming Outgoing Next
Hops Interfaces Interfaces Hops Hops Interfaces Interfaces Hops
_____ _____________________ _____ _____ _____________________ _____
| | data --> | | data --> | | | | data --> | | data --> | |
| A |-----------| a c |--------------| C | | A |-----------| a c |--------------| C |
|_____| <-- Resv | | <-- Resv |_____| |_____| <-- Resv | | <-- Resv |_____|
Path --> | | Path --> _____ Path --> | | Path --> _____
_____ | ROUTER | | | | _____ | ROUTER | | | |
| | | | | |--| D | | | | | | |--| D |
| B |--| data-->| | data --> | |_____| | B |--| data-->| | data --> | |_____|
|_____| |--------| b d |-----------| |_____| |--------| b d |-----------|
|<-- Resv| | <-- Resv | _____ |<-- Resv| | <-- Resv | _____
_____ | Path-->|_____________________| Path --> | | | _____ | Path-->|_____________________| Path --> | | |
| | | |--| D' | | | | |--| D' |
| B' |--| | |_____| | B' |--| | |_____|
|_____| | | |_____| | |
Figure 4: Router Using RSVP Figure 5: Router Using RSVP
Figure 4 illustrates RSVP's model of a router node. Each data Figure 5 illustrates RSVP's model of a router node. Each data
stream arrives from a previous hop through a corresponding stream arrives from a previous hop through a corresponding
incoming interface and departs through one or more outgoing incoming interface and departs through one or more outgoing
interface(s). The same physical interface may act in both the interface(s). The same physical interface may act in both the
incoming and outgoing roles (for different data flows but the same incoming and outgoing roles (for different data flows but the same
session). session).
As illustrated in Figure 4, there may be multiple previous hops As illustrated in Figure 5, there may be multiple previous hops
and/or next hops through a given physical interface. This may and/or next hops through a given physical interface. This may
result from the connected network being a shared medium or from result from the connected network being a shared medium or from
the existence of non-RSVP routers in the path to the next RSVP hop the existence of non-RSVP routers in the path to the next RSVP hop
(see Section 2.6). An RSVP daemon must preserve the next and (see Section 2.6). An RSVP daemon must preserve the next and
previous hop addresses in its reservation and path state, previous hop addresses in its reservation and path state,
respectively. A RESV message is sent with a unicast destination respectively. A RESV message is sent with a unicast destination
address, the address of a previous hop. PATH messages, on the address, the address of a previous hop. PATH messages, on the
other hand, are sent with the session destination address, unicast other hand, are sent with the session destination address, unicast
or multicast. or multicast.
Although multiple next hops may send reservation requests through Although multiple next hops may send reservation requests through
the same physical interface, the final effect should be to install the same physical interface, the final effect should be to install
a reservation on that interface, which is defined by an effective a reservation on that interface, which is defined by an effective
flowspec. This effective flowspec will be the "maximum" of the flowspec. This effective flowspec will be the "maximum" of the
flowspecs requested by the different next hops. In turn, a RESV flowspecs requested by the different next hops. In turn, a RESV
message forwarded to a particular previous hop carries a flowspec message forwarded to a particular previous hop carries a flowspec
that is the "maximum" over the effective reservations on the that is the "maximum" over the effective reservations on the
corresponding outgoing interfaces. Both cases represent merging, corresponding outgoing interfaces. Both cases represent merging,
which is discussed further below. which is discussed further below.
There are a number of ways for a new reservation request to fail There are a number of ways for a new or modified reservation
in a given node. request to fail in a given node:
1. There may be no matching path state (i.e., the scope may 1. The effective flowspec, computed using the new request, may
fail admission control.
2. Administrative policy or control may prevent the requested
reservation.
3. There may be no matching path state (i.e., the scope may be
empty), which would prevent the reservation being propagated empty), which would prevent the reservation being propagated
upstream. upstream.
2. Its style may be incompatible with the style(s) of existing 4. A reservation style that requires a unique sender may have a
reservations for the same session on the same outgoing filter spece that matches more than one sender in the path
interface, so an effective flowspec cannot be computed. state, due to the use of wildcards.
3. Its style may be incompatible with the style(s) of 5. The requested style may be incompatible with the style(s) of
reservations that exist on other outgoing interfaces but will existing reservations for the same session on the same
be merged with this reservation when a refresh message to outgoing interface, so an effective flowspec cannot be
create a refresh message for the previous hop. computed.
4. The effective flowspec may fail admission control. 6. The requested style may be incompatible with the style(s) of
reservations that exist on other outgoing interfaces but will
be merged with this reservation to create a refresh message
for the previous hop.
In any of these cases, an error message is returned to the In any of these cases, an error message is returned to the
receiver(s) responsible for the message, but any existing receiver(s) responsible for the erroneous message, which may or
reservation is left in place. This prevents a new, very large, may not be propagated forward along the path. An error message
reservation from disrupting the existing QoS by merging with an does not modify state in the nodes through which it passes.
existing reservation and then failing admission control. Therefore, any reservations established downstream of the node
where the failure was detected will persist until the receiver(s)
responsible cease attempting the reservation.
2.2 Soft State In general, if the error is likely to be repeated at every node
further along the path, it is best to drop the errneous message
rather than generate a flood of error messages; this is the case
for the last four error classes listed above. The first two error
classes, admission control and administrative policy, may or may
not allow propagation of the message, depending upon the detailed
reason and perhaps on local administrative policy and/or the
particular service request. More complete rules are given in the
error definitions in Appendix B.
An erroneous FILTER_SPEC object in a RESV message will normally be
detected at the first RSVP hop from the receiver application,
i.e., within the receiver host. However, an admission control
failure caused by a FLOWSPEC or a POLICY_DATA object may be
detected anywhere along the path(s) to the sender(s).
When admission control fails for a reservation request, any
existing reservation is left in place. This prevents a new, very
large, reservation from disrupting the existing QoS by merging
with an existing reservation and then failing admission control
(this has been called the "killer reservation" problem).
A node may be allowed to preempt an established reservation, in
accordance with administrative policy; this will also trigger an
error message to all affected receivers.
2.2 Merging and Packing
A previous section explained that reservation requests in RESV
messages are necessarily merged, to match the multicast
distribution tree. As a result, only the essential (i.e., the
"largest") reservation requests are forwarded, once per refresh
period. A successful reservation request will propagate as far as
the closest point(s) along the sink tree to the sender(s) where a
reservation level equal or greater than that being requested has
been made. At that point, the merging process will drop it in
favor of another, equal or larger, reservation request.
For protocol efficiency, RSVP also allows multiple sets of path
(or reservation) information for the same session to be "packed"
into a single PATH (or RESV) message, respectively. (For
simplicity, the protocol currently prohibits packing different
sessions into the same RSVP message). Unlike merging, packing
preserves information.
In order to merge reservations, RSVP must be able to merge
flowspecs and to merge filterspecs. Merging flowspecs requires
calculating the the "largest" of a set of flowspecs, which are
otherwise opaque to RSVP. Merging flowspecs is required both to
calculate the effective flowspec to install on a given physical
interface (see the discussion in connection with Figure 5), and to
merge flowspecs when sending a refresh message upstream. Since
flowspecs are generally multi-dimensional vectors (they contain
both Tspec and Rspec components, each of which may itself be
multi-dimensional), they are not strictly ordered. When it cannot
take the larger of two flowspecs, RSVP must compute and use a
third flowspec that is at least as large as each, i.e., a "least
upper bound" (LUB). It is also possible for two flowspecs to be
incomparable, which is treated as an error. The definition and
implementation of the rules for comparing flowspecs are outside
RSVP proper, but they are defined as part of the service templates
[ServTempl95a]
We can now give the complete rules for calculating the effective
flowspec (Te, Re), to be installed on an interface. Here Te is
the effective Tspec and Re is the effective Rspec. As an example,
consider interface (d) in Figure 5.
o Re is calculated as the largest (using an LUB if necessary)
of the Rspecs in RESV messages from different next hops
(e.g., D and D') but the same outgoing interface (d).
o The Tspecs supplied in PATH messages from different previous
hops which may send data packets to this reservation (e.g.,
some or all of A, B, and B' in Figure 5) are summed; call
this sum Path_Te.
o The maximum Tspec supplied in RESV messages from different
next hops (e.g., D and D') is calculated; call this Resv_Te.
o Te is the GLB (greatest lower bound) of Path_Te and Resv_Te.
For Tspecs defined by token bucket parameters, this means to
take the smaller of the bucket size and the rate parameters.
Two filter specs can be merged only they are identical or if one
contains the other through wild-carding. The result is the more
general of the two, i.e., the one with more wildcard fields.
2.3 Soft State
To maintain reservation state, RSVP keeps "soft state" in router To maintain reservation state, RSVP keeps "soft state" in router
and host nodes. RSVP soft state is created and periodically and host nodes. RSVP soft state is created and periodically
refreshed by PATH and RESV messages. The state is deleted if no refreshed by PATH and RESV messages. The state is deleted if no
refreshes arrive before the expiration of a "cleanup timeout" refreshes arrive before the expiration of a "cleanup timeout"
interval; it may also be deleted as the result of an explicit interval; it may also be deleted as the result of an explicit
"Teardown" message. It is not necessary (although it may be "teardown" message.
desirable, since the resources being consumed may be "valuable"),
to explicitly tear down an old reservation.
When a route changes, the next PATH message will initialize the When a route changes, the next PATH message will initialize the
path state on the new route, and future RESV messages will path state on the new route, and future RESV messages will
establish reservation state, while the state on the now-unused establish reservation state; the state on the now-unused segment
segment of the route will time out. Thus, whether a message is of the route will time out. Thus, whether a message is "new" or a
"new" or a "refresh" is determined separately at each node, "refresh" is determined separately at each node, depending upon
depending upon the existence of state at that node. (This the existence of state at that node. (This document uses the term
document uses the term "refresh message" in this effective sense, "refresh message" in this effective sense, to indicate an RSVP
to indicate an RSVP message that does not modify the existing message that does not modify the existing state at the node in
state at the node in question.) question.)
In addition to the cleanup timeout, there is a "refresh timeout" In addition to the cleanup timeout, there is a "refresh timeout"
period. As messages arrive, the RSVP daemon checks them against period. As messages arrive, the RSVP daemon checks them against
the existing state; if it matches, the cleanup timeout timer on the existing state; if it matches, the cleanup timeout timer on
the state is reset and the message is dropped. At the expiration the state is reset and the message is dropped. At the expiration
of each refresh timeout period, RSVP scans its state to build and of each refresh timeout period, RSVP scans its state to build and
forward PATH and RESV refresh messages to succeeding hops. forward PATH and RESV messages to succeeding hops.
RSVP sends its messages as IP datagrams without reliability RSVP sends its messages as IP datagrams without reliability
enhancement. Periodic transmission of refresh messages by hosts enhancement. Periodic transmission of refresh messages by hosts
and routers is expected to replace any lost RSVP messages. To and routers is expected to replace any lost RSVP messages. To
tolerate K successive packet losses, the effective cleanup timeout tolerate K-1 successive packet losses, the effective cleanup
must be at least K times the refresh timeout. In addition, the timeout must be at least K times the refresh timeout. In
traffic control mechanism in the network should be statically addition, the traffic control mechanism in the network should be
configured to grant high-reliability service to RSVP messages, to statically configured to grant high-reliability service to RSVP
protect RSVP messages from congestion losses. messages, to protect RSVP messages from congestion losses.
In steady state, refreshing is performed hop-by-hop, which allows In steady state, refreshing is performed hop-by-hop, which allows
merging and packing as described in the next section. However, if merging and packing as described in the previous section. If the
the received state differs from the stored state, the stored state received state differs from the stored state, the stored state is
is updated. Furthermore, if the result will be to modify the updated. Furthermore, if the result will be to modify the refresh
refresh messages to be generated, these refresh messages must be messages to be generated, these refresh messages must be generated
generated and forwarded immediately. This will result in changes and forwarded immediately. This will result in state changes
propagating end-to-end without delay. However, propagation of a propagating end-to-end without delay. However, propagation of a
change stops when and if it reaches a point where merging causes change stops when and if it reaches a point where merging causes
no resulting state change; this minimizes RSVP control traffic due no resulting state change. This minimizes RSVP control traffic
to changes, and is essential for scaling to large multicast due to changes and is essential for scaling to large multicast
groups. groups.
The "soft" router state maintained by RSVP is dynamic; to change The "soft" router state maintained by RSVP is dynamic; to change
the set of senders Si or receivers Rj or to change any QoS the set of senders Si or receivers Rj or to change any QoS
request, a host simply starts sending revised PATH and/or RESV request, a host simply starts sending revised PATH and/or RESV
messages. The result should be the appropriate adjustment in the messages. The result should be an appropriate adjustment in the
distributed RSVP state, and immediate propagation to the RSVP state and immediate propagation to all nodes along the path.
succeeding nodes.
The RSVP state associated with a session in a particular node is The RSVP state associated with a session in a particular node is
divided into atomic elements that are created, refreshed, and divided into atomic elements that are created, refreshed, and
timed out independently. The atomicity is determined by the timed out independently. The atomicity is determined by the
requirement that any sender or receiver may enter or leave the requirement that any sender or receiver may enter or leave the
session at any time, and its state should be created and timed out session at any time, so its state should be created and timed out
independently. Management of RSVP state is complex because there independently.
may not be a one-to-one correspondence between state carried in
RSVP control messages and the resulting state in nodes. Due to
merging, a single message contain state referring to multiple
stored elements. Conversely, due to reservation sharing, a single
stored state element may depend upon (typically, the maximum of)
state values received in multiple control messages.
2.3 Merging and Packing
A previous section explained that reservation requests in RESV
messages are necessarily merged, to match the multicast
distribution tree. As a result, only the essential (i.e., the
"largest") reservation requests are forwarded, once per refresh
period. A successful reservation request will propagate as far as
the closest point(s) along the sink tree to the sender(s) where a
reservation level equal or greater than that being requested has
been made. At that point, the merging process will drop it in
favor of another, equal or larger, reservation request.
Although flowspecs are opaque to RSVP, an RSVP daemon must be able
to calculate the "largest" of a set of flowspecs. This is
required both to calculate the effective flowspec to install on a
given physical interface (see the discussion in connection with
Figure 4), and to merge flowspecs when sending a refresh message
upstream. Since flowspecs are generally multi-dimensional vectors
(they contain both Tspec and Rspec components, each of which may
itself be multi-dimensional), they are not strictly ordered. When
it cannot take the larger of two flowspecs, RSVP must compute and
use a third flowspec that is at least as large as each, i.e., a
"least upper bound" (LUB). It is also possible for two flowspecs
to be incomparable, which is treated as an error. The definition
and implementation of the rules for comparing flowspecs are
outside RSVP proper, but they are defined as part of the service
templates.
For protocol efficiency, RSVP also allows multiple sets of path
(or reservation) information for the same session to be "packed"
into a single PATH (or RESV) message, respectively. (For
simplicity, the protocol prohibits packing different sessions into
the same RSVP message).
2.4 Teardown 2.4 Teardown
RSVP teardown messages remove path and reservation state without RSVP teardown messages remove path and reservation state without
waiting for the cleanup timeout period, as an optimization to waiting for the cleanup timeout period, as an optimization to
release resources quickly. Although teardown messages (like other release resources quickly. It is not necessary (although it may
RSVP messages) are not delivered reliably, the state will time out be desirable, since the resources being consumed may be
even if it is not explicitly deleted. "valuable"), to explicitly tear down an old reservation.
A teardown request may be initiated either by an application in an A teardown request may be initiated either by an application in an
end system (sender or receiver), or by a router as the result of end system (sender or receiver), or by a router as the result of
state timeout. A router may also initiate a teardown message as state timeout. Once initiated, a teardown request should be
the result of router or link failures detected by the routing forwarded hop-by-hop without delay.
protocol. Once initiated, a teardown request should be forwarded
hop-by-hop without delay.
To increase the reliability of teardown, Q copies of any given Teardown messages (like other RSVP messages) are not delivered
teardown message can be sent. Note that a node cannot actually reliably. However, loss of a teardown message is not considered a
delete the state being torn down until it has sent Q Teardown problem because the state will time out even if it is not
messages; it must place the state in a "moribund" status explicitly deleted. If one or more teardown message hops are
meanwhile. The appropriate value of Q is an engineering issue. Q lost, the router that failed to receive a teardown message will
= 1 would be the simplest and may be adequate, since unrefreshed time out its state and initiate a new teardown message beyond the
state will time out anyway; teardown is an optimization. If one loss point. Assuming that RSVP message loss probability is small,
or more Teardown message hops are lost, the router that failed to the longest time to delete state will seldom exceed one refresh
receive a Teardown message will time out its state and initiate a timeout period.
new Teardown message beyond the loss point. Assuming that RSVP
message loss probability is small, the longest time to delete
state will seldom exceed one refresh timeout period.
There are two types of RSVP Teardown message, PTEAR and RTEAR. A There are two types of RSVP teardown message, PTEAR and RTEAR. A
PTEAR message travels towards all receivers downstream from its PTEAR message travels towards all receivers downstream from its
point of initiation and tears down path state along the way. A point of initiation and deletes path state along the way. A RTEAR
RTEAR message tears down reservation state and travels towards all message deletes reservation state and travels towards all senders
senders upstream from its point of initiation. A PTEAR (RTEAR) upstream from its point of initiation. A PTEAR (RTEAR) message
message may be conceptualized as a reversed-sense Path message may be conceptualized as a reversed-sense Path message (Resv
(Resv message, respectively). message, respectively).
A teardown message deletes the specified state in the node where A teardown message deletes the specified state in the node where
it is received. Like any other state change, this will be it is received. Like any other state change, this will be
propagated immediately to the next node, but only if it represents propagated immediately to the next node, but only if it represents
a change. As a result, an RTEAR message will prune the a net change after merging. As a result, an RTEAR message will
reservation state back (only) as far as possible. Note that the prune the reservation state back (only) as far as possible.
RTEAR message will cease to be forwarded at the same node where
merging suppresses forwarding of the corresponding RESV messages.
The change will be propagated as a new teardown message if the
result has been to remove all state for this session at this node.
However, the result may simply be to change the propagated
information; thus, the receipt of a RTEAR message may result in
the immediate forwarding of a modified RESV refresh message.
Deletion of path state, whether as the result of a teardown
message or because of timeout, may force adjustments in order in
related reservation state to maintain consistency in the local
node. For example, when a PTEAR deletes the path state for a
sender S, the adjustment in reservation depends upon the style: if
the style is WF and S is the only sender to the session, delete
the reservation; if the style is FF, delete only reservations for
sender S. These reservation changes should not trigger an
immediate RESV refresh message, since the teardown message will
have already made the required changes upstream. However, at the
node in which an RTEAR message stops, the change of reservation
state may trigger a RESV refresh starting at that node.
2.5 Security
There are two distinct types of security concerns in RSVP. 2.5 Admission Policy and Security
1. Protecting RSVP Message Integrity RSVP-mediated QoS requests will result in particular user(s)
getting preferential access to network resources. To prevent
abuse, some form of back pressure on users will be required. This
back pressure might take the form of administrative rules, or of
some form of real or virtual billing for the `cost' of a
reservation. The form and contents of such back pressure is a
matter of administrative policy that may be determined
independently by each administrative domain in the Internet.
It may be necessary to ensure the integrity of RSVP messages Therefore, admission control at each node is likely to contain a
against corruption or spoofing, hop by hop. RSVP messages policy component as well as a resource reservation component. As
have an optional integrity field that can be created and input to the policy-based admission decision, RSVP messages may
verified by neighboring RSVP nodes. carry policy data. This data may include credentials identifying
users or user classes, account numbers, limits, quotas, etc.
2. Authenticating Reservation Requests To protect the integrity of the policy-based admission control
mechanisms, it may be necessary to ensure the integrity of RSVP
messages against corruption or spoofing, hop by hop. For this
purpose, RSVP messages may carry integrity objects that can be
created and verified by neighboring RSVP-capable nodes. These
objects are expected to contain an encrypted part and to assume a
shared secret between neighbors.
RSVP-mediated resource reservations may reserve network User policy data in reservation request messages presents a
resources, providing special treatment for a particular set scaling problem. When a multicast group has a large number of
of users. Administrative mechanisms will be necessary to receivers, it will not be possible or desirable to carry all the
control who gets privileged service and to collect billing receivers' policy data upstream to the sender(s). The policy data
information. These mechanisms may require secure will have to be administratively merged, near enough to the
authentication of senders and/or receivers responsible for receivers to avoid excessive policy data. Administrative merging
the reservation. RSVP messages may contain credential implies checking the user credentials and accounting data and then
information to verify user identity. substituting a token indicating the check has succeeded. A chain
of trust established using an integrity field will allow upstream
nodes to accept these tokens.
The RSVP packet formats provide for both; see Section 4. Note that the merge points for policy data are likely to be at the
boundaries of administrative domains. It may be necessary to
carry accumulated and unmerged policy data upstream through
multiple nodes before reaching one of these merge points.
2.6 Automatic RSVP Tunneling 2.6 Automatic RSVP Tunneling
It is impossible to deploy RSVP (or any new protocol) at the same It is impossible to deploy RSVP (or any new protocol) at the same
moment throughout the entire Internet. Furthermore, RSVP may moment throughout the entire Internet. Furthermore, RSVP may
never be deployed everywhere. RSVP must therefore provide correct never be deployed everywhere. RSVP must therefore provide correct
protocol operation even when two RSVP-capable routers are joined protocol operation even when two RSVP-capable routers are joined
by an arbitrary "cloud" of non-RSVP routers. Of course, an by an arbitrary "cloud" of non-RSVP routers. Of course, an
intermediate cloud that does not support RSVP is unable to perform intermediate cloud that does not support RSVP is unable to perform
resource reservation, so service guarantees cannot be made. resource reservation, so service guarantees cannot be made.
However, if there is sufficient excess capacity through such a However, if such a cloud has sufficient excess capacity, it may
cloud, acceptable and useful realtime service may still be provide acceptable and useful realtime service.
possible.
RSVP will automatically tunnel through such a non-RSVP cloud. RSVP will automatically tunnel through such a non-RSVP cloud.
Both RSVP and non-RSVP routers forward PATH messages towards the Both RSVP and non-RSVP routers forward PATH messages towards the
destination address using their local uni-/multicast routing destination address using their local uni-/multicast routing
table. Therefore, the routing of Path messages will be table. Therefore, the routing of PATH messages will be unaffected
unaffected by non-RSVP routers in the path. When a PATH message by non-RSVP routers in the path. When a PATH message traverses a
traverses a non-RSVP cloud, the copies that emerge will carry as a non-RSVP cloud, the copies that emerge will carry as a Previous
Previous Hop address the IP address of the last RSVP-capable Hop address the IP address of the last RSVP-capable router before
router before entering the cloud. This will effectively construct entering the cloud. This will effectively construct a tunnel
a tunnel through the cloud for RESV messages, which will be through the cloud for RESV messages, which will be forwarded
forwarded directly to the next RSVP-capable router on the path(s) directly to the next RSVP-capable router on the path(s) back
back towards the source. towards the source.
Automatic tunneling is not perfect; in some circumstances it may Automatic tunneling is not perfect; in some circumstances it may
distribute path information to RSVP-capable routers not included distribute path information to RSVP-capable routers not included
in the data distribution paths, which may create unused in the data distribution paths, which may create unused
reservations at these routers. This is because PATH messages reservations at these routers. This is because PATH messages
carry the IP source address of the previous hop, not of the carry the IP source address of the previous hop, not of the
original sender, and multicast routing may depend upon the source original sender, and multicast routing may depend upon the source
as well as the destination address. This can be overcome by as well as the destination address. This can be overcome by
manual configuration of the neighboring RSVP programs, when manual configuration of the neighboring RSVP programs, when
necessary. necessary.
2.7 Session Groups 2.7 Host Model
Section 1.2 explained that a distinct destination address, and
therefore a distinct session, will be used for each of the
subflows in a hierarchically encoded flow. However, these
separate sessions are logically related. For example it may be
necessary to pass reservations for all subflows to Admission
Control at the same time (since it would be nonsense to admit high
frequency components but reject the baseband component of the
session data). Such a logical grouping is indicated in RSVP by
defining a "session group", an ordered set of sessions.
To declare that a set of sessions form a session group, a receiver
includes a data structure we call a SESSION_GROUP object in the
RESV message for each of the sessions. A SESSION_GROUP object
contains four fields: a reference address, a session group ID, a
count, and a rank.
o The reference address is an agreed-upon choice from among the
DestAddress values of the sessions in the group, for example
the smallest numerically.
o The session group ID is used to distinguish different groups
with the same reference address.
o The count is the number of members in the group.
o The rank, an integer between 1 and count, is different in
each session of the session group.
The SESSION_GROUP objects for all sessions in the group will
contain the same values of the reference address, the session
group ID, and the count value. The rank values establishes the
desired order among them.
If RSVP at a given node receives a RESV message containing a
SESSION_GROUP object, it should wait until RESV messages for all
`count' sessions have appeared (or until the end of the refresh
cycle) and then pass the RESV requests to Admission Control as a
group. It is normally expected that all sessions in the group
will be routed through the same nodes. However, if not, only a
subset of the session group reservations may appear at a given
node; in this case, the RSVP should wait until the end of the
refresh cycle and then perform Admission Control on the subset of
the session group that it has received. The rank values will
identify which are missing.
Note that routing different sessions of the session group
differently will generally result in delays in establishing or
rejecting the desired QoS. A "bundling" facility could be added
to multicast routing, to force all sessions in a session group to
be routed along the same path.
2.8 Host Model
Before a session can be created, the session identification, Before a session can be created, the session identification,
comprised of DestAddress and perhaps the generalized destination comprised of DestAddress and perhaps the generalized destination
port, must be assigned and communicated to all the senders and port, must be assigned and communicated to all the senders and
receivers by some out-of-band mechanism. In order to join an RSVP receivers by some out-of-band mechanism. When an RSVP session is
session, the following events happen at the end systems. being set up, the following events happen at the end systems.
H1 A receiver joins the multicast group specified by H1 A receiver joins the multicast group specified by
DestAddress, using IGMP. DestAddress, using IGMP.
H2 A potential sender starts sending RSVP PATH messages to the H2 A potential sender starts sending RSVP PATH messages to the
DestAddress, using RSVP. DestAddress, using RSVP.
H3 A receiver listens for PATH messages. H3 A receiver application receives a PATH message.
H4 A receiver starts sending appropriate RESV messages, H4 A receiver starts sending appropriate RESV messages,
specifying the desired flow descriptors, using RSVP. specifying the desired flow descriptors, using RSVP.
H5 A sender starts sending data packets. H5 A sender application receives a RESV message.
H6 A sender starts sending data packets.
There are several synchronization considerations. There are several synchronization considerations.
o Suppose that a new sender starts sending data (H5) but no o Suppose that a new sender starts sending data (H6) but no
receivers have joined the group (H1). Then there will be no receivers have joined the group (H1). Then there will be no
multicast routes beyond the host (or beyond the first RSVP- multicast routes beyond the host (or beyond the first RSVP-
capable router) along the path; the data will be dropped at capable router) along the path; the data will be dropped at
the first hop until receivers(s) do appear (assuming a the first hop until receivers(s) do appear (assuming a
multicast routing protocol that "prunes off" or otherwise multicast routing protocol that "prunes off" or otherwise
avoids unnecessary paths). avoids unnecessary paths).
o Suppose that a new sender starts sending PATH messages (H2) o Suppose that a new sender starts sending PATH messages (H2)
and immediately starts sending data (H5), and there are and immediately starts sending data (H6), and there are
receivers but no RESV messages have reached the sender yet receivers but no RESV messages have reached the sender yet
(e.g., because its PATH messages have not yet propagated to (e.g., because its PATH messages have not yet propagated to
the receiver(s)). Then the initial data may arrive at the receiver(s)). Then the initial data may arrive at
receivers without the desired QoS. receivers without the desired QoS. The sender could mitigate
this problem by awaiting arrival of the first RESV message
[H5]; however, receivers that are farther away may not have
reservations in place yet.
o If a receiver starts sending RESV messages (H4) before any o If a receiver starts sending RESV messages (H4) before any
PATH messages have reached it (H5) (and if path state is PATH messages have reached it (H3), RSVP will return error
being used to route RESV messages), RSVP will return error
messages to the receiver. The receiver may simply choose to messages to the receiver. The receiver may simply choose to
ignore such error messages, or it may avoid them by waiting ignore such error messages, or it may avoid them by waiting
for PATH messages before sending RESV messages. for PATH messages before sending RESV messages.
A specific application program interface (API) for RSVP is not A specific application program interface (API) for RSVP is not
defined in this protocol spec, as it may be host system dependent. defined in this protocol spec, as it may be host system dependent.
However, Section 4.6.1 discusses the general requirements and However, Section 4.6.1 discusses the general requirements and
presents a generic API. presents a generic API.
3. Examples 3. Examples
We use the following notation for a RESV message: We use the following notation for a RESV message:
1. Wildcard-Filter 1. Wildcard-Filter (WF)
WF( *{Q}) WF( *{Q})
Here "*{Q}" represents a Flow Descriptor with a "wildcard" scope Here "*{Q}" represents a Flow Descriptor with a "wildcard" scope
(choosing all senders) and a flowspec of quantity Q. (choosing all senders) and a flowspec of quantity Q.
2. Fixed-Filter 2. Fixed-Filter (FF)
FF( S1{Q1}, S2{Q2}, ...) FF( S1{Q1}, S2{Q2}, ...)
A list of (sender, flowspec) pairs, i.e., flow descriptors, A list of (sender, flowspec) pairs, i.e., flow descriptors,
packed into a single RESV message. packed into a single RESV message.
3. Shared Explicit (SE)
SE( (S1,S2,...)Q1, (S3,S4,...)Q2, ...)
A list of shared reservations, each specified by a single
flowspec and a list of senders.
For simplicity we assume here that flowspecs are one-dimensional, For simplicity we assume here that flowspecs are one-dimensional,
defining for example the average throughput, and state them as a defining for example the average throughput, and state them as a
multiple of some unspecified base resource quantity B. multiple of some unspecified base resource quantity B.
Figure 5 shows schematically a router with two previous hops labeled Figure 6 shows schematically a router with two previous hops labeled
(a) and (b) and two outgoing interfaces labeled (c) and (d). This (a) and (b) and two outgoing interfaces labeled (c) and (d). This
topology will be assumed in the examples that follow. There are topology will be assumed in the examples that follow. There are
three upstream senders; packets from sender S1 (S2 and S3) arrive three upstream senders; packets from sender S1 (S2 and S3) arrive
through previous hop (a) ((b), respectively). There are also three through previous hop (a) ((b), respectively). There are also three
downstream receivers; packets bound for R1 and R2 (R3) are routed via downstream receivers; packets bound for R1 and R2 (R3) are routed via
outgoing interface (c) ((d) respectively). outgoing interface (c) ((d) respectively).
In addition to the connectivity shown in 5, we must also specify the In addition to the connectivity shown in 6, we must also specify the
multicast routing within this node. Assume first that data packets multicast routing within this node. Assume first that data packets
(hence, PATH messages) from each Si shown in Figure 5 is routed to (hence, PATH messages) from each Si shown in Figure 6 is routed to
both outgoing interfaces. Under this assumption, Figures 6 and 7 both outgoing interfaces. Under this assumption, Figures 7, 8, and 9
illustrate Wildcard-Filter reservations and Fixed-Filter illustrate Wildcard-Filter, Fixed-Filter, and Shared-Explicit
reservations, respectively. reservations, respectively.
________________ ________________
(a)| | (c) (a)| | (c)
( S1 ) ---------->| |----------> ( R1, R2) ( S1 ) ---------->| |----------> ( R1, R2)
| Router | | Router |
(b)| | (d) (b)| | (d)
( S2,S3 ) ------->| |----------> ( R3 ) ( S2,S3 ) ------->| |----------> ( R3 )
|________________| |________________|
Figure 5: Router Configuration Figure 6: Router Configuration
In Figure 6, the "Receive" column shows the RESV messages received In Figure 7, the "Receive" column shows the RESV messages received
over outgoing interfaces (c) and () and the "Reserve" column shows over outgoing interfaces (c) and (d) and the "Reserve" column shows
the resulting reservation state for each interface. The "Send" the resulting reservation state for each interface. The "Send"
column shows the RESV messages forwarded to previous hops (a) and column shows the RESV messages forwarded to previous hops (a) and
(b). In the "Reserve" column, each box represents one reservation (b). In the "Reserve" column, each box represents one reservation
"channel", with the corresponding filter. As a result of merging, "channel", with the corresponding filter. As a result of merging,
only the largest flowspec is forwarded upstream to each previous hop. only the largest flowspec is forwarded upstream to each previous hop.
| |
Send | Reserve Receive Send | Reserve Receive
| |
| _______ | _______
WF( *{3B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} ) WF( *{3B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} )
| |_______| | |_______|
| |
-----------------------|---------------------------------------- -----------------------|----------------------------------------
| _______ | _______
WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} ) WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} )
| |_______| | |_______|
Figure 6: Wildcard-Filter Reservation Example 1 Figure 7: Wildcard-Filter Reservation Example 1
Figure 7 shows Fixed-Filter style reservations. The flow descriptors Figure 8 shows Fixed-Filter (FF) style reservations. The flow
for senders S2 and S3, received from outgoing interfaces (c) and (d), descriptors for senders S2 and S3, received from outgoing interfaces
are packed into the message forwarded to previous hop b. On the (c) and (d), are packed into the message forwarded to previous hop b.
other hand, the two different flow descriptors for sender S1 are On the other hand, the two different flow descriptors for sender S1
merged into the single message FF( S1{3B} ), which is sent to are merged into the single message FF( S1{3B} ), which is sent to
previous hop (a), For each outgoing interface, there is a private previous hop (a). For each outgoing interface, there is a private
reservation for each source that has been requested, but this private reservation for each source that has been requested, but this private
reservation is shared among the receivers that made the request. reservation is shared among the receivers that made the request.
Finally, Figure 9 shows a simple example of Shared-Explicit (SE)
style reservations. Here each outgoing interface has a single
reservation that is shared by a list of senders.
| |
Send | Reserve Receive Send | Reserve Receive
| |
| ________ | ________
FF( S1{3B} ) <- (a) | (c) | S1{B} | (c) <- FF( S1{B}, S2{5B} ) FF( S1{3B} ) <- (a) | (c) | S1{B} | (c) <- FF( S1{B}, S2{5B} )
| |________| | |________|
| | S2{5B} | | | S2{5B} |
| |________| | |________|
---------------------|--------------------------------------------- ---------------------|---------------------------------------------
| ________ | ________
<- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} ) <- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} )
FF( S2{5B}, S3{B} ) | |________| FF( S2{5B}, S3{B} ) | |________|
| | S3{B} | | | S3{B} |
| |________| | |________|
Figure 7: Fixed-Filter Reservation Example Figure 8: Fixed-Filter Reservation Example
The two examples just shown assume full routing, i.e., data packets |
from S1, S2, and S3 are routed to both outgoing interfaces. Assume Send | Reserve Receive
the routing shown in Figure 8, in which data packets from S1 are not |
forwarded to interface (d) (because the mesh topology provides a | ________
shorter path for S1 -> R3 that does not traverse this node). SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} )
| | {B} |
| |________|
---------------------|---------------------------------------------
| ________
<- (b) | (d) |(S1,S3) | (d) <- SE( (S1,S3){3B} )
SE( (S2,S3){3B} ) | | {3B} |
| |________|
Figure 9: Shared-Explicit Reservation Example
The three examples just shown assume full routing, i.e., data packets
from S1, S2, and S3 are routed to both outgoing interfaces. The top
part of Figure 10 shows another routing assumption: data packets
from S1 are not forwarded to interface (d), because the mesh topology
provides a shorter path for S1 -> R3 that does not traverse this
node. The bottom of Figure 10 shows WF style reservations under this
assumption. Since there is no route from (a) to (d), the reservation
forwarded out interface (a) considers only the reservation on
interface (c); no merging takes place in this case.
_______________ _______________
(a)| | (c) (a)| | (c)
( S1 ) ---------->| --------->--> |----------> ( R1, R2) ( S1 ) ---------->| --------->--> |----------> ( R1, R2)
| / | | / |
| / | | / |
(b)| / | (d) (b)| / | (d)
( S2,S3 ) ------->| ->----------> |----------> ( R3 ) ( S2,S3 ) ------->| ->----------> |----------> ( R3 )
|_______________| |_______________|
Figure 8: Router Configuration Router Configuration
Under this assumption, Figure 9 shows Wildcard-Filter reservations.
Since there is no route from (a) to (d), the reservation forwarded
out interface (a) considers only the reservation on interface (c), so
no merging takes place in this case.
| |
Send | Reserve Receive Send | Reserve Receive
| |
| _______ | _______
WF( *{B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} ) WF( *{B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} )
| |_______| | |_______|
| |
-----------------------|---------------------------------------- -----------------------|----------------------------------------
| _______ | _______
WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} ) WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} )
| |_______| | |_______|
Figure 9: Wildcard-Filter Reservation Example -- Partial Routing Figure 10: Wildcard-Filter Reservation Example -- Partial Routing
Finally, we note that state that is received through a particular
interface Iout in never forwarded out the same interface.
Conversely, state that is forwarded out interface Iout must be
computed using only state that arrived on interfaces different from
Iout. A trivial example of this rule is illustrated in Figure 11,
which shows a transit router with one sender and one receiver on each
interface (and assumes one next/previous hop per interface).
Interfaces (a) and (c) are both outgoing and incoming interfaces for
this session. Both receivers are making wildcard-scope reservations,
in which the RESV messages are forwarded to all previous hops for
senders in the group, with the exception of the next hop from which
they came. These result in independent reservations in the two
directions.
________________
a | | c
( R1, S1 ) <----->| Router |<-----> ( R2, S2 )
|________________|
Send | Receive
|
WF( *{3B}) <-- (a) | (c) <-- WF( *{3B})
|
Receive | Send
|
WF( *{4B}) --> (a) | (c) --> WF( *{4B})
|
Reserve on (a) | Reserve on (c)
__________ | __________
| * {4B} | | | * {3B} |
|__________| | |__________|
|
Figure 11: Independent Reservations
4. RSVP Functional Specification 4. RSVP Functional Specification
4.1 RSVP Message Formats 4.1 RSVP Message Formats
All RSVP messages consist of a common header followed by a All RSVP messages consist of a common header followed by a
variable number of variable-length typed "objects" using a common variable number of variable-length typed "objects". The
structure. The subsections that follow define the formats of the subsections that follow define the formats of the common header,
common header, the object structures, and each of the RSVP message the object structures, and each of the RSVP message types.
types. For each RSVP message type, there is a set of rules for
the permissible ordering and choice of object types. These rules For each RSVP message type, there is a set of rules for the
are specified using Backus-Naur Form (BNF) augmented with square permissible ordering and choice of object types. These rules are
specified using Backus-Naur Form (BNF) augmented with square
brackets surrounding optional sub-sequences. brackets surrounding optional sub-sequences.
4.1.1 Common Header 4.1.1 Common Header
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Vers | Type | Flags | Message Length | | Vers | Flags| Type | RSVP Checksum |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| RSVP Checksum | Object Count | | Message Length | (Reserved) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
The common header fields are as follows: The fields in the common header are as follows:
Vers Vers
Protocol version number. This is version 2. Protocol version number. This is version 2.
Flags
(None defined yet)
Type Type
1 = PATH 1 = PATH
2 = RESV 2 = RESV
3 = PERR 3 = PERR
4 = RERR 4 = RERR
5 = PTEAR 5 = PTEAR
6 = RTEAR 6 = RTEAR
Flags
0x01 = Entry-Police
This flag should be on in a PATH message sent by an
RSVP daemon in a sender host. The first RSVP node
that finds the flag on in a PATH message (i.e., the
first-[RSVP-]hop router) should institute policing
for the flow(s) described in this message. This flag
should never be forwarded in PATH refresh messages.
0x02 = LUB-Used
This flag is described below in the section on Error
Messages.
Message Length
The total length of this RSVP message, including this
common header and the objects included in Object Count.
RSVP Checksum RSVP Checksum
A standard TCP/UDP checksum over the contents of the RSVP A standard TCP/UDP checksum over the contents of the RSVP
message, with the checksum field replaced by zero. message, with the checksum field replaced by zero.
Object Count Message Length
Count of variable-length objects that follow. The total length of this RSVP message in bytes, including
this common header and the variable-length objects that
follow.
4.1.2 Object Formats 4.1.2 Object Formats
An object consists of one or more 32-bit words with a one-word An object consists of one or more 32-bit words with a one-word
header, in the following format: header, in the following format:
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length (bytes) | Class | C-Type | | Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
// (Object contents) // // (Object contents) //
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
An object header has the following fields: An object header has the following fields:
Length Length
Total length in bytes. Must always be a multiple of 4, A 16-bit field containing the total object length in
and at least 4. bytes. Must always be a multiple of 4, and at least 4.
Class Class-Num
Object class. In this document, the names of object Identifies the object class; values of this field are
classes are capitalized. defined in Appendix A. Each object class has a name,
which will always be capitalized in this document. An
RSVP implementation must recognize the following classes:
0 = NULL NULL
A NULL object has a Class of zero; its C-Type is A NULL object has a Class-Num of zero, and its C-Type
ignored. Its length must be at least 4, but can be is ignored. Its length must be at least 4, but can
any multiple of 4. A NULL object may appear anywhere be any multiple of 4. A NULL object may appear
in a sequence of objects, and its contents will be anywhere in a sequence of objects, and its contents
ignored by the receiver. will be ignored by the receiver.
1 = SESSION SESSION
Contains the IP destination address (DestAddress) and Contains the IP destination address (DestAddress) and
possibly a generalized source port, to define a possibly a generalized destination port, to define a
specific session for the other objects that follow. specific session for the other objects that follow.
Required in every RSVP message. Required in every RSVP message.
2 = SESSION_GROUP RSVP_HOP
When present, defines a session group, a set of
related sessions whose reservation requests should be
passed collectively to Admission Control.
3 = RSVP_HOP
Carries the IP address of the RSVP-capable node that Carries the IP address of the RSVP-capable node that
sent this message. This document refers to a sent this message. This document refers to a
RSVP_HOP object as a PHOP ("previous hop") object for RSVP_HOP object as a PHOP ("previous hop") object for
downstream messages or as a NHOP ("next hop") object downstream messages or as a NHOP ("next hop") object
for upstream messages. for upstream messages.
4 = STYLE TIME_VALUES
If present, contains values for the refresh period R
and the state time-to-live T (see section 4.5), to
override the default values of R and T.
STYLE
Defines the reservation style plus style-specific Defines the reservation style plus style-specific
information that is not a FLOWSPEC or FILTER_SPEC information that is not a FLOWSPEC or FILTER_SPEC
object, in a RESV message. object, in a RESV message.
5 = FLOWSPEC FLOWSPEC
Defines a desired QoS, in a RESV message. Defines a desired QoS, in a RESV message.
6 = FILTER_SPEC FILTER_SPEC
Defines a subset of session data packets that should Defines a subset of session data packets that should
receive the desired QoS (specified by an FLOWSPEC receive the desired QoS (specified by an FLOWSPEC
object), in a RESV message. object), in a RESV message.
7 = SENDER_TEMPLATE SENDER_TEMPLATE
Contains a sender IP address and perhaps some Contains a sender IP address and perhaps some
additional demultiplexing information to identify a additional demultiplexing information to identify a
sender, in a PATH message. sender, in a PATH message.
8 = SENDER_TSPEC SENDER_TSPEC
Defines the traffic characteristics of a sender's Defines the traffic characteristics of a sender's
data stream, in a PATH message. data stream, in a PATH message.
9 = ADVERT ADSPEC
Carries an Adspec containing OPWA data, in a PATH Carries an Adspec containing OPWA data, in a PATH
message. message.
10 = TIME_VALUES ERROR_SPEC
If present, contains values for the refresh period R Specifies an error, in a PERR or RERR message.
and the state time-to-live T (see section 4.5), to
override the default values of R and T.
11 = ERROR_SPEC POLICY_DATA
Specifies an error, in a PERR or RERR message. Carries information that will allow a local policy
module to decide whether an associated reservation is
administratively permitted. May appear in a PATH or
RESV message.
12 = CREDENTIAL INTEGRITY
Contains user credential and/or information for Contains cryptographic data to authenticate the
policy control and/or accounting. originating node, and perhaps to verify the contents,
of this RSVP message.
13 = INTEGRITY SCOPE
Contains a cryptographic data to authenticate the An explicit specification of the scope for forwarding
originating node, and perhaps verify the contents, of a RESV message.
this RSVP message.
C-Type TAG
Object type; unique within Class. Values defined in Encloses a list of one or more objects and attaches a
Appendix A. logical name or "tag" value to them. The tag value
is unique to the next/previous hop and the session
(specified by HOP and SESSION objects, respectively).
The enclosed object list is the "tagged sublist", and
the objects in it said to be "tagged" with the tag
value. Objects in a particular tagged sublist must
all have the same class-num.
The Class and C-Type fields may be used together as a 16-bit Tagged objects with the same tag value are declared
number to define a unique type for each object. to be logically related, i.e., to be members of some
larger logical set of objects. Note that the tagged
sublist implies no ordering; it defines only a set of
objects.
The formats of specific object types are defined in Appendix A. The meaning of the logical relationship depends upon
the class-num of the tagged objects.
C-Type
Object type, unique within Class-Num. Values are defined
in Appendix A.
The maximum object content length is 65528 bytes. The Class-
Num and C-Type fields (together with the 'Optional' flag bit)
may be used together as a 16-bit number to define a unique type
for each object.
The high-order bit of the Class-Num is used to determine what
action a node should take if it does not recognize the Class-
Num of an object. If Class-Num < 128, then the node should
ignore the object but forward it (unmerged). If Class-Num >=
128, the message should be rejected and an "Unknown Object
Class" error returned. Note that merging cannot be performed
on unknown object types; as a result, unmerged objects may be
forwarded to the first node that does know how to merge them.
The scaling limitations that this imposes must be considered
when defining and deploying new object types.
4.1.3 Path Message 4.1.3 Path Message
PATH messages carry information from senders to receivers along PATH messages carry information from senders to receivers along
the same paths, and using the same uni-/multicast routes, as the paths used by the data packets. The IP destination address
the data packets. The IP destination address of a PATH message of a PATH message is the DestAddress for the session; the
is the DestAddress for the session, and the source address is source address is an address of the node that sent the message
an address of the node that sent the message (if possible, the (preferably the address of the interface through which it was
address of the particular interface through which it was sent). sent). The PHOP (i.e., the RSVP_HOP) object of each PATH
message should contain the IP source address.
The format of a PATH message is as follows: The format of a PATH message is as follows:
<Path Message> ::= <Common Header> <SESSION> <RSVP_HOP> <Path Message> ::= <Common Header> <SESSION> <RSVP_HOP>
[ <INTEGRITY> ] [ <TIME_VALUES> ] [ <INTEGRITY> ] [ <TIME_VALUES> ]
<sender descriptor list> <sender descriptor list>
<sender descriptor list> ::= <empty > | <sender descriptor list> ::= <empty > |
<sender descriptor list> <sender descriptor> <sender descriptor list> <sender descriptor>
<sender descriptor> ::= [ <CREDENTIAL> ] <SENDER_TEMPLATE> <sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
[ <SENDER_TSPEC> ] [ <ADVERT> ] [ <POLICY_DATA> ] [ <ADSPEC> ]
Each sender descriptor defines a sender, and the sender Each sender descriptor defines a sender, and the sender
descriptor list allows multiple sender descriptors to be packed descriptor list allows multiple sender descriptors to be packed
into a PATH message. For each sender in the list, the into a PATH message. For each sender in the list, the
SENDER_TEMPLATE object defines the format of data packets, the SENDER_TEMPLATE object defines the format of data packets; in
SENDER_TSPEC object may specify the traffic flow, and the addition, a SENDER_TSPEC object may specify the traffic flow, a
CREDENTIAL object may specify the user credentials. There may POLICY_DATA object may specify user credential and accounting
also be an ADVERT object carrying advertising (OPWA) data. information, and an ADSPEC object may carry advertising (OPWA)
data.
Each sender host must periodically send a PATH message Each sender host must periodically send PATH message(s)
containing the sender descriptor(s) describing its own data containing a sender descriptor for each its own data stream(s).
stream(s), for a given session. Each sender descriptor is Each sender descriptor is forwarded and replicated as necessary
forwarded and replicated as necessary to follow the delivery to follow the delivery path(s) for a data packet from the same
path(s) for a data packet from the same sender, finally sender, finally reaching the applications on all receivers
reaching the applications on all receivers (except not a (except that it is not looped back to a receiver included in
receiver included in the sender process). the same application process as the sender).
At each node, a route must be computed independently for each It is an error to send ambiguous path state, i.e., two or more
sender descriptors being forwarded. These routes, obtained Sender Templates that are different but overlap, due to
from the uni/multicast routing table, generally depend upon the wildcards. For example, if we represent a Sender Template as
(sender host address, DestAddress) pairs, and consist of a list (IP address, sender port, protocol id and use `*' to represent
of outgoing interfaces. Then the descriptors being forwarded a wildcard, then each of the following pairs of Sender
through the same outgoing interface can be packed into as few Templates would be an error:
PATH messages as possible. Note that multicast routing of path
information is based on the sender address(es) from the sender
descriptors, not the IP source address; this is necessary to
prevent routing loops; see Section 4.3. PHOP (i.e., the
RSVP_HOP object) of each PATH message should contain the IP
source address, the interface address through which the message
is sent.
PATH messages are processed at each node they reach to create (10.1.2.3, 34567, *) and (10.1.2.3, *, *)
path state, which includes SENDER_TEMPLATE object and possibly
CREDENTIAL, SENDER_TSPEC, and ADVERT objects. If an error is (10.1.2.3, 34567, *) and (10.1.2.3, 34567, 17)
encountered while processing a PATH message, a PERR message is
sent to all senders implied by the SENDER_TEMPLATEs in the A PATH message received at a node is processed to create path
sender descriptor list. state for all senders defined by SENDER_TEMPLATE objects in the
sender descriptor list. If present, any POLICY_DATA,
SENDER_TSPEC, and ADSPEC objects are also saved in the path
state. If an error is encountered while processing a PATH
message, a PERR message is sent to all senders implied by the
SENDER_TEMPLATEs.
Periodically, the path state is scanned to create new PATH
messages which are forwarded upstream. A node must
independently compute the route for each sender descriptor
being forwarded. These routes, obtained from uni-/multicast
routing, generally depend upon the (sender host address,
DestAddress) pairs and consist of a list of outgoing
interfaces. The descriptors being forwarded through the same
outgoing interface may be packed into as few PATH messages as
possible. Note that multicast routing of path information is
based on the sender address(es) from the sender descriptors,
not the IP source address; this is necessary to prevent routing
loops; see Section 4.3.
Multicast routing may also report the expected incoming
interface (i.e., the shortest path back to the sender). If so,
any PATH message that arrives on a different interface should
be discarded immediately.
It is possible that routing will report no routes for a
(sender, DestAddress) pair; path state for this sender should
be stored locally but not forwarded.
4.1.4 Resv Messages 4.1.4 Resv Messages
RESV messages carry reservation requests hop-by-hop from RESV messages carry reservation requests hop-by-hop from
receivers to senders, along the reverse paths of data flow for receivers to senders, along the reverse paths of data flow for
the session. The IP destination address of a RESV message is the session. The IP destination address of a RESV message is
the unicast address of a previous-hop node, obtained from the the unicast address of a previous-hop node, obtained from the
path state. The Next Hop address (in the RSVP_HOP object) path state. The IP source address is an address of the node
should be the IP address of the (incoming) interface through that sent the message. The NHOP (i.e., the RSVP_HOP) object
which the RESV message is sent. The IP source address is an must contain the IP address of the (incoming) interface through
address of the node that sent the message (if possible, the which the RESV message is sent.
address of the particular interface through which it was sent).
The permissible sequence of objects in a RESV message depends
upon the reservation style specified in the STYLE object.
Currently, object types Style-WF and Style-FF of class STYLE
are defined (see Appendix A).
The RESV message format is as follows: The RESV message format is as follows:
<Resv Message> ::= <Common Header> <SESSION> <Resv Message> ::= <Common Header> <SESSION> <RSVP_HOP>
[ <SESSION_GROUP> ] <RSVP_HOP>
[ <INTEGRITY> ] [ <TIME_VALUES> ] [ <INTEGRITY> ] [ <TIME_VALUES> ]
[ <CREDENTIAL> ] [ <SCOPE> ]
<style-specific tail> <STYLE> <flow descriptor list>
<style-specific-tail> ::= The following style-dependent rules control the composition of
a valid flow descriptor list.
<Style-WF> [ <FILTER_SPEC> ] <FLOWSPEC> | o WF Style:
<Style-FF> <flow descriptor list>
<flow descriptor list> ::= <empty> | <flow descriptor list> ::=
<flow descriptor list> <FILTER_SPEC> <FLOWSPEC> <FLOWSPEC> [ <POLICY_DATA> ] [ <FILTER_SPEC> ]
The reservation scope, i.e., the set of senders towards which a A FILTER_SPEC that is entire wildcard may be omitted.
particular reservation is to be forwarded, is determined by
matching FILTER_SPEC objects against the path state created o FF style:
from SENDER_TEMPLATE objects, considering any wildcards that
may be present. <flow descriptor list> ::=
<FLOWSPEC> [ <POLICY_DATA> ] <FILTER_SPEC>
| <flow descriptor list> [ <FLOWSPEC> ]
[ <POLICY_DATA> ] <FILTER_SPEC>
Each elementary FF style request is defined by a single
(FLOWSPEC, FILTER_SPEC) pair, and multiple such requests
may be packed into the flow descriptor list of a single
RESV message. A FLOWSPEC or POLICY_DATA object can be
omitted if it is identical to the most recent such object
that appeared in the list.
o SE style:
<flow descriptor list> ::= <SE descriptor>
| <flow descriptor list> <SE descriptor>
<SE descriptor> ::= <FLOWSPEC> [ <POLICY_DATA> ]
<filter spec list>
<filter spec list> ::= <FILTER_SPEC>
| <filter spec list> <FILTER_SPEC>
Each elementary SE style request is defined by a single SE
descriptor, which includes a FLOWSPEC defining the shared
reservation, possibly a POLICY_DATA object, and a list of
FILTER_SPEC objects. Multiple elementary requests, each
representing an independent shared reservation, may be
packed into the flow descriptor list of a single RESV
message. A POLICY_DATA object may be omitted if it is
identical to the most recent such object that appeared in
the list.
The reservation scope, i.e., the set of sender hosts towards
which a particular reservation is to be forwarded, is
determined as follows:
o For a style with explicit scope, match each FILTER_SPEC
object against the path state created from SENDER_TEMPLATE
objects to select a particular sender. It is an error if
a FILTER_SPEC matches more than one SENDER_TEMPLATE, due
to wildcarding. A SCOPE object, if present, should be
ignored.
o For a style with wildcard scope, a SCOPE object, if
present, defines the scope with an explicit list of sender
IP addresses (see Section 4.3 below). If there is no
SCOPE object, the scope is determined by the relevant set
of senders in the path state. A SCOPE object must be sent
in any wildcard scope RESV message that is forwarded to
more than one previous hop. See Section 4.3 below.
If an outgoing message is too large to fit into the MTU of the
interface, it can be sent as multiple messages, as follows:
o For FF style, the flow descriptor list can be split as
required to fit; the rest of the message should be
replicated into each packet.
o For WF style, a SCOPE object containing an explicit list
of sender IP addresses can be split as required to fit;
the rest of the message should be replicated into each
packet.
o For SE style, the flow descriptor list can be split as
required to fit; the rest of the message should be
replicated into each packet.
If a single SE descriptor is too large to fit, its filter
spec list can similarly be split as required. However,
the subsets of a particular filter spec list must each be
enclosed in TAG objects carrying the same tag value, so
the receiver will be able to match each FILTER_SPEC object
to the appropriate shared reservation.
4.1.5 Error Messages 4.1.5 Error Messages
There are two types of RSVP error messages: There are two types of RSVP error messages.
o PERR messages result from PATH messages and travel towards o PERR messages result from PATH messages and travel towards
senders. PERR messages are routed hop-by-hop like RESV senders. PERR messages are routed hop-by-hop using the
messages; at each hop, the IP destination address is the path state; at each hop, the IP destination address is the
unicast address of a previous hop. unicast address of a previous hop.
o RERR messages result from RESV messages and travel hop- o RERR messages result from RESV messages and travel towards
by-hop towards the appropriate receivers, routed by the the appropriate receivers. They are routed hop-by-hop
reservation state. At each hop, the IP destination using the reservation state; at each hop, the IP
address is the unicast address of a next-hop node. destination address is the unicast address of a next-hop
Routing is discussed below. node.
RSVP error messages are triggered only by processing of PATH Errors encountered while processing error messages must not
and RESV messages; errors encountered while processing error or create further error messages.
teardown messages must not create error messages.
<PathErr message> ::= <Common Header> <SESSION> <RSVP_HOP> <PathErr message> ::= <Common Header> <SESSION>
[ <INTEGRITY> ] <ERROR_SPEC> [ <INTEGRITY> ] <ERROR_SPEC>
<sender descriptor> <sender descriptor>
<sender descriptor list> ::= (see earlier definition) <sender descriptor> ::= (see earlier definition)
<ResvErr Message> ::= <Common Header> <SESSION> <RSVP_HOP> <ResvErr Message> ::= <Common Header> <SESSION>
[ <INTEGRITY> ] <ERROR_SPEC> [ <INTEGRITY> ] <ERROR_SPEC>
[ <CREDENTIAL> ] <style-specific tail> <STYLE> <error flow descriptor>
<style-specific tail> ::= (see earlier definition)
The ERROR_SPEC specifies the error. It includes the IP address The following style-dependent rules control the composition of
of the node that detected the error, called the Error Node a valid error flow descriptor.
Address.
o WF Style:
<error flow descriptor> ::= <FLOWSPEC> [ <FILTER_SPEC> ]
o FF style:
<error flow descriptor> ::= <FLOWSPEC> <FILTER_SPEC>
o SE style:
<error flow descriptor> ::= <FLOWSPEC> <filter spec list>
The ERROR_SPEC object specifies the error and includes the IP
address of the node that detected the error (Error Node
Address).
When a PATH or RESV message has been "packed" with multiple When a PATH or RESV message has been "packed" with multiple
sets of elementary parameters, the RSVP implementation should sets of elementary parameters, the RSVP implementation should
process each set independently and return a separate error process each set independently and return a separate error
message for each that is in error. message for each that is in error.
An error message may be duplicated and forwarded unchanged. In In general, error messages should be delivered to the
general, error messages should be delivered to the applications applications on all the session nodes that (may have)
on all the session nodes that (may have) contributed to this contributed to this error. More specifically:
error.
o A PERR message is forwarded to all previous hops for all o A PERR message is forwarded to all previous hops for all
senders listed in the Sender Descriptor List. senders listed in the Sender Descriptor List.
o The node that creates a RERR message as the result of o A RERR message is generally forwarded to all receivers
processing a RESV message should send the RERR message out that may have caused the error being reported.
the interface through which the RESV arrived.
In succeeding hops, the routing of a RERR message depends The node that creates a RERR message sends the RERR
upon its style and upon routing. In general, a RERR message to the next hop from which the erroneous
message is sent out some subset of the outgoing interfaces reservation came. The message must contain the
specified for multicast routing, using Error Node Address information required to define the error and to route the
as the source address and DestAddress as the destination. error message. Thus, it contains the STYLE, a FLOWSPEC,
(This rule is necessary to prevent packet loops; see and one or more FILTER_SPEC(s) from the erroneous RESV
Section 4.3 below). Within this set of outgoing message.
interfaces, a RERR message is sent only to next hop(s)
whose RESV message(s) created the error; this in turn In succeeding hops, a RERR message is forwarded using the
depends upon the merging of flowspecs. Assume that a node's reservation state, to the next hops of reservations
reservation whose error is being reported was formed by that match the FILTER_SPEC(s) and the FLOWSPEC in the RERR
merging two flowspecs Q1 and Q2 from different next hops. message. Assume that a reservation whose error is being
reported was formed by merging two flowspecs Q1 and Q2
from different next hops.
- If Q1 = Q2, the error message should be forwarded to - If Q1 = Q2, the error message should be forwarded to
both next hops. both next hops.
- If Q1 < Q2, the error message should be forwarded - If Q1 < Q2, the error message should be forwarded
only to the next hop for Q2. only to the next hop for Q2.
- If Q1 and Q2 are incomparable, the error message - If Q1 and Q2 are incomparable, the error message
should be forwarded to both next hops, and the LUB should be forwarded to both next hops, and the LUB-
flag should be turned on. Used flag should be turned on.
The ERROR_SPEC and the LUB-flag should be delivered to the The RERR message that is forwarded should carry the
receiver application. In the case of an Admission Control FILTER_SPEC from the corresponding reservation state (thus
error, the style-specific tail will contain the FLOWSPEC `un-merging' the filter spec). For reservations with
object that failed. If the LUB-flag is off, this should wildcard scope, there is an additional limitation on
be the same as a FLOWSPEC in a RESV message sent by this forwarding RERR messages, to avoid loops; see Section 4.3
application; otherwise, they may differ. below.
An error in a FILTER_SPEC object in a RESV message will When a RERR message reaches a receiver, the STYLE object,
normally be detected at the first RSVP hop from the flow descriptor list, and ERROR_SPEC object (which
receiver application, i.e., within the receiver host. contains the LUB-Used flag) should be delivered to the
However, an admission control failure caused by a FLOWSPEC receiver application. In the case of an Admission Control
or a CREDENTIAL object may be detected anywhere along the error, the flow descriptor list will contain the FLOWSPEC
path(s) to the sender(s). object that failed. If the LUB-Used flag is off, this
should be `equal' to (but not necessarily identical to)
the FLOWSPEC originated by this application; otherwise,
they may differ.
4.1.6 Teardown Messages 4.1.6 Teardown Messages
There are two types of RSVP Teardown message, PTEAR and RTEAR. There are two types of RSVP Teardown message, PTEAR and RTEAR.
o PTEAR messages delete path state (which in turn may delete o A PTEAR message deletes path state (which may, in turn,
reservations state) and travel towards all receivers that delete reservation state) and travels towards all
are downstream from the point of initiation. PTEAR receivers that are downstream from the point of
messages are routed like PATH messages, and their IP initiation. A PTEAR message is routed like a PATH
destination address is DestAddress for the session. message, and its IP destination address is DestAddress for
the session.
o RTEAR messages delete reservation state and travel towards o A RTEAR message deletes reservation state and travels
all matching senders upstream from the point of teardown towards all matching senders upstream from the point of
initiation. RTEAR message are routed like RESV messages, teardown initiation. A RTEAR message is routed like a
and their IP destination address is the unicast address of corresponding RESV message (using the same scope rules).
a previous hop. Its IP destination address is the unicast address of a
previous hop.
<PathTear Message> ::= <Common Header> <SESSION> <RSVP HOP> <PathTear Message> ::= <Common Header> <SESSION> <RSVP_HOP>
[ <INTEGRITY> ] [ <INTEGRITY> ]
<sender descriptor list> <sender descriptor list>
<sender descriptor list> ::= (see earlier definition) <sender descriptor list> ::= (see earlier definition)
<ResvTear Message> ::= <Common Header> <SESSION> <RSVP HOP> <ResvTear Message> ::= <Common Header> <SESSION> <RSVP_HOP>
[ <INTEGRITY> ] [ <CREDENTIAL> ] [ <INTEGRITY> ] [ <SCOPE> ]
<style-specific tail> <STYLE> <flow descriptor list>
<style-specific tail> ::= (see earlier definition) <flow descriptor list> ::= (see earlier definition)
Flowspec objects in the style-specific tail of a RTEAR message FLOWSPEC or POLICY_DATA objects in the flow descriptor list of
will be ignored and may be omitted. a RTEAR message will be ignored and may be omitted.
If the state being deleted was created with user credentials Note that the RTEAR message will cease to be forwarded at the
from a CREDENTIAL field, then the matching PTEAR or RTEAR same node where merging suppresses forwarding of the
message must include matching CREDENTIAL field(s). corresponding RESV messages. The change will be propagated as
a new teardown message if the result has been to remove all
state for this session at this node; otherwise, it may result
in the immediate forwarding of a modified RESV refresh message.
[There is a problem here: tearing down path state may Deletion of path state, whether as the result of a teardown
implicitly delete reservation state. But a PTEAR message does message or because of timeout, may force adjustments in related
not have credentials for the reservation state, only for the reservation state to maintain consistency in the local node.
path state. Some argue that a CREDENTIAL may not be needed in
teardown messages, on the assumption that false teardown The adjustment in reservation state depends upon the style.
messages can be injected only with the collusion of routers For example, suppose a PTEAR deletes the path state for a
along the data path, and in that case, the colluding router can sender S. If the style specifies distinct reservations (FF),
just as well stop delivering the RESV messages, which will have only reservations for sender S should be deleted; if the style
the same effect.] specifies shared reservations (WF or SE), delete the
reservation if this was the last filter spec. These
reservation changes should not trigger an immediate RESV
refresh message, since the teardown message will have already
made the required changes upstream. However, at the node in
which a RTEAR message stops, the change of reservation state
may trigger a RESV refresh starting at that node.
4.2 Sending RSVP Messages 4.2 Sending RSVP Messages
RSVP messages are sent hop-by-hop between RSVP-capable routers as RSVP messages are sent hop-by-hop between RSVP-capable routers as
"raw" IP datagrams, protocol number 46. Raw IP datagrams are "raw" IP datagrams with protocol number 46. Raw IP datagrams are
similarly intended to be used between an end system and the similarly intended to be used between an end system and the
first/last hop router; however, it is also possible to encapsulate first/last hop router; however, it is also possible to encapsulate
RSVP messages as UDP datagrams for end-system communication, as RSVP messages as UDP datagrams for end-system communication, as
described in Appendix C. UDP encapsulation will simplify described in Appendix C. UDP encapsulation may simplify
installation of RSVP on current end systems, particularly when installation of RSVP on current end systems, particularly when
firewalls are in use. firewalls are in use.
Under overload conditions, lost RSVP control messages could cause Under overload conditions, lost RSVP control messages could cause
the loss of resource reservations. Routers should be configured a failure of resource reservations. Routers should be configured
to give a preferred class of service to RSVP packets. RSVP should to give a preferred class of service to RSVP packets. RSVP should
not use significant bandwidth, but the queueing delay for RSVP not use significant bandwidth, but queueing delay and dropping of
messages needs to be controlled. RSVP messages needs to be controlled.
An RSVP PATH or RESV message consists of a small root segment An RSVP PATH or RESV message generally consists of a small root
followed by a variable-length list of objects, which may overflow segment followed by a potentially unbounded variable-length list
the capacity of one datagram. IP fragmentation is inadvisable, of objects. The variable part may overflow the capacity of one
since it has bad error characteristics; RSVP-level fragmentation datagram. If RSVP used IP fragmentation and reassembly (or an
should be used. That is, a message with a long list of equivalent byte-by-byte fragmentation mechanism at the RSVP
descriptors will be divided into segments that will fit into level), loss of a single packet would unnecessarily lose the
individual datagrams, each carrying the same root fields. Each of entire state update for a session. It is instead recommended that
these messages will be processed at the receiving node, with a an RSVP implementation use "semantic" fragmentation, using the
cumulative effect on the local state. No explicit reassembly is structure of the RSVP message.
needed.
An unbounded list in an RSVP message in fact consists of
individual atomic elements that are packed together for
efficiency. Wben sending a message, an RSVP should therefore pack
only what will fit into one packet, and then continue packing with
the next packet, etc. Each of these messages will be processed
independently at the receiving node, each updating its part of the
session state in the node. No explicit reassembly is needed.
Since RSVP messages are normally expected to be generated and sent Since RSVP messages are normally expected to be generated and sent
hop-by-hop, their MTU should be determined by the MTU of each hop-by-hop, their MTU should be determined by the MTU of each
interface. interface.
[There may be rare instances in which this does not work very Upon the arrival of an RSVP message M that changes the state, a
well, and in which manual configuration would not help. The node must forward the modified state immediatly. If this is
problem case is an interface connected to a non-RSVP cloud in implemented as an immediate refresh of all the state for the
which some particular link far away has a smaller MTU. This would session, then no refresh messages should be sent out the interface
affect only those sessions that happened to use that link. through which M arrived. This rule is necessary to prevent packet
Proper solution to this case would require MTU discovery storms on broadcast LANs.
separately for each interface and each session, which is a very
large amount of machinery and some overhead for a rare (?) case. Some multicast routing protocols provide for "multicast tunnels",
Best approach seems to be to rely on IP fragmentation and which encapsulate multicast packets for transmission through
reassembly for this case.] routers that do not have multicast capability. A multicast tunnel
looks like a logical outgoing interface that is mapped into some
physical interface. A multicast routing protocol that supports
tunnels will describe a route using a list of logical rather than
physical interfaces. RSVP can support multicast tunnels in the
following manner:
1. When a node N forwards a PATH message out a logical outgoing
interface L, it includes in the message some encoding of the
identity of L. This information is carried (in the HOP
object) as a value called the "logical interface handle" or
LIH.
2. The next hop node N' stores the LIH value in its path state.
3. When N' sends a RESV message to N, it includes the LIH value
from the path state (again, in the HOP object).
4. When the RESV message arrives at N, its LIH value provides
the information necessary to attach the reservation to the
appropriate logical interface. Note that N creates and
interprets the LIH; it is an opaque value to N'.
4.3 Avoiding RSVP Message Loops 4.3 Avoiding RSVP Message Loops
We must ensure that the rules for forwarding RSVP control messages We must ensure that the rules for forwarding RSVP control messages
avoid looping. In steady state, PATH and RESV messages are avoid looping. In steady state, PATH and RESV messages are
forwarded on each hop only once per refresh period. This avoids forwarded only once per refresh period on each hop. This avoids
directly looping packets, but there is still the possibility of an directly looping packets, but there is still the possibility of an
" auto-refresh" loop, clocked by the refresh period. The effect " auto-refresh" loop, clocked by the refresh period. The effect
of such a loop is to keep state active "forever", even if the end of such a loop is to keep state active "forever", even if the end
nodes have ceased refreshing it (but the state will be deleted nodes have ceased refreshing it (but the state will be deleted
when the receivers leave the multicast group and/or the senders when the receivers leave the multicast group and/or the senders
stop sending PATH messages). stop sending PATH messages). On the other hand, error and
teardown messages are forwarded immediately and are therefore
subject to direct looping.
In addition, error and teardown messages are forwarded immediately o PATH Messages
and are therefore subject to direct looping.
PATH messages are forwarded using routes determined by the PATH messages are forwarded using routes determined by the
appropriate routing protocol. For routing that is source- appropriate routing protocol. For routing that is source-
dependent (e.g., some multicast routing algorithms), the RSVP dependent (e.g., some multicast routing algorithms), the RSVP
daemon must route each sender descriptor separately using the daemon must route each sender descriptor separately using the
source addresses found in the SENDER_TEMPLATE objects. This source addresses found in the SENDER_TEMPLATE objects. This
should ensure that there will be no auto-refresh loops of PATH should ensure that there will be no auto-refresh loops of
information, even in a topology with cycles. PATH messages, even in a topology with cycles.
Since PATH messages don't loop, they create path state defining a Consider each message type.
loop-free reverse path to each sender. As a result, RESV and
RTEAR messages directed to particular senders cannot loop. PERR
messages are always directed to particular senders and therefore
cannot loop. However, there is a potential auto-refresh problem
for RESV, RTEAR, and RERR messages with wildcard scope, as we now
discuss.
If the topology has no loops, then auto-refresh can be avoided, o PTEAR Messages
even for wildcard scope, with the following rule:
A reservation request received from next hop N must not be PTEAR messages use the same routing as PATH messages and
forwarded to N. therefore cannot loop.
This rule is illustrated in Figure 10, which shows a transit o PERR Messages
router with one sender and one receiver on each interface (and
assumes one next/previous hop per interface). Interfaces a and c Since PATH messages don't loop, they create path state
are both outgoing and incoming interfaces for this session. Both defining a loop-free reverse path to each sender. PERR
receivers are making wildcard-scope reservations, in which the messages are always directed to particular senders and
RESV messages are forwarded to all previous hops for senders in therefore cannot loop.
the group, with the exception of the next hop from which they
came. These result in independent reservation requests in the two o RESV Messages
directions, without an auto-refresh loop.
Like PERR message, RESV messages directed to particular
senders (i.e., with explicit scope) cannot loop. However,
there is a potential for auto-refresh of RESV messages with
wildcard scope; the solution is presented below.
o RTEAR Messages
RTEAR messages are routed the same as RESV messages and have
an analogous looping problem for wildcard scope.
o RERR Messages
RERR messages for wildcard scope reservations have the same
potential for looping as the reservations themselves, and the
solution presented below is required.
If the topology has no loops, then looping of wildcard-scoped
messages can be avoided by simply enforcing the rule given
earlier: state that is received through a particular interface
must never be forwarded out the same interface. However, when the
topology does have cycles then further effort is needed to prevent
auto-refresh loops in wildcard-scope RESV, RTEAR, and RERR
messages. The solution is for such messages to carry an explicit
sender address list in a SCOPE object.
When a RESV or RTEAR message with wildcard scope is to be
forwarded to a particular previous hop, a new SCOPE object is
computed from the SCOPE objects that were received (in messages of
the same type). If the computed SCOPE object is empty, the
message is not forwarded to the previous hop; otherwise, the
message is sent containing the new SCOPE object. The rules for
computing a new SCOPE object for a RESV or RTEAR message are as
follows:
1. The union is formed of the sets of sender IP addresses listed
in all SCOPE objects in the reservation state for the given
session.
If reservation state from some NHOP does not contain a SCOPE
object, a substitute sender list must be created and included
in the union. For a wildcard scope (WF) message that arrived
on outgoing interface OI, the substitute list is the set of
senders that route to OI. For an explicit scope (SE)
message, it is the set of senders explicitly listed in the
message.
2. Any local senders are removed from this set.
3. If the SCOPE object is to be sent to PHOP, remove from the
set any senders that did not come from PHOP.
Figure 12 shows an example of wildcard-scoped (WF style) RESV
messages. The address lists within SCOPE objects are shown in
square brackets. Note that there may be additional connections
among the nodes, creating looping topology that is not shown.
________________ ________________
a | | c a | | c
( R1, S1 ) <----->| Router |<-----> ( R2, S2 ) R4, S4<----->| Router |<-----> R2, S2, S3
| |
b | |
R1, S1<----->| |
|________________| |________________|
Send & Receive on (a) | Send & Receive on (c) Send on (a): | Receive on (c):
| |
WF( *{3B}) <-- (a) | (c) <-- WF( *{3B}) <-- WF( [S4] ) | <-- WF( [S4, S1])
| |
WF( *{4B}) --> (a) | (c) --> WF( *{4B}) Send on (b): |
| |
<-- WF( [S1] ) |
| |
Reserve on (a) | Reserve on (c) Receive on (a): | Send on (c):
__________ | __________ |
| * {4B} | | | * {3B} | WF( [S1,S2,S3]) --> | WF( [S2, S3]) -->
|__________| | |__________| |
Receive on (b): |
|
WF( [S2,S3,S4]) --> |
| |
Figure 10: Avoiding Auto-Refresh in Non-Looping Topology Figure 12: SCOPE Objects in Wildcard-Scope Reservations
However, further effort is needed to prevent auto-refresh loops SCOPE objects are not necessary if the multicast routing uses
from wildcard-scope reservations in the presence of cycles in the shared trees or if the reservation style has explicit scope.
topology. [TBD!!]. Furthermore, attaching a SCOPE object to a reservation may be
deferred to a node which has more than one previous hop upstream.
We treat routing of RERR messages as a special case. They are The following rules are used for SCOPE objects in wildcard-scoped
sent with unicast addresses of next hops, but the multicast RERR messages:
routing is used to prevent loops. As explained above, RERR
messages are forwarded to a subset of the multicast tree to
DestAddress, rooted at the node on which the error was discovered.
Since multicast routing cannot create loops, this will prevent
loops for RERR messages.
[Open question about Figure 10: should it be possible to have 1. The node that detected the error initiates an RERR message
incompatible reservation styles on the two interfaces? For containing a copy of the SCOPE object associated with the
example, if R1 requests a WF reservation and R2 requests a FF reservation state or message in error.
reservation, it is logically possible to make the corresponding
reservations on the two different interfaces. The current 2. Suppose a wildcard-scoped RERR message arrives at a node with
implementation does NOT allow this; instead, it prevents mixing of a SCOPE object containing the sender host address list L.
incompatible styles in the same session on a node, even if they The node forwards the RERR message using the rules of Section
are on different interfaces.] 4.1.5. However, the RERR message forwarded out OI must
contain a SCOPE object derived from L by including only those
senders that route to OI. If this SCOPE object is empty, the
RERR message should not be sent out OI.
4.4 Local Repair 4.4 Local Repair
Each RSVP daemon periodically sends refreshes to its next/previous When a route changes, the next PATH or RESV refresh will establish
hops. An important optimization would allow the local routing path or reservation state (respectively) along the new route. To
protocol module to notify the RSVP daemon of route changes for provide fast adaptation to routing changes without the overhead of
particular destinations. The RSVP daemon should use this short refresh periods, the local routing protocol module can
information to trigger an immediate refresh of state for these notify the RSVP daemon of route changes for particular
destinations, using the new route. This allows fast adaptation to destinations. The RSVP daemon should use this information to
routing changes without the overhead of a short refresh period. trigger an immediate refresh of state for these destinations,
using the new route.
More specifically, the rules are as follows:
o When routing detects a change of the set of outgoing
interfaces for sending PATH messages for destination G, RSVP
should send immediate PATH refreshes for all sessions G/*
(i.e., for any session with destination G, regardless of
destination port).
o When a PATH message arrives with a Previous Hop address that
differs from the one stored in the path state, RSVP should
send immediate RESV refreshes for that session.
4.5 Time Parameters 4.5 Time Parameters
For each element of state, there are two time parameters: the There are two time parameters relevant to each element of RSVP
refresh period R and the time-to-live value T. R specifies the path or reservation state in a node: the refresh period R between
period between sending successive refreshes of this data. T receiving successive refreshes for the state, and its lifetime L.
controls how long state will be retained after refreshes stop Each RSVP RESV or PATH message may contain a TIME_VALUES object
appearing, and depends upon period between receiving successive specifying the R value that was used to generate this refresh
refreshes. Specifically, R <= T, and the "cleanout time" is K * message; this is used to determine the L when the state is
T. Here K is a small integer; K-1 successive messages may be lost received and stored.
before state is deleted. Currently K = 3 is suggested.
Clearly, a smaller T means increased RSVP overhead. If the router In more detail:
does not implement local repair, a smaller T improves the speed of
adapting to routing changes. With local repair, a router can be
more relaxed about T, since the periodic refresh becomes only a
backstop robustness mechanism.
There are three possible ways for a router to determine R and T. 1. To avoid premature loss of state, we require that L >= (K +
0.5)* R, where K is a small integer. Then K-1 successive
messages may be lost without state being deleted. Currently
K = 3 is suggested.
o Default values are configured in the router. Current 2. Each message will generally carry a TIME_VALUES object
defaults are 30 seconds for T and R. containing the R used to generate refreshes; the recipient
node uses this R to determine L of the stored state.
o A router may adjust the value of T dynamically to keep a However, if a default R = Rdef is used, the TIME_VALUES
constant total overhead due to refresh traffic; as more object may be omitted from a message. Rdef is currently
sessions appear, the period would be lengthened. In this defined to be 30 seconds.
case, R = T could be used.
o R and T can be specified by the end systems. For this 3. This document does not specify the interval R to be used for
purpose, PATH and RESV messages may contain the optional generating refresh messages. If the node does not implement
TIM_VALUES object. When messages are merged and forwarded to local repair of reservations disrupted by route changes, a
the next hop, R should be the minimum R that has been smaller R improves the speed of adapting to routing changes
received, and T should be the maximum T that has been (but increases overhead). With local repair, a router can be
received. Thus, the largest T determines how long state is more relaxed about R since the periodic refresh becomes only
retained, and the smallest R determines the responsiveness of a backstop robustness mechanism. A node may therefore adjust
RSVP to route changes. In the first hop, they are expected the effective R dynamically to limit the overhead due to
to be equal. The RSVP API might allow an application to refresh messages.
override the default value for a particular session.
4. The TIME_VALUES object could contain, in addition to the
hop-by-hop R value, an end-to-end upper bound on R, called
Rmax. When Rmax is specified, a node cannot set R > Rmax.
However, a node is allowed to refuse an RSVP message (i.e.,
drop it and return an error) when it specifies an Rmax value
that is so small that it would create unacceptable overhead.
This refusal would look like a kind of admission control
failure.
5. However, when R is changed dynamically, there is a limit to
how fast it may increase. Specifically, the ratio of two
successive values R2/R1 must not exceed 1 + Slew.Max.
Currently, Slew.Max is 0.30. With K = 3, one packet may be
lost without state timeout while R is increasing 30 percent
per refresh cycle.
6. To improve robustness, a node may temporarily send refreshes
more often than R after a state change (including initial
state establishment).
7. A node should randomize its refresh timeouts to avoid
synchronization and burstiness of refreshes.
8. The values of Rdef, K, and Slew.Max used in an implementation
should be easily modifiable, as experience may lead to
different values. The possibility of dynamically changing K
and/or Slew.Max in response to measured loss rates is for
future study.
4.6 RSVP Interfaces 4.6 RSVP Interfaces
RSVP on a router has interfaces to routing and to traffic control RSVP on a router has interfaces to routing and to traffic control
in the kernel. RSVP on a host has an interface to applications in the kernel. RSVP on a host has an interface to applications
(i.e, an API) and also an interface to traffic control (if it (i.e, an API) and also an interface to traffic control (if it
exists on the host). exists on the host).
4.6.1 Application/RSVP Interface 4.6.1 Application/RSVP Interface
skipping to change at page 37, line 28 skipping to change at page 47, line 28
these calls cause information to be returned asynchronously. these calls cause information to be returned asynchronously.
o Register o Register
Call: REGISTER( DestAddress , DestPort Call: REGISTER( DestAddress , DestPort
[ , SESSION_object ] , SND_flag , RCV_flag [ , SESSION_object ] , SND_flag , RCV_flag
[ , Source_Address ] [ , Source_Port ] [ , Source_Address ] [ , Source_Port ]
[ , Sender_Template ] [ , Sender_Tspec ] [ , Source_ProtID ] [ , Sender_Template ]
[ , Data_TTL ] [ , UserCredential ] [ , Sender_Tspec ] [ , Data_TTL ]
[ , Sender_Policy_Data ]
[ , Upcall_Proc_addr ] ) -> Session-id [ , Upcall_Proc_addr ] ) -> Session-id
This call initiates RSVP processing for a session, defined This call initiates RSVP processing for a session, defined
by DestAddress together with the TCP/UDP port number by DestAddress together with the TCP/UDP port number
DestPort. If successful, the REGISTER call returns DestPort. If successful, the REGISTER call returns
immediately with a local session identifier Session-id, immediately with a local session identifier Session-id,
which may be used in subsequent calls. which may be used in subsequent calls.
The SESSION_object parameter is included as an escape The SESSION_object parameter is included as an escape
skipping to change at page 38, line 4 skipping to change at page 48, line 6
session ("generalized destination port"), should that be session ("generalized destination port"), should that be
necessary in the future. Normally SESSION_object will be necessary in the future. Normally SESSION_object will be
omitted; if it is supplied, it should be an omitted; if it is supplied, it should be an
appropriately-formatted representation of a SESSION appropriately-formatted representation of a SESSION
object. object.
SND_flag should be set true if the host will send data, SND_flag should be set true if the host will send data,
and RCV_flag should be set true if the host will receive and RCV_flag should be set true if the host will receive
data. Setting neither true is an error. The optional data. Setting neither true is an error. The optional
parameters Source_Address, Source_Port, Sender_Template, parameters Source_Address, Source_Port, Sender_Template,
Sender_Tspec, and Data_TTL are all concerned with a data Sender_Tspec, Data_TTL, and Sender_Policy_Data are all
source, and they will be ignored unless SND_flag is true. concerned with a data source, and they will be ignored
unless SND_flag is true.
If SND_FLAG is true, a successful REGISTER call will cause If SND_FLAG is true, a successful REGISTER call will cause
RSVP to begin sending PATH messages for this session using RSVP to begin sending PATH messages for this session using
these parameters, which are interpreted as follows: these parameters, which are interpreted as follows:
- Source_Address - Source_Address
This is the address of the interface from which the This is the address of the interface from which the
data will be sent. If it is omitted, a default data will be sent. If it is omitted, a default
interface will be used. interface will be used. This parameter is needed on
a multihomed sender host.
- Source_Port - Source_Port
This is the UDP/TCP port from which the data will be This is the UDP/TCP port from which the data will be
sent. If it is omitted or zero, the port is "wild" sent. If it is omitted or zero, the port is "wild"
and can match any port in a FILTERSPEC. and can match any port in a FILTER_SPEC.
- Source_ProtID
This is the IP protocol ID for the sender data. If
it is omitted or zero, the protocol id is "wild" and
can match any protocol id in a FILTER_SPEC.
- Sender_Template - Sender_Template
This parameter is included as an escape mechanism to This parameter is included as an escape mechanism to
support a more general definition of the sender support a more general definition of the sender
("generalized source port"). Normally this parameter ("generalized source port"). Normally this parameter
may be omitted; if it is supplied, it should be an may be omitted; if it is supplied, it should be an
appropriately formatted representation of a appropriately formatted representation of a
SENDER_TEMPLATE object. SENDER_TEMPLATE object.
skipping to change at page 38, line 45 skipping to change at page 49, line 7
to be sent. It may be included to prevent over- to be sent. It may be included to prevent over-
reservation on the initial hops. reservation on the initial hops.
- Data_TTL - Data_TTL
This is the (non-default) IP Time-To-Live parameter This is the (non-default) IP Time-To-Live parameter
that is being supplied on the data packets. It is that is being supplied on the data packets. It is
needed to ensure that Path messages do not have a needed to ensure that Path messages do not have a
scope larger than multicast data packets. scope larger than multicast data packets.
- Sender_Policy_Data
This optional parameter passes policy data for the
sender. This data may be supplied by a system
service, with the application treating it as opaque.
Finally, Upcall_Proc_addr is the address of an upcall Finally, Upcall_Proc_addr is the address of an upcall
procedure to receive asynchronous error or event procedure to receive asynchronous error or event
notification; see below. notification; see below.
o Reserve o Reserve
Call: RESERVE( session-id, style, style-dependent-parms ) Call: RESERVE( session-id,
style, style-dependent-parms )
A receiver uses this call to make a resource reservation A receiver uses this call to make a resource reservation
for the session registered as `session-id'. The style for the session registered as `session-id'. The style
parameter indicates the reservation style. The rest of parameter indicates the reservation style. The rest of
the parameters depend upon the style, but generally these the parameters depend upon the style, but generally these
will include appropriate flowspecs and filter specs. will include appropriate flowspecs, filter specs, and
possibly receiver policy data objects.
The first RESERVE call will initiate the periodic The first RESERVE call will initiate the periodic
transmission of RESV messages. A later RESERVE call may transmission of RESV messages. A later RESERVE call may
be given to modify the parameters of the earlier call (but be given to modify the parameters of the earlier call (but
note that changing the reservations may result in note that changing the reservations may result in
admission control failure, depending upon the style). admission control failure, depending upon the style).
The RESERVE call returns immediately. Following a RESERVE The RESERVE call returns immediately. Following a RESERVE
call, an asynchronous ERROR/EVENT upcall may occur at any call, an asynchronous ERROR/EVENT upcall may occur at any
time. time.
skipping to change at page 39, line 30 skipping to change at page 50, line 4
o Release o Release
Call: RELEASE( session-id ) Call: RELEASE( session-id )
This call will terminate RSVP state for the session This call will terminate RSVP state for the session
specified by session-id. It may send appropriate teardown specified by session-id. It may send appropriate teardown
messages and will cease sending refreshes for this messages and will cease sending refreshes for this
session-id. session-id.
o Error/Event Upcalls o Error/Event Upcalls
Upcall: <Upcall_Proc>( ) -> session-id, Info_type,
Call: <Upcall_Proc> (session-id, Info_type, List_count [ Error_code , Error_value , LUB-Used, ]
[ ,Error_code ,Error_value ,LUB-flag ] List_count, [ Flowspec_list,]
[ ,Filter_spec_list ] [ ,Flowspec_list ] [ Filter_spec_list, ] [ Advert_list, ]
[ ,Advert_list ] ) [ Policy_data ]
Here "Upcall_Proc" represents the upcall procedure whose Here "Upcall_Proc" represents the upcall procedure whose
address was supplied in the REGISTER call. address was supplied in the REGISTER call.
This upcall may occur asynchronously at any time after a This upcall may occur asynchronously at any time after a
REGISTER call and before a RELEASE call, to indicate an REGISTER call and before a RELEASE call, to indicate an
error or an event. Currently there are three upcall error or an event. Currently there are three upcall
types, distinguished by the Info_type parameter: types, distinguished by the Info_type parameter:
1. Info_type = Path Event 1. Info_type = Path Event
A Path Event upcall indicates the receipt of a PATH A Path Event upcall indicates to a receiver
message, indicating to the application that there is application that there is at least one active sender.
at least one active sender. This upcall provides It results from receipt of the first PATH message for
synchronizing information to the receiver this session.
application, and it may also provide parallel lists
of senders (in Filter_spec_list), traffic
descriptions (in Flowspec_list), and service
advertisements (in Advert_list). 'List_count' is the
number in each list; where these objects are
missing, corresponding null objects must appear.
Error_code and Error_value, and LUB-flag should be This upcall provides synchronizing information to the
ignored in a Path Event upcall. receiver application, and it may also provide
parallel lists of senders (in Filter_spec_list),
traffic descriptions (in Flowspec_list), and service
advertisements (in Advert_list). `List_count'will be
the number in each list; where these objects are
missing, corresponding null objects must appear. The
Error_code, Error_value, LUB-Used flag, and
Policy_data parameters will be undefined in this
upcall.
2. Info_type = Path Error 2. Info_type = Resv Event
An Path Error event indicates an error in processing A Resv Event upcall indicates to a sender application
a sender descriptor originated by this sender. The that a reservation for this session in place along
Error_code parameter will define the error, and the entire path to at least one receiver. It is
triggered by the receipt of the first reservation
message or by modification of previous reservation
state, for this session.
`List_count' will be 1, and Flowspec_list will
contain one FLOWSPEC, the effective QoS that would be
applicable to the application itself.
Filter_spec_list and Advert_list will contain one
NULL object. The Error_code, Error_value, LUB-Used
flag, and Policy_data parameters will be undefined in
this upcall.
3. Info_type = Path Error
An Path Error event indicates an error in sender
information that was specified in the REGISTER call.
The Error_code parameter will define the error, and
Error_value may supply some additional (perhaps Error_value may supply some additional (perhaps
system-specific) data about the error. `List_count' system-specific) data about the error. `List_count'
will be 1, and Filter_spec_list and Flowspec_list will be 1, and Filter_spec_list and Flowspec_list
will contain the Sender_Template and the Sender_Tspec will contain the Sender_Template supplied in the
supplied in the REGISTER call; Advert_list will REGISTER call; Sender_Tspec and Advert_list will each
contain one NULL object. contain one NULL object. The Policy_data parameter
will be undefined in this upcall.
3. Info_type = Resv Error 4. Info_type = Resv Error
An Resv Error event indicates an error in processing An Resv Error event indicates an error in processing
a RESV message to which this application contributed. a reservation message to which this application
The Error_code parameter will define the error, and contributed. The Error_code parameter will define
Error_value may supply some additional (perhaps the error, and Error_value may supply some additional
system-specific) data on the error. (perhaps system-specific) data on the error.
`List_count' will be 1, and Filter_spec_list and Filter_spec_list and Flowspec_list will contain the
Flowspec_list will contain one FILTER_SPEC and one FILTER_SPEC and FLOWSPEC objects from the error flow
FLOWSPEC object. These objects are taken from the descriptor (see Section 4.1.5). List_count will
RESV message that caused the error (unless the LUB- specify the number of FILTER_SPECS in
flag is on, in which case FLOWSPEC may differ). Filter_spec_list, while there will be one FLOWSPEC in
Flowspec_list. The Policy_data parameter will be
undefined in this upcall.
5. Info_type = Policy Data
A Policy Information upcall passes a Policy_data
parameter containing policy information (accounting,
current costs, prices, quota, etc.) that arrived at
the receiver.
List_count will be zero, and the Error_code,
Error_value, and LUB-Used flag parameters will be
undefined in this upcall.
Although RSVP messages indicating path events or errors Although RSVP messages indicating path events or errors
may be received periodically, the API should make the may be received periodically, the API should make the
corresponding asynchronous upcall to the application only corresponding asynchronous upcall to the application only
on the first occurrence, or when the information to be on the first occurrence, or when the information to be
reported changes. reported changes.
4.6.2 RSVP/Traffic Control Interface 4.6.2 RSVP/Traffic Control Interface
In each router and host, enhanced QoS is achieved by a group of In each router and host, enhanced QoS is achieved by a group of
inter-related traffic control functions: a packet classifier, inter-related traffic control functions: a packet classifier,
an admission control module, and a packet scheduler. This an admission control module, and a packet scheduler. This
section describes a generic RSVP interface to traffic control. section describes a generic RSVP interface to traffic control.
1. Make a Reservation 1. Make a Reservation
Call: Rhandle = TC_AddFlowspec( Flowspec, Police_Flag Call: Rhandle = TC_AddFlowspec( Interface, Flowspec
[ , Sender_Tspec] [ , Sender_Tspec]
[ , SD_rank , SD_end_flag ] ) , E_Police_Flag , M_Police_Flag )
This call passes a Flowspec defining a desired QoS to This call passes a Flowspec defining a desired QoS to
admission control. It may also pass Sender_Tspec, the admission control. It may also pass Sender_Tspec, the
maximum traffic characteristics computed over the maximum traffic characteristics computed over the
SENDER_TSPECs of senders that will contribute data packets SENDER_TSPECs of senders that will contribute data packets
to this reservation. Police_Flag is a Boolean parameter to this reservation.
that indicates whether traffic policing should be applied
at this point.
The SD_rank and SD_end_flag fields are used for a member E_Police_Flag and M_Police_Flag are Boolean parameters.
of a session group. SD_rank is the rank value from the E_Police_Flag is on if this is an entry node, while
SESSION_GROUP object. The call is made with each of the M_Police is on if this node is an interior data merge
sessions in the group, and SD_end_flag is set true for the point for a shared reservation style. These flags are
last one. used to enable traffic policing or shaping when
appropriate, in accordance with the service.
This call returns an error code if Flowspec is malformed This call returns an error code if Flowspec is malformed
or if the requested resources are unavailable. Otherwise, or if the requested resources are unavailable. Otherwise,
it establishes a new reservation channel corresponding to it establishes a new reservation channel corresponding to
Rhandle. It returns the opaque number Rhandle for Rhandle. It returns the opaque number Rhandle for
subsequent references to this reservation. subsequent references to this reservation.
2. Add Filter 2. Modify Reservation
Call: TC_AddFilter( Rhandle, Session, Filterspec ) Call: TC_ModFlowspec( Rhandle, new_Flowspec
This call is used to define a filter corresponding to the [ , Sender_Tspec] , Police_flag )
given handle, following a successful TC_AddFlowspec call.
3. Modify or Delete Filter This call can modify an existing reservation. If
new_Flowspec is included, it is passed to Admission
Control; if it is rejected, the current flowspec is left
in force. The corresponding filter specs, if any, are not
affected.
Call: TC_ModFilter( Rhandle, Session, 3. Delete Flowspec
[ new_Filterspec] ) Call: TC_DelFlowspec( Rhandle )
This call can modify an existing filter or replace an This call will delete an existing reservation, including
existing filter with no filter (i.e., delete the filter). the flowspec and all associated filter specs.
4. Modify or Delete Flowspec 4. Add Filter Spec
Call: TC_ModFlowspec( Rhandle Call: FHandle = TC_AddFilter( Rhandle, Session , FilterSpec )
[, new_Flowspec [ ,Sender_Tspec]] ) This call is used to associate an additional filter spec
with the reservation specified by the given Rhandle,
following a successful TC_AddFlowspec call. This call
returns a filter handle FHandle.
This call can modify an existing reservation or delete the 5. Delete Filter Spec
reservation. If new_Flowspec is included, it is passed to
Admission Control; if it is rejected, the current flowspec
is left in force. If new_Flowspec is omitted, the
reservation is deleted and Rhandle is invalidated.
5. OPWA Update Call: TC_DelFilter( FHandle )
This call is used to remove a specific filter, specified
by FHandle.
6. OPWA Update
Call: TC_Advertise( interface, Adspec Call: TC_Advertise( interface, Adspec
[ ,Sender_TSpec ] ) -> New_Adspec [ ,Sender_TSpec ] ) -> New_Adspec
This call is used for OPWA to compute the outgoing This call is used for OPWA to compute the outgoing
advertisement New_Adspec for a specified interface. advertisement New_Adspec for a specified interface.
Sender_TSpec is also passed if it is available.
6. Initialize Traffic Control 7. Preemption Upcall
Call: TC_Initialize(interface ) Upcall: TC_Preempt() -> RHandle, Reason_code
This call is used when RSVP initializes its state, to In order to grant a new reservation request, the admission
clear out all existing classifier and/or packet scheduler control and/or policy modules may be allowed to preempt an
state for a specified interface. existing reservation. This might be reflected in an
upcall to RSVP, passing the RHandle of the preempted
reservation, and some indication of the reason.
4.6.3 RSVP/Routing Interface 4.6.3 RSVP/Routing Interface
An RSVP implementation needs the following support from the An RSVP implementation needs the following support from the
packet forwarding and routing mechanism of the node. packet forwarding and routing mechanisms of the node.
o Promiscuous receive mode for RSVP messages o Promiscuous receive mode for RSVP messages
Any datagram received for IP protocol 46 is to be diverted Any datagram received for IP protocol 46 must be diverted
to the RSVP program for processing, without being to the RSVP program for processing, without being
forwarded. The identity of the interface on which it is forwarded. The identity of the interface on which it is
received should also be available to the RSVP daemon. received should also be available to the RSVP daemon.
o Route discovery o Route Query
RSVP must be able to discover the route(s) that the
routing algorithm would have used for forwarding a
specific datagram.
GetUcastRoute( DestAddress ) -> OutInterface RSVP must be able to query the routing daemon for the
route(s) for forwarding a specific datagram.
GetMcastRoute( SrcAddress, DestAddress ) Ucast_Route_Query( DestAddress, Notify_flag ) -> OutInterface
Mcast_Route_Query( SrcAddress, DestAddress, Notify_flag )
-> OutInterface_list -> OutInterface_list
o Route Change Notification If the Notify_flag is True, routing will save state
necessary to issue unsolicited route change notification
callbacks whenever the specified route changes. This will
continue until routing receives a route query call with
the Notify_Flag set False.
Routing may provide an asynchronous notification to RSVP o Route Change Notification
that a specified route has changed.
New_Ucast_Route( DestAddress ) -> new_OutInterface If requested by a route query with the Notify_flag True,
the routing daemon may provide an asynchronous callback to
RSVP that a specified route has changed.
New_Mcast_Route( SrcAddress, DestAddress ) Ucast_Route_Change( ) -> DestAddress, OutInterface
-> new_OutInterface_list Mcast_Route_Change( )
-> SrcAddress, DestAddress, OutInterface_list
o Outgoing Link Specification o Outgoing Link Specification
RSVP must be able to force a (multicast) datagram to be RSVP must be able to force a (multicast) datagram to be
sent on a specific outgoing virtual link, bypassing the sent on a specific outgoing virtual link, bypassing the
normal routing mechanism. A virtual link may be a real normal routing mechanism. A virtual link may be a real
outgoing link or a multicast tunnel. Outgoing link outgoing link or a multicast tunnel. Outgoing link
specification is necessary because RSVP may send different specification is necessary because RSVP may send different
versions of outgoing PATH messages on different versions of outgoing PATH messages for the same source and
interfaces, for the same source and destination addresses, destination addresses on different interfaces. It is also
and to avoid loops. necessary in some cases to avoid routing loops.
o Discover Interface List o Discover Interface List
RSVP must be able to learn what real and virtual RSVP must be able to learn what real and virtual
interfaces exist. interfaces are active, with their IP addresses.
5. Message Processing Rules 5. Message Processing Rules
This generic description of RSVP operation assumes the following data This generic description of RSVP operation assumes the following data
structures. An actual implementation may use additional or different structures. An actual implementation may use additional or different
structures to optimize processing. structures to optimize processing.
o PSB -- Path State Block o PSB -- Path State Block
Each PSB holds path state for a particular (session, sender) Each PSB holds path state for a particular (session, sender)
pair, defined by SESSION and SENDER_TEMPLATE objects, pair, which are defined by SESSION and SENDER_TEMPLATE objects,
respectively. PSB contents include a PHOP object and possibly respectively. PSB contents include a PHOP object and possibly
SENDER_TSPEC, CREDENTIAL, and/or ADVERT objects from PATH SENDER_TSPEC, POLICY_DATA, and/or ADSPEC objects from PATH
messages. messages.
o RSB -- Reservation State Block o RSB -- Reservation State Block
RSB's are used to hold reservation state. Each RSB holds Each RSB holds reservation state for a particular 4-tuple:
reservation state for the 4-tuple: (session, next hop, style, (session, next hop, style, filterspec), which are defined in
filterspec), defined in SESSION, NHOP (i.e., RSVP_HOP), STYLE, SESSION, NHOP, STYLE, and FILTER_SPEC objects, respectively.
and FILTER_SPEC objects, respectively. We assume that RSB RSB contents also include a FLOWSPEC object and may include a
contents include the outgoing interface OI that is implied by POLICY_DATA object. We assume that RSB contents include the
NHOP. RSB contents also include a FLOWSPEC object and may outgoing interface OI that is implied by NHOP.
include a CERTIFICATE object.
MESSAGE ARRIVES MESSAGE ARRIVES
Verify version number, checksum, and length fields of common header, Verify version number, checksum, and length fields of common header,
and discard message if it fails. and discard message if any mismatch is found.
Further processing depends upon message type. Further processing depends upon message type.
PATH MESSAGE ARRIVES PATH MESSAGE ARRIVES
Start with the Refresh_Needed flag off. Start with the Refresh_Needed flag off.
Each sender descriptor object sequence in the message defines a Each sender descriptor object sequence in the message defines a
sender. Process each sender as follows. sender. Process each sender as follows, starting the
Path_Refresh_Needed and Resv_Refresh_Needed flags off.
1. If there is a CREDENTIAL object, verify it; if it is 1. If there is a POLICY_DATA object, verify it; if it is
unacceptable, build and send a PERR message, drop the PATH unacceptable, build and send a "Administrative Rejection"
message, and return. PERR message, drop the PATH message, and return.
2. If there is no path state block (PSB) for the (session, 2. Call the appropriate Route_Query routine, using DestAddress
sender) pair then: from SESSION and (for multicast routing) SrcAddress from
SENDER_TEMPLATE. This provides a routing bit mask
ROUTE_MASK and (for a multicast destination) an
EXPECTED_INTERFACE.
3. If the message arrived on an interface different from
EXPECTED_INTERFACE, drop it and return.
4. Search for a path state block (PSB) whose (SESSION,
SENDER_TEMPLATE) pair matches the corresponding objects in
the message.
If there is a match considering wildcards in the
SENDER_TEMPLATE objects, but the two SENDER_TEMPLATEs
differ, build and send a "Ambiguous Path" PERR message,
drop the PATH message, and return.
5. If there is no matching PSB for the (SESSION,
SENDER_TEMPLATE) pair then:
o Create a new PSB. o Create a new PSB.
o Set a cleanup timer for the PSB. If this is the first o Set a cleanup timer for the PSB. If this is the first
PSB for the session, set a refresh timer for the PSB for the session, set a refresh timer for the
session. session.
o Copy PHOP into the PSB. Copy into the PSB any of the o Copy the SESSION, TIME_VALUES, and PHOP objects into
following objects that are present in the message: the PSB. Copy into the PSB any of the following
CREDENTIAL, SENDER_TSPEC, and/or ADVERT. Copy the objects that are present: POLICY_DATA, SENDER_TSPEC,
EntryPolice flag from the common header into the PSB. and ADSPEC.
o Call the appropriate route discovery routine, using o Store ROUTE_MASK and EXPECTED_INTERFACE in the PSB.
DestAddress from SESSION and (for multicast routing)
SrcAddress from SENDER_TEMPLATE. Store the resulting
routing bit mask ROUTE_MASK in the PSB.
3. Otherwise (there is a matching PSB): o Turn on the Path_Refresh_Needed flag.
o If CREDENTIAL differs between message and PSB, verify 6. Otherwise (there is a matching PSB):
new CREDENTIAL. If it is acceptable, copy it into
PSB. Otherwise, build and send a PERR message for
"Bad Credential", drop the PATH message, and return.
o Restart cleanup timer. o Restart cleanup timer.
o Update the PSB with values from the message, as o If the SENDER_TSPEC and/or ADSPEC values differ
follows. Copy the ADVERT object, if any, into the between the message and the PSB, copy the new values
PSB. Copy the EntryPolice flag into the PSB. into the PSB and turn on the Path_Refresh_Needed flag.
Note that if SEND_TSPEC has changed, reservations
matching S may also change; this may be deferred until
a RESV refresh arrives.
If the values of PHOP or SEND_TSPEC differ between the o If the new ROUTE_MASK differs from that stored in the
message and the PSB, copy the new values into the PSB PSB, turn on the Path_Refresh_Needed flag, and store
and turn on the Refresh_Needed flag. If SEND_TSPEC the new ROUTE_MASK into the PSB.
has changed, reservations matching S may also change;
this may be deferred until a RESV refresh arrives.
o Call the appropriate route discovery routine and o If the new EXPECTED_INTERFACE differs from that stored
compare the route mask with the ROUTE_MASK value in the PSB, turn on the Resv_Refres_Needed flag and
already in the PSB; if a new bit (interface) has been store the new EXPECTED_INTERFACE value into the PSB.
added, turn on the Refresh_Needed flag. Store new
ROUTE_MASK in the PSB.
4. If the Refresh_Needed flag is now set, execute the PATH 7. Save the IP TTL with which the message arrived in the PSB .
8. If the Refresh_Needed flag is now set, execute the PATH
REFRESH event sequence (below); however, send no PATH
refresh messages out the interface through which the PATH
message arrived.
9. If the Resv_Needed flag is now set, execute the RESV
REFRESH event sequence (below). REFRESH event sequence (below).
PATH TEAR MESSAGE ARRIVES PATH TEAR MESSAGE ARRIVES
o If there is no path state for this destination, drop the o If there is no path state for this destination, drop the
message and return. message and return.
o Forward a copy of the PTEAR message using the same rules as o Forward a copy of the PTEAR message using the same rules as
for a PATH message (see PATH REFRESH). for a PATH message (see PATH REFRESH).
o Each sender descriptor in the PTEAR message contains a o Each sender descriptor in the PTEAR message contains a
SENDER_TEMPLATE object defines a sender S; process it as SENDER_TEMPLATE object defining a sender S; process it as
follows. follows.
1. Locate the PSB for the pair: (session, S). If none 1. Locate the PSB for the pair: (session, S). If none
exists, continue with next sender descriptor. exists, continue with next sender descriptor.
2. Examine the RSB's for this session and delete any 2. Examine the RSB's for this session and delete
reservation state associated with sender S, depending reservation state that is associated with sender S and
upon the reservation style. For example: no other sender.
Delete a WF reservation for which S is the only
sender.
Delete an FF reservation for S.
3. Delete the PSB. 3. Delete the PSB.
o Drop the PTEAR message and return.
PATH ERROR MESSAGE ARRIVES PATH ERROR MESSAGE ARRIVES
o If there are no existing PSB's for SESSION then drop the o If there are no existing PSB's for SESSION then drop the
PERR message and return. PERR message and return.
o Look up the PSB for (session, sender); sender is defined by o Look up the PSB for (session, sender); sender is defined by
SENDER_TEMPLATE. If no PSB is found, drop PERR message and SENDER_TEMPLATE. If no PSB is found, drop PERR message and
return. return.
o If PHOP in PSB is local API, deliver error to application o If PHOP in PSB is local API, deliver error to application
via an upcall: via an upcall:
Call: <Upcall_Proc>( session-id, Path Error, 1, Call: <Upcall_Proc>( session-id, Path Error,
Error_code, Error_value, 0, Error_code, Error_value, 0,
SENDER_TEMPLATE, NULL, NULL) 1, SENDER_TEMPLATE, NULL, NULL, NULL)
Note that CREDENTIAL, SENDER_TSPEC, and ADVERT objects in Any POLICY_DATA, SENDER_TSPEC, or ADSPEC object in the
the message is ignored. message is ignored.
Otherwise (PHOP is not local API), forward a copy of the o Otherwise (PHOP is not local API), forward a copy of the
PERR message to the PHOP node. PERR message to the PHOP node.
RESV MESSAGE ARRIVES RESV MESSAGE ARRIVES
A RESV message arrives through outgoing interface OI. A RESV message arrives through outgoing interface OI.
o Check the SESSION object. o Check the SESSION object.
If there are no existing PSB's for SESSION then build and If there are no existing PSB's for SESSION then build and
send a RERR message (as described later) specifying "No send a RERR message (as described later) specifying "No
Path Information", drop the RESV message, and return. path information", drop the RESV message, and return.
However, do not send the RERR message if the style has However, do not send the RERR message if the style has
wildcard reservation scope and this is not the receiver wildcard reservation scope and this is not the receiver
host itself. host itself.
o Check the STYLE object. o Check the STYLE object.
If style in the message conflicts with the style of any If the style in the message conflicts with the style of any
reservation for this session in place on any interface, reservation for this session in place on any interface,
reject the RESV message by building and sending a RERR reject the RESV message by building and sending a RERR
message specifying "Bad Style", drop the RESV message, and message specifying "Conflicting Style", drop the RESV
return. message, and return.
o Check the CREDENTIAL object.
Verify the CREDENTIAL field (if any) to check permission to
create a reservation. [This check may also involve the
CREDENTIAL fields from the PSB's in the scope of this
reservation; in that case, it would better fit below in
processing the individual flow descriptors.]
o Check for path state o Check the POLICY_DATA object.
If there are no PSB's matching the scope of this Verify the POLICY_DATA field (if any) to check permission
reservation, build and send a RERR message specifying "No to create a reservation. If it is unacceptable, build and
Sender Information", drop the RESV message, and return. send an "Administrative rejection" RERR message, drop the
RESV message, and return.
o Make reservations o Make reservations
Process the style-specific tail sequence. Process the STYLE object and the flow descriptor list.
For FF style, execute the following steps for each b flow For FF style, execute the following steps for each b flow
descriptor, i.e., each (FLOWSPEC, FILTERSPEC) pair. For WF descriptor, i.e., for each (FLOWSPEC, FILTER_SPEC) pair.
style execute the following once, using some internal For SE style, execute the following steps for each
placeholder "WILD_FILTER" for FILTERSPEC to indicate FILTER_SPEC in the list, using the given FLOWSPEC. For WF
wildcard scope. style, execute the following once, using an internal
placeholder "WILD_FILTER" for FILTERSPEC if it is omitted.
1. Find or create a reservation state block (RSB) for the 1. Find or create a reservation state block (RSB) for the
4-tuple: (SESSION, NHOP, style, FILTERSPEC). 4-tuple: (SESSION, NHOP, style, FILTER_SPEC).
2. Start or restart the cleanout timer on the RSB. 2. Start or restart the cleanout timer on the RSB. Start
a refresh timer for this session if none was started.
3. Start a refresh timer for this session if none was 3. If the RSB existed and contains state matching this
started. flow descriptor, continue with the next flow
descriptor. Otherwise (the state is new or modified),
continue processing the current flow descriptor with
the following steps.
4. If the RSB existed and if FLOWSPEC and the 4. Scan the set of PSBs (senders) whose SENDER_TSPECs
SENDER_TSPEC objects are unchanged, drop the RESV match FILTER_SPEC.
message and return.
5. Compute Sender_Tspec as the maximum over the - If this set is empty, build and send an error
SENDER_TSPEC objects of the PSB's within the scope of message specifying "No sender information", and
the reservation. continue with the next flow descriptor.
6. Set Police_flag on if any PSB's in the scope have the - If this set contains more than one PSB and if the
EntryPolice flag on, or if the style is WF and there style has the explicit option (e.g., FF or SE),
is more than one PSB in the scope, otherwise off. build and send an error message specifying
"Ambiguous filter spec" and continue with the
next flow descriptor.
7. Computer K_Flowspec, the effective kernel flowspec, as - Set K_E_Police_flag on if any of these PSBs have
the maximum of the FLOWSPEC values in all RSB's for the E_Police flag on, otherwise set
the same (SESSION, OI, FILTERSPEC) triple. Similarly, K_E_Police_flag off. Set K_M_Police_flag on if
the kernel filter spec K_filter is either the the style has wildcard scope and there is more
FILTER_SPEC object under consideration (unitary than one PSB in the scope, otherwise, set
scope), or it is WILD_FILTER (wildcard scope). K_M_Police_flag off.
If there was no previous kernel reservation in place - Compute K_Tspec as the sum of the SENDER_TSPEC
for (SESSION, OI, FILTERSPEC), call the kernel objects, if any, in this set of PSBs.
interface module:
TC_AddFlowspec( Sender_Tspec, K_flowspec, Police_Flag ) 5. Compute the parameters for the effective reservation,
by considering all RSB's for the same (SESSION, OI,
FILTERSPEC) triple.
- Compute the effective kernel flowspec,
K_Flowspec, as the maximum of the FLOWSPEC values
in these RSB's
- Compute the effective kernel filter spec K_Filter
by merging the FILTER_SPEC objects in these
RSB's.
6. If this reservation has wildcard scope and this is not
the first flow descriptor in the message, one of the
filter specs must have changed; delete the old one and
install the new:
TC_DelFilter( old_Fhandle );
Fhandle = TC_AddFilter( Rhandle, SESSION, K_filter)
Then continue with the next flow descriptor.
7. Otherwise, if there was no previous kernel reservation
in place for (SESSION, OI, FILTERSPEC), call the
kernel interface module:
Rhandle = TC_AddFlowspec( OI, K_flowspec, K_Tspec,
K_E_Police_flag, K_M_Police_flag )
If this call fails, build and send a RERR message If this call fails, build and send a RERR message
specifying "Admission control failed", drop the RESV specifying "Admission control failed", and continue
message, and return. Otherwise, record the kernel with the next flow descriptor. Otherwise, record the
handle K_handle returned by the call in the RSB(s). kernel handle Rhandle returned by the call in the
Then call: RSB(s). Then call:
TC_AddFilter( K_handle, K_Filter) TC_AddFilter( Rhandle, SESSION, K_Filter)
to set the filter, drop the RESV message and return. to set the filter, and continue with the next flow
descriptor.
/item However, if there was a previous kernel However, if there was a previous kernel reservation
reservation with handle K_handle, call the kernel with handle Rhandle, and the flowspec has changed,
interface module: call:
TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec) TC_ModFlowspec( Rhandle, K_Flowspec, K_Tspec,
K_E_Police_flag, K_M_Police_flag )
If this call fails, build and send a RERR message If this call fails, build and send a RERR message
specifying "Admission control failed". In any case, specifying "Admission control failed". In any case,
drop the RESV message and return. drop the RESV message and return.
If the flowspec is unchanged but the filter spec has
changed, install the new:
TC_DelFilter( old_Fhandle )
Fhandle = TC_AddFilter( Rhandle, SESSION, K_filter)
Then continue with the next flow descriptor.
If processing a RESV message finds an error, a RERR message is If processing a RESV message finds an error, a RERR message is
created containing flow descriptor and an ERRORS object. The created containing flow descriptor and an ERRORS object. The
Error Node field of the ERRORS object (see Appendix A) is set to Error Node field of the ERRORS object (see Appendix A) is set to
the IP address of OI, and the message is sent unicast to NHOP. the IP address of OI, and the message is sent unicast to NHOP.
created
RESV TEAR MESSAGE ARRIVES RESV TEAR MESSAGE ARRIVES
A RTEAR message arrives on outgoing interface OI. A RTEAR message arrives on outgoing interface OI.
o If there are no existing PSB's for SESSION then drop the o If there are no existing PSB's for SESSION then drop the
RTEAR message and return. RTEAR message and return.
o Process the style-specific tail sequence to tear down o Process the flow descriptor list sequence to tear down
reservations. reservations.
For FF style, execute the following steps for each b flow For FF style, execute the following steps for each b flow
descriptor, i.e., each (FLOWSPEC, FILTERSPEC) pair. For WF descriptor, i.e., each (FLOWSPEC, FILTERSPEC) pair. For WF
style execute the following once, using some internal style execute the following once, using some internal
placeholder "WILD_FILTER" for FILTERSPEC to indicate placeholder "WILD_FILTER" for FILTERSPEC to indicate
wildcard scope. wildcard scope.
1. Find matching RSB(s) for the 4-tuple: (SESSION, NHOP, 1. Find matching RSB(s) for the 4-tuple: (SESSION, NHOP,
style, FILTERSPEC). If no RSB is found, continue with style, FILTERSPEC). If no RSB is found, continue with
next flow descriptor, if any. next flow descriptor, if any.
2. Delete the RSB(s). 2. Delete the RSB(s).
3. If there are no more RSBs for the same (SESSION, OI, 3. If there are no more RSBs for the same (SESSION, OI,
FILTERSPEC/) triple, call the kernel interface module: FILTERSPEC/) triple, call the kernel interface module:
TC_ModFlowspec( K_handle ) TC_DelFlowspec( K_handle )
to delete the reservation. Then build and forward a to delete the reservation. Then build and forward a
new RERR message. new RTEAR message.
- WF style: send a copy to each PHOP among all - WF style: send a copy to each PHOP among all
matching senders. matching senders.
- FF style: Send to PHOP of matching PSB. - FF style: Send to PHOP of matching PSB.
4. Otherwise (there are other RSB's for the same 4. Otherwise (there are other RSB's for the same
reservation), recompute K_Flowspec and call the kernel reservation), recompute K_Flowspec and call the kernel
interface module: interface module:
skipping to change at page 50, line 4 skipping to change at page 63, line 13
- WF style: send a copy to each PHOP among all - WF style: send a copy to each PHOP among all
matching senders. matching senders.
- FF style: Send to PHOP of matching PSB. - FF style: Send to PHOP of matching PSB.
4. Otherwise (there are other RSB's for the same 4. Otherwise (there are other RSB's for the same
reservation), recompute K_Flowspec and call the kernel reservation), recompute K_Flowspec and call the kernel
interface module: interface module:
TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec) TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec)
to update the reservation, and then execute the RESV to update the reservation, and then execute the RESV
REFRESH sequence (below). If this kernel call fails, REFRESH sequence (below). If this kernel call fails,
return; the prior reservation will remain in place. return; the prior reservation will remain in place.
RESV ERROR MESSAGE ARRIVES RESV ERROR MESSAGE ARRIVES
o Call the appropriate route discovery routine, using o Call the appropriate route discovery routine, using
DestAddress from SESSION and (for multicast routing) DestAddress from SESSION and (for multicast routing)
SrcAddress from the Error Node field in the ERRORS object. SrcAddress from the Error Node Address field in the ERRORS
Let the resulting routing bit mask be M. object. Let the resulting routing bit mask be M.
o Determine the set of RSBs matching the triple: (SESSION, o Determine the set of RSBs matching the triple: (SESSION,
style, FILTERSPEC). If no RSB is found, drop RERR message style, FILTERSPEC). If no RSB is found, drop RERR message
and return. and return.
Recompute the maximum over the FLOWSPEC objects of this set Recompute the maximum over the FLOWSPEC objects of this set
of RSB's. If the LUB was used in this computation, turn on of RSB's. If the LUB was used in this computation, turn on
the LUB-flag in the received RESV message. the LUB-Used flag in the received RESV message.
o Delete from the set of RSVs any whose OI does not appear in o Delete from the set of RSVs any whose OI does not appear in
the bit mask M and whose NHOP is not the local API. If the bit mask M and whose NHOP is not the local API. If
none remain, drop RERR message and return. none remain, drop RERR message and return.
For each PSB in the resulting set, do the following step. For each PSB in the resulting set, do the following step.
o If NHOP in PSB is local API, deliver error to application o If NHOP in PSB is local API, deliver error to application
via an upcall: via an upcall:
Call: <Upcall_Proc>( session-id, Resv Error, 1, Call: <Upcall_Proc>( session-id, Resv Error, 1,
Error_code, Error_value, LUB-flag, Error_code, Error_value, LUB-Used,
FILTER_SPEC, FLOWSPEC, NULL) FILTER_SPEC, FLOWSPEC, NULL)
Here LUB-flag is taken from the received packet, as Here LUB-Used flag is taken from the received packet, as
possibly modified above. possibly modified above.
Otherwise (NHOP is not local API), forward a copy of the Otherwise (NHOP is not local API), forward a copy of the
RERR message to the PHOP node. RERR message to the PHOP node.
PATH REFRESH PATH REFRESH
This sequence may be entered by either the expiration of the path This sequence may be entered by either the expiration of the path
refresh timer for a particular session, or immediately as the result refresh timer for a particular session, or immediately as the result
of processing a PATH message turning on the Refresh_Needed flag. of processing a PATH message turning on the Refresh_Needed flag.
For each virtual outgoing interface ("vif") V, build a PATH message For each outgoing interface OI, build a PATH message and send it to
and send it to V. To build the message, consider each PSB whose OI. To build the message, consider each PSB whose ROUTE_MASK
ROUTE_MASK includes V, and do the following: includes OI, and do the following:
o Pass the ADVERT and SENDER_TSPEC objects present in the PSB to o Pass the ADSPEC and SENDER_TSPEC objects present in the PSB to
the kernel call TC_Advertise, and get back a modified ADVERT the kernel call TC_Advertise, and get back a modified ADSPEC
object. Pack this modified object into the PATH message being object. Pack this modified object into the PATH message being
built. built.
o Create a sender descriptor sequence containing the o Create a sender descriptor sequence containing the
SENDER_TEMPLATE, CREDENTIAL, and SENDER_TSPEC objects, if SENDER_TEMPLATE, SENDER_TSPEC, and POLICY_DATA objects, if
present in the PSB. Pack the sender descriptor into the PATH present in the PSB. Pack the sender descriptor into the PATH
message being built. message being built.
o If the PSB has the EntryPolice flag on and if interface V is not o If the PSB has the E_Police flag on and if interface OI is not
capable of policing, turn the EntryPolice flag on in the PATH capable of policing, turn the E_Police flag on in the PATH
message being built. message being built.
o Compute the IP TTL for the PATH message as one less than the
maximum of the TTL values from the senders included in the
message. However, if the result is zero, return without sending
the PATH message.
o If the maximum size of the PATH message is reached, send the o If the maximum size of the PATH message is reached, send the
packet out interface V and start packing a new one. packet out interface OI and start packing a new one.
RESV REFRESH RESV REFRESH
This sequence may be entered by either the expiration of the This sequence may be entered by either the expiration of the
reservation refresh timer for a particular session, or immediately as reservation refresh timer for a particular session, or immediately as
the result of processing a RESV message. the result of processing a RESV or RTEAR message.
Each PSB for this session is considered in turn, to compute a style- For each PHOP defined by the path state, scan the RSBs, merge the
dependent tail sequence. These sequences for a given PHOP are then style, FLOWSPECs and FILTER_SPECs appropriately, build a new RESV
packed into the same message(s) and sent to that PHOP. The logic is message, and send it to PHOP. Each message carries a NHOP object
somewhat different depending upon whether the scope of the containing the local address of the interface through which it is
reservations is wildcard or not (they may not be mixed). sent.
For each PSB that does not correspond to the API, do the following. The details of building the RESV messages depend upon the
shared/distinct option of the style. For each PHOP, do the
following:
o Compute (FLOWSPEC, FILTER_SPEC) Pair o Distinct style
Select each RSB in whose reservation scope the PSB falls, and Select each sender Si (PSB) for PHOP, and do the following:
compute the maximum over the FLOWSPEC objects of this set of
RSB's. Also, select an appropriate FILTER_SPEC. The scope
depends upon the style and the filter spec of the RSB:
1. WF: Select every RSB whose OI matches a bit in the 1. Select all RSB's whose FILTER_SPECs match the
ROUTE_MASK of the PSB. SENDER_TEMPLATE object for Si and whose OI matches a bit in
the ROUTE_MASK of the PSB for Si.
In this case, FILTER_SPEC is the standard WILD_FILTER. 2. Compute the maximum over the FLOWSPEC objects of this set
of RSB's, and merge their FILTER_SPEC, STYLE, and
POLICY_DATA objects.
2. FF: Select every RSB whose FILTER_SPEC matches 3. Append the (FLOWSPEC, FILTER_SPEC pair) to the RESV message
SENDER_TEMPLATE in the RSB. This matching process should being built for destination PHOP. When the packet fills,
consider wildcards. or upon completion of all PSB's with the same PHOP, send
it.
In this case, FILTER_SPEC is taken from any of the matching o Shared style
RSB's. [?? Need to either 'merge' filter specs, which
probably means to remove gratuitous wildcards??]
This computation also yields a style (since style must be 1. Select each sender Si (PSB) for PHOP, and select all RSB's
consistent across RSB's for given session). [??Again, need that: (a) have an OI matching a bit in the ROUTE_MASK for
merging rules]] Si, and (b) contain at least one FILTER_SPEC that matches
the SENDER_TEMPLATE object for Si.
o Build RESV packets 2. For all selected RSB's for all Si corresponding to a given
PHOP:
Append this (FLOWSPEC, FILTER_SPEC pair) to the RESV message - Compute the maximum over the FLOWSPEC objects of this
being built for destination PHOP (from the PSB). When the set of RSB's.
packet fills, or upon completion of all PSB's with the same
PHOP, set the NHOP address in the message to the interface
address and send the packet out that interface to the PHOP
address.
appendix - Merge the metching FILTER_SPEC objects; this will in
6. Object Type Definitions general result in a list of non-overlapping
FILTER_SPECs, but where there are overlaps due to
wildcards, use the `wildest'.
C-types are defined for the two Internet address families IPv4 and - Merge the STYLE and POLICY_DATA objects.
IP6. To accomodate other address families, additional C-types could
easily be defined. These definitions are contained as an Appendix to
ease updating.
6.1 SESSION Class - Place the resulting merged objects into a RESV message
and send it to PHOP.
Currently, SESSION objects contain the pair: (DestAddress, 3. If the scope is wildcard, a forwarded RESV must contain a
DestPort), where DestAddress is the data destination address and SCOPE object. The set of IP addresses in the SCOPE object
DestPort is the UDP/TCP destination port. Other SESSION C-Types sent to a given PHOP is formed as follows.
could be defined in the future to support other demultiplexing
conventions in the transport-layer or application layer. - Take the union of the senders listed in SCOPE objects
in all RSB's.
- Intersect that set with the set of sender hosts listed
in path state for PHOP.
- If the resulting set is empty, no RESV should be
forwarded to this PHOP.
APPENDIX A. Object Definitions
C-Types are defined for the two Internet address families IPv4 and
IP6. To accomodate other address families, additional C-Types could
easily be defined. These definitions are contained as an Appendix,
to ease updating.
All unused fields should be sent as zero and ignored on receipt.
A.1 SESSION Class
SESSION Class = 1.
o IPv4/UDP SESSION object: Class = 1, C-Type = 1 o IPv4/UDP SESSION object: Class = 1, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) | | IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| //////////// | DestPort | | ////// | Flags | DestPort |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o IP6/UDP SESSION object: Class = 1, C-Type = 129 o IP/UDP SESSION object: Class = 1, C-Type = 2
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IP6 DestAddress (16 bytes) + + IP6 DestAddress (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| //////////// | DestPort | | /////// | Flags | DestPort |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
6.2 SESSION_GROUP Class
o IPv4 SESSION_GROUP Object: Class = 2, C-Type = 1: DestAddress
The IP unicast or multicast destination address of the
session.
Flags
0x01 = E_Police flag
The E_Police flag is used in PATH messages to determine
the effective "edge" of the network, to control traffic
policing. If the sender host is not itself capable of
traffic policing, it will set this bit on in PATH
messages it sends. The first node whose RSVP is capable
of traffic policing will do so (if appropriate to the
service) and turn the flag off.
[It might make more sense to include this flag in ADSPEC
object.]
DestPort
The UDP/TCP destination port for the session. Zero may be
used to indicate a `wildcard', i.e., any port.
Other SESSION C-Types could be defined in the future to
support other demultiplexing conventions in the transport-
layer or application layer.
A.2 RSVP_HOP Class
RSVP_HOP class = 3.
o IPv4 RSVP_HOP object: Class = 3, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 Reference DestAddress | | IPv4 Next/Previous Hop Address |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Session_Group ID | Count | Rank | | Logical Interface Handle |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o IP6 SESSION_GROUP Object: Class = 2, C-Type = 129: o IP6 RSVP_HOP object: Class = 3, C-Type = 2
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IP6 Reference DestAddress + + IP6 Next/Previous Hop Address +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Session-Group ID | Count | Rank | | Logical Interface Handle |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
6.3 RSVP_HOP Class
o IPv4 RSVP_HOP object: Class = 3, C-Type = 1 This object provides the IP address of the interface through which
the last RSVP-knowledgeable hop forwarded this message. The
Logical Interface Handle is a 32-bit number which may be used to
distinguish logical outgoing interfaces as described in Section
4.2; it should be identically zero if there is no logical
interface handle.
A.3 INTEGRITY Class
INTEGRITY class = 4.
See draft-ietf-rsvp-md5-00.txt.
A.4 TIME_VALUES Class
TIME_VALUES class = 5.
o TIME_VALUES Object: Class = 5, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 Next/Previous Hop Address | | Refresh Period |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o IP6 RSVP_HOP object: Class = 3, C-Type = 129 | Max Refresh Period |
+-------------+-------------+-------------+-------------+
Refresh Period
The refresh timeout period R used to generate this message;
in milliseconds.
Max Refresh Period
The largest R value that a node is allowed to apply to the
downstream state for this session. A node may refuse to
accept this requirement, by ignoring the message containing
this TIME_VALUES object and sending a "R too small" error
message.
If this value is zero, no limit is set.
A.5 ERROR_SPEC Class
ERROR_SPEC class = 6.
o IPv4 ERROR_SPEC object: Class = 6, C-Type = 1
+-------------+-------------+-------------+-------------+
| IP4 Error Node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
o IP6 ERROR_SPEC object: Class = 6, C-Type = 2
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IP6 Next/Previous Hop Address + + IP6 Error Node Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
This object provides the IP address of the interface through which Error Node Address
the last RSVP-knowledgeable hop forwarded this message.
6.4 STYLE Class The IP address of the node in which the error was detected.
o STYLE-WF object: Class = 4, C-Type = 1 Flags
0x01 = LUB-Used
The use of this flag is described in section 4.1.5.
Error Code
A one-octet error description.
Error Value
A two-octet field containing additional information about the
error. Its contents depend upon the Error Type.
The values for Error Code and Error Value are defined in Appendix
B.
A.6 SCOPE Class
SCOPE class = 7.
This object contains a list of IP addresses, used for routing
messages with wildcard scope without loops. The addresses must be
listed in ascending numerical order.
o IPv4 SCOPE List object: Class = 7, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Style=1 | //////// | //////// | ///////// | | IP4 Src Address (4 bytes) |
+-------------+-------------+-------------+-------------+
// //
+-------------+-------------+-------------+-------------+
| IP4 Src Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o STYLE-FF object: Class = 4, C-Type = 2 o IP6 SCOPE list object: Class = 7, C-Type = 2
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Style=2 | //////// | //////// | FD Count | | |
+ +
| |
+ IP6 Src Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
// //
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 Src Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
A.7 STYLE Class
FD Count STYLE class = 8.
The count of elements in the variable-length object list o STYLE object: Class = 8, C-Type = 1
that follows. See the RESV message format definition
earlier.
6.5 Flowspec Class +-------------+-------------+-------------+-------------+
| Style ID | Option Vector |
+-------------+-------------+-------------+-------------+
o CSZ FLOWSPEC object: Class = 5, C-Type = 1 Style ID
+-----------+-----------+-----------+-----------+ An integer identifying the style, as follows:
| QoS Service Code |
+-----------+-----------+-----------+-----------+
| b: Token Bucket Depth (bits) |
+-----------+-----------+-----------+-----------+
| r: Average data rate (bits/sec) |
+-----------+-----------+-----------+-----------+
| d: Max end-to-end delay (ms) |
+-----------+-----------+-----------+-----------+
| (For Future Use) |
+-----------+-----------+-----------+-----------+
QoS Service Code 0 = No ID assigned; use option vector.
Integer value defining what service is being requested. 1 = WF
The values currently defined for this code are:
1 = Guaranteed Service 2 = FF
The Tspec is (b, r), while the Rspec is (r). (d) 3 = SE
is ignored.
2 = Bounded-Delay Predictive Service Option Vector
The Tspec is (b, r), while the Rspec is (d). A set of bit fields giving values for the reservation
options. If new options are added in the futre,
corresponding fields in the option vector will be assigned
from the least-significant end. If a node does not recognize
a style ID, it may interpret as much of the option vector as
it can, ignoring new fields that may have been defined.
6.6 FILTER_SPEC Class The option vector bits are assigned (from the left) as
follows:
o IPv4/UDP FILTER_SPEC object: Class = 6, C-Type = 1 19 bits: Reserved
2 bits: Sharing control
00b: Reserved
01b: Distinct reservations
10b: Shared reservations
11b: Reserved
3 bits: Scope control
000b: Reserved
001b: Wildcard scope
010b: Explicit scope
011b - 111b: Reserved
The low order bits of the option vector are determined by the
style id, as follows:
WF 10001b
FF 01010b
SE 10010b
A.8 FLOWSPEC Class
FLOWSPEC class = 9.
The following C-Types for service types are defined. The
corresponding object contents are specified in service template
documents created by the int-serv working group.
o Class = 9, C-Type = 1: Controlled-Delay Quality of Service
o Class = 9, C-Type = 2: Predictive Quality of Service
o Class = 9, C-Type = 3: Guaranteed Quality of Service
There is also a container C-Type, used to enclose a set of
FLOWSPEC objects that could not be merged at a downstream node
because they include unrecognized C-Types.
o Class = 9, C-Type = 254: Controlled-Delay Quality of Service
+-------------+-------------+-------------+-------------+
| |
// FLOWSPEC object 1 //
| |
+-------------+-------------+-------------+-------------+
| |
// FLOWSPEC object 2 //
| |
+-------------+-------------+-------------+-------------+
// //
// //
+-------------+-------------+-------------+-------------+
| |
// FLOWSPEC object k //
| |
+-------------+-------------+-------------+-------------+
A.9 FILTER_SPEC Class
FILTER_SPEC class = 10.
o IPv4 FILTER_SPEC object: Class = 10, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 SrcAddress (4 bytes) | | IPv4 SrcAddress (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Protocol Id | ////// | SrcPort | | Protocol Id | ////// | SrcPort |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o IP6/UDP FILTER_SPEC object: Class = 6, C-Type = 129 o IP6 FILTER_SPEC object: Class = 10, C-Type = 2
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IP6 SrcAddress (16 bytes) + + IP6 SrcAddress (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Protocol Id | ////// | SrcPort | | Protocol Id | ////// | SrcPort |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
SrcAddress is an IP address for a host, and SrcPort is a UDP/TCP o IP6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3
source port, defining a sender.
6.7 SENDER_TEMPLATE Class +-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 SrcAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| /////// | Flow Label (24 bits) |
+-------------+-------------+-------------+-------------+
o IPv4/UDP SENDER_TEMPLATE object: Class = 7, C-Type = 1 SrcAddress
The IP source address for a sender host, or zero to indicate
a `wildcard'.
Protocol Id
The IP protocol Identifier, or zero to indicate a `wildcard'.
SrcPort
The UDP/TCP source port for a sender, or zero to indicate a
`wildcard' (i.e., any port).
Flow Label
A 24-bit Flow Label, defined in IP6. This value may be used
by the packet classifier to efficiently identify the packets
belonging to a particular (sender->destination) data flow.
A.10 SENDER_TEMPLATE Class
SENDER_TEMPLATE class = 11.
o IPv4/UDP SENDER_TEMPLATE object: Class = 11, C-Type = 1
Definition same as IPv4/UDP FILTER_SPEC object. Definition same as IPv4/UDP FILTER_SPEC object.
o IP6/UDP SENDER_TEMPLATE object: Class = 7, C-Type = 129 o IP6/UDP SENDER_TEMPLATE object: Class = 11, C-Type = 2
Definition same as IP6/UDP FILTER_SPEC object. Definition same as IP6/UDP FILTER_SPEC object.
6.8 SENDER_TSPEC Class A.11 SENDER_TSPEC Class
The most common form of Tspec is a token bucket. SENDER_TSPEC class = 12.
o Token Bucket SENDER_TSPEC object: Class = 8, C-Type = 1 The only current form of Tspec is a token bucket.
o Token Bucket SENDER_TSPEC object: Class = 12, C-Type = 1
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| b: Token Bucket Depth (bits) | | b: Token Bucket Depth (bits) |
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| r: Average data rate (bits/sec) | | r: Average data rate (bits/sec) |
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
6.9 ADVERT Class A.12 ADSPEC Class
ADSPEC class = 13.
[TBD] [TBD]
A.13 POLICY_DATA Class
6.10 TIME_VALUES Class POLICY_DATA class = 14.
o TIME_VALUES Object: Class = 10, C-Type = 1 o Type 1 POLICY_DATA object: Class = 14, C-Type = 1
+-------------+-------------+-------------+-------------+ [TBD]
| Refresh Period |
+-------------+-------------+-------------+-------------+
| State TTL Time |
+-------------+-------------+-------------+-------------+
6.11 ERROR_SPEC Class
o IPv4 ERROR_SPEC object: Class = 11, C-Type = 1 o Unmerged POLICY_DATA object: Class = 14, C-Type = 254
This object is a container for a list of POLICY_DATA objects
(none of which may have C-Type = 254). The contained objects
have not yet been merged.
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IP4 Error Node Address (4 bytes) | | |
// POLICY_DATA object 1 //
| |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Error Code | ////////// | Error Value | | |
// POLICY_DATA object 2 //
| |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
// //
o IP6 ERROR_SPEC object: Class = 11, C-Type = 129 // //
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + // POLICY_DATA object k //
| | | |
+ IP6 Error Node Address (16 bytes) + +-------------+-------------+-------------+-------------+
A.14 TAG class
TAG class = 20.
o TAG object: Class = 20, C-Type = 1
+-------------+-------------+-------------+-------------+
| Tag Value |
+-------------+-------------+-------------+-------------+
| | | |
+ + // Tagged Sublist //
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Error Code | ////////// | Error Value |
+-------------+-------------+-------------+-------------+
Errnor Node Tag Value
The IP address The value of the tag being attached to the objects in
the Tagged Sublist. The tag value is unique for each
session and next/previous hop.
Error Code Tagged Sublist
A one-octet error description. A list of objects with the same class-num (but not
necessarily the same C-Type).
01 = Insufficient memory APPENDIX B. Error Codes and Values
02 = Count Wrong The following Error Codes are defined.
The FD Count field does not match length of o Error Code = 01: Admission failure
message.
03 = No path information for this Resv Reservation rejected by admission control.
04 = No Sender information for this Resv For this Error Code, the 16 bits of the Error Value field are:
There is path information, but it does not include
the sender specified in any of the Filterspecs
listed in the Resv messager.
05 = Incorrect Dynamic Reservation Count suur cccc cccc cccc
Dynamic Reservation Count is zero or less than FD where the bits are:
Count.
06 = Filterspec error s = 0: RSVP should reject the message without updating local
state.
07 = Flowspec syntax error s = 1: RSVP may use message to update local state and propagate
it.
08 = Flowspec value error uu = 00: Low order 12 bits contain a globally-defined sub-code
(values listed below).
Internal inconsistency of values. uu = 10: Low order 12 bits contain a sub-code that is specific
to local organization. RSVP is not expected to be able to
interpret this except as a numeric value.
[What should be done with Flowspec Feature Not uu = 11: Low order 12 bits contain a sub-code that is specific
Supported?] to the service. RSVP is not expected to be able to
interpret this except as a numeric value. Since the
traffic control mechanism might substitute a different
service, this encoding may include some representation of
the service in use.
09 = Resources unavailable [Sub-reasons? Depend upon r: Reserved bit, should be zero.
traffic control and admission control algorithms?]
10 = Illegal style cccc cccc cccc: 12 bit code.
Error Value The following globally-defined sub-codes may appear in the low-
order 12 bits when uu = 00:
Specific cause of the error described by the Error Code. - Sub-code = 1: Delay bound cannot be met
6.12 CREDENTIAL Class - Sub-code = 2: Requested bandwidth unavailable
[TBD] - Sub-code = 11: Service conflict
6.13 INTEGRITY Class - Sub-code = 12: Service unsupported
[TBD] Traffic control can provide neither the requested service
nor an acceptable substitute.
7. UDP Encapsulation - Sub-code = 13: Bad Flowspec or Tspec value
Unreasonable request. High order 4 bits should be 000r, so
that RSVP will reject the message.
- Sub-code = 14: Rmax value too small.
Rmax would result in excessive refresh overhead.
o Error Code = 02: Administrative rejection
Reservation has been rejected for administrative reasons.
For this Error Code, the high order 4 bits of the Error Value
field are assigned as for Code = 01 (above). For this case, the
following global sub-codes may be used:
- Sub-code = 1: Required credential(s) not presented.
- Sub-code = 2: Request too large
Reservation request exceeds allowed value for this user
class.
- Sub-code = 3: Insufficient quota or balance.
- Sub-code = 4: Administrative preemption
o Error Code = 03: No path information for this Resv
RSVP should reject the message.
o Error Code = 04: No sender information for this Resv
There is path information, but it does not include the sender
specified in any of the Filterspecs listed in the Resv message.
RSVP should reject the message.
o Error Code = 05: Ambiguous path
Sender specification is ambiguous with existing path state.
RSVP should reject the message.
o Error Code = 06: Ambiguous filter spec
Filter spec matches more than one sender, in style that requires
a unique match. RSVP should reject the message.
o Error Code = 07: Conflicting or unknown style
Reservation style conflicts with style(s) of existing
reservation state, or it is unknown. If the high-order bit of
Error Value is zero, RSVP should reject the message.
o Error Code = 11: Missing required object
RSVP was unable to find or construct required object data from
message. Error Value will be Class-Num that is missing. RSVP
should reject the message.
o Error Code = 12: Unknown object class
Error Value will contain 16-bit value composed of (Class-Num,
C-Type) of unknown object. This error should be sent only if
RSVP is going to reject the message.
o Error Code = 13: Unknown object C-Type
Error Value will contain 16-bit value composed of (Class-Num,
C-Type) of object. This error should be sent only if RSVP is
going to should reject the message.
o Error Code = 14: Object error
A non-specific error indicating bad format or contents of an
object. The Error Value will contain 16-bits value (Class-Num,
C-Type) from header of bad object. RSVP should reject the
message.
o Error Code = 21: Traffic Control error
Some system error was detected and reported by the traffic
control modules. The Error Value will contain a system-specific
value giving more information about the error.
o Error Code = 22: RSVP System error
The Error Value field will provide implementation- dependent
information on the error.
APPENDIX C. UDP Encapsulation
As described earlier, RSVP control messages are intended to be As described earlier, RSVP control messages are intended to be
carried as "raw packets", directly within IP datagrams. Implementing carried directly within IP datagrams as "raw packets". Implementing
RSVP in a node will typically require an intercept in the packet RSVP in a node will require an intercept in the packet forwarding
forwarding path for protocol 46, which means a kernel change. path for protocol 46, and the necessary kernel change is incorporated
However, for ease of installing RSVP on host systems in the short in the recent releases of IP multicasting
term, it may be desirable to avoid host kernel changes by supporting
UDP encapsulation of RSVP messages. This encapsulation would be used
between hosts and the last- (or first-) hop router(s). This scheme
will also support the case of an intermediate RSVP router whose
kernel supports multicast but does not have the RSVP intercept, by
allowing UDP encapsulation on each interface.
The UDP encapsulation approach must support a domain that contains a There are particular circumstances where it may be desirable to
mix of "UDP-only" hosts, which require UDP encapsulation, and "raw- encapsulate RSVP messages in UDP packets, as a short-term measure.
capable" host, which can use raw RSVP packets. Raw-capable hosts and
first-hop router(s) must send each RSVP message twice in the local
domain, once as a raw packet and once with UDP encapsulation; these
nodes will also receive some local RSVP packets in both formats. We
assume that the only negative impact of this duplication will be
(negligible) additional packet processing overhead in the raw-capable
hosts and first-hop routers.
[REST TBD] 1. UDP encapsulation can be used between hosts and the last- (or
first-) hop router(s). This may ease installing RSVP on some
host systems, by avoiding a kernel change for the RSVP
intercept.
8. DF Style (Experimental) 2. UDP encapsulation may be useful for legal penetration of
firewalls.
In addition to the WF and FF styles defined in this specification, a 3. UDP encapsulation might be used on each interface of an
Dynamic Filter (DF) style has also been proposed. The following intermediate RSVP router whose kernel supported multicast but
describes this style and gives examples of its usage. At this time, which did not have the RSVP intercept.
DF style is experimental.
8.1 Reservation Styles In the following discussion, we concentrate on (1) and (2).
A Dynamic-Filter (DF) style reservation decouples reservations Figure 13 shows a typical situation for a host running RSVP. Here
from filters. two RSVP-capable hosts Hu and Hr within a corporation are connected
to the Internet through some arbitrarily complex set of networks and
routers that is labelled the "Corporate cloud". The border router R
is assumed to be RSVP-capable, but the corporate cloud is not.
Each DF reservation request specifies a number D of distinct _ _ _ _
reservations to be made using the same specified flowspec, and ______ ( ) RSVP-capable
these reservations have a wildcard reservation scope, so they go | | ( ) router
everywhere. The number of reservations that are actually made in | Hu |-----( Corporate ) ______
a particular node is D' = min(D,Ns), where Ns is the total number |______| ( ) a| |b
of senders upstream of the node. Like a FF style request, a DF ( cloud )-----| R |---->Internet
style request causes distinct reservations for different senders. ______ ( ) |______|
| | ( )
| Hr |------( )
|______| (_ _ _ _ _)
In addition to D and the flowspec, a DF style reservation may also Figure 13: End Host Situation
specify a list of K filterspecs, for some K in the range: 0 <= K
<= D'. These filterspecs define particular senders to use the D'
reservations, and this list establishes the scope for the filter
specs.
Once a DF reservation has been established, the receiver may We assume that Hu is a "UDP-only" host that requires UDP
change the set of filterspecs to specify a different selection of encapsulation, while Hr is a "raw-capable" host that can use raw RSVP
senders, without a new admission control check (assuming D' and packets. The UDP encapsulation scheme should allow RSVP
the common flowspec remain unchanged). This is known as "channel interoperation among an arbitrary topology of Hr hosts and Hu hosts
switching", in analogy with a television set. as well as routers R.
In order to provide assured channel switching, each node along the RESV messages are always sent unicast; once path state has been
path must reserve enough bandwidth for all D' channels, even established, the unicast destination address of each RESV message is
though some of this bandwidth may be unused at any one time. If known. If the path state also indicates whether the next host node
D' changes (because the receiver changed D or because the number needs UDP encapsulation, a RESV message can simply be sent to the
Ns of upstream sources changed), or if the common flowspec next-hop node, either in raw mode or with UDP encapsuation.
changes, the refresh message is treated as a new reservation that
is subject to admission control and may fail.
The essential difference between the FF and DF styles is that the UDP encapsulation of PATH messages poses a more difficult problem.
DF style allows a receiver to switch channels without danger of an To solve it, we define two new well-known multicast addresses G1 and
admission denial due to limited resources (unless a topology G2, and a well-known UDP port Pu. Then the table in Figure 14 shows
change reroutes traffic along a lower-capacity path or new senders the rules. Under the `Send' column, the notation is <mode>(destaddr,
appear), once the initial reservations have been made. This in destport, TTL), where TTL is the IP-layer hop count. The `Receive'
turn implies that the DF style creates reservations that may not column shows the group that is joined and, where relevant, the UDP
be in use at any given time. Listen port. T1 and T2 are configured IP TTL values used for
encapsulation, while Tr is the local TTL value of the specific PATH
message. Finally, D is the DestAddress for the particular session.
The DF style is compatible with the FF style but not the WF style. Node Node Type Send Receive
___ __________ _______________ _______________
Hu UDP-only host UDP(G1,Pu,T1) UDP(G1,Pu)
and UDP(G2,Pu)
8.2 Examples Hr Raw-mode host UDP(G1,Pu,T1) UDP(G1,Pu)
and Raw(D,,Tr) and Raw()
To give an example of the DF style, we use the following notation: R Router
Interface a: UDP(G2,Pu,T2) UDP(G1,Pu)
and Raw(D,,Tr) and Raw()
Interface b: Raw(D,,Tr) Raw()
Figure 14: UDP Encapsulation Rules for Path Messages
Note that R and Hr must send their PATH messages twice, once with UDP
encapsulation and once in raw mode. In two cases (Hr -> R and Hr ->
Hr), each PATH message will be delivered twice. The router may take
steps to ignore the duplicates, but this redundancy actually has no
ill effect other than overhead for processing the extra messages.
A router must keep track of which of its interfaces are using UDP
encapsulation and which are not. A node can always listen for
UDP(G1,Pu) on each interface, and if it receives a UDP-encapsulated
PATH message, mark the corresponding path state as UDP-needed. Then
matching RESV messages will be correctly encapsulated.
Two provisions are necessary for this automatic determination of
encapsulation to work.
C1 A router must use different groups G1 and G2 for sending and
receiving, as already shown.
C2 The TTL value T1 used by a host must be exactly enough to reach
the router R.
If T1 is too small to pass through the corporate cloud, of course
PATH messages will not be forwarded. If T1 is too large, multicast
routing in R will forward the UDP packet into the Internet until its
hop count expires. This will turn on UDP encapsulation between
routers within the Internet, causing bogus UDP traffic. (Note that
UDP packets addressed to G2 by a router will not be received by a
neighboring router).
However, there are possible situations where it will be impossible to
find a value of T1 that meets condition C2. Within the corporate
cloud there might be a multicast tunnel with an outgoing threshold
larger than the hop count through the cloud. Another possibility is
that there might be more than one border router R, with different
TTL's. There are several possible ways that C2 might be satisfied in
such cases.
1. It might be possible to configure the hosts' RSVP daemons with
the IP address for R; the daemons could then "unicast" PATH
messages to this address. This solution will be feasible as
long as the number of Hr and Hu hosts is small.
2. A particular host on the LAN including Hu could be designated as
an "RSVP relay host". This system would listen on (G1,Pu) and
be configured with the IP address of R. It could then forward
any (PATH) messages it received directly to R, and T1 could be
set only large enough to reach local hosts and the relay.
Finally, manual configuration of T1 could be replaced by an expanding
ring search conducted by host RSVP daemons. This possibility is for
future study.
APPENDIX D. Experimental and Open Issues
D.1 RSVP MTU
The spec says that the MTU for RSVP messages, which are sent hop
by hop, is determined by the MTU at each interface. There may be
rare instances in which this does not work very well, and in which
manual configuration would not help. The problem case is an
interface connected to a non-RSVP cloud in which some particular
link far away has a smaller MTU. This would affect only those
sessions that happened to use that link. Proper solution to this
case would require MTU discovery separately for each interface and
each session, which is a very large amount of machinery and some
overhead for a rare (?) case. The best approach seems to be to
rely on IP fragmentation and reassembly for this case.
D.2 Reservation Compatability
How strong is the requirement for compatability of reservations in
different directions? For example, see Figure 11; should it be
possible to have incompatible reservation styles on the two
interfaces? If R1 requests a WF reservation and R2 requests a FF
reservation, it is logically possible to make the corresponding
reservations on the two different interfaces. The current
implementation does NOT allow this; instead, it prevents mixing of
incompatible styles in the same session on a node, even if they
are on different interfaces.
D.3 Session Groups (Experimental)
Section 1.2 explained that a distinct destination address, and
therefore a distinct session, will be used for each of the
subflows in a hierarchically encoded flow. However, these
separate sessions are logically related. For example it may be
necessary to pass reservations for all subflows to Admission
Control at the same time (since it would be nonsense to admit high
frequency components but reject the baseband component of the
session data). Such a logical grouping is indicated in RSVP by
defining a "session group", an ordered set of sessions.
To declare that a set of sessions form a session group, a receiver
includes a data structure we call a SESSION_GROUP object in the
RESV message for each of the sessions. A SESSION_GROUP object
contains four fields: a reference address, a session group ID, a
count, and a rank.
o The reference address is an agreed-upon choice from among the
DestAddress values of the sessions in the group, for example
the smallest numerically.
o The session group ID is used to distinguish different groups
with the same reference address.
o The count is the number of members in the group.
o The rank, an integer between 1 and count, is different in
each session of the session group.
The SESSION_GROUP objects for all sessions in the group will
contain the same values of the reference address, the session
group ID, and the count value. The rank values establishes the
desired order among them.
If RSVP at a given node receives a RESV message containing a
SESSION_GROUP object, it should wait until RESV messages for all
`count' sessions have appeared (or until the end of the refresh
cycle) and then pass the RESV requests to Admission Control as a
group. It is normally expected that all sessions in the group
will be routed through the same nodes. However, if not, only a
subset of the session group reservations may appear at a given
node; in this case, the RSVP should wait until the end of the
refresh cycle and then perform Admission Control on the subset of
the session group that it has received. The rank values will
identify which are missing.
Note that routing different sessions of the session group
differently will generally result in delays in establishing or
rejecting the desired QoS. A "bundling" facility could be added
to multicast routing, to force all sessions in a session group to
be routed along the same path.
D.3.1 Resv Messages
Add:
[ <SESSION_GROUP> ]
after the SESSION object.
D.3.2 SESSION_GROUP Class
SESSION_GROUP class = 2.
o IPv4 SESSION_GROUP Object: Class = 2, C-Type = 1:
+-------------+-------------+-------------+-------------+
| IPv4 Reference DestAddress |
+-------------+-------------+-------------+-------------+
| Session_Group ID | Count | Rank |
+-------------+-------------+-------------+-------------+
o IP6 SESSION_GROUP Object: Class = 2, C-Type = 2:
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 Reference DestAddress +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Session-Group ID | Count | Rank |
+-------------+-------------+-------------+-------------+
The variables are defined in above.
D.4 DF Style (Experimental)
In addition to the WF and FF styles defined in this specification,
a Dynamic Filter (DF) style has also been proposed. The following
describes this style and gives examples of its usage. At this
time, DF style is experimental.
D.4.1 Reservation Styles
A Dynamic-Filter (DF) style reservation makes "distinct"
reservations with "wildcard" scope, but it decouples
reservations from filters.
o Each DF reservation request specifies a number D of
distinct reservations using the same specified flowspec.
These reservations are distributed with wildcard scope,
i.e., to all senders.
The number of reservations that are actually made in a
particular node is D' = min(D,Ns), where Ns is the total
number of senders upstream of the node.
o In addition to D and the flowspec, a DF style reservation
may also specify a list of K filterspecs, for some K in
the range: 0 <= K <= D'. These filterspecs define
particular senders to use the D' reservations, and this
list establishes the scope for the filter specs.
Once a DF reservation has been established, the receiver
may change the set of filterspecs to specify a different
selection of senders, without a new admission control
check (assuming D' and the common flowspec remain
unchanged). This is known as "channel switching", in
analogy with a television set.
In order to provide assured channel switching, each node along
the path must reserve enough bandwidth for all D' channels,
even though some of this bandwidth may be unused at any one
time. If D' changes (because the receiver changed D or because
the number Ns of upstream sources changed), or if the common
flowspec changes, the refresh message is treated as a new
reservation that is subject to admission control and may fail.
The DF style allows a receiver to switch channels without
danger of an admission denial due to limited resources (unless
a topology change reroutes traffic along a lower-capacity path
or new senders appear), once the initial reservations have been
made. This in turn implies that the DF style creates
reservations that may not be in use at any given time.
The DF style is compatible with the FF style but not the WF or
SE style.
D.4.2 Examples
To give an example of the DF style, we use the following
notation:
o DF Style o DF Style
DF( n, {r} ; ) or DF( n, {r} ; S1, S2, ...) DF( n, {r} ; ) or DF( n, {r} ; S1, S2, ...)
This message carries the count n of channels to be reserved, each This message carries the count n of channels to be reserved,
using common flowspec r. It also carries a list, perhaps empty, each using common flowspec r. It also carries a list, perhaps
of filterspecs defining senders. empty, of filterspecs defining senders.
Figure 11 shows an example of Dynamic-Filter reservations. The Figure 15 shows an example of Dynamic-Filter reservations. The
receivers downstream from interface (d) have requested two receivers downstream from interface (d) have requested two
reserved channels, but selected only one sender, S1. The node reserved channels, but selected only one sender, S1. The node
reserves min(2,3) = 2 channels of size B on interface (d), and it reserves min(2,3) = 2 channels of size B on interface (d), and
then applies any specified filters to these channels. Since only it then applies any specified filters to these channels. Since
one sender was specified, one channel has no corresponding filter, only one sender was specified, one channel has no corresponding
as shown by `?'. filter, as shown by `?'.
Similarly, the receivers downstream of interface (c) have Similarly, the receivers downstream of interface (c) have
requested two channels and selected senders S1 and S2. The two requested two channels and selected senders S1 and S2. The two
channels might have been one channel each from R1 and R2, or two channels might have been one channel each from R1 and R2, or
channels requested by one of them, for example. two channels requested by one of them, for example.
| |
Send | Reserve Receive Send | Reserve Receive
| |
| ________ | ________
DF( 1,{B}; S1) <- (a) | (c) | S1{B} | (c) <- DF( 2,{B}; S1, S2) DF( 1,{B}; S1) <- (a) | (c) | S1{B} | (c) <- DF( 2,{B}; S1, S2)
| |________| | |________|
| | S2{B} | | | S2{B} |
| |________| | |________|
| |
------------------------|------------------------------------------- ------------------------|-------------------------------------------
| ________ | ________
DF( 2,{B}; S2) <- (b) | (d) | S1{B} | (d) <- DF( 2,{B}; S1) DF( 2,{B}; S2) <- (b) | (d) | S1{B} | (d) <- DF( 2,{B}; S1)
| |________| | |________|
| | ?{B} | | | ?{B} |
| |________| | |________|
Figure 11: Dynamic-Filter Reservation Example Figure 15: Dynamic-Filter Reservation Example
A router should not reserve more Dynamic-Filter channels than the A router should not reserve more Dynamic-Filter channels than
number of upstream sources (three, in the router of Figure 11). the number of upstream sources (three, in the router of Figure
Since there is only one source upstream from previous hop (a), the 15). Since there is only one source upstream from previous hop
first parameter of the DF message (the count of channels to be (a), the first parameter of the DF message (the count of
reserved) was decreased to 1 in the forwarded reservations. channels to be reserved) was decreased to 1 in the forwarded
However, this is unnecessary, because the routers upstream will reservations. However, this is unnecessary, because the
reserve only one channel, regardless. routers upstream will reserve only one channel, regardless.
When a DF reservation is received, it is labeled with the IP When a DF reservation is received, it is labeled with the IP
address of the next hop (RSVP-capable) router, downstream from the address of the next hop (RSVP-capable) router, downstream from
current node. Since the outgoing interface may be directly the current node. Since the outgoing interface may be directly
connected to a shared medium network or to a non-RSVP-capable connected to a shared medium network or to a non-RSVP-capable
router, there may be more than one next-hop node downstream; if router, there may be more than one next-hop node downstream; if
so, each sends independent DF RESV messages for a given session. so, each sends independent DF RESV messages for a given
The number N' of DF channels reserved on an outgoing interface is session. The number N' of DF channels reserved on an outgoing
given by the formula: interface is given by the formula:
N' = min( D1+D2+...Dn, Ns), N' = min( D1+D2+...Dn, Ns),
where Di is the D value (channel reservation count) in a RESV from where Di is the D value (channel reservation count) in a RESV
the ith next-hop node. from the ith next-hop node.
For a DF reservation request with a Dynamic Reservation Count = C, For a DF reservation request with a Dynamic Reservation Count =
RSVP should call TC_AddFlowspec C times. C, RSVP should call TC_AddFlowspec C times.
8.3 Resv Messages D.4.3 Resv Messages
Add the following sequence: Add the following sequence:
<style-specific-tail> ::= <flow descriptor list> ::=
<Style-DF> <FLOWSPEC> <filter spec list>
<filter spec list> ::= <empty> | <filter spec list> <FILTER_SPEC> <FLOWSPEC> <filter spec list>
8.4 STYLE Class D.4.4 STYLE Class
o STYLE-DF object: Class = 4, C-Type = 3 o STYLE-DF object: Class = 8, C-Type = 2
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Style=3 | //////// | Dyn Resv Cnt| FD Count | | Style ID=4 | Attribute Vector 0...0101001b |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| ////// /////// | Dynamic Resv Count |
+-------------+-------------+---------------------------+
Style Style ID
3 = Dynamic-Filter 4 = Dynamic-Filter (DF)
Dyn Resv Count Attribute Vector
18 bits: Reserved
1 bit: Decoupled if 1.
2 bits: Sharing control (as before)
3 bits: Scope control (as before)
Dynamic Resv Count
The number of channels to be reserved for a Dynamic The number of channels to be reserved for a Dynamic
Filter style reservation. This integer value must not Filter style reservation. This integer value must
less than FD Count. not less than the number of FILTER_SPEC objects in
filter spec list.
REFERENCES References
[CSZ92] Clark, D., Shenker, S., and L. Zhang, "Supporting Real-Time [CSZ92] Clark, D., Shenker, S., and L. Zhang, "Supporting Real-Time
Applications in an Integrated Services Packet Network: Architecture Applications in an Integrated Services Packet Network: Architecture
and Mechanisms", Proc. SIGCOMM '92, Baltimore, MD, August 1992. and Mechanisms", Proc. SIGCOMM '92, Baltimore, MD, August 1992.
[ISInt93] Braden, R., Clark, D., and S. Shenker, "Integrated Services [ISInt93] Braden, R., Clark, D., and S. Shenker, "Integrated Services
in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and
PARC, June 1994. PARC, June 1994.
[IServ93] Shenker, S., Clark, D., and L. Zhang, "A Service Model for an [IServ93] Shenker, S., Clark, D., and L. Zhang, "A Service Model for an
Integrated Services Internet", Work in Progress, October 1993. Integrated Services Internet", Work in Progress, October 1993.
[Partridge92] Partridge, C., "A Proposed Flow Specification", RFC 1363, [Partridge92] Partridge, C., "A Proposed Flow Specification", RFC 1363,
BBN, September 1992. BBN, September 1992.
[Shenker94] Shenker, S., "Two-Pass or Not Two-Pass", Current Meeting
Report, RSVP Working Group, Proceedings of the Thirtieth Internet
Engineering Task Force, Toronto, Canada, July 1994.
[RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. [RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D.
Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network, Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network,
September 1993. September 1993.
[ServTempl95a] Shenker, S., "Network Element Service Specification
Template", Internet Draft draft-ietf-intserv-svc-template-00.txt,
Integrated Services Working Group, March 1995.
[Shenker94] Shenker, S., "Two-Pass or Not Two-Pass", Current Meeting
Report, RSVP Working Group, Proceedings of the Thirtieth Internet
Engineering Task Force, Toronto, Canada, July 1994.
Security Considerations Security Considerations
See Section 2.5. See Section 2.5.
Authors' Addresses Authors' Addresses
Lixia Zhang Lixia Zhang
Xerox Palo Alto Research Center Xerox Palo Alto Research Center
3333 Coyote Hill Road 3333 Coyote Hill Road
Palo Alto, CA 94304 Palo Alto, CA 94304
skipping to change at page 70, line 4 skipping to change at page 96, line 19
Phone: (310) 822-1511 Phone: (310) 822-1511
EMail: Braden@ISI.EDU EMail: Braden@ISI.EDU
Deborah Estrin Deborah Estrin
Computer Science Department Computer Science Department
University of Southern California University of Southern California
Los Angeles, CA 90089-0871 Los Angeles, CA 90089-0871
Phone: (213) 740-4524 Phone: (213) 740-4524
EMail: estrin@USC.EDU EMail: estrin@USC.EDU
Shai Herzog
Shai Herzog
USC Information Sciences Institute USC Information Sciences Institute
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292 Marina del Rey, CA 90292
Palo Alto, CA 94304 Palo Alto, CA 94304
Phone: (310) 822 1511 Phone: (310) 822 1511
EMail: Herzog@ISI.EDU EMail: Herzog@ISI.EDU
Sugih Jamin Sugih Jamin
Computer Science Department Computer Science Department
 End of changes. 

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