draft-ietf-rsvp-spec-04.txt   draft-ietf-rsvp-spec-05.txt 
Internet Draft L. Zhang Internet Draft R. Braden, Ed.
Expiration: May 95 PARC Expiration: September 1995 ISI
File: draft-ietf-rsvp-spec-04.txt R. Braden File: draft-ietf-rsvp-spec-05.txt L.Zhang
ISI 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
**DRAFT** March 24, 1995
November 3, 1994
Status of Memo Status of Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
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 Seattle IETF What's Changed Since Toronto IETF
o Redesign generic RSVP API (section 3.6.2) This version of the document incorporates many of the protocol changes
agreed to at the December 1994 IETF meeting in San Jose. The most major
changes are:
o Change encoding of style in RESV messages (section 3.1.2) o The RSVP packet format has been reorganized to carry most data
as typed variable-length objects.
o Clarify filterspec functions (section 2.1) o This generality includes provision for 16-byte IP6 addresses.
o Simplify definition of DF style (sections 2.2, 2.4). o Filter specs have been simplified.
o Revise discussion of flowspec merging (section 2.3.3). o DF style has been moved to an Appendix, as experimental.
o Change format of variable-length filterspecs and flowspecs o UDP encapsulation has been included.
(section 3.1 and 3.6.1).
o Add a user authentication field in all RSVP messages (Section o OPWA has been included.
3).
o Add short discussion of local repair (Section 3.3.3). o The Drop flag has been eliminated.
o Editorial nits. o Session groups have been added.
o The routing of RERR messages has been changed.
1. Introduction 1. Introduction
This memo describes RSVP, a resource reservation setup protocol This document defines RSVP, a resource reservation setup protocol
designed for an integrated services Internet [RSVP93,ISInt93]. An designed for an integrated services Internet [RSVP93,ISInt93].
application invokes RSVP to request a specific quality of service (
QoS) for a data stream. Hosts and routers use RSVP to deliver these
requests to the routers along the path(s) of the data stream and to
maintain router and host state to provide the requested service.
This generally requires reserving resources in those nodes.
At each "node" (i.e., router or host) along the path, RSVP passes a A host uses the RSVP protocol to request a specific quality of
new resource reservation request to an admission control routine, to service (QoS) from the network, on behalf of an application data
determine whether there are sufficient resources available. If there stream. RSVP is also used to deliver QoS requests to routers along
are, the node reserves the resources and updates its packet scheduler the path(s) of the data stream and to maintain router and host state
and classifier control parameters to provide the requested QoS to provide the requested service. This will generally (but not
[ISInt93]. It is expected that RSVP implementations will execute in necessarily) require reserving resources along the data path.
user space in a host, and in background in a router. On the other
hand, the packet scheduler and classifier are expected to execute in
the kernel of a host operating system, and in the high-speed packet
forwarding path of a router.
RSVP messages are sent as IP datagrams; thus, RSVP occupies the place RSVP reserves resources for simplex data streams, i.e., it reserves
of a transport protocol in the protocol stack. However, like ICMP, resources in only one direction on a link, so that a sender is
IGMP, and routing protocols, RSVP is really an Internet control logically distinct from a receiver. However, the same application
protocol; it does not carry any application data, and its messages may act as both sender and receiver. RSVP operates on top of IP,
are processed by the routers in the path. occupying the place of a transport protocol in the protocol stack.
However, like ICMP, IGMP, and routing protocols, RSVP does not
transport application data but is rather an Internet control
protocol. As shown in Figure 1, an implementation of RSVP, like the
implementations of routing and management protocols, will typically
execute in the background, not in the data forwarding path.
RSVP is not itself a routing protocol, but rather it is designed to RSVP is not itself a routing protocol; the RSVP daemon consults the
operate with existing and future unicast and multicast routing local routing protocol(s) to obtain routes. Thus, a host sends IGMP
protocols. Thus, a host sends IGMP messages to join a multicast messages to join a multicast group, and it sends RSVP messages to
group, and then it sends RSVP messages to reserve resources along the reserve resources along the delivery path(s) from that group. RSVP
deliver path(s) from that group. Unlike a routing protocol, RSVP is is designed to operate with existing and future unicast and multicast
explicitly invoked by applications, to obtain a special QoS. routing protocols.
The objectives and general justification for RSVP design are HOST ROUTER
presented in [RSVP93,ISInt93]. In summary, RSVP has the following
attributes: _________________________ RSVP ______________________
| | .---------------. |
| _______ ______ | . | ________ . ______ |
| | | | | | . || | . | || RSVP
| |Applic-| | RSVP <----- ||Routing | -> RSVP <------>
| | App <----->daemon| | ||Protocol| |daemon||
| | | | | | || daemon <----> ||
| |_______| |___.__| | ||_ ._____| |__.___||
|===|===============v=====| |===v=============v====|
| data .......... | | . ............ |
| | ____v_ ____v____ | | _v__v_ _____v___ |
| | |Class-| | || data | |Class-| | || data
| |=> ifier|=> Packet =============> ifier|==> Packet |======>
| |______| |Scheduler|| | |______| |Scheduler||
| |_________|| | |_________||
|_________________________| |______________________|
Figure 1: RSVP in Hosts and Routers
Each router that is capable of resource reservation passes incoming
data packets to a packet classifier and then queues them as necessary
in a packet scheduler. The packet classifier determines the route
and the QoS class for each packet. The scheduler allocates a
particular outgoing link for packet transmission, and it may also
allocate other system resources such as CPU time or buffers.
In order to efficiently accommodate heterogeneous receivers and
dynamic group membership and to be consistent with IP multicast, RSVP
makes receivers responsible for requesting resource reservations
[RSVP93]. A QoS request, typically originating in a receiver host
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
the request to all the nodes (routers and hosts) along the reverse
data path(s) to the data source(s).
At each node, the RSVP program applies a local decision procedure,
called "admission control", to determine if it can supply the
requested QoS. If admission control succeeds, the RSVP program sets
parameters to the packet classifier and scheduler to obtain the
desired QoS. If admission control fails at any node, the RSVP
program returns an error indication to the application that
originated the request. We refer to the packet classifier, packet
scheduler, and admission control components as "traffic control".
RSVP is designed to scale well for very large multicast groups.
Since the membership of a large group will be constantly changing,
the RSVP design assumes that router state for traffic control will be
built and destroyed incrementally. For this purpose, RSVP uses "soft
state" in the routers, in addition to receiver-initiation.
RSVP protocol mechanisms provide a general facility for creating and
maintaining distributed reservation state across a mesh of multicast
or unicast delivery paths. RSVP transfers reservation parameters as
opaque data (except for certain well-defined operations on the data),
which it simply passes to traffic control for interpretation.
Although the RSVP protocol mechanisms are largely independent of the
encoding of these parameters, the encodings must be defined in the
reservation model that is presented to an application (see Appendix
A).
In summary, RSVP has the following attributes:
o RSVP supports multicast or unicast data delivery and adapts to o RSVP supports multicast or unicast data delivery and adapts to
changing group membership as well as changing routes. changing group membership as well as changing routes.
o RSVP reserves resources for simplex data streams. o RSVP is simplex.
o RSVP is receiver-oriented, i.e., the receiver of a data flow is o RSVP is receiver-oriented, i.e., the receiver of a data flow is
responsible for the initiation and maintenance of the resource responsible for the initiation and maintenance of the resource
reservation used for that flow. reservation used for that flow.
o RSVP maintains "soft state" in the routers, enabling it to o RSVP maintains "soft state" in the routers, enabling it to
gracefully support dynamic membership changes and automatically gracefully support dynamic membership changes and automatically
adapt to routing changes. adapt to routing changes.
o RSVP provides several reservation models or "styles" (defined o RSVP provides several reservation models or "styles" (defined
below) to fit a variety of applications. below) to fit a variety of applications.
o RSVP provides transparent operation through routers that do not o RSVP provides transparent operation through routers that do not
support it. support it.
The RSVP protocol mechanisms provide a general facility for creating Further discussion on the objectives and general justification for
and maintaining distributed reservation state across a mesh of RSVP design are presented in [RSVP93,ISInt93].
multicast delivery paths. These mechanisms treat the reservation
parameters as opaque data, except for certain well-defined
operations, and simply pass them to the traffic control modules
(admission control, packet scheduler, and classifier) for
interpretation. Although the RSVP protocol mechanisms are largely
independent of the encoding of these parameters, the encodings must
be defined in the reservation model that is presented to an
application (see section 3.6.1).
In order to efficiently accommodate heterogeneous receivers and
dynamic group membership, RSVP makes the receivers responsible for
requesting resource reservations [RSVP93]. Each receiver can request
a reservation that is tailored to its particular requirement, and
RSVP will deliver this request to the routers along the reverse
path(s) to the sender(s).
There are two aspects to RSVP, its reservation model and its protocol The remainder of this section describes the RSVP reservation
mechanisms. Sections 2.1 and 2.2 of this memo summarize the RSVP services. Section 2 presents an overview of the RSVP protocol
reservation model, while Sections 2.3 describes the protocol mechanisms, while Section 3 gives examples of the services and
mechanisms. Sections 2.4 gives examples of both model and mechanism, mechanism. Section 4 contains the functional specification of RSVP.
and Section 2.5 summarizes the model of RSVP seen by a host. Section Section 5 presents explicit message processing rules.
3 presents the functional specification for RSVP.
2. RSVP Overview 1.1 Data Flows
2.1 RSVP Reservation Model The set of data flows with the same unicast or multicast
destination constitute a session. RSVP treats each session
independently. All data packets in a particular session are
directed to the same IP destination address DestAddress, and
perhaps to some further demultiplexing point defined in a higher
layer (transport or application). We refer to the latter as a
"generalized destination port".
Figure 1 illustrates a single multicast distribution session. The DestAddress is the group address for multicast delivery, or the
arrows indicate data flowing from senders S1 and S2 to receivers unicast address of a single receiver. A generalized destination
R1, R2, and R3, and the cloud represents the distribution mesh port could be defined by a UDP/TCP destination port field, by an
created by the multicast routing protocol. Multicast distribution equivalent field in another transport protocol, or by some
forwards a copy of each data packet from a sender Si to every application-specific information. Although the RSVP protocol is
receiver Rj. Each sender Si and receiver Rj may correspond to a designed to be easily extendible for greater generality, the
unique Internet host, or there may be multiple logical senders present version uses only UDP/TCP ports as generalized ports.
(e.g., multiple TV cameras) and/or receivers in a single host.
RSVP reserves resources for simplex data streams, i.e., it Figure 2 illustrates the flow of data packets in a single RSVP
reserves resources in only one direction on a link, so that a session, assuming multicast data distribution. The arrows
sender is logically distinct from a receiver. However, the same indicate data flowing from senders S1 and S2 to receivers R1, R2,
application may act as both sender and receiver. and R3, and the cloud represents the distribution mesh created by
the multicast routing protocol. Multicast distribution forwards a
copy of each data packet from a sender Si to every receiver Rj; a
unicast distribution session has a single receiver R. Each sender
Si and each receiver Rj may correspond to a unique Internet host,
or a single host may contain multiple logical senders and/or
receivers, distinguished by generalized ports.
Senders Receivers Senders Receivers
_____________________ _____________________
( ) ===> R1 ( ) ===> R1
S1 ===> ( Multicast ) S1 ===> ( Multicast )
( ) ===> R2 ( ) ===> R2
( distribution ) ( distribution )
S2 ===> ( ) S2 ===> ( )
( by Internet ) ===> R3 ( by Internet ) ===> R3
(_____________________) (_____________________)
Figure 1: Multicast Distribution Session Figure 2: Multicast Distribution Session
All data packets in a given session are addressed to the same IP
destination address DestAddress. For multicast delivery,
DestAddress is the multicast group address to which the data is
addressed. For unicast delivery, DestAddress is simply the
unicast address of the single receiver. RSVP identifies a session
by DestAddress plus a 32-bit stream identifier called the
"reservation id" (ResvID). We use the term "session socket" for
the (DestAddress, ResvID) pair that defines a session. RSVP
treats each session independently. In the rest of this document,
a particular session (hence, session socket) is always implied
even if not stated.
Depending upon the reservation style and the session state already
in place, a new or modified reservation request may or may not
result in a call to admission control at each node [ISInt93]. If
an admission control call fails, the reservation is rejected and
an RSVP error message is sent to the receiver(s) responsible for
it.
A single RSVP resource reservation request is defined by a "
flowspec" together with a "filterspec"; this pair is called a "
Flow Descriptor". The flowspec specifies the desired QoS in a
quantitative manner, e.g., the tolerable delay, the average
throughput, the maximum burstiness, etc [Partridge92, ISInt93,
IServ93]; it is used to set parameters to the packet scheduling
mechanism in the node (router or host). The filterspec (plus the
DestAddress) defines the set of data packets to receive this
service; it is used to set parameters in the packet classifier
component of the node. For all packets that are addressed to a
particular session, only those that can match the filter spec(s)
of that session will be forwarded according to the flowspec; the
rest will be either dropped or sent as best-effort traffic.
More specifically, a filterspec may have two distinct functions.
o Sender Selection
A filterspec may select packets that originate from a 1.2 Reservation Model
particular sender Si, from the entire stream of packets
destined to a given DestAddress. The sender is selected
using its IP source address and optionally a "generalized
source port", i.e., multiplexing field(s) at the transport
layer (e.g., a UDP destination port) and/or the application
layer (e.g., a particular subset of a hierarchically encoded
video stream).
o Receiver Sub-selection An elementary RSVP reservation request consists of a "flowspec"
together with a "filter spec"; this pair is called a "flow
descriptor". The flowspec specifies a desired QoS. The filter
spec (together with the DestAddress and the generalized
destination port defining the session) defines the set of data
packets -- the "flow" -- to receive the QoS defined by the
flowspec. The flowspec is used to set parameters to the packet
scheduler in the node (assuming that admission control succeeds),
while the filter spec is used to set parameters in the packet
classifier.
A filterspec may distinguish different sessions with the same The flowspec in a reservation request will generally include a
DestAddress by selecting a subset of the packets destined to service type and two sets of numeric parameters: (1) an " Rspec"
that address. This subset is defined by a "generalized (R for `reserve'), which defines the desired per-hop reservation,
destination port", which again may include transport-layer and (2) a "Tspec" (T for `traffic'), which defines the parameters
(e.g., UDP destination port) and/or application-layer that may be used to police the data flow, i.e., to ensure it does
demultiplexing information. An RSVP receiver Rj is defined not exceed its promised traffic level.
by the pair (Hj, Pj), where Hj is the IP host address and Pj
is the generalized destination port.
RSVP needs to distinguish different sessions. It is difficult to The general RSVP reservation model allows filter specs to select
do this by matching generalized destination ports buried within arbitrary subsets of the packets in a given session. Such subsets
the filterspecs, since the part of the filterspec that defines the might be defined in terms of senders (i.e., sender IP address and
generalized destination port should be opaque to an RSVP module in generalized source port), in terms of a higher-level protocol, or
a router, which does not not know the structure of transport or generally in terms of any fields in any protocol headers in the
application layer protocol headers. Therefore, RSVP identifies a packet. For example, filter specs might be used to select
session by the pair (DestAddress, ResvID), where the ResvID's form different subflows in a hierarchically-encoded signal, by
a simple space of identifiers that RSVP can use to distinguish selecting on fields in an application-layer header. However,
different sessions with the same DestAddress. The ResvID's need considerations of both architectural purity and practical
not themselves be (generalized) ports, but the the ResvID values requirements have led to the decision that RSVP should use
that are used must have a one-to-one correspondence with the separate sessions for distinct subflows of hierarchically-encoded
generalized ports in use for the given DestAddress. 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.
All reservation requests for a given session must use filterspecs Any packets that are addressed to a particular session but do not
that specify the same DestAddress and the same generalized match any of the filter specs for that session will be sent as
destination port (since receivers of the same substream, best-effort traffic. Under congested conditions, such packets are
downstream of a given node, must share a common resource likely to experience long delays and may be dropped. A receiver
reservation in that node). may wish to conserve network resources by explicitly asking the
network to drop those data packets for which there is no
reservation; however, such dropping should be performed by
routing, not by RSVP. 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.
2.2 Reservation Styles RSVP reservation request messages originate at receivers and are
passed upstream towards the sender(s). (Note that this document
always uses the directional terms "upstream" vs. "downstream",
"previous hop" vs. "next hop", and "incoming interface" vs
"outgoing interface" with respect to the data flow direction).
When an elementary reservation request is received at a node, the
RSVP daemon takes two primary actions.
In addition to the Flow Descriptors, each RSVP reservation request 1. Make a reservation
specifies a "reservation style". The following reservation styles
have been defined so far.
1. Wildcard-Filter (WF) Style The flowspec and the filter spec are passed to traffic
control. Admission Control determines the admissibility of
the request (if it's new); if it fails this test, the
reservation is rejected and RSVP sends back an error message
towards the responsible receiver(s). If it passes, the
flowspec is used to set up the packet scheduler for the
desired QoS and the filter spec is used to set the packet
classifier to select the appropriate data packets.
A Wildcard-Filter (WF) style reservation creates a single 2. Forward reservation upstream.
resource "pipe" along each link, shared by data packets from
all senders for the given session. The "size" of this pipe
is the largest of the resource requests for that link from
all receivers, independent of the number of senders using it.
(The concept of a "largest" flowspec is discussed later).
The term "wildcard" implies a filterspec that selects all The reservation request is propagated upstream towards the
senders. A WF reservation automatically extends to new appropriate senders. The set of senders to which a given
senders to the session, as they appear. reservation request is propagated is called the "scope" of
that request.
2. Fixed-Filter (FF) Style The reservation request that a node forwards upstream may differ
from the request that it received, for two reasons. First, it is
possible (at least in theory) for the kernel to modify the
flowspec hop-by-hop (although currently no realtime services do
this). Second, reservations from different downstream branches of
the multicast distribution tree(s) must be "merged" as
reservations travel upstream. Merging reservations is a necessary
consequence of multicast distribution, which creates a single
stream of data packets in a particular router from any Si,
regardless of the set of receivers downstream. The reservation
for Si on a particular outgoing link L should be the "maximum" of
the individual flowspecs from the receivers Rj that are downstream
via link L. Merging is discussed further in Section 2.3.
A Fixed-Filter (FF) style reservation request creates For both of these primary actions, there are options controlled by
reservation(s) for data packets from particular sender(s). A the receiver making the reservation. These options are combined
FF reservation request from a particular receiver Rj contains into a control variable called the reservation "style", which is
a list of one or more Flow Descriptors, each consisting of a discussed in section 1.3. One option concerns the treatment of
filterspec, which specifies some sender Si, and a reservations for different senders within the same session:
corresponding flowspec. 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.
FF reservations requested by different receivers Rj but The basic RSVP reservation model is "one pass": a receiver sends a
selecting the same sender Si must necessarily share a single reservation request upstream, and each node in the path can only
reservation in a given node. This is simply the result of accept or reject the request. This scheme provides no way to make
multicast distribution, which creates a single stream of data end-to-end service guarantees; the QoS request is applied
packets in a particular router from any Si, regardless of the independently at each hop. RSVP also supports an optional
number of receivers downstream. The reservation for Si will reservation model, known as " One Pass With Advertising" (OPWA)
be the maximum of the individual flowspecs from different [Shenker94]. In OPWA, RSVP control packets sent downstream,
downstream receivers Rj (see Section 2.3.3). following the data paths, are used to gather information on the
end-to-end service that would result from a variety of possible
reservation requests. The results ("advertisements") are
delivered by RSVP to the receiver host, and perhaps to the
receiver application. The information may then be used by the
receiver to construct an appropriate reservation request.
FF reservations for different senders are distinct; they do 1.3 Reservation Styles
NOT share a common pipe. The total reservation on a link for
a given session is therefore the cumulative total of the
reservations for each requested sender. A receiver that has
established a FF style reservation may modify, add, or delete
a flow descriptor at any time. However, any additional or
modified reservations are subject to admission control and
may fail.
3. Dynamic-Filter (DF) Style Each RSVP reservation request specifies a "reservation style".
The following reservation styles are defined in this version of
the protocol.
A Dynamic-Filter (DF) style reservation decouples 1. Wildcard-Filter (WF) Style
reservations from filters. Each DF reservation request
specifies a number D of distinct reservations to be made
using the same specified flowspec. 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.
In addition to D and the flowspec, a DF style reservation may The WF style specifies the options: "mixing" reservation and
also specify a list of K filterspecs, for some K in the " wildcard" reservation scope. Thus, a WF-style reservation
range: 0 <= K <= D'. These filterspecs define particular creates a single reservation into which flows from all
senders to use the D' reservations. Once a DF reservation upstream senders are mixed. This reservation may be thought
has been established, the receiver may change the set of of a shared "pipe", whose "size" is the largest of the
filterspecs to specify a different selection of senders, resource requests for that link from all receivers,
without a new admission control check (assuming D' and the independent of the number of senders using it. A WF-style
common flowspec remain unchanged). This is known as "channel reservation has wildcard scope, i.e., the reservation is
switching", in analogy with a television set. propagated upstream towards all senders. A WF-style
reservation automatically extends to new senders to the
session as they appear.
In order to provide assured channel switching, each node 2. Fixed-Filter (FF) Style
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.
Like a FF style request, a DF style request causes distinct The FF style specifies the options: "distinct" reservation
reservations for different senders. and a "unitary" reservation scope. Thus, an elementary FF-
style reservation request creates a distinct reservation for
data packets from a particular sender, not mixing them with
other senders' packets for the same session.
As noted earlier, those data packets from senders that are The total reservation on a link for a given session is the
not currently selected may either be dropped or sent best- total of the FF reservations for all requested senders. On
effort. the other hand, FF reservations requested by different
receivers Rj but selecting the same sender Si must
necessarily be merged to share a single reservation in a
given node.
WF reservations are appropriate for those multicast applications WF reservations are appropriate for those multicast applications
whose application-level constraints prohibit all data sources from whose application-specific constraints make it unlikely that
transmitting simultaneously; one example is audio conferencing, multiple data sources will transmit simultaneously. One example is
where a limited number of people talk at once. Thus, each audio conferencing, where a limited number of people talk at once;
receiver might issue a WF reservation request for twice one audio each receiver might issue a WF reservation request for twice one
channel (to allow some over-speaking). On the other hand, the FF audio channel (to allow some over-speaking). On the other hand,
and DF styles create independent reservations for the flows from the FF style, which creates independent reservations for the flows
different senders; this is required for video signals, whose from different senders, is appropriate for video signals.
`silence' periods, if any, are uncoordinated among different
senders.
The essential difference between the FF and DF styles is that the The WF and FF styles are incompatible and cannot be combined
DF style allows a receiver to switch channels without danger of an within a session. Other reservation styles may be defined in the
admission denial due to limited resources (unless a topology future (see Appendix C).
change reroutes traffic along a lower-capacity path or new senders
appear), once the initial reservations have been made.
Other reservation styles may be defined in the future. 2. RSVP Protocol Mechanisms
2.3 RSVP Protocol Mechanisms 2.1 RSVP Messages
2.3.1 RSVP Messages There are two fundamental RSVP message types, RESV messages and
PATH messages.
Each receiver host sends RSVP reservation (RESV) messages into Each receiver host sends RSVP reservation request (RESV) messages
the Internet, carrying Flow Descriptors requesting the desired towards the senders. These reservation messages must follow in
reservation; see Figure 2. These reservation messages must reverse the routes the data packets will use, all the way upstream
follow the reverse of the routes the data packets will use, all to the senders within the scope. RESV messages are delivered to
the way upstream to all the senders. If a reservation request the sender hosts, so that the hosts can set up appropriate traffic
control parameters for the first hop. If a reservation request
fails at any node, an RSVP error message is returned to the fails at any node, an RSVP error message is returned to the
receiver; however, RSVP sends no positive acknowledgment receiver; however, RSVP sends no positive acknowledgment messages
messages to indicate success. RESV messages are finally to indicate success.
delivered to the sender hosts, so that the hosts can set up
appropriate traffic control parameters for the first hop.
Sender Receiver Sender Receiver
_____________________ _____________________
Path --> ( ) Path --> ( )
Si =======> ( Multicast ) Path --> Si =======> ( Multicast ) Path -->
<-- Resv ( ) =========> Rj <-- Resv ( ) =========> Rj
( distribution ) <-- Resv ( distribution ) <-- Resv
(_____________________) (_____________________)
Figure 2: RSVP Messages Figure 3: RSVP Messages
Each sender transmits RSVP PATH messages forward along the Each sender transmits RSVP PATH messages forward along the uni-
uni-/multicast routes provided by the routing protocol(s). /multicast routes provided by the routing protocol(s); see Figure
These "Path" messages store path state in all the intermediate 3. These "Path" messages store path state in each node. Path
routers. state is used by RSVP to route the RESV messages hop-by-hop in the
reverse direction. (In the future, some routing protocols may
supply reverse path forwarding information directly, without path
state).
The path state is currently used by RSVP to route the RESV PATH messages may also carry the following information:
messages in the reverse direction from each receiver to all
selected senders for a given session. In the future, this
function may be assumed by routing protocols. PATH messages
have other functions; they carry the following additional
information:
o A sender template, which describes the format of data o Sender Template
packets that the sender will originate.
The sender template takes the form of two bitstrings The Sender Template describes the format of data packets that
forming a (value, mask) pair. Zero mask bits represent the sender will originate. This template is in the form of a
"don't care" (variable) bits in data packets. If present, filter spec that could be used to select this sender's
this template is used by RSVP to match the filterspecs in packets from others in the same session on the same link.
a RESV message. Without such a template in the path
state, there will be no feedback (except poor service) to
the receiver that sets an impossible filter by mistake.
ISSUE: o Tspec
Should sender templates be defined to be precisely The PATH message may optionally carry a flowspec containing
filterspecs, or should templates and filterspecs be only a Tspec, defining an upper bound on the traffic level
allowed to use different syntax? that the sender will generate. This Tspec can be used by
RSVP to prevent over-reservation (and perhaps unnecessary
Admission Control failure) on the non-shared links starting
at the sender.
o A flowspec defining an upper bound on the traffic that o Adspec
will be generated.
This flowspec can be used by RSVP to prevent over- The PATH message may carry a package of OPWA advertising
reservation on the non-shared links starting at the information, known as an "Adspec".
sender.
A (template, flowspec) pair in a PATH message is called a Previous Incoming Outgoing Next
Sender Descriptor. Hops Interfaces Interfaces Hops
2.3.2 Soft State _____ _____________________ _____
| | data --> | | data --> | |
| A |-----------| a c |--------------| C |
|_____| <-- Resv | | <-- Resv |_____|
Path --> | | Path --> _____
_____ | ROUTER | | | |
| | | | | |--| D |
| B |--| data-->| | data --> | |_____|
|_____| |--------| b d |-----------|
|<-- Resv| | <-- Resv | _____
_____ | Path-->|_____________________| Path --> | | |
| | | |--| D' |
| B' |--| | |_____|
|_____| | |
To maintain reservation state, RSVP keeps "soft state" in Figure 4: Router Using RSVP
router and host nodes. RSVP soft state is created and
periodically refreshed by PATH and RESV messages, and it can be
removed at each node by explicit "Teardown" messages. RSVP
also has a timer-driven cleanup procedure if no message is
received within a cleanup timeout interval.
When the route changes, the next PATH message will initialize Figure 4 illustrates RSVP's model of a router node. Each data
the path state on the new route, and future RESV messages will stream arrives from a previous hop through a corresponding
establish reservation state while the state on the now-unused incoming interface and departs through one or more outgoing
segment of the route times out. Thus, whether a message is interface(s). The same physical interface may act in both the
incoming and outgoing roles (for different data flows but the same
session).
As illustrated in Figure 4, there may be multiple previous hops
and/or next hops through a given physical interface. This may
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
(see Section 2.6). An RSVP daemon must preserve the next and
previous hop addresses in its reservation and path state,
respectively. A RESV message is sent with a unicast destination
address, the address of a previous hop. PATH messages, on the
other hand, are sent with the session destination address, unicast
or multicast.
Although multiple next hops may send reservation requests through
the same physical interface, the final effect should be to install
a reservation on that interface, which is defined by an effective
flowspec. This effective flowspec will be the "maximum" of the
flowspecs requested by the different next hops. In turn, a RESV
message forwarded to a particular previous hop carries a flowspec
that is the "maximum" over the effective reservations on the
corresponding outgoing interfaces. Both cases represent merging,
which is discussed further below.
There are a number of ways for a new reservation request to fail
in a given node.
1. There may be no matching path state (i.e., the scope may
empty), which would prevent the reservation being propagated
upstream.
2. Its style may be incompatible with the style(s) of existing
reservations for the same session on the same outgoing
interface, so an effective flowspec cannot be computed.
3. Its style may be incompatible with the style(s) of
reservations that exist on other outgoing interfaces but will
be merged with this reservation when a refresh message to
create a refresh message for the previous hop.
4. The effective flowspec may fail admission control.
In any of these cases, an error message is returned to the
receiver(s) responsible for the message, but 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.
2.2 Soft State
To maintain reservation state, RSVP keeps "soft state" in router
and host nodes. RSVP soft state is created and periodically
refreshed by PATH and RESV messages. The state is deleted if no
refreshes arrive before the expiration of a "cleanup timeout"
interval; it may also be deleted as the result of an explicit
"Teardown" message. It is not necessary (although it may be
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
path state on the new route, and future RESV messages will
establish reservation state, while the state on the now-unused
segment of the route will time out. Thus, whether a message is
"new" or a "refresh" is determined separately at each node, "new" or a "refresh" is determined separately at each node,
depending upon the existence of state at that node. (This depending upon the existence of state at that node. (This
document will use the term "refresh message" in this effective document uses the term "refresh message" in this effective sense,
sense, to indicate an RSVP message that does not modify the to indicate an RSVP message that does not modify the existing
existing state at the node in question.) state at the node in question.)
In addition to the cleanup timeout, there is a "refresh timeout"
period. As messages arrive, the RSVP daemon checks them against
the existing state; if it matches, the cleanup timeout timer on
the state is reset and the message is dropped. At the expiration
of each refresh timeout period, RSVP scans its state to build and
forward PATH and RESV refresh messages to succeeding hops.
RSVP sends all its messages as IP datagrams without any RSVP sends its messages as IP datagrams without reliability
reliability enhancement. Periodic transmission of refresh enhancement. Periodic transmission of refresh messages by hosts
messages by hosts and routers is expected to replace any lost and routers is expected to replace any lost RSVP messages. To
RSVP messages. However, the traffic control mechanism should tolerate K successive packet losses, the effective cleanup timeout
be statically configured to grant high-reliability service to must be at least K times the refresh timeout. In addition, the
RSVP messages, to protect RSVP messages from severe congestion. traffic control mechanism in the network should be statically
configured to grant high-reliability service to RSVP messages, to
protect RSVP messages from congestion losses.
If the set of senders Si or receivers Rj changes, or if any of In steady state, refreshing is performed hop-by-hop, which allows
the receivers' reservation requests change, the RSVP state is merging and packing as described in the next section. However, if
adjusted accordingly. RSVP believes the latest PATH and RESV the received state differs from the stored state, the stored state
messages (ignoring the possibility of reordering). To modify a is updated. Furthermore, if the result will be to modify the
reservation, a receiver simply starts sending the new values. refresh messages to be generated, these refresh messages must be
It is not necessary (although it may sometimes be desirable, generated and forwarded immediately. This will result in changes
when the resources being consumed are "valuable"), to tear down propagating end-to-end without delay. However, propagation of a
the old reservation explicitly. change stops when and if it reaches a point where merging causes
no resulting state change; this minimizes RSVP control traffic due
to changes, and is essential for scaling to large multicast
groups.
When a RESV message is received at a router or sender host, the The "soft" router state maintained by RSVP is dynamic; to change
RSVP module checks whether the message is a new or a modified the set of senders Si or receivers Rj or to change any QoS
reservation request, or whether it simply refreshes an existing request, a host simply starts sending revised PATH and/or RESV
reservation. A new or modified request is passed to the messages. The result should be the appropriate adjustment in the
admission control module for a decision. If the reservation is distributed RSVP state, and immediate propagation to the
accepted, RSVP sets up (or modifies) the reservation and filter succeeding nodes.
state. It also forwards the RESV message to the next reverse-
hop router(s) or sender host(s), as determined by the path (or
routing) state. If RSVP on the node rejects the reservation
request due to admission control failure or to some processing
error, it discards the RESV message and returns a RSVP error
message to the originating receiver host. If the request
modifies a previous reservation, RSVP may immediately remove
the old state, or it may simply let the old state time out
since it is no longer being refreshed; the details depend upon
the style and the implementation.
Previous Incoming Outgoing Next The RSVP state associated with a session in a particular node is
Hops Interfaces Interfaces Hops divided into atomic elements that are created, refreshed, and
timed out independently. The atomicity is determined by 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
independently. Management of RSVP state is complex because there
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
| | data --> | | data --> | |
| |-----------| |------------| |
|_____| <-- Resv | | <-- Resv |_____|
Path --> | | Path -->
| Router |
_____ | | _____
| | data --> | | data --> | |
| |-----------| |------------| |
|_____| <-- Resv | | <-- Resv |_____|
Path --> |_____________________| Path -->
Figure 3: Router Using RSVP 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.
Figure 3 illustrates RSVP's model of a router node. Each data Although flowspecs are opaque to RSVP, an RSVP daemon must be able
stream arrives from a previous hop through a corresponding to calculate the "largest" of a set of flowspecs. This is
incoming interface and departs through one or more outgoing required both to calculate the effective flowspec to install on a
interface(s). Since the same host may be hosting both sender given physical interface (see the discussion in connection with
and receiver applications for a given session, the same Figure 4), and to merge flowspecs when sending a refresh message
physical interface may act in both the incoming and outgoing upstream. Since flowspecs are generally multi-dimensional vectors
roles (for different data streams). (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.
The interfaces shown in Figure 3 may be physical interfaces For protocol efficiency, RSVP also allows multiple sets of path
(e.g., to point-to-point links), or they may be logical (or reservation) information for the same session to be "packed"
interfaces that reach multiple nodes through the same physical into a single PATH (or RESV) message, respectively. (For
interface. Multiple previous hops and/or next hops through a simplicity, the protocol prohibits packing different sessions into
given physical interface can result from either the connected the same RSVP message).
network being a shared medium (e.g., an Ethernet), or from the
existence of non-RSVP routers in the path to the next RSVP hop
(see Section 3.5). It is generally necessary for RSVP to track
both logical and physical interfaces on both the incoming and
outgoing sides.
2.3.3 Merging RSVP Messages 2.4 Teardown
Whenever possible, the control information arriving in RSVP RSVP teardown messages remove path and reservation state without
messages for a given session is combined into fewer outgoing waiting for the cleanup timeout period, as an optimization to
messages; this is known generically as "merging". Those release resources quickly. Although teardown messages (like other
messages that cause a state change are forwarded without delay, RSVP messages) are not delivered reliably, the state will time out
while the refresh messages may be merged into fewer messages, even if it is not explicitly deleted.
perhaps only one per session.
For PATH messages, merging implies collecting together the A teardown request may be initiated either by an application in an
Sender Descriptors from multiple incoming messages into a end system (sender or receiver), or by a router as the result of
single outgoing PATH message. For RESV messages, merging state timeout. A router may also initiate a teardown message as
implies that only the essential (e.g., the largest) reservation the result of router or link failures detected by the routing
requests need be forwarded, once per refresh period; redundant protocol. Once initiated, a teardown request should be forwarded
messages are "purged". A successful reservation request will hop-by-hop without delay.
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.
To allow merging, each node must save the state from received To increase the reliability of teardown, Q copies of any given
messages and then periodically generate cumulative PATH and teardown message can be sent. Note that a node cannot actually
RESV messages from the saved state, to be forwarded in place of delete the state being torn down until it has sent Q Teardown
the received messages. Thus, new refresh messages are created messages; it must place the state in a "moribund" status
hop-by-hop inside the network, at a rate determined by a meanwhile. The appropriate value of Q is an engineering issue. Q
"refresh period". Since messages that modify the state in a = 1 would be the simplest and may be adequate, since unrefreshed
node ("new" messages) are forwarded without delay, the refresh state will time out anyway; teardown is an optimization. If one
period does not affect the rate at which new state propagates or more Teardown message hops are lost, the router that failed to
from end to end (when packets are not lost). receive a Teardown message will time out its state and initiate a
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.
Although flowspecs are opaque to RSVP, merging requires the There are two types of RSVP Teardown message, PTEAR and RTEAR. A
ability to determine which of two flowspecs is "larger", i.e. PTEAR message travels towards all receivers downstream from its
whether one represents a stricter request (and hence represents point of initiation and tears down path state along the way. A
a larger resource commitment) than the other. However, a RTEAR message tears down reservation state and travels towards all
flowspec may be a complex multi-dimensional vector, so the senders upstream from its point of initiation. A PTEAR (RTEAR)
"larger-than" relationship may not be defined for a given pair message may be conceptualized as a reversed-sense Path message
of flowspecs. For example, consider two flowspecs Fls1 and (Resv message, respectively).
Fls2, where Fls2 asks for a lower throughput but shorter delay
that Fls1. It is not clear which is "larger", so we say they
are "incompatible".
There are several possible solutions to merging incompatible A teardown message deletes the specified state in the node where
flowspecs. it is received. Like any other state change, this will be
propagated immediately to the next node, but only if it represents
a change. As a result, an RTEAR message will prune the
reservation state back (only) as far as possible. Note that the
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.
(1) Compare on a single dimension, e.g., compare the Deletion of path state, whether as the result of a teardown
throughput requirement (average bit rate) only. 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) Construct a third flowspec that is greater than each 2.5 Security
of the two being compared. In the example above, we
could construct a third flowspec Fls3 by combining
the higher throughput from Fls1 with the lower delay
from Fls2.
(3) Treat the compatibility as an error that should be There are two distinct types of security concerns in RSVP.
avoided by applications.
The choice of one of these approaches should be governed by 1. Protecting RSVP Message Integrity
flags in the flowspec itself, not by RSVP.
Note that this problem cannot be avoided by refraining from It may be necessary to ensure the integrity of RSVP messages
merging flowspecs. If incompatible flowspecs were not merged against corruption or spoofing, hop by hop. RSVP messages
at a particular node A, then they would arrive at the next node have an optional integrity field that can be created and
upstream, say B, in separate RESV messages. This may also verified by neighboring RSVP nodes.
happen if there are multiple next hops across the same outgoing
interface. Node B would have to make a reservation for the
largest flowspec, if that is defined, or one that dominates all
the given flowspecs; that is, it must merge the unmerged
reservations. Thus, failing to merge simply moves the problem
one node upstream.
This mechanism, reserving for the highest demand at each node, 2. Authenticating Reservation Requests
allows an application to increase an existing reservation
request immediately (assuming admission control does not fail
for the larger flowspec). Decreasing a reservation has to be
handled more cautiously, however. The arrival of a RESV
message with an apparently decreased reservation might be
caused by the loss of a merged RESV message downstream.
Therefore, an RSVP should not "believe" a reservation decrease
until the cleanup timeout has passed.
The refresh period and the cleanup timeout must obey the RSVP-mediated resource reservations may reserve network
following general principles: resources, providing special treatment for a particular set
of users. Administrative mechanisms will be necessary to
control who gets privileged service and to collect billing
information. These mechanisms may require secure
authentication of senders and/or receivers responsible for
the reservation. RSVP messages may contain credential
information to verify user identity.
A. The refresh period must be long enough to keep RSVP The RSVP packet formats provide for both; see Section 4.
overhead at an acceptable level.
B. The refresh period should be short enough to allow 2.6 Automatic RSVP Tunneling
quick adaptation to route and multicast membership
changes.
Applications may differ in their sensitivity to It is impossible to deploy RSVP (or any new protocol) at the same
service outages, and therefore they should be able to moment throughout the entire Internet. Furthermore, RSVP may
adjust the refresh period for their session state. never be deployed everywhere. RSVP must therefore provide correct
However, the technique of "local repair" (see Section protocol operation even when two RSVP-capable routers are joined
3.3.3) can provide rapid adaptation despite a long by an arbitrary "cloud" of non-RSVP routers. Of course, an
refresh period. intermediate cloud that does not support RSVP is unable to perform
resource reservation, so service guarantees cannot be made.
However, if there is sufficient excess capacity through such a
cloud, acceptable and useful realtime service may still be
possible.
C. The timeout period must be long enough to allow for RSVP will automatically tunnel through such a non-RSVP cloud.
loss of individual RSVP messages. Both RSVP and non-RSVP routers forward PATH messages towards the
destination address using their local uni-/multicast routing
table. Therefore, the routing of Path messages will be
unaffected by non-RSVP routers in the path. When a PATH message
traverses a non-RSVP cloud, the copies that emerge will carry as a
Previous Hop address the IP address of the last RSVP-capable
router before entering the cloud. This will effectively construct
a tunnel through the cloud for RESV messages, which will be
forwarded directly to the next RSVP-capable router on the path(s)
back towards the source.
2.3.4 Teardown Automatic tunneling is not perfect; in some circumstances it may
distribute path information to RSVP-capable routers not included
in the data distribution paths, which may create unused
reservations at these routers. This is because PATH messages
carry the IP source address of the previous hop, not of the
original sender, and multicast routing may depend upon the source
as well as the destination address. This can be overcome by
manual configuration of the neighboring RSVP programs, when
necessary.
As an optimization to release resources quickly, RSVP teardown 2.7 Session Groups
messages remove path and reservation state without waiting for
the cleanup timeout period. RSVP messages are not delivered
reliably, but the state will eventually time out even if a
teardown message is lost.
Teardown may be initiated either by an end system (sender or Section 1.2 explained that a distinct destination address, and
receiver), or by a router as the result of state timeout. A therefore a distinct session, will be used for each of the
router may also initiate a teardown message as the result of subflows in a hierarchically encoded flow. However, these
router or link failures detected by the routing protocol. A separate sessions are logically related. For example it may be
teardown, once initiated, will be forwarded hop-by-hop without necessary to pass reservations for all subflows to Admission
delay. 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.
There are two types of RSVP Teardown message, PTEAR and RTEAR. To declare that a set of sessions form a session group, a receiver
A PTEAR message travels towards all receivers downstream from includes a data structure we call a SESSION_GROUP object in the
its point of initiation and tears down path state along the RESV message for each of the sessions. A SESSION_GROUP object
way, while an RTEAR message tears down reservation state and contains four fields: a reference address, a session group ID, a
travels towards all senders upstream from its point of count, and a rank.
initiation.
A particular reservation on a node may be shared among multiple o The reference address is an agreed-upon choice from among the
senders and/or receivers, but it must apply to a unique next DestAddress values of the sessions in the group, for example
hop (and outgoing interface). The receipt of an RTEAR message the smallest numerically.
implies that the corresponding reservation state has been
removed downstream, so that the reservation can safely be
deleted locally. Again, the local node will only forward the
teardown message upstream when the state named in the message
has been entirely removed locally. As a result, an RTEAR
message will prune the reservation state back (only) as far as
possible. Note that the RTEAR message will cease to be
forwarded at the same node where merging suppresses forwarding
of the corresponding RESV messages.
Consider the router configuration shown in Figure 4 below. o The session group ID is used to distinguish different groups
Assume that there are reservations for source S1 on both with the same reference address.
outgoing interfaces (c) and (d), and that the receiver R1 wants
to tear down its reservation state for S1. R1's RTEAR message
arriving through interface (c) indicates that all reservation
state for (this session and) sender S1 has been removed
downstream. The current node therefore removes the S1
reservation state from interface (c). However, since there
will still be an S1 reservation on interface (d), the RTEAR
message will not be forwarded any further.
However, if the outgoing interface connects to a shared medium o The count is the number of members in the group.
or if there is a non-RSVP router immediately downstream, then
there may be multiple next-hop RSVP nodes downstream that are
reached through the same outgoing interface, say (c). Then a
single reservation may be shared among multiple next hops.
RSVP must tag each reservation with the next hop(s) from which
the RESV messages came, for use by teardown to avoid deleting
shared state.
Deletion of path state, whether as the result of a teardown o The rank, an integer between 1 and count, is different in
message or because of timeout, may force adjustments in related each session of the session group.
reservation state to maintain consistency in the local node.
Consider the path state for a sender S; the related reservation
state would be as follows.
o Wildcard-Filter style: If S is the only sender to the The SESSION_GROUP objects for all sessions in the group will
session, delete the reservation. 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.
o Fixed-Filter style: Delete reservations made for S. 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.
o Dynamic-Filter style: Reduce total reservation if it now Note that routing different sessions of the session group
exceeds the total number of remaining senders. 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.4 Examples 2.8 Host Model
Before a session can be created, the session identification,
comprised of DestAddress and perhaps the generalized destination
port, must be assigned and communicated to all the senders and
receivers by some out-of-band mechanism. In order to join an RSVP
session, the following events happen at the end systems.
H1 A receiver joins the multicast group specified by
DestAddress, using IGMP.
H2 A potential sender starts sending RSVP PATH messages to the
DestAddress, using RSVP.
H3 A receiver listens for PATH messages.
H4 A receiver starts sending appropriate RESV messages,
specifying the desired flow descriptors, using RSVP.
H5 A sender starts sending data packets.
There are several synchronization considerations.
o Suppose that a new sender starts sending data (H5) but no
receivers have joined the group (H1). Then there will be no
multicast routes beyond the host (or beyond the first RSVP-
capable router) along the path; the data will be dropped at
the first hop until receivers(s) do appear (assuming a
multicast routing protocol that "prunes off" or otherwise
avoids unnecessary paths).
o Suppose that a new sender starts sending PATH messages (H2)
and immediately starts sending data (H5), and there are
receivers but no RESV messages have reached the sender yet
(e.g., because its PATH messages have not yet propagated to
the receiver(s)). Then the initial data may arrive at
receivers without the desired QoS.
o If a receiver starts sending RESV messages (H4) before any
PATH messages have reached it (H5) (and if path state is
being used to route RESV messages), RSVP will return error
messages to the receiver. The receiver may simply choose to
ignore such error messages, or it may avoid them by waiting
for PATH messages before sending RESV messages.
A specific application program interface (API) for RSVP is not
defined in this protocol spec, as it may be host system dependent.
However, Section 4.6.1 discusses the general requirements and
presents a generic API.
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( *{r}) WF( *{Q})
Here "*{r}" represents a Flow Descriptor with a "wildcard" Here "*{Q}" represents a Flow Descriptor with a "wildcard" scope
filter (choosing all senders) and a flowspec of quantity r. (choosing all senders) and a flowspec of quantity Q.
For simplicity we assume here that flowspecs are one-
dimensional, defining for example the average throughput, and
state them as a multiple of some unspecified base resource
quantity B.
2. Fixed-Filter 2. Fixed-Filter
FF( S1{r1}, S2{r2}, ...)
This message carries a list of (sender, flowspec) pairs, FF( S1{Q1}, S2{Q2}, ...)
i.e., Flow Descriptors.
3. Dynamic-Filter
DF( n, {r} ; ) or DF( n, {r} ; S1, S2, ...) A list of (sender, flowspec) pairs, i.e., flow descriptors,
packed into a single RESV message.
This message carries the count n of channels to be reserved, For simplicity we assume here that flowspecs are one-dimensional,
each using common flowspec r. It also carries a list, defining for example the average throughput, and state them as a
perhaps empty, of filterspecs defining senders. multiple of some unspecified base resource quantity B.
Figure 4 shows schematically a router with two previous hops Figure 5 shows schematically a router with two previous hops labeled
labeled (a) and (b) and two outgoing interfaces labeled (c) and (a) and (b) and two outgoing interfaces labeled (c) and (d). This
(d). This topology will be assumed in the examples that follow. topology will be assumed in the examples that follow. There are
There are three upstream senders; packets from sender S1 (S2 and three upstream senders; packets from sender S1 (S2 and S3) arrive
S3) arrive through previous hop (a) ((b), respectively). There through previous hop (a) ((b), respectively). There are also three
are also three downstream receivers; packets bound for R1 and R2 downstream receivers; packets bound for R1 and R2 (R3) are routed via
(R3) are routed via outgoing interface (c) ((d) respectively). outgoing interface (c) ((d) respectively).
In addition to the connectivity shown in 4, we must also specify In addition to the connectivity shown in 5, we must also specify the
the multicast routing within this node. Assume first that data multicast routing within this node. Assume first that data packets
packets (hence, PATH messages) from each Si shown in Figure 4 is (hence, PATH messages) from each Si shown in Figure 5 is routed to
routed to both outgoing interfaces. Under this assumption, both outgoing interfaces. Under this assumption, Figures 6 and 7
Figures 5, 6, and 7 illustrate Wildcard-Filter reservations, illustrate Wildcard-Filter reservations and Fixed-Filter
Fixed-Filter reservations, and Dynamic-Filter reservations, reservations, respectively.
respectively.
________________ ________________
(a)| | (c) (a)| | (c)
( S1 ) ---------->| |----------> ( R1, R2) ( S1 ) ---------->| |----------> ( R1, R2)
| Router | | Router |
(b)| | (d) (b)| | (d)
( S2,S3 ) ------->| |----------> ( R3 ) ( S2,S3 ) ------->| |----------> ( R3 )
|________________| |________________|
Figure 4: Router Configuration Figure 5: Router Configuration
In Figure 5, the "Receive" column shows the RESV messages received In Figure 6, the "Receive" column shows the RESV messages received
over outgoing interfaces (c) and () and the "Reserve" column shows over outgoing interfaces (c) and () 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 message with the largest flowspec is forwarded upstream only the largest flowspec is forwarded upstream to each previous hop.
to each previous hop.
| |
Send | Reserve Receive Send | Reserve Receive
| |
| _______ | _______
WF( *{3B} ) <- (a) | (c) | * {3B}| (c) <- WF( *{B} ) WF( *{3B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} )
| |_______| | |_______|
| |
-----------------------|---------------------------------------- -----------------------|----------------------------------------
| _______ | _______
WF( *{3B} ) <- (b) | (d) | * {B} | (d) <- WF( *{3B} ) WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} )
| |_______| | |_______|
Figure 5: Wildcard-Filter Reservation Example 1 Figure 6: Wildcard-Filter Reservation Example 1
Figure 6 shows Fixed-Filter style reservations. Merging takes
place among the flow descriptors (i.e., filter spec, flowspec
pairs). For example, the message forwarded to previous hop b,
towards S2 and S3, contains flow descriptors received from
outgoing interfaces (c) and (d). Similarly, when FF( S1{B} ) and
FF( S1{3B} ) are merged, the single message FF( S1{3B} ) is sent
to previous hop (a), towards S1.
For each outgoing interface, there is a private reservation for Figure 7 shows Fixed-Filter style reservations. The flow descriptors
each source that has been requested, but this private reservation for senders S2 and S3, received from outgoing interfaces (c) and (d),
is shared among the receivers that made the request. are packed into the message forwarded to previous hop b. On the
other hand, the two different flow descriptors for sender S1 are
merged into the single message FF( S1{3B} ), which is sent to
previous hop (a), For each outgoing interface, there is a private
reservation for each source that has been requested, but this private
reservation is shared among the receivers that made the request.
| |
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 6: Fixed-Filter Reservation Example Figure 7: Fixed-Filter Reservation Example
Figure 7 shows an example of Dynamic-Filter reservations. The
receivers downstream from interface (d) have requested two
reserved channels, but selected only one sender, S1. The node
reserves min(2,3) = 2 channels of size B on interface (d), and it
then applies any specified filters to these channels. Since only
one sender was specified, one channel has no corresponding filter,
as shown by `?'.
Similarly, the receivers downstream of interface (c) have
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 requested by one of them, for example.
|
Send | Reserve Receive
|
| ________
DF( 1,{B}; S1) <- (a) | (c) | S1{B} | (c) <- DF( 2,{B}; S1, S2)
| |________|
| | S2{B} |
| |________|
|
| ________
DF( 2,{B}; S2) <- (b) | (d) | S1{B} | (d) <- DF( 2,{B}; S1)
| |________|
| | ?{B} |
| |________|
Figure 7: Dynamic-Filter Reservation Example
A router should not reserve more Dynamic-Filter channels than the
number of upstream sources (three, in the router of Figure 7).
Since there is only one source upstream from previous hop (a), the
first parameter of the DF message (the count of channels to be
reserved) was decreased to 1 in the forwarded reservations.
However, this is unnecessary, because the routers upstream will
reserve only one channel, regardless.
When a DF reservation is received, it is labeled with the IP
address of the next hop (RSVP-capable) router, downstream from the
current node. Since the outgoing interface may be directly
connected to a shared medium network or to a non-RSVP-capable
router, there may be more than one next-hop node downstream; if
so, each sends independent DF RESV messages for a given session.
The number N' of DF channels reserved on an outgoing interface is
given by the formula:
N' = min( D1+D2+...Dn, Ns),
where Di is the D value (channel reservation count) in a RESV from
the ith next-hop node.
The three examples just shown assume full routing, i.e., data The two examples just shown assume full routing, i.e., data packets
packets from S1, S2, and S3 are routed to both outgoing from S1, S2, and S3 are routed to both outgoing interfaces. Assume
interfaces. Assume the routing shown in Figure 8, in which data the routing shown in Figure 8, in which data packets from S1 are not
packets from S1 are not forwarded to interface (d) (because the forwarded to interface (d) (because the mesh topology provides a
mesh topology provides a shorter path for S1->R3 that does not shorter path for S1 -> R3 that does not traverse this node).
traverse this node).
_______________ _______________
(a)| | (c) (a)| | (c)
( S1 ) ---------->| --------->--> |----------> ( R1, R2) ( S1 ) ---------->| --------->--> |----------> ( R1, R2)
| / | | / |
| / | | / |
(b)| / | (d) (b)| / | (d)
( S2,S3 ) ------->| ->----------> |----------> ( R3 ) ( S2,S3 ) ------->| ->----------> |----------> ( R3 )
|_______________| |_______________|
Figure 8: Router Configuration Figure 8: Router Configuration
Under this assumption, Figure 9 shows Wildcard-Filter Under this assumption, Figure 9 shows Wildcard-Filter reservations.
reservations. Since there is no route from (a) to (d), the Since there is no route from (a) to (d), the reservation forwarded
reservation forwarded out interface (a) considers only the out interface (a) considers only the reservation on interface (c), so
reservation on interface (c), so no merging takes place in this no merging takes place in this case.
case.
| |
Send | Reserve Receive Send | Reserve Receive
| |
| _______ | _______
WF( *{B} ) <- (a) | (c) | * {3B}| (c) <- WF( *{B} ) WF( *{B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} )
| |_______| | |_______|
| |
-----------------------|---------------------------------------- -----------------------|----------------------------------------
| _______ | _______
WF( *{3B} ) <- (b) | (d) | * {B} | (d) <- WF( * {3B} ) WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} )
| |_______| | |_______|
Figure 9: Wildcard-Filter Reservation Example -- Partial Routing Figure 9: Wildcard-Filter Reservation Example -- Partial Routing
2.5 Host Model 4. RSVP Functional Specification
Before a session can be created, the session socket, comprised of 4.1 RSVP Message Formats
DestAddress and ResvID, must be assigned and communicated to all
the senders and receivers by some out-of-band mechanism. In order
to join an RSVP session, the end systems perform the following
actions.
H1 A receiver joins the multicast group specified by All RSVP messages consist of a common header followed by a
DestAddress. variable number of variable-length typed "objects" using a common
structure. The subsections that follow define the formats of the
common header, the object structures, and each of the RSVP message
types. For each RSVP message type, there is a set of rules for
the permissible ordering and choice of object types. These rules
are specified using Backus-Naur Form (BNF) augmented with square
brackets surrounding optional sub-sequences.
H2 A potential sender starts sending RSVP PATH messages to 4.1.1 Common Header
the DestAddress.
H3 A receiver listens for PATH messages. 0 1 2 3
+-------------+-------------+-------------+-------------+
| Vers | Type | Flags | Message Length |
+-------------+-------------+-------------+-------------+
| RSVP Checksum | Object Count |
+-------------+-------------+-------------+-------------+
H4 A receiver starts sending appropriate RESV messages, The common header fields are as follows:
specifying the desired Flow Descriptors.
There are several synchronization issues. Vers
o Suppose that a new sender starts sending data but there are Protocol version number. This is version 2.
no receivers. There will be no multicast routes beyond the
host (or beyond the first RSVP-capable router) along the
path; the data will be dropped at the first hop until
receivers(s) do appear (assuming a multicast routing protocol
that "prunes off" or otherwise avoids unnecessary paths).
o Suppose that a new sender starts sending PATH messages (H2) Type
and immediately starts sending data, and there are receivers
but no RESV messages have reached the sender yet (e.g.,
because its PATH messages have not yet propagated to the
receiver(s)). Then the initial data may arrive at receivers
without the desired QoS.
o If a receiver starts sending RESV messages (H4) before any 1 = PATH
PATH messages have reached it (and if path state is being
used to route RESV messages), RSVP will return error messages
to the receiver.
The receiver may simply choose to ignore such error messages, 2 = RESV
or it may avoid them by waiting for PATH messages before
sending RESV messages.
A specific application program interface (API) for RSVP is not 3 = PERR
defined in this protocol spec, as it may be host system dependent.
However, Section 3.6.2 discusses the general requirements and
presents a generic API.
3. Functional Specification 4 = RERR
There are currently 6 types of RSVP messages: PATH, RESV, PTEAR, 5 = PTEAR
RTEAR, PERR, and RERR.
3.1 Message Formats 6 = RTEAR
3.1.1 Path Message 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
A standard TCP/UDP checksum over the contents of the RSVP
message, with the checksum field replaced by zero.
Object Count
Count of variable-length objects that follow.
4.1.2 Object Formats
An object consists of one or more 32-bit words with a one-word
header, in the following format:
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Vers | Type | Flags | RSVP Checksum | | Length (bytes) | Class | C-Type |
+-------------+-------------+-------------+-------------+
| DestAddress |
+-------------+-------------+-------------+-------------+
| ResvID |
+-------------+-------------+-------------+-------------+
| Refresh Period |
+-------------+-------------+-------------+-------------+
| State TTL Time |
+-------------+-------------+-------------+-------------+
| Previous Hop Address |
+-------------+-------------+-------------+-------------+
| /////////////// | SD Count |
+-------------+-------------+-------------+-------------+
| Authentication Field |
// ... //
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Sender Descriptor List | | |
// ... // // (Object contents) //
| |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
IP Fields: An object header has the following fields:
Protocol Length
46 Total length in bytes. Must always be a multiple of 4,
and at least 4.
IP Source Address Class
The IP address of the host or router sending this Object class. In this document, the names of object
classes are capitalized.
0 = NULL
A NULL object has a Class of zero; its C-Type is
ignored. Its length must be at least 4, but can be
any multiple of 4. A NULL object may appear anywhere
in a sequence of objects, and its contents will be
ignored by the receiver.
1 = SESSION
Contains the IP destination address (DestAddress) and
possibly a generalized source port, to define a
specific session for the other objects that follow.
Required in every RSVP message.
2 = SESSION_GROUP
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
sent this message. This document refers to a
RSVP_HOP object as a PHOP ("previous hop") object for
downstream messages or as a NHOP ("next hop") object
for upstream messages.
4 = STYLE
Defines the reservation style plus style-specific
information that is not a FLOWSPEC or FILTER_SPEC
object, in a RESV message.
5 = FLOWSPEC
Defines a desired QoS, in a RESV message.
6 = FILTER_SPEC
Defines a subset of session data packets that should
receive the desired QoS (specified by an FLOWSPEC
object), in a RESV message.
7 = SENDER_TEMPLATE
Contains a sender IP address and perhaps some
additional demultiplexing information to identify a
sender, in a PATH message.
8 = SENDER_TSPEC
Defines the traffic characteristics of a sender's
data stream, in a PATH message.
9 = ADVERT
Carries an Adspec containing OPWA data, in a PATH
message. message.
IP Destination Address 10 = TIME_VALUES
The IP address of the data destination (DestAddress). 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.
RSVP Fields: 11 = ERROR_SPEC
Vers Specifies an error, in a PERR or RERR message.
Version number. This is version 1. 12 = CREDENTIAL
Type Contains user credential and/or information for
policy control and/or accounting.
1 = Path Message 13 = INTEGRITY
Flags Contains a cryptographic data to authenticate the
originating node, and perhaps verify the contents, of
this RSVP message.
8 = Drop C-Type
If this flag bit is on then data packets will be Object type; unique within Class. Values defined in
dropped when they are destined to this session Appendix A.
but their sender is not currently selected by
any filter. If this flag bit is off, such data
packets will still be forwarded but without a
reservation, i.e., using a best-effort class.
RSVP Checksum The Class and C-Type fields may be used together as a 16-bit
number to define a unique type for each object.
A standard TCP/UDP checksum, over the contents of the The formats of specific object types are defined in Appendix A.
RSVP message with the checksum field replaced by
zero.
DestAddress, ResvID 4.1.3 Path Message
The IP address and stream Id identifying the session, PATH messages carry information from senders to receivers along
i.e., the session socket. the same paths, and using the same uni-/multicast routes, as
the data packets. The IP destination address of a PATH message
is the DestAddress for the session, and the source address is
an address of the node that sent the message (if possible, the
address of the particular interface through which it was sent).
Previous Hop Address The format of a PATH message is as follows:
The IP address of the interface through which the <Path Message> ::= <Common Header> <SESSION> <RSVP_HOP>
host or router last forwarded this message.
The Previous Hop Address is used to support reverse- [ <INTEGRITY> ] [ <TIME_VALUES> ]
path forwarding of RESV messages. This field is
initialized by a sender to its IP address (see IP
Source Address above) and must be updated at each
router hop as the PATH message is forwarded.
Refresh Period <sender descriptor list>
This field specifies the refresh timeout period in <sender descriptor list> ::= <empty > |
milliseconds. See Section 3.3 below.
State TTL Time <sender descriptor list> <sender descriptor>
This field specifies the time-to-live for soft state, <sender descriptor> ::= [ <CREDENTIAL> ] <SENDER_TEMPLATE>
in milliseconds. It determines the cleanup timeout
period; see Section 3.3 below.
SD Count [ <SENDER_TSPEC> ] [ <ADVERT> ]
Count of Sender Descriptors that follow. Each sender descriptor defines a sender, and the sender
descriptor list allows multiple sender descriptors to be packed
into a PATH message. For each sender in the list, the
SENDER_TEMPLATE object defines the format of data packets, the
SENDER_TSPEC object may specify the traffic flow, and the
CREDENTIAL object may specify the user credentials. There may
also be an ADVERT object carrying advertising (OPWA) data.
Authentication Field Each sender host must periodically send a PATH message
containing the sender descriptor(s) describing its own data
stream(s), for a given session. Each sender descriptor is
forwarded and replicated as necessary to follow the delivery
path(s) for a data packet from the same sender, finally
reaching the applications on all receivers (except not a
receiver included in the sender process).
A variable-length authentication field to identify At each node, a route must be computed independently for each
and perhaps authenticate the principal making this sender descriptors being forwarded. These routes, obtained
reservation request. The field has the following from the uni/multicast routing table, generally depend upon the
form: (sender host address, DestAddress) pairs, and consist of a list
of outgoing interfaces. Then the descriptors being forwarded
through the same outgoing interface can 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. 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
| AuthLen | AuthType | | path state, which includes SENDER_TEMPLATE object and possibly
+-------------+-------------+ + CREDENTIAL, SENDER_TSPEC, and ADVERT objects. If an error is
// Authentication Info // encountered while processing a PATH message, a PERR message is
+-------------+-------------+-------------+-------------+ sent to all senders implied by the SENDER_TEMPLATEs in the
sender descriptor list.
The AuthLen octet contains the integer length of the 4.1.4 Resv Messages
field in fullwords, and AuthType specifies the format
of the field. See Section 3.6.1 for currently
defined authentication field formats. If there is no
authentication information, AuthLen will be zero, but
the Authentication Field will still occupy one
fullword in the message.
Sender Descriptor List RESV messages carry reservation requests hop-by-hop from
receivers to senders, along the reverse paths of data flow for
the session. The IP destination address of a RESV message is
the unicast address of a previous-hop node, obtained from the
path state. The Next Hop address (in the RSVP_HOP object)
should be the IP address of the (incoming) interface through
which the RESV message is sent. The IP source address is an
address of the node that sent the message (if possible, the
address of the particular interface through which it was sent).
A list of Sender Descriptors (see below). The order The permissible sequence of objects in a RESV message depends
of entries in this list is irrelevant. 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).
Each sender must periodically send a PATH message containing a The RESV message format is as follows:
single Sender Descriptor describing its own data stream. These
messages are addressed to the uni-/multicast destination
address for the session, and they are forwarded to all
receivers, following the same paths as a data packet from the
same sender. PATH messages are received and processed locally
to create path state at each intermediate router along the
path.
If an error is encountered while processing a PATH message, an <Resv Message> ::= <Common Header> <SESSION>
RSVP error message is sent to all the sender hosts listed in
the Sender Descriptor List.
PATH messages are distributed from senders to receivers along [ <SESSION_GROUP> ] <RSVP_HOP>
the exact paths that the data will traverse, using uni-
/multicast routing. This distribution actually takes place
hop-by-hop, allowing RSVP in each router along the path to
observe and modify the message. Routing of PATH messages is
based on the sender address(es) from the Sender Descriptor(s),
not the IP source address. This is necessary to prevent loops;
see Section 3.2.
Each Sender Descriptor consists of two variable-length fields: [ <INTEGRITY> ] [ <TIME_VALUES> ]
a sender template that defines the format of data packets and a
corresponding Flowspec that describes the traffic
characteristics. The sender template has the form of a
filterspec, and a Sender Descriptor has the form defined below
for a Flow Descriptor (see also Section 3.6.1). The flowspec
may be omitted, in which case its length field will be zero
(but it will still occupy one fullword in the Sender
Descriptor).
The Sender template is retained in the Path state in order to [ <CREDENTIAL> ]
validate filterspecs in RESV messages. Suppose that a
filterspec consisted of a simple (value,mask) pair (Vf,Mf) to
be applied to the headers of the data packets (the actual
format is slightly more complex; see Section 3.6.1). Then the
corresponding template would be a (value,mask) pair defining
those bits of the data packet headers that are fixed. While
processing a reservation using filterspec (Vf,Mf) for the
sender with template (Vs,Ms), RSVP can then test whether
Vf&(Mf&Ms) = Vs&(M&Ms). If not, this filterspec cannot
possibly match the data stream from this sender at any node
upstream, and the reservation can be rejected with an error
message back to the receiver.
3.1.2 Resv Message <style-specific tail>
RESV messages are sent from receivers to senders along reverse <style-specific-tail> ::=
paths established by PATH messages.
0 1 2 3 <Style-WF> [ <FILTER_SPEC> ] <FLOWSPEC> |
+-------------+-------------+-------------+-------------+ <Style-FF> <flow descriptor list>
| Vers | Type | Flags | RSVP Checksum |
+-------------+-------------+-------------+-------------+
| DestAddress |
+-------------+-------------+-------------+-------------+
| ResvID |
+-------------+-------------+-------------+-------------+
| Refresh Period |
+-------------+-------------+-------------+-------------+
| State TTL Time |
+-------------+-------------+-------------+-------------+
| Next Hop Address |
+-------------+-------------+-------------+-------------+
| RecvAddress |
+-------------+-------------+-------------+-------------+
| Dynamic Reservation Count | FD Count |
+-------------+-------------+-------------+-------------+
| Authentication Field |
// ... //
+-------------+-------------+-------------+-------------+
| Flow Descriptor List |
// ... //
+-------------+-------------+-------------+-------------+
The fields are the same as defined earlier for a PATH message, <flow descriptor list> ::= <empty> |
except for the following:
IP Fields: <flow descriptor list> <FILTER_SPEC> <FLOWSPEC>
IP Source Address The reservation scope, i.e., the set of senders towards which a
particular reservation is to be forwarded, is determined by
matching FILTER_SPEC objects against the path state created
from SENDER_TEMPLATE objects, considering any wildcards that
may be present.
The IP address of the node sending this message. 4.1.5 Error Messages
IP Destination Address There are two types of RSVP error messages:
The IP address of the next-hop router or host to o PERR messages result from PATH messages and travel towards
which this message is being sent. senders. PERR messages are routed hop-by-hop like RESV
messages; at each hop, the IP destination address is the
unicast address of a previous hop.
RSVP Fields: o RERR messages result from RESV messages and travel hop-
by-hop towards the appropriate receivers, routed by the
reservation state. At each hop, the IP destination
address is the unicast address of a next-hop node.
Routing is discussed below.
Type RSVP error messages are triggered only by processing of PATH
and RESV messages; errors encountered while processing error or
teardown messages must not create error messages.
2 = Resv Message <PathErr message> ::= <Common Header> <SESSION> <RSVP_HOP>
Flags [ <INTEGRITY> ] <ERROR_SPEC>
The following flag bit combinations define the <sender descriptor>
reservation style:
001xxxxx = Wildcard-Filter <sender descriptor list> ::= (see earlier definition)
010xxxxx = Fixed-Filter <ResvErr Message> ::= <Common Header> <SESSION> <RSVP_HOP>
011xxxxx = Dynamic-Filter [ <INTEGRITY> ] <ERROR_SPEC>
Next Hop Address [ <CREDENTIAL> ] <style-specific tail>
<style-specific tail> ::= (see earlier definition)
The IP address of the interface through which the The ERROR_SPEC specifies the error. It includes the IP address
last forwarded this message. of the node that detected the error, called the Error Node
Address.
The Next Hop Address is used to support teardown. When a PATH or RESV message has been "packed" with multiple
This field is initialized by a receiver to its IP sets of elementary parameters, the RSVP implementation should
address and must be updated at each router hop as the process each set independently and return a separate error
RESV message is forwarded. message for each that is in error.
RecvAddress An error message may be duplicated and forwarded unchanged. In
general, error messages should be delivered to the applications
on all the session nodes that (may have) contributed to this
error.
The IP address of (one of the) receiver(s) that o A PERR message is forwarded to all previous hops for all
originated this message, or one of the RESV messages senders listed in the Sender Descriptor List.
that was merged to form this message.
Dynamic Reservation Count o The node that creates a RERR message as the result of
processing a RESV message should send the RERR message out
the interface through which the RESV arrived.
The number of channels to be reserved, for a In succeeding hops, the routing of a RERR message depends
Dynamic-Filter style reservation. upon its style and upon routing. In general, a RERR
message is sent out some subset of the outgoing interfaces
specified for multicast routing, using Error Node Address
as the source address and DestAddress as the destination.
(This rule is necessary to prevent packet loops; see
Section 4.3 below). Within this set of outgoing
interfaces, a RERR message is sent only to next hop(s)
whose RESV message(s) created the error; this in turn
depends upon the merging of flowspecs. Assume that a
reservation whose error is being reported was formed by
merging two flowspecs Q1 and Q2 from different next hops.
If the ResvStyle is Dynamic-Filter, this integer - If Q1 = Q2, the error message should be forwarded to
value must be constant and equal or greater than (FD both next hops.
Count). For other ResvStyles, this field must be
zero.
FD Count - If Q1 < Q2, the error message should be forwarded
only to the next hop for Q2.
Count of Flow Descriptors in the Flow Descriptor - If Q1 and Q2 are incomparable, the error message
List. should be forwarded to both next hops, and the LUB
flag should be turned on.
Flow Descriptor List The ERROR_SPEC and the LUB-flag should be delivered to the
A list of Flow Descriptors, i.e., (Filterspec, receiver application. In the case of an Admission Control
flowspec) pairs, to define individual reservation error, the style-specific tail will contain the FLOWSPEC
requests. The first entry in the list may have object that failed. If the LUB-flag is off, this should
special meaning (see below); the order of later be the same as a FLOWSPEC in a RESV message sent by this
entries is irrelevant. application; otherwise, they may differ.
Each Flow Descriptor has the following form: An error in a 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 CREDENTIAL object may be detected anywhere along the
path(s) to the sender(s).
+-------------+-------------+-------------+-------------+ 4.1.6 Teardown Messages
| FiltSLen | FiltSType | |
+-------------+-------------+ +
// Filter Spec ... //
+-------------+-------------+-------------+-------------+
| FlowSLen | FlowSType | |
+-------------+-------------+ +
// Flow Spec ... //
+-------------+-------------+-------------+-------------+
Here FiltSLen and FlowSLen are one-octet fields There are two types of RSVP Teardown message, PTEAR and RTEAR.
specifying the lengths in fullwords (including the
length byte) of the filterspec and flowspec,
respectively, and FiltSType and FlowSType are one-
octet fields defining the corresponding field
formats. See Section 3.6.1 for currently defined
formats.
The following specific rules hold for different reservation o PTEAR messages delete path state (which in turn may delete
styles. reservations state) and travel towards all receivers that
are downstream from the point of initiation. PTEAR
messages are routed like PATH messages, and their IP
destination address is DestAddress for the session.
o Wildcard-Filter o RTEAR messages delete reservation state and travel towards
all matching senders upstream from the point of teardown
initiation. RTEAR message are routed like RESV messages,
and their IP destination address is the unicast address of
a previous hop.
To obtain Wildcard-Filter service, set FD Count = 1 and <PathTear Message> ::= <Common Header> <SESSION> <RSVP HOP>
include a single Flow Descriptor whose Filterspec part is
a wild card, i.e., selects all senders. and whose
flowspec part defines the desired flow parameters.
o Fixed-Filter [ <INTEGRITY> ]
Include a list of FD Count >= 1 Flow Descriptors, each <sender descriptor list>
defining a sender Filterspec and a corresponding flowspec.
o Dynamic-Filter <sender descriptor list> ::= (see earlier definition)
Include max(1, FD Count) Flow Descriptors in the message. <ResvTear Message> ::= <Common Header> <SESSION> <RSVP HOP>
Here the FD Count specifies the number of sender
Filterspecs that are included. If DC is the Dynamic
Reservation Count, then DC >= FD Count >= 0.
The Flowspec part of the first Flow Descriptor defines the [ <INTEGRITY> ] [ <CREDENTIAL> ]
desired size of all the DC channels that are reserved.
The Flowspec parts of later Flow Descriptors (if any) are
ignored.
3.1.3 Error Messages <style-specific tail>
There are two types of RSVP error messages: PERR messages <style-specific tail> ::= (see earlier definition)
result from PATH messages and travel towards senders, while
RERR messages result from RESV messages and travel towards
receivers. RSVP error messages are triggered only by
processing of PATH and RESV messages; errors encountered while
processing error or teardown messages must not create error
messages.
A PERR message has the following form: Flowspec objects in the style-specific tail of a RTEAR message
will be ignored and may be omitted.
0 1 2 3 If the state being deleted was created with user credentials
+-------------+-------------+-------------+-------------+ from a CREDENTIAL field, then the matching PTEAR or RTEAR
| Vers | Type | Flags | RSVP Checksum | message must include matching CREDENTIAL field(s).
+-------------+-------------+-------------+-------------+
| DestAddress |
+-------------+-------------+-------------+-------------+
| ResvID |
+-------------+-------------+-------------+-------------+
| Error Code | Error Index | Error Value |
+-------------+-------------+-------------+-------------+
| ////////////// (ignored) ////////////////// |
+-------------+-------------+-------------+-------------+
| ////////////// (ignored) ////////////////// |
+-------------+-------------+-------------+-------------+
| /// Reserved /// | SD Count |
+-------------+-------------+-------------+-------------+
| Authentication Field |
// ... //
+-------------+-------------+-------------+-------------+
| Sender Descriptor List |
// ... //
+-------------+-------------+-------------+-------------+
The fields are the same as in a PATH message, defined earlier, [There is a problem here: tearing down path state may
except for the following: implicitly delete reservation state. But a PTEAR message does
not have credentials for the reservation state, only for the
path state. Some argue that a CREDENTIAL may not be needed in
teardown messages, on the assumption that false teardown
messages can be injected only with the collusion of routers
along the data path, and in that case, the colluding router can
just as well stop delivering the RESV messages, which will have
the same effect.]
RSVP Fields: 4.2 Sending RSVP Messages
RSVPType RSVP messages are sent hop-by-hop between RSVP-capable routers as
"raw" IP datagrams, protocol number 46. Raw IP datagrams are
similarly intended to be used between an end system and the
first/last hop router; however, it is also possible to encapsulate
RSVP messages as UDP datagrams for end-system communication, as
described in Appendix C. UDP encapsulation will simplify
installation of RSVP on current end systems, particularly when
firewalls are in use.
3 = PERR message Under overload conditions, lost RSVP control messages could cause
the loss of resource reservations. Routers should be configured
to give a preferred class of service to RSVP packets. RSVP should
not use significant bandwidth, but the queueing delay for RSVP
messages needs to be controlled.
Error Code An RSVP PATH or RESV message consists of a small root segment
A one-octet error description. followed by a variable-length list of objects, which may overflow
the capacity of one datagram. IP fragmentation is inadvisable,
since it has bad error characteristics; RSVP-level fragmentation
should be used. That is, a message with a long list of
descriptors will be divided into segments that will fit into
individual datagrams, each carrying the same root fields. Each of
these messages will be processed at the receiving node, with a
cumulative effect on the local state. No explicit reassembly is
needed.
01 = Insufficient memory Since RSVP messages are normally expected to be generated and sent
hop-by-hop, their MTU should be determined by the MTU of each
interface.
02 = Count Wrong [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.
Best approach seems to be to rely on IP fragmentation and
reassembly for this case.]
The SD Count field does not match length of 4.3 Avoiding RSVP Message Loops
message.
Error Index We must ensure that the rules for forwarding RSVP control messages
avoid looping. In steady state, PATH and RESV messages are
forwarded on each hop only once per refresh period. This avoids
directly looping packets, but there is still the possibility of an
" auto-refresh" loop, clocked by the refresh period. The effect
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
when the receivers leave the multicast group and/or the senders
stop sending PATH messages).
Position of Sender Descriptor that caused the error In addition, error and teardown messages are forwarded immediately
within and are therefore subject to direct looping.
Sender Descriptor List. An integer between zero
and SD Count - 1.
Error Value PATH messages are forwarded using routes determined by the
appropriate routing protocol. For routing that is source-
dependent (e.g., some multicast routing algorithms), the RSVP
daemon must route each sender descriptor separately using the
source addresses found in the SENDER_TEMPLATE objects. This
should ensure that there will be no auto-refresh loops of PATH
information, even in a topology with cycles.
(Unused) Since PATH messages don't loop, they create path state defining a
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.
A RERR message has the following form: If the topology has no loops, then auto-refresh can be avoided,
even for wildcard scope, with the following rule:
0 1 2 3 A reservation request received from next hop N must not be
+-------------+-------------+-------------+-------------+ forwarded to N.
| Vers | Type | Flags | RSVP Checksum |
+-------------+-------------+-------------+-------------+
| DestAddress |
+-------------+-------------+-------------+-------------+
| ResvID |
+-------------+-------------+-------------+-------------+
| Error Code | Error Index | Error Value |
+-------------+-------------+-------------+-------------+
| ////////////// (ignored) ////////////////// |
+-------------+-------------+-------------+-------------+
| ////////////// (ignored) ////////////////// |
+-------------+-------------+-------------+-------------+
| RecvAddress |
+-------------+-------------+-------------+-------------+
| Dynamic Reservation Count | FD Count |
+-------------+-------------+-------------+-------------+
| Authentication Field |
// ... //
+-------------+-------------+-------------+-------------+
| Flow Descriptor List |
// ... //
+-------------+-------------+-------------+-------------+
The fields are the same as in a RESV message, defined earlier, This rule is illustrated in Figure 10, which shows a transit
except for the following: 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 reservation requests in the two
directions, without an auto-refresh loop.
RSVP Fields: ________________
a | | c
( R1, S1 ) <----->| Router |<-----> ( R2, S2 )
|________________|
RSVPType Send & Receive on (a) | Send & Receive on (c)
|
WF( *{3B}) <-- (a) | (c) <-- WF( *{3B})
|
WF( *{4B}) --> (a) | (c) --> WF( *{4B})
|
|
Reserve on (a) | Reserve on (c)
__________ | __________
| * {4B} | | | * {3B} |
|__________| | |__________|
|
4 = RERR message Figure 10: Avoiding Auto-Refresh in Non-Looping Topology
Error Code However, further effort is needed to prevent auto-refresh loops
from wildcard-scope reservations in the presence of cycles in the
topology. [TBD!!].
A one-octet error description. We treat routing of RERR messages as a special case. They are
sent with unicast addresses of next hops, but the multicast
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.
DEFINE THESE VALUES IN AN APPENDIX?? [Open question about Figure 10: should it be possible to have
incompatible reservation styles on the two interfaces? For
example, 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.]
01 = Insufficient memory 4.4 Local Repair
02 = Count Wrong Each RSVP daemon periodically sends refreshes to its next/previous
hops. An important optimization would allow the local routing
protocol module to notify the RSVP daemon of route changes for
particular destinations. The RSVP daemon should use this
information to trigger an immediate refresh of state for these
destinations, using the new route. This allows fast adaptation to
routing changes without the overhead of a short refresh period.
The FD Count field does not match length of 4.5 Time Parameters
message.
03 = No path information for this Resv For each element of state, there are two time parameters: the
refresh period R and the time-to-live value T. R specifies the
period between sending successive refreshes of this data. T
controls how long state will be retained after refreshes stop
appearing, and depends upon period between receiving successive
refreshes. Specifically, R <= T, and the "cleanout time" is K *
T. Here K is a small integer; K-1 successive messages may be lost
before state is deleted. Currently K = 3 is suggested.
04 = No Sender information for this Resv Clearly, a smaller T means increased RSVP overhead. If the router
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 is path information, but it does not There are three possible ways for a router to determine R and T.
include the sender specified in any of the
Filterspecs listed in the Resv messager.
05 = Incorrect Dynamic Reservation Count o Default values are configured in the router. Current
defaults are 30 seconds for T and R.
Dynamic Reservation Count is zero or less o A router may adjust the value of T dynamically to keep a
than FD Count. constant total overhead due to refresh traffic; as more
sessions appear, the period would be lengthened. In this
case, R = T could be used.
06 = Filterspec error o R and T can be specified by the end systems. For this
purpose, PATH and RESV messages may contain the optional
TIM_VALUES object. When messages are merged and forwarded to
the next hop, R should be the minimum R that has been
received, and T should be the maximum T that has been
received. Thus, the largest T determines how long state is
retained, and the smallest R determines the responsiveness of
RSVP to route changes. In the first hop, they are expected
to be equal. The RSVP API might allow an application to
override the default value for a particular session.
07 = Flowspec syntax error 4.6 RSVP Interfaces
08 = Flowspec value error RSVP on a router has interfaces to routing and to traffic control
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
exists on the host).
Internal inconsistency of values. 4.6.1 Application/RSVP Interface
[What should be done with Flowspec Feature This section describes a generic interface between an
Not Supported?] application and an RSVP control process. The details of a real
interface may be operating-system dependent; the following can
only suggest the basic functions to be performed. Some of
these calls cause information to be returned asynchronously.
09 = Resources unavailable o Register
[Sub-reasons? Depend upon traffic control Call: REGISTER( DestAddress , DestPort
and admission control algorithms?]
Error Index [ , SESSION_object ] , SND_flag , RCV_flag
Position of Flow Descriptor that caused the error [ , Source_Address ] [ , Source_Port ]
within
Flow Descriptor List. An integer between zero
and FD Count - 1.
Error Value [ , Sender_Template ] [ , Sender_Tspec ]
Specific cause of the error described by the Error [ , Data_TTL ] [ , UserCredential ]
Code.
DEFINE THESE VALUES IN AN APPENDIX?? [ , Upcall_Proc_addr ] ) -> Session-id
An error message may be duplicated and forwarded unchanged.
Since PATH and RESV messages may be merged, an error condition
must be disseminated to all RSVP client applications whose
requests may have contributed to the error situation.
Therefore, RSVP error messages must be propagated and perhaps
duplicated hop-by-hop. For this purpose, an error message must
include all the information used to route the original message
that caused the error: the Sender Descriptor List, Flags,
RecvAddress, and Flow Descriptor List fields, as appropriate.
In particular, a RERR message carries the same style flags as
the RESV message that caused the error.
To ease implementation, the error message formats are chosen to This call initiates RSVP processing for a session, defined
match the formats of the messages whose processing caused the by DestAddress together with the TCP/UDP port number
error. In particular, a PATH or RESV message that encounters DestPort. If successful, the REGISTER call returns
an error can be simply converted to the corresponding error immediately with a local session identifier Session-id,
message by overwriting the Type and the Refresh Period fields. which may be used in subsequent calls.
A PERR message is forwarded to all previous hops for all The SESSION_object parameter is included as an escape
senders listed in the Sender Descriptor List. The routing of a mechanism to support some more general definition of the
RERR message is more complex. session ("generalized destination port"), should that be
necessary in the future. Normally SESSION_object will be
omitted; if it is supplied, it should be an
appropriately-formatted representation of a SESSION
object.
o An error in a filterspec should be detected at the first SND_flag should be set true if the host will send data,
RSVP hop from the receiver application, normally within and RCV_flag should be set true if the host will receive
the receiver host. However, an error caused by a data. Setting neither true is an error. The optional
flowspec, normally an admission control failure, may be parameters Source_Address, Source_Port, Sender_Template,
detected somewhere along the path(s) to the sender(s). Sender_Tspec, and Data_TTL are all concerned with a data
source, and they will be ignored unless SND_flag is true.
o The router that creates a RERR message as the result of If SND_FLAG is true, a successful REGISTER call will cause
processing a RESV message should send the RERR message out RSVP to begin sending PATH messages for this session using
the interface through which the RESV arrived. these parameters, which are interpreted as follows:
o In succeeding hops, the routing of a RERR message depends - Source_Address
upon its style. In general, a RERR message is sent on a
pruned version of the multicast distribution tree for the
session; those branches that do not have reservations for
any of the specified senders are pruned off.
A DF-style or WF-style RERR message is forwarded on all This is the address of the interface from which the
outgoing interfaces for which there is already a data will be sent. If it is omitted, a default
reservation of the corresponding style. interface will be used.
A FF-style RERR message is forwarded on all outgoing - Source_Port
interfaces for which there is already a FF-style
reservation for the sender (filterspec) corresponding to
the error.
At the end host, RSVP delivers a copy of every relevant error This is the UDP/TCP port from which the data will be
message to its local application clients. It examines the set sent. If it is omitted or zero, the port is "wild"
of RSVP requests that local clients have made through the API, and can match any port in a FILTERSPEC.
and notifies every client that contributed to the error
message. A match is required between the session, filters
(senders), and reservation styles of the error message and the
corresponding state in the latest API requests. A particular
notification should include only the information (e.g.,
filters) relevant to that application.
3.1.4 Teardown Messages - Sender_Template
There are two types of RSVP Teardown message, PTEAR and RTEAR. This parameter is included as an escape mechanism to
A PTEAR message tears down path state and travels towards all support a more general definition of the sender
receivers downstream from its point of initiation. A RTEAR ("generalized source port"). Normally this parameter
message tears down reservation state and travels towards all may be omitted; if it is supplied, it should be an
senders upstream from its point of initiation. appropriately formatted representation of a
SENDER_TEMPLATE object.
A PTEAR message has the same format as a PATH message, except - Sender_Tspec
that in a PTEAR message:
o Type field = 5 This parameter is a Tspec describing the traffic flow
to be sent. It may be included to prevent over-
reservation on the initial hops.
o Refresh Period and State TTL Time fields are ignored. - Data_TTL
A RTEAR message has the same format as a RESV message, except This is the (non-default) IP Time-To-Live parameter
that in a RTEAR message: that is being supplied on the data packets. It is
needed to ensure that Path messages do not have a
scope larger than multicast data packets.
o Type field = 6 Finally, Upcall_Proc_addr is the address of an upcall
procedure to receive asynchronous error or event
notification; see below.
o Refresh Period and State TTL Time fields are ignored. o Reserve
Any Flowspec components of Flow Descriptors in a RTEAR or PTEAR Call: RESERVE( session-id, style, style-dependent-parms )
message are ignored. A receiver uses this call to make a resource reservation
for the session registered as `session-id'. The style
parameter indicates the reservation style. The rest of
the parameters depend upon the style, but generally these
will include appropriate flowspecs and filter specs.
Teardown messages are processed in the following way. The first RESERVE call will initiate the periodic
transmission of RESV messages. A later RESERVE call may
be given to modify the parameters of the earlier call (but
note that changing the reservations may result in
admission control failure, depending upon the style).
o PTEAR The RESERVE call returns immediately. Following a RESERVE
call, an asynchronous ERROR/EVENT upcall may occur at any
time.
Processing a PTEAR message is straightforward. For each o Release
sender S in the message, the node removes path state for S
and also deletes all related reservations. Finally, the
node forwards the original PTEAR message to all outgoing
interfaces through which data packets from some S in the
packet would be routed. That is, PTEAR forwarding rules
are the same as those for PATH messages.
o RTEAR Call: RELEASE( session-id )
Processing an RTEAR message is more complex. Suppose a
RTEAR message arrives through outgoing interface OI from
next hop NH. For each sender S listed in the RTEAR
message, the node checks the reservation, if any, for S on
OI. If there is a reservation and if this reservation is
shared among more than one next hop, then the only action
is to remove NH from the list of next hops sharing this
reservation. If there is only a single next hop, then the
reservation is deleted. Finally, the node forwards the
original RTEAR message to all incoming interfaces for
senders listed in the message. That is, RTEAR forwarding
rules are the same as those for RESV messages.
3.2 Avoiding Message Loops This call will terminate RSVP state for the session
specified by session-id. It may send appropriate teardown
messages and will cease sending refreshes for this
session-id.
RSVP routes its control messages, and every routing procedure must o Error/Event Upcalls
avoid looping packets. The merging of RSVP messages delays
forwarding at each node for up to one refresh period. This may Call: <Upcall_Proc> (session-id, Info_type, List_count
avoid high-speed loop, but there can still be "slow" loops,
clocked by the refresh period; the effect of such slow loops is to [ ,Error_code ,Error_value ,LUB-flag ]
keep state active forever, even if the end nodes have ceased
refreshing it. RSVP uses the following rules to prevent looping [ ,Filter_spec_list ] [ ,Flowspec_list ]
[ ,Advert_list ] )
Here "Upcall_Proc" represents the upcall procedure whose
address was supplied in the REGISTER call.
This upcall may occur asynchronously at any time after a
REGISTER call and before a RELEASE call, to indicate an
error or an event. Currently there are three upcall
types, distinguished by the Info_type parameter:
1. Info_type = Path Event
A Path Event upcall indicates the receipt of a PATH
message, indicating to the application that there is
at least one active sender. This upcall provides
synchronizing information to the 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' 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
ignored in a Path Event upcall.
2. Info_type = Path Error
An Path Error event indicates an error in processing
a sender descriptor originated by this sender. The
Error_code parameter will define the error, and
Error_value may supply some additional (perhaps
system-specific) data about the error. `List_count'
will be 1, and Filter_spec_list and Flowspec_list
will contain the Sender_Template and the Sender_Tspec
supplied in the REGISTER call; Advert_list will
contain one NULL object.
3. Info_type = Resv Error
An Resv Error event indicates an error in processing
a RESV message to which this application contributed.
The Error_code parameter will define the error, and
Error_value may supply some additional (perhaps
system-specific) data on the error.
`List_count' will be 1, and Filter_spec_list and
Flowspec_list will contain one FILTER_SPEC and one
FLOWSPEC object. These objects are taken from the
RESV message that caused the error (unless the LUB-
flag is on, in which case FLOWSPEC may differ).
Although RSVP messages indicating path events or errors
may be received periodically, the API should make the
corresponding asynchronous upcall to the application only
on the first occurrence, or when the information to be
reported changes.
4.6.2 RSVP/Traffic Control Interface
In each router and host, enhanced QoS is achieved by a group of
inter-related traffic control functions: a packet classifier,
an admission control module, and a packet scheduler. This
section describes a generic RSVP interface to traffic control.
1. Make a Reservation
Call: Rhandle = TC_AddFlowspec( Flowspec, Police_Flag
[ , Sender_Tspec]
[ , SD_rank , SD_end_flag ] )
This call passes a Flowspec defining a desired QoS to
admission control. It may also pass Sender_Tspec, the
maximum traffic characteristics computed over the
SENDER_TSPECs of senders that will contribute data packets
to this reservation. Police_Flag is a Boolean parameter
that indicates whether traffic policing should be applied
at this point.
The SD_rank and SD_end_flag fields are used for a member
of a session group. SD_rank is the rank value from the
SESSION_GROUP object. The call is made with each of the
sessions in the group, and SD_end_flag is set true for the
last one.
This call returns an error code if Flowspec is malformed
or if the requested resources are unavailable. Otherwise,
it establishes a new reservation channel corresponding to
Rhandle. It returns the opaque number Rhandle for
subsequent references to this reservation.
2. Add Filter
Call: TC_AddFilter( Rhandle, Session, Filterspec )
This call is used to define a filter corresponding to the
given handle, following a successful TC_AddFlowspec call.
3. Modify or Delete Filter
Call: TC_ModFilter( Rhandle, Session,
[ new_Filterspec] )
This call can modify an existing filter or replace an
existing filter with no filter (i.e., delete the filter).
4. Modify or Delete Flowspec
Call: TC_ModFlowspec( Rhandle
[, new_Flowspec [ ,Sender_Tspec]] )
This call can modify an existing reservation or delete the
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_Advertise( interface, Adspec
[ ,Sender_TSpec ] ) -> New_Adspec
This call is used for OPWA to compute the outgoing
advertisement New_Adspec for a specified interface.
6. Initialize Traffic Control
Call: TC_Initialize(interface )
This call is used when RSVP initializes its state, to
clear out all existing classifier and/or packet scheduler
state for a specified interface.
4.6.3 RSVP/Routing Interface
An RSVP implementation needs the following support from the
packet forwarding and routing mechanism of the node.
o Promiscuous receive mode for RSVP messages
Any datagram received for IP protocol 46 is to be diverted
to the RSVP program for processing, without being
forwarded. The identity of the interface on which it is
received should also be available to the RSVP daemon.
o Route discovery
RSVP must be able to discover the route(s) that the
routing algorithm would have used for forwarding a
specific datagram.
GetUcastRoute( DestAddress ) -> OutInterface
GetMcastRoute( SrcAddress, DestAddress )
-> OutInterface_list
o Route Change Notification
Routing may provide an asynchronous notification to RSVP
that a specified route has changed.
New_Ucast_Route( DestAddress ) -> new_OutInterface
New_Mcast_Route( SrcAddress, DestAddress )
-> new_OutInterface_list
o Outgoing Link Specification
RSVP must be able to force a (multicast) datagram to be
sent on a specific outgoing virtual link, bypassing the
normal routing mechanism. A virtual link may be a real
outgoing link or a multicast tunnel. Outgoing link
specification is necessary because RSVP may send different
versions of outgoing PATH messages on different
interfaces, for the same source and destination addresses,
and to avoid loops.
o Discover Interface List
RSVP must be able to learn what real and virtual
interfaces exist.
5. Message Processing Rules
This generic description of RSVP operation assumes the following data
structures. An actual implementation may use additional or different
structures to optimize processing.
o PSB -- Path State Block
Each PSB holds path state for a particular (session, sender)
pair, defined by SESSION and SENDER_TEMPLATE objects,
respectively. PSB contents include a PHOP object and possibly
SENDER_TSPEC, CREDENTIAL, and/or ADVERT objects from PATH
messages. messages.
L1: When an RSVP message is received through a particular o RSB -- Reservation State Block
incoming interface F, the message must not be forwarded
out F as an outgoing interface. This implies that RSVP
must keep track of the interface through which each
message is received, to avoid forwarding it out that
interface. Note that, although RSVP distinguishes
incoming from outgoing interfaces, in many cases the
same physical interface will play both roles.
L2: Upon receipt of a PATH message in particular, a route RSB's are used to hold reservation state. Each RSB holds
must be computed for each of its sender Flow reservation state for the 4-tuple: (session, next hop, style,
Descriptors. These routes, obtained from the filterspec), defined in SESSION, NHOP (i.e., RSVP_HOP), STYLE,
uni/multicast routing table, generally depend upon the and FILTER_SPEC objects, respectively. We assume that RSB
(sender host address, DestAddress) pairs. Each route contents include the outgoing interface OI that is implied by
consists of a list of outgoing interfaces; these lists NHOP. RSB contents also include a FLOWSPEC object and may
(with the incoming interfaces deleted by rule L1) are include a CERTIFICATE object.
used to create merged PATH messages to be forwarded
through the outgoing interfaces.
Assuming that multicast routing is free of loops, PATH messages MESSAGE ARRIVES
cannot loop even in a topology with cycles.
Since PATH messages don't loop, they create path state defining a Verify version number, checksum, and length fields of common header,
loop-free path to each sender. Similarly, RESV messages directed and discard message if it fails.
to particular senders cannot loop. However, rules L1 and L2
cannot protect against looping RESV messages that are directed
towards all senders (WF or DF styles). The following three rules
are needed for this purpose.
L3: Each RESV message carries a receiver address in the Further processing depends upon message type.
RecvAddress field. When the choice of address to place
in a merged RESV message is otherwise arbitrary, RSVP
must use the IP address that is numerically largest.
L4: When a RESV message is received, the Reverse Path PATH MESSAGE ARRIVES
Forwarding rule is applied to the receiver address in
the message; that is, the message must be discarded
unless it arrives on the interface that is the preferred
route to the receiver.
L5: A RESV message whose RecvAddress matches one of the IP Start with the Refresh_Needed flag off.
addresses of the local node must be discarded without
processing.
Figure 10 illustrates the effect of the rule L1 applied to RESV Each sender descriptor object sequence in the message defines a
messages. It shows a transit router, with one sender and one sender. Process each sender as follows.
receiver on each side; interfaces a and c therefore are both
outgoing interfaces and physical previous hops. Both receivers
are making a Wildcard-Filter style reservation, in which the RESV
message is to be forwarded to all previous hops for senders in the
group, with the exception of the interface through which it
arrived.
________________ 1. If there is a CREDENTIAL object, verify it; if it is
a | | c unacceptable, build and send a PERR message, drop the PATH
( R1, S1 ) <----->| Router |<-----> ( R2, S2 ) message, and return.
|________________|
Send & Receive on (a) | Send & Receive on (c) 2. If there is no path state block (PSB) for the (session,
| sender) pair then:
WF( *{3B}) <-- (a) | (c) <-- WF( *{3B})
|
WF( *{4B}) --> (a) | (c) --> WF( *{4B})
|
|
Reserve on (a) | Reserve on (c)
__________ | __________
| * {4B} | | | * {3B} |
|__________| | |__________|
|
Figure 10: Example: Rule (1) for Preventing Loops. o Create a new PSB.
The loop-suppression rules for RESV messages also prevent looping o Set a cleanup timer for the PSB. If this is the first
of RTEAR messages. Note that RTEAR messages are otherwise subject PSB for the session, set a refresh timer for the
to fast loops, since they are not delayed by a refresh timeout session.
period.
PERR messages are routed upstream by the same rules used for FF o Copy PHOP into the PSB. Copy into the PSB any of the
and DF RESV messages (there is no equivalent of wildcard-filter following objects that are present in the message:
for routing a PERR message). Similarly, RERR messages are routed CREDENTIAL, SENDER_TSPEC, and/or ADVERT. Copy the
by the rules for PATH messages. For reasons explained above, no EntryPolice flag from the common header into the PSB.
special loop-suppression rules are required in either case.
3.3 Soft State Management o Call the appropriate route discovery routine, using
DestAddress from SESSION and (for multicast routing)
SrcAddress from SENDER_TEMPLATE. Store the resulting
routing bit mask ROUTE_MASK in the PSB.
The RSVP state associated with a session in a particular node is 3. Otherwise (there is a matching PSB):
divided into atomic elements that are created, refreshed, and
timed out independently. The atomicity is determined by 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
independently.
Management of RSVP state is complex because there is not generally o If CREDENTIAL differs between message and PSB, verify
a one-to-one correspondence between state carried in RSVP control new CREDENTIAL. If it is acceptable, copy it into
messages and the resulting state in nodes. Due to merging, a PSB. Otherwise, build and send a PERR message for
single message contain state referring to multiple stored "Bad Credential", drop the PATH message, and return.
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.
3.3.1 Time Parameters o Restart cleanup timer.
For each element, there are two time parameters controlling the o Update the PSB with values from the message, as
maintenance of soft state: the refresh period R and the TTL follows. Copy the ADVERT object, if any, into the
(time-to-live) value T. R specifies the period between PSB. Copy the EntryPolice flag into the PSB.
successive refresh messages over the same link. T controls how
long state will be retained after refreshes stop appearing.
PATH and RESV messages specify both R and T. When messages are If the values of PHOP or SEND_TSPEC differ between the
merged and forwarded to the next hop, R should be the minimum R message and the PSB, copy the new values into the PSB
that has been received, and T should be the maximum T that has and turn on the Refresh_Needed flag. If SEND_TSPEC
been received. Thus, the largest T determines how long state has changed, reservations matching S may also change;
is retained, and the smallest R determines the responsiveness this may be deferred until a RESV refresh arrives.
of RSVP to route changes. In the first hop, they are expected
to be equal. The RSVP API should set a configurable default
value, which can be overridden by an application for a
particular session.
To avoid gaps in user service due to lost RSVP messages, RSVP o Call the appropriate route discovery routine and
should be forgiving about missing refresh messages. A node compare the route mask with the ROUTE_MASK value
should not discard an RSVP state element until K * Tmax has already in the PSB; if a new bit (interface) has been
elapsed without a refresh message, where Tmax is the maximum of added, turn on the Refresh_Needed flag. Store new
the T values it has received. K is some small integer; K-1 ROUTE_MASK in the PSB.
successive messages may be lost before state is deleted.
Currently K = 3 is suggested.
Let X indicate a particular message type (either "Path" or 4. If the Refresh_Needed flag is now set, execute the PATH
"Resv") and a particular session. Then each X message from REFRESH event sequence (below).
node a to node b carries refresh period Rab and TTL time Tab.
o As X messages arrive at node b, the node computes and PATH TEAR MESSAGE ARRIVES
saves both the min over the Rab values (min(Rab)) and the
max over the Tab values (max(Tab)) from these messages.
o The node uses K * max(Tab) as its cleanup timeout o If there is no path state for this destination, drop the
interval. message and return.
o The node uses min(Rab's) as the refresh period. o Forward a copy of the PTEAR message using the same rules as
for a PATH message (see PATH REFRESH).
o Each refresh message forwarded by node b to node c has Tbc o Each sender descriptor in the PTEAR message contains a
= max(Tab) and Rbc = min(Rab) SENDER_TEMPLATE object defines a sender S; process it as
follows.
o A node may impose an upper bound Tmax and a lower bound 1. Locate the PSB for the pair: (session, S). If none
Rmin, set by configuration information, and enforce: Rmin exists, continue with next sender descriptor.
<= R <= T <= Tmax.
The receiver should be conservative about reacting to certain 2. Examine the RSB's for this session and delete any
error messages. For example, during a route change a receiver reservation state associated with sender S, depending
may get back "No Path" error messages until Path messages have upon the reservation style. For example:
propagated along the new route.
3.3.2 Teardown Delete a WF reservation for which S is the only
sender.
Teardown messages, like other RSVP messages, are sent as Delete an FF reservation for S.
datagrams and may be lost (although a QoS is used that should
minimize the chances of congestive loss of RSVP messages). To
increase the reliability of teardown, Q copies of any given
teardown message can be sent. Note that if the iteration count
Q on initiating teardown messages is > 1, then the state cannot
actually be deleted until Q teardowns have been sent. The
state would be placed in a "moribund" status meanwhile.
The appropriate value of Q is an engineering issue. Q = 1 3. Delete the PSB.
would be the simplest and may be adequate, since unrefreshed
state will time out anyway; teardown is an optimization. Note
that if one or more teardown hops are lost, the router that
failed to receive a teardown message will time out its state
and initiate a new teardown message beyond the loss point.
Assuming that RSVP message loss probability is small (but non-
zero), the longest time to delete state will seldom exceed one
state timeout time K*Tab.
Here is an example. Here G1, G2, G3, and G4 are routers PATH ERROR MESSAGE ARRIVES
between a sender S and a receiver R. S initiates a PTEAR
message (denoted by "PT"), but this message is lost between
routers G2 and G3. Since G2 has deleted its state for S, G2
will cease refreshing G3 (though G3 is still refreshing G4,
etc.)
PT PT PT o If there are no existing PSB's for SESSION then drop the
S ---> G1 ---> G2 -->x G3 G4 R PERR message and return.
After a time K*Tab, G3's state will time out, and G3 will o Look up the PSB for (session, sender); sender is defined by
initiate a teardown for S path state: SENDER_TEMPLATE. If no PSB is found, drop PERR message and
return.
PT PT o If PHOP in PSB is local API, deliver error to application
G3 ----> G4 ----> R via an upcall:
If some hop of this chain is lost, there will again be state Call: <Upcall_Proc>( session-id, Path Error, 1,
timeout to continue the teardown. This process should Error_code, Error_value, 0,
terminate in a few timeout periods. SENDER_TEMPLATE, NULL, NULL)
3.3.3 Local Repair Note that CREDENTIAL, SENDER_TSPEC, and ADVERT objects in
the message is ignored.
To accommodate merging, RSVP uses hop-by-hop refreshing of Otherwise (PHOP is not local API), forward a copy of the
state, where each node sends refreshes to its next/previous PERR message to the PHOP node.
hops periodically. However, as an optimization, local events
could be used to trigger the RSVP module to send such refreshes
to any time. For example, suppose that the local routing
protocol module were able to notify the RSVP module that a
route has changed for particular destinations. The RSVP module
could use this information to trigger an immediate refresh of
state for these destinations along the new route. This would
allow fast adaptation to routing changes without the overhead
of a short refresh period.
3.4 Sending RSVP Messages RESV MESSAGE ARRIVES
A RESV message arrives through outgoing interface OI.
Under overload conditions, lost RSVP control messages could cause o Check the SESSION object.
the loss of resource reservations. It recommended that routers be
configured to give a preferred class of service to RSVP packets.
RSVP should not use significant bandwidth, but the delay of RSVP
packets needs to be controlled.
An RSVP PATH or RESV message consists of a small root segment (24 If there are no existing PSB's for SESSION then build and
or 28 bytes) followed by a list of descriptors. The descriptors send a RERR message (as described later) specifying "No
are bulky and there could be a large number of them, resulting in Path Information", drop the RESV message, and return.
potentially very large messages. IP fragmentation is inadvisable, However, do not send the RERR message if the style has
since it has bad error characteristics. Instead, RSVP-level wildcard reservation scope and this is not the receiver
fragmentation should be used. That is, a message with a long list host itself.
of descriptors will be divided into segments that will fit into
individual datagrams, each carrying the same root fields. Each of
these messages will be processed at the receiving node, with a
cumulative effect on the local state. No explicit reassembly is
needed.
The largest RSVP message is 556 bytes. o Check the STYLE object.
3.5 Automatic Tunneling If style in the message conflicts with the style of any
reservation for this session in place on any interface,
reject the RESV message by building and sending a RERR
message specifying "Bad Style", drop the RESV message, and
return.
It is impractical to deploy RSVP (or any protocol) at the same o Check the CREDENTIAL object.
moment throughout the Internet, and RSVP may never be deployed
everywhere. RSVP must therefore provide correct protocol
operation even when two RSVP-capable routers are joined by an
arbitrary "cloud" of non-RSVP routers.
RSVP will automatically tunnel through such a non-RSVP cloud. Verify the CREDENTIAL field (if any) to check permission to
Both RSVP and non-RSVP routers forward PATH messages towards the create a reservation. [This check may also involve the
destination address using their local uni-/multicast routing CREDENTIAL fields from the PSB's in the scope of this
table. Therefore, the routing of Path messages will be reservation; in that case, it would better fit below in
unaffected by non-RSVP routers in the path. When a PATH message processing the individual flow descriptors.]
traverses a non-RSVP cloud, the copies that emerge will carry as a
Previous Hop address the IP address of the last RSVP-capable
router before entering the cloud. This will cause effectively
construct a tunnel through the cloud for RESV messages, which will
be forwarded directly to the next RSVP-capable router on the
path(s) back towards the source.
This automatic tunneling capability of RSVP has a cost: a PATH o Check for path state
message must carry the session DestAddress as its IP destination
address; it cannot be addressed hop-by-hop. As a result, each
RSVP router must have a small change in its multicast forwarding
path to recognize RSVP messages (by the IP protocol number) and
intercept them for local processing. See Section 3.6.5 below.
(There is a potential defect in tunneling. Merged PATH messages If there are no PSB's matching the scope of this
can carry information for a list of senders, and since multicast reservation, build and send a RERR message specifying "No
routing depends in general upon the sender, it is not possible to Sender Information", drop the RESV message, and return.
ensure that all the non-RSVP routers along the tunnel will be able
to route the packet properly. The effect turns out to be that
tunnels may distribute path information to RSVP routers where it
should not go, which may in turn lead to unused reservations at
these routers. This is hoped to be an acceptable defect.)
Of course, if an intermediate cloud does not support RSVP, it is o Make reservations
unable to perform resource reservation. In this case, firm end-
to-end service guarantees cannot be made. However, if there is
sufficient excess capacity through such a cloud, acceptable and
useful realtime service may still be possible.
3.6 Interfaces Process the style-specific tail sequence.
3.6.1 Reservation Parameters For FF style, execute the following steps for each b flow
descriptor, i.e., each (FLOWSPEC, FILTERSPEC) pair. For WF
style execute the following once, using some internal
placeholder "WILD_FILTER" for FILTERSPEC to indicate
wildcard scope.
All variable-length RSVP parameters use the same general 1. Find or create a reservation state block (RSB) for the
format. They begin with a length octet followed by a type 4-tuple: (SESSION, NHOP, style, FILTERSPEC).
octet, and occupy an integral number of fullwords. The length
octet specifies the total length of the parameter in fullwords
or zero to indicate no parameter. An RSVP implementation can
store and pass such parameters as opaque objects.
o Flowspec Format 2. Start or restart the cleanout timer on the RSB.
Flowspec type 1 is specific to the CSZ packet scheduler 3. Start a refresh timer for this session if none was
[CSZ92]. It has the following format: started.
4. If the RSB existed and if FLOWSPEC and the
SENDER_TSPEC objects are unchanged, drop the RESV
message and return.
5. Compute Sender_Tspec as the maximum over the
SENDER_TSPEC objects of the PSB's within the scope of
the reservation.
6. Set Police_flag on if any PSB's in the scope have the
EntryPolice flag on, or if the style is WF and there
is more than one PSB in the scope, otherwise off.
7. Computer K_Flowspec, the effective kernel flowspec, as
the maximum of the FLOWSPEC values in all RSB's for
the same (SESSION, OI, FILTERSPEC) triple. Similarly,
the kernel filter spec K_filter is either the
FILTER_SPEC object under consideration (unitary
scope), or it is WILD_FILTER (wildcard scope).
If there was no previous kernel reservation in place
for (SESSION, OI, FILTERSPEC), call the kernel
interface module:
TC_AddFlowspec( Sender_Tspec, K_flowspec, Police_Flag )
If this call fails, build and send a RERR message
specifying "Admission control failed", drop the RESV
message, and return. Otherwise, record the kernel
handle K_handle returned by the call in the RSB(s).
Then call:
TC_AddFilter( K_handle, K_Filter)
to set the filter, drop the RESV message and return.
/item However, if there was a previous kernel
reservation with handle K_handle, call the kernel
interface module:
TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec)
If this call fails, build and send a RERR message
specifying "Admission control failed". In any case,
drop the RESV message and return.
If processing a RESV message finds an error, a RERR message is
created containing flow descriptor and an ERRORS object. The
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.
created
RESV TEAR MESSAGE ARRIVES
A RTEAR message arrives on outgoing interface OI.
o If there are no existing PSB's for SESSION then drop the
RTEAR message and return.
o Process the style-specific tail sequence to tear down
reservations.
For FF style, execute the following steps for each b flow
descriptor, i.e., each (FLOWSPEC, FILTERSPEC) pair. For WF
style execute the following once, using some internal
placeholder "WILD_FILTER" for FILTERSPEC to indicate
wildcard scope.
1. Find matching RSB(s) for the 4-tuple: (SESSION, NHOP,
style, FILTERSPEC). If no RSB is found, continue with
next flow descriptor, if any.
2. Delete the RSB(s).
3. If there are no more RSBs for the same (SESSION, OI,
FILTERSPEC/) triple, call the kernel interface module:
TC_ModFlowspec( K_handle )
to delete the reservation. Then build and forward a
new RERR message.
- WF style: send a copy to each PHOP among all
matching senders.
- FF style: Send to PHOP of matching PSB.
4. Otherwise (there are other RSB's for the same
reservation), recompute K_Flowspec and call the kernel
interface module:
TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec)
to update the reservation, and then execute the RESV
REFRESH sequence (below). If this kernel call fails,
return; the prior reservation will remain in place.
RESV ERROR MESSAGE ARRIVES
o Call the appropriate route discovery routine, using
DestAddress from SESSION and (for multicast routing)
SrcAddress from the Error Node field in the ERRORS object.
Let the resulting routing bit mask be M.
o Determine the set of RSBs matching the triple: (SESSION,
style, FILTERSPEC). If no RSB is found, drop RERR message
and return.
Recompute the maximum over the FLOWSPEC objects of this set
of RSB's. If the LUB was used in this computation, turn on
the LUB-flag in the received RESV message.
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
none remain, drop RERR message and return.
For each PSB in the resulting set, do the following step.
o If NHOP in PSB is local API, deliver error to application
via an upcall:
Call: <Upcall_Proc>( session-id, Resv Error, 1,
Error_code, Error_value, LUB-flag,
FILTER_SPEC, FLOWSPEC, NULL)
Here LUB-flag is taken from the received packet, as
possibly modified above.
Otherwise (NHOP is not local API), forward a copy of the
RERR message to the PHOP node.
PATH REFRESH
This sequence may be entered by either the expiration of the path
refresh timer for a particular session, or immediately as the result
of processing a PATH message turning on the Refresh_Needed flag.
For each virtual outgoing interface ("vif") V, build a PATH message
and send it to V. To build the message, consider each PSB whose
ROUTE_MASK includes V, and do the following:
o Pass the ADVERT and SENDER_TSPEC objects present in the PSB to
the kernel call TC_Advertise, and get back a modified ADVERT
object. Pack this modified object into the PATH message being
built.
o Create a sender descriptor sequence containing the
SENDER_TEMPLATE, CREDENTIAL, and SENDER_TSPEC objects, if
present in the PSB. Pack the sender descriptor into the PATH
message being built.
o If the PSB has the EntryPolice flag on and if interface V is not
capable of policing, turn the EntryPolice flag on in the PATH
message being built.
o If the maximum size of the PATH message is reached, send the
packet out interface V and start packing a new one.
RESV REFRESH
This sequence may be entered by either the expiration of the
reservation refresh timer for a particular session, or immediately as
the result of processing a RESV message.
Each PSB for this session is considered in turn, to compute a style-
dependent tail sequence. These sequences for a given PHOP are then
packed into the same message(s) and sent to that PHOP. The logic is
somewhat different depending upon whether the scope of the
reservations is wildcard or not (they may not be mixed).
For each PSB that does not correspond to the API, do the following.
o Compute (FLOWSPEC, FILTER_SPEC) Pair
Select each RSB in whose reservation scope the PSB falls, and
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
ROUTE_MASK of the PSB.
In this case, FILTER_SPEC is the standard WILD_FILTER.
2. FF: Select every RSB whose FILTER_SPEC matches
SENDER_TEMPLATE in the RSB. This matching process should
consider wildcards.
In this case, FILTER_SPEC is taken from any of the matching
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
consistent across RSB's for given session). [??Again, need
merging rules]]
o Build RESV packets
Append this (FLOWSPEC, FILTER_SPEC pair) to the RESV message
being built for destination PHOP (from the PSB). When the
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
6. Object Type 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.
6.1 SESSION Class
Currently, SESSION objects contain the pair: (DestAddress,
DestPort), where DestAddress is the data destination address and
DestPort is the UDP/TCP destination port. Other SESSION C-Types
could be defined in the future to support other demultiplexing
conventions in the transport-layer or application layer.
o IPv4/UDP SESSION object: Class = 1, C-Type = 1
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| //////////// | DestPort |
+-------------+-------------+-------------+-------------+
o IP6/UDP SESSION object: Class = 1, C-Type = 129
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| //////////// | DestPort |
+-------------+-------------+-------------+-------------+
6.2 SESSION_GROUP Class
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 = 129:
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 Reference DestAddress +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Session-Group ID | Count | Rank |
+-------------+-------------+-------------+-------------+
6.3 RSVP_HOP Class
o IPv4 RSVP_HOP object: Class = 3, C-Type = 1
+-------------+-------------+-------------+-------------+
| IPv4 Next/Previous Hop Address |
+-------------+-------------+-------------+-------------+
o IP6 RSVP_HOP object: Class = 3, C-Type = 129
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 Next/Previous Hop Address +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
This object provides the IP address of the interface through which
the last RSVP-knowledgeable hop forwarded this message.
6.4 STYLE Class
o STYLE-WF object: Class = 4, C-Type = 1
+-------------+-------------+-------------+-------------+
| Style=1 | //////// | //////// | ///////// |
+-------------+-------------+-------------+-------------+
o STYLE-FF object: Class = 4, C-Type = 2
+-------------+-------------+-------------+-------------+
| Style=2 | //////// | //////// | FD Count |
+-------------+-------------+-------------+-------------+
FD Count
The count of elements in the variable-length object list
that follows. See the RESV message format definition
earlier.
6.5 Flowspec Class
o CSZ FLOWSPEC object: Class = 5, C-Type = 1
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| FlowSLen=6|FlowSType=1| VFoffset | | QoS Service Code |
+-----------+-----------+-----------+-----------+
| QoS Type (Guaranteed, Predictive, ...) |
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| Max end-to-end delay (ms) | | b: Token Bucket Depth (bits) |
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| Average data rate (bits/ms) | | r: Average data rate (bits/sec) |
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| Token Bucket Depth (bits) | | d: Max end-to-end delay (ms) |
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| Global Share Handle | | (For Future Use) |
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
Flowspec format 2 is defined in RFC-1363 [Partridge92]. QoS Service Code
o Filterspec Format Integer value defining what service is being requested.
The values currently defined for this code are:
For compactness and simplicity of processing, this version 1 = Guaranteed Service
of the RSVP specification defines an RSVP Filterspec to be
composed of an explicit IP address plus an optional
variable-length mask-and-value pair VF, in the following
format:
+-----------+-----------+-----------+-----------+ The Tspec is (b, r), while the Rspec is (r). (d)
| FiltSLen |FiltSType=1| VFoffset | is ignored.
+-----------+-----------+-----------+-----------+
| Sender IP Address |
+-----------+-----------+-----------+-----------+ ---
| V: VF Value Part | Nf
/ / octets
/ /
+-----------+-----------+-----------+-----------+ ---
| M: VF Mask Part | Nf
/ / octets
/ /
+-----------+-----------+-----------+-----------+ ---
The value M and the mask V each have length: 2 = Bounded-Delay Predictive Service
Nf = (4*FiltSLen - 8)/2 octets. The Tspec is (b, r), while the Rspec is (d).
M and V define a filter that uses a mask-and-match 6.6 FILTER_SPEC Class
algorithm applied to the packet at VFoffset octets from
the beginning of the IP header. The minimum length of
this format of sender template is 7 octets (FiltSLen = 2).
A wildcard Filterspec, which will match any sender host, o IPv4/UDP FILTER_SPEC object: Class = 6, C-Type = 1
has zero for the Sender IP Address [If VM part zero also,
could shorten to FiltSLen = 2].
To speed RSVP processing, a filterspec that appears in an +-------------+-------------+-------------+-------------+
RSVP message use the following "canonical form". | IPv4 SrcAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Protocol Id | ////// | SrcPort |
+-------------+-------------+-------------+-------------+
o o IP6/UDP FILTER_SPEC object: Class = 6, C-Type = 129
The high-order octet of the mask M must be non-zero
(this can always be achieved by adjusting VFoffset).
o The (V,M) part must not include either the sender or +-------------+-------------+-------------+-------------+
receiver address of the IP header; these are carried | |
explicitly. + +
ISSUE: | |
+ IP6 SrcAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | ////// | SrcPort |
+-------------+-------------+-------------+-------------+
There are many possible filter rules that cannot be SrcAddress is an IP address for a host, and SrcPort is a UDP/TCP
expressed using a simple mask and value pair. A source port, defining a sender.
compact and general filter encoding is for further
study.
o Authenticator Format 6.7 SENDER_TEMPLATE Class
The following simple form of authenticator is defined: o IPv4/UDP SENDER_TEMPLATE object: Class = 7, C-Type = 1
Definition same as IPv4/UDP FILTER_SPEC object.
o IP6/UDP SENDER_TEMPLATE object: Class = 7, C-Type = 129
Definition same as IP6/UDP FILTER_SPEC object.
6.8 SENDER_TSPEC Class
The most common form of Tspec is a token bucket.
o Token Bucket SENDER_TSPEC object: Class = 8, C-Type = 1
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| AuthLen | AuthType=1| | | b: Token Bucket Depth (bits) |
+-----------+-----------+ +
| Mailbox name: user@domain |
// //
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| r: Average data rate (bits/sec) |
+-----------+-----------+-----------+-----------+
6.9 ADVERT Class
The rules for merging and interpreting this field require [TBD]
further study.
3.6.2 Application/RSVP Interface 6.10 TIME_VALUES Class
This section describes a generic API from an application to an o TIME_VALUES Object: Class = 10, C-Type = 1
RSVP control process. The details of a real interface may be
operating-system dependent; the following can only suggest the
basic functions to be performed. Some of these calls cause
information to be returned asynchronously.
An application could directly send and receive RSVP messages, +-------------+-------------+-------------+-------------+
just as an application can do file transfer using UDP. | Refresh Period |
However, we envision that many applications will not want to +-------------+-------------+-------------+-------------+
know the details of RSVP operation, nor to provide the timing | State TTL Time |
services necessary to keep the state refreshed, any more than +-------------+-------------+-------------+-------------+
an application wants to handle TCP retransmission timeouts. 6.11 ERROR_SPEC Class
Therefore, a host using RSVP may have an RSVP control process
to handle these functions. Using local IPC, applications will
register or modify resource requests with this process and
receive notifications of success or change of conditions.
Register o IPv4 ERROR_SPEC object: Class = 11, C-Type = 1
Call: REGISTER( DestAddress, ResvID, SND-flag, RCV-flag, +-------------+-------------+-------------+-------------+
[, DROP-flag] [, rsvpTTL] [, SenderTemplate] [, flowspec] | IP4 Error Node Address (4 bytes) |
[, UserCredentials] ) -> session-id +-------------+-------------+-------------+-------------+
| Error Code | ////////// | Error Value |
+-------------+-------------+-------------+-------------+
This call initiates RSVP processing for the session o IP6 ERROR_SPEC object: Class = 11, C-Type = 129
(DestAddress, ResvID). If successful, the call returns
immediately with a local session identifier "session-id",
which may be used in subsequent calls. Following this
call, an asynchronous ERROR or EVENT call (see below) may
occur at any time.
SND-flag should be set true if the host will send data, +-------------+-------------+-------------+-------------+
and RCV-flag should be set true if the host will receive | |
data. Setting neither true is an error. The optional + +
parameters DROP-flag, rsvpTTL, SenderTemplate, and | |
Flowspec should be supplied only if SND-flag is true. + IP6 Error Node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Error Code | ////////// | Error Value |
+-------------+-------------+-------------+-------------+
DROP-flag indicates that session data packets that do not Errnor Node
match any active filter in some node should be dropped at
that node; otherwise, such packets will be forwarded using
a best-effort QoS. The rsvp-TTL parameter specifies the
IP Time-to-Live field that will be used in PATH messages.
The value of rsvp-TTL should match the TTL field to be
sent in data packets, so they will have the same multicast
scope.
A REGISTER call with SND-flag equals TRUE will initiate The IP address
the transmission of PATH messages.
Reserve Error Code
Call: RESERVE( session-id, style [, DF-chan-count] A one-octet error description.
Flowspec-list, Filterspec-list)
A receiver uses this call to make a resource reservation 01 = Insufficient memory
for the session registered as `session-id'. The style
parameter is an integer index indicating the reservation
style. The DF-chan-count parameter, indicating the number
of Dynamic Filter channels to be reserved, should only be
included if the style is DF.
The first RESERVE call will initiate the periodic 02 = Count Wrong
transmission of RESV messages. A later RESERVE call may
be given to modify the parameters of the earlier call (but
note that changing the reservations may result in
admission control failure, depending upon the style).
The RESERVE call returns immediately. Following this The FD Count field does not match length of
call, an asynchronous ERROR or EVENT call may come at any message.
time.
Release 03 = No path information for this Resv
Call: RELEASE( session-id ) 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 messager.
This call will terminate RSVP state for the session 05 = Incorrect Dynamic Reservation Count
specified by session-id. It will send appropriate
"Teardown" messages and cease sending refreshes.
Error Upcall Dynamic Reservation Count is zero or less than FD
Count.
Call: ERROR( ) -> session-id, error-type, error-code 06 = Filterspec error
[, flowspec] [, filterspec]
This upcall may occur asynchronously at any time after a 07 = Flowspec syntax error
REGISTER call and before a RELEASE call, to indicate an
error. The allowed values of error-type and error-code
depend on whether the node is sending, receiving, or both.
The ERROR upcall reporting an admission control failure to 08 = Flowspec value error
a receiver will specify in `flowspec' the flowspec that
actually failed. This may differ from the flowspec
specified by this application in a RESERVE call, due to
upstream merging with reservation requests from other
receivers.
Event Upcall Internal inconsistency of values.
Call: EVENT( ) -> session-id, info-type, [What should be done with Flowspec Feature Not
[, flowspec-list] [, filterspec-list] Supported?]
This upcall may occur asynchronously at any time after a 09 = Resources unavailable [Sub-reasons? Depend upon
REGISTER call and before a RELEASE call, to signal an traffic control and admission control algorithms?]
event and to pass information to the application.
The `info-type' field indicates one of two possible event 10 = Illegal style
types. A Path event indicates the receipt of a PATH
message, indicating to the application that there is at
least one active sender. A Reservation event indicates
the receipt of a RESV message, indicating to the
application that there is at least one receiver. Although
these messages are repeatedly received, the API should
make the corresponding asynchronous upcall to the
application only on the first event, or when the
information to be reported changes.
ISSUE: Error Value
The precise form and function of the flowspec-list and Specific cause of the error described by the Error Code.
filterspec-list parameters are to be determined.
3.6.3 RSVP/Traffic Control Interface 6.12 CREDENTIAL Class
In each router and host, enhanced QoS is achieved by a group of [TBD]
inter-related functions: a packet Classifier, an admission
control module, and a packet scheduler. We group these
functions together under the heading traffic control. RSVP
uses the interfaces in this section to invoke the traffic
control functions.
1. Make a Reservation 6.13 INTEGRITY Class
Call: Rhandle = TCAddFlow( Flowspec, DropFlag, [TBD]
[SessionFilterspec [, SenderFilterspec]] )
Returns an internal handle Rhandle for subsequent 7. UDP Encapsulation
references to this reservation.
This call passes Flowspec to admission control and returns As described earlier, RSVP control messages are intended to be
an error code if Flowspec is malformed or if the requested carried as "raw packets", directly within IP datagrams. Implementing
resources are unavailable. Otherwise, it establishes a RSVP in a node will typically require an intercept in the packet
new reservation channel corresponding to Rhandle, and if forwarding path for protocol 46, which means a kernel change.
Filterspecs are supplied, installs a corresponding filter However, for ease of installing RSVP on host systems in the short
in the classifier. 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.
For FF reservation requests, RSVP knows about sharing and The UDP encapsulation approach must support a domain that contains a
calls AddFlow only for distinct source pipes. mix of "UDP-only" hosts, which require UDP encapsulation, and "raw-
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.
For DF reservation requests: suppose that the RESV message [REST TBD]
specifies a Dynamic Reservation Count = D, and F flow
descriptors, where 0 <= F <= D. Then RSVP calls AddFlow D
times, and D - F of those calls have null filterspecs.
2. Switch a Channel 8. DF Style (Experimental)
Call: TCModFilter( Rhandle, [new Filterspec]) 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.
This call replaces the filter without calling admission 8.1 Reservation Styles
control. It may replace an existing filter with no
filter, modify an existing filter, or replace no filter by
a filter.
3. Modify Flowspec A Dynamic-Filter (DF) style reservation decouples reservations
from filters.
Call: TCModFlowspec( Rhandle, oldFlowspec, newFlowspec) Each DF reservation request specifies a number D of distinct
reservations to be made using the same specified flowspec, and
these reservations have a wildcard reservation scope, so they go
everywhere. 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. Like a FF style request, a DF
style request causes distinct reservations for different senders.
Here newFlowspec may be larger or smaller than In addition to D and the flowspec, a DF style reservation may also
oldFlowspec. 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.
4. Delete Flow 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.
Call: TCDeleteFlow( Rhandle ) 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.
This call kills the reservation and reduces the reference The essential difference between the FF and DF styles is that the
count of, and deletes if the count is zero, any filter DF style allows a receiver to switch channels without danger of an
associated with this handle. 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.
5. Initialize The DF style is compatible with the FF style but not the WF style.
Call: TCInitialize( ) 8.2 Examples
This call is used when RSVP initializes its state, to To give an example of the DF style, we use the following notation:
clear out all existing classifier and/or packet scheduler
state.
3.6.4 RSVP/Routing Interface o DF Style
An RSVP implementation needs the following support from the DF( n, {r} ; ) or DF( n, {r} ; S1, S2, ...)
packet forwarding and routing mechanism of the node.
o Promiscuous receive mode for RSVP messages This message carries the count n of channels to be reserved, each
using common flowspec r. It also carries a list, perhaps empty,
of filterspecs defining senders.
Any datagram received for IP protocol 46 is to be diverted Figure 11 shows an example of Dynamic-Filter reservations. The
to the RSVP program for processing, without being receivers downstream from interface (d) have requested two
forwarded. reserved channels, but selected only one sender, S1. The node
reserves min(2,3) = 2 channels of size B on interface (d), and it
then applies any specified filters to these channels. Since only
one sender was specified, one channel has no corresponding filter,
as shown by `?'.
o Route discovery Similarly, the receivers downstream of interface (c) have
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 requested by one of them, for example.
RSVP must be able to discover the route(s) that the |
routing algorithm would have used for forwarding a Send | Reserve Receive
specific datagram. |
| ________
DF( 1,{B}; S1) <- (a) | (c) | S1{B} | (c) <- DF( 2,{B}; S1, S2)
| |________|
| | S2{B} |
| |________|
|
------------------------|-------------------------------------------
| ________
DF( 2,{B}; S2) <- (b) | (d) | S1{B} | (d) <- DF( 2,{B}; S1)
| |________|
| | ?{B} |
| |________|
GetUCRoute( DestAddress ) -> NextHop, Interface Figure 11: Dynamic-Filter Reservation Example
GetMCRoute( SrcAddress, DestAddress ) -> Interface A router should not reserve more Dynamic-Filter channels than the
number of upstream sources (three, in the router of Figure 11).
Since there is only one source upstream from previous hop (a), the
first parameter of the DF message (the count of channels to be
reserved) was decreased to 1 in the forwarded reservations.
However, this is unnecessary, because the routers upstream will
reserve only one channel, regardless.
o Outgoing Link Specification When a DF reservation is received, it is labeled with the IP
address of the next hop (RSVP-capable) router, downstream from the
current node. Since the outgoing interface may be directly
connected to a shared medium network or to a non-RSVP-capable
router, there may be more than one next-hop node downstream; if
so, each sends independent DF RESV messages for a given session.
The number N' of DF channels reserved on an outgoing interface is
given by the formula:
RSVP must be able to force a (multicast) datagram to be N' = min( D1+D2+...Dn, Ns),
sent on a specific outgoing virtual link, bypassing the
normal routing mechanism. A virtual link may be a real
outgoing link or a multicast tunnel.
This is necessary because RSVP may send different versions where Di is the D value (channel reservation count) in a RESV from
of outgoing PATH messages on different interfaces, for the the ith next-hop node.
same source and destination addresses.
o Discover (Virtual) Interface List For a DF reservation request with a Dynamic Reservation Count = C,
RSVP should call TC_AddFlowspec C times.
RSVP must be able to learn what real and virtual 8.3 Resv Messages
interfaces exist.
4. ACKNOWLEDGMENTS Add the following sequence:
Lixia Zhang, Scott Shenker, Deborah Estrin, Dave Clark, Sugih Jamin, <style-specific-tail> ::=
Shai Herzog, Steve Berson, Steve Deering, Bob Braden, and Daniel
Zappala have all made contributions to the design of RSVP. We are <Style-DF> <FLOWSPEC> <filter spec list>
grateful to Jamin, Herzog, and Berson for prototype implementations.
The original protocol concepts for RSVP arose out of discussions in <filter spec list> ::= <empty> | <filter spec list> <FILTER_SPEC>
meetings of the End-to-End Research Group.
8.4 STYLE Class
o STYLE-DF object: Class = 4, C-Type = 3
+-------------+-------------+-------------+-------------+
| Style=3 | //////// | Dyn Resv Cnt| FD Count |
+-------------+-------------+-------------+-------------+
Style
3 = Dynamic-Filter
Dyn Resv Count
The number of channels to be reserved for a Dynamic
Filter style reservation. This integer value must not
less than FD Count.
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.
Security Considerations Security Considerations
As noted in Section 2.1, the ability to reserve resources will create See Section 2.5.
a requirement for authentication of users who request reservations.
An authentication field has been included in this version of the
protocol spec, but further study on its format and usage will be
required.
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
Phone: (415) 812-4415 Phone: (415) 812-4415
EMail: Lixia@PARC.XEROX.COM EMail: Lixia@PARC.XEROX.COM
 End of changes. 

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