WDIFF

draft-ietf-rsvp-spec-04.txt --> draft-ietf-rsvp-spec-05.txt

Internet Draft L. Zhang
Expiration: May 95 PARC
File: draft-ietf-rsvp-spec-04.txt R. Braden Braden, Ed.
Expiration: September 1995 ISI
File: draft-ietf-rsvp-spec-05.txt L.Zhang
PARC
D. Estrin
ISI
S. Herzog
ISI
S. Jamin
USC

Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification

**DRAFT**
November 3, 1994

March 24, 1995

Status of Memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check the
linebreak "1id-abstracts.txt" listing contained in the Internet-
Drafts Shadow Directories on ds.internic.net (US East Coast),
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au
(Pacific Rim).

Abstract

This memo describes version 1 of RSVP, a resource reservation setup
protocol designed for an integrated services Internet. RSVP provides
receiver-initiated setup of resource reservations for multicast or
unicast data flows, with good scaling and robustness properties.

Zhang,

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page September 1995 [Page 1]

Internet Draft RSVP Specification November 1994 March 1995

What's Changed Since Seattle Toronto IETF

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 Redesign generic The RSVP API (section 3.6.2) packet format has been reorganized to carry most data
as typed variable-length objects.

o Change encoding of style in RESV messages (section 3.1.2) This generality includes provision for 16-byte IP6 addresses.

o Clarify filterspec functions (section 2.1) Filter specs have been simplified.

o Simplify definition of DF style (sections 2.2, 2.4). has been moved to an Appendix, as experimental.

o Revise discussion of flowspec merging (section 2.3.3). UDP encapsulation has been included.

o Change format of variable-length filterspecs and flowspecs
(section 3.1 and 3.6.1). OPWA has been included.

o Add a user authentication field in all RSVP messages (Section
3). The Drop flag has been eliminated.

o Add short discussion of local repair (Section 3.3.3). Session groups have been added.

o Editorial nits. The routing of RERR messages has been changed.

1. Introduction

This memo describes document defines RSVP, a resource reservation setup protocol
designed for an integrated services Internet [RSVP93,ISInt93]. An
application invokes

A host uses the RSVP protocol to request a specific quality of
service (
QoS) for a (QoS) from the network, on behalf of an application data
stream. Hosts and routers use RSVP is also used to deliver these QoS 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 will generally requires (but not
necessarily) require reserving resources in those nodes.

At each "node" (i.e., router or host) along the path, data path.

RSVP passes a
new resource reservation request to an admission control routine, to
determine whether there are sufficient reserves resources available. If there
are, the node for simplex data streams, i.e., it reserves the
resources and updates its packet scheduler
and classifier control parameters to provide the requested QoS
[ISInt93]. It is expected that RSVP implementations will execute in
user space in only one direction on a host, and in background in link, so that a router. On the other
hand, sender is
logically distinct from a receiver. However, the packet scheduler same application
may act as both sender 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, receiver. RSVP occupies operates on top of IP,
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 really rather an Internet control

Zhang,
protocol. As shown in Figure 1, an implementation of RSVP, like the
implementations of routing and management protocols, will typically

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page September 1995 [Page 2]

Internet Draft RSVP Specification November 1994

protocol; it does not carry any application data, and its messages
are processed by March 1995

execute in the routers background, not in the data forwarding path.

RSVP is not itself a routing protocol, but rather it is designed to
operate with existing and future unicast and multicast protocol; the RSVP daemon consults the
local routing
protocols. protocol(s) to obtain routes. Thus, a host sends IGMP
messages to join a multicast group, and then it sends RSVP messages to
reserve resources along the
deliver delivery path(s) from that group. Unlike a routing protocol, RSVP
is
explicitly invoked by applications, designed to obtain a special QoS.

The objectives operate with existing and general justification for future unicast and multicast
routing protocols.

HOST ROUTER

_________________________ RSVP design are
presented in [RSVP93,ISInt93]. In summary, ______________________
| | .---------------. |
| _______ ______ | . | ________ . ______ |
| | | | | | . || | . | || RSVP has the following
attributes:

o
| |Applic-| | RSVP supports multicast or unicast data delivery and adapts to
changing group membership as well as changing routes.

o <----- ||Routing | -> RSVP reserves resources for simplex <------>
| | App <----->daemon| | ||Protocol| |daemon||
| | | | | | || daemon <----> ||
| |_______| |___.__| | ||_ ._____| |__.___||
|===|===============v=====| |===v=============v====|
| data streams.

o RSVP is receiver-oriented, i.e., the receiver of a .......... | | . ............ |
| | ____v_ ____v____ | | _v__v_ _____v___ |
| | |Class-| | || data flow is
responsible for the initiation | |Class-| | || data
| |=> ifier|=> Packet =============> ifier|==> Packet |======>
| |______| |Scheduler|| | |______| |Scheduler||
| |_________|| | |_________||
|_________________________| |______________________|

Figure 1: RSVP in Hosts and maintenance Routers

Each router that is capable of the resource reservation used for that flow.

o RSVP maintains "soft state" in the routers, enabling it to
gracefully support dynamic membership changes and automatically
adapt to routing changes.

o RSVP provides several reservation models or "styles" (defined
below) passes incoming
data packets to fit a variety of applications.

o RSVP provides transparent operation through routers that do not
support it.

The RSVP protocol mechanisms provide a general facility for creating packet classifier and maintaining distributed reservation state across then queues them as necessary
in a mesh of
multicast delivery paths. These mechanisms treat packet scheduler. The packet classifier determines the reservation
parameters as opaque data, except for certain well-defined
operations, route
and simply pass them to the traffic control modules
(admission control, QoS class for each packet. The scheduler allocates a
particular outgoing link for packet scheduler, transmission, 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). it may also
allocate other system resources such as CPU time or buffers.

In order to efficiently accommodate heterogeneous receivers and
dynamic group membership, membership and to be consistent with IP multicast, RSVP
makes the receivers responsible for requesting resource reservations
[RSVP93]. Each A QoS request, typically originating in a receiver can request host
application, will be passed to the local RSVP implementation, shown
as a reservation that user daemon in Figure 1. The RSVP protocol is tailored then used to its particular requirement, pass
the request to all the nodes (routers and

Zhang, hosts) along the reverse
data path(s) to the data source(s).

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page September 1995 [Page 3]

Internet Draft RSVP Specification November 1994 March 1995

At each node, the RSVP will deliver this request program applies a local decision procedure,
called "admission control", to determine if it can supply the routers along
requested QoS. If admission control succeeds, the reverse
path(s) RSVP program sets
parameters to the sender(s).

There are two aspects to RSVP, its reservation model packet classifier and its protocol
mechanisms. Sections 2.1 and 2.2 of this memo summarize scheduler to obtain the
desired QoS. If admission control fails at any node, the RSVP
reservation model, while Sections 2.3 describes
program returns an error indication to the protocol
mechanisms. Sections 2.4 gives examples of both model and mechanism, application that
originated the request. We refer to the packet classifier, packet
scheduler, and Section 2.5 summarizes admission control components as "traffic control".

RSVP is designed to scale well for very large multicast groups.
Since the model membership of RSVP seen by a host. Section
3 presents large group will be constantly changing,
the functional specification RSVP design assumes that router state for RSVP.

2. traffic control will be
built and destroyed incrementally. For this purpose, RSVP Overview

2.1 uses "soft
state" in the routers, in addition to receiver-initiation.

RSVP Reservation Model

Figure 1 illustrates protocol mechanisms provide a single general facility for creating and
maintaining distributed reservation state across a mesh of multicast distribution session. The
arrows indicate
or unicast delivery paths. RSVP transfers reservation parameters as
opaque data flowing from senders S1 and S2 (except for certain well-defined operations on the data),
which it simply passes to receivers
R1, R2, and R3, and traffic control for interpretation.
Although the cloud represents RSVP protocol mechanisms are largely independent of the distribution mesh
created by
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 routing protocol. Multicast distribution
forwards a copy of each or unicast data packet from a sender Si to every
receiver Rj. Each sender Si delivery and receiver Rj may correspond adapts to
changing group membership as well as changing routes.

o RSVP is simplex.

o RSVP is receiver-oriented, i.e., the receiver of a
unique Internet host, or there may be multiple logical senders
(e.g., multiple TV cameras) and/or receivers in a single host.

RSVP reserves resources for simplex data streams, i.e., it
reserves resources in only one direction on a link, so that a
sender flow is logically distinct from a receiver. However,
responsible for the same
application may act as both sender initiation and receiver.

Senders Receivers
_____________________
( ) ===> R1
S1 ===> ( Multicast )
( ) ===> R2
( distribution )
S2 ===> ( )
( by Internet ) ===> R3
(_____________________)

Figure 1: Multicast Distribution Session

All data packets in a given session are addressed to maintenance of the same IP
destination address DestAddress. For multicast delivery,
DestAddress is resource
reservation used for that flow.

o RSVP maintains "soft state" in the multicast group address routers, enabling it to which the data is
addressed. For unicast delivery, DestAddress is simply the
unicast address of the single receiver.
gracefully support dynamic membership changes and automatically
adapt to routing changes.

o RSVP identifies a session
by DestAddress plus provides several reservation models or "styles" (defined
below) to fit a 32-bit stream identifier called variety of applications.

o RSVP provides transparent operation through routers that do not
support it.

Further discussion on the

Zhang, objectives and general justification for
RSVP design are presented in [RSVP93,ISInt93].

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page September 1995 [Page 4]

Internet Draft RSVP Specification November 1994

"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 March 1995

The remainder of this document,
a particular session (hence, session socket) is always implied
even if not stated.

Depending upon section describes the RSVP reservation style and the session state already
in place, a new or modified reservation request may
services. Section 2 presents an overview of the RSVP protocol
mechanisms, while Section 3 gives examples of the services and
mechanism. Section 4 contains the functional specification of RSVP.
Section 5 presents explicit message processing rules.

1.1 Data Flows

The set of data flows with the same unicast or may not
result multicast
destination constitute a session. RSVP treats each session
independently. All data packets in a call particular session are
directed to admission control at each node [ISInt93]. If
an admission control call fails, the reservation is rejected same IP destination address DestAddress, and
an RSVP error message is sent
perhaps to some further demultiplexing point defined in a higher
layer (transport or application). We refer to the receiver(s) responsible latter as a
"generalized destination port".

DestAddress is the group address for
it.

A multicast delivery, or the
unicast address of a single RSVP resource reservation request is receiver. A generalized destination
port could be defined by a "
flowspec" together with a "filterspec"; this pair is called a "
Flow Descriptor". The flowspec specifies the desired QoS UDP/TCP destination port field, by an
equivalent field in a
quantitative manner, e.g., the tolerable delay, the average
throughput, another transport protocol, or by some
application-specific information. Although the maximum burstiness, etc [Partridge92, ISInt93,
IServ93]; it RSVP protocol is used to set parameters
designed to be easily extendible for greater generality, the packet scheduling
mechanism in the node (router or host). The filterspec (plus the
DestAddress) defines
present version uses only UDP/TCP ports as generalized ports.

Figure 2 illustrates the set flow 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 single RSVP
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
particular sender Si, assuming multicast data distribution. The arrows
indicate data flowing from the entire stream of packets
destined senders S1 and S2 to a given DestAddress. The sender is selected
using its IP source address receivers R1, R2,
and R3, and optionally a "generalized
source port", i.e., multiplexing field(s) at the transport
layer (e.g., a UDP destination port) and/or cloud represents the application
layer (e.g., distribution mesh created by
the multicast routing protocol. Multicast distribution forwards a particular subset
copy of each data packet from a hierarchically encoded
video stream).

o Receiver Sub-selection

A filterspec may distinguish different sessions with the same
DestAddress by selecting sender Si to every receiver Rj; a subset of the packets destined
unicast distribution session has a single receiver R. Each sender
Si and each receiver Rj may correspond to
that address. This subset is defined by a "generalized
destination port", which again unique Internet host,
or a single host may include transport-layer
(e.g., UDP destination port) contain multiple logical senders and/or application-layer
demultiplexing information. An RSVP receiver Rj is defined

Zhang,
receivers, distinguished by generalized ports.

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page September 1995 [Page 5]

Internet Draft RSVP Specification November 1994 March 1995

Senders Receivers
_____________________
( ) ===> R1
S1 ===> ( Multicast )
( ) ===> R2
( distribution )
S2 ===> ( )
( by the Internet ) ===> R3
(_____________________)

Figure 2: Multicast Distribution Session

1.2 Reservation Model

An elementary RSVP reservation request consists of a "flowspec"
together with a "filter spec"; this pair (Hj, Pj), where Hj is called a "flow
descriptor". The flowspec specifies a desired QoS. The filter
spec (together with the IP host address DestAddress and Pj
is the generalized
destination port.

RSVP needs to distinguish different sessions. It is difficult to
do this by matching generalized destination ports buried within port defining the filterspecs, since session) defines the part set of data
packets -- the filterspec that defines the
generalized destination port should be opaque "flow" -- to an RSVP module in
a router, which does not not know receive the structure of transport or
application layer protocol headers. Therefore, RSVP identifies a
session QoS defined by the pair (DestAddress, ResvID), where the ResvID's form
a simple space of identifiers that RSVP can use to distinguish
different sessions with the same DestAddress.
flowspec. The ResvID's need
not themselves be (generalized) ports, but flowspec is used to set parameters to the packet
scheduler in the ResvID values node (assuming that are used must have a one-to-one correspondence with admission control succeeds),
while the
generalized ports filter spec is used to set parameters in use for the given DestAddress.

All packet
classifier.

The flowspec in a reservation requests for request will generally include a given session must use filterspecs
that specify the same DestAddress
service type and the same generalized
destination port (since receivers two sets of numeric parameters: (1) an " Rspec"
(R for `reserve'), which defines the same substream,
downstream of a given node, must share desired per-hop reservation,
and (2) a common resource
reservation in "Tspec" (T for `traffic'), which defines the parameters
that node).

2.2 Reservation Styles

In addition may be used to police the Flow Descriptors, each RSVP reservation request
specifies a "reservation style". data flow, i.e., to ensure it does
not exceed its promised traffic level.

The following reservation styles
have been defined so far.

1. Wildcard-Filter (WF) Style

A Wildcard-Filter (WF) style general RSVP reservation creates a single
resource "pipe" along each link, shared by data packets from
all senders for model allows filter specs to select
arbitrary subsets of the packets in a given session. The "size" of this pipe
is the largest of the resource requests for that link from
all receivers, independent of the number Such subsets
might be defined in terms of senders using it.
(The concept (i.e., sender IP address and
generalized source port), in terms of a "largest" flowspec is discussed later).

The term "wildcard" implies a filterspec that selects all
senders. A WF reservation automatically extends higher-level protocol, or
generally in terms of any fields in any protocol headers in the
packet. For example, filter specs might be used to new
senders select
different subflows in a hierarchically-encoded signal, by
selecting on fields in an application-layer header. However,
considerations of both architectural purity and practical
requirements have led to the session, as they appear.

2. Fixed-Filter (FF) Style

A Fixed-Filter (FF) style reservation request creates
reservation(s) decision that RSVP should use
separate sessions for data packets from particular sender(s). A
FF reservation request from a particular receiver Rj contains
a list of one or more Flow Descriptors, each consisting distinct subflows of a
filterspec, which specifies some sender Si, and a

Zhang, hierarchically-encoded
signals. For multicast sessions, subflows can be distinguished by
multicast destination address; for unicast sessions, they must be

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page September 1995 [Page 6]

Internet Draft RSVP Specification November 1994

corresponding flowspec.

FF reservations requested March 1995

distinguished by different receivers Rj but
selecting the same sender Si must necessarily share a single
reservation in destination port. As a given node. This is simply the result of
multicast distribution, which creates these
considerations, the present RSVP version includes a single stream quite
restricted definition of data
packets filter specs, selecting only on sender IP
address and UDP/TCP port number, and on protocol id. However, the
design of the protocol would easily handle a more general
definition in future versions.

Any packets that are addressed to a particular router from session but do not
match any Si, regardless of the
number of receivers downstream. The reservation filter specs for Si that session will be the maximum of the individual flowspecs from different
downstream receivers Rj (see Section 2.3.3).

FF reservations for different senders are distinct; they do
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 sent as
best-effort traffic. Under congested conditions, such packets are subject
likely to admission control experience long delays and may fail.

3. Dynamic-Filter (DF) Style be dropped. A Dynamic-Filter (DF) style reservation decouples
reservations from filters. Each DF reservation request
specifies a number D of distinct reservations receiver
may wish to be made
using conserve network resources by explicitly asking the same specified flowspec. The number of
reservations that are actually made in a particular node
network to drop those data packets for which there is
D' = min(D,Ns), no
reservation; however, such dropping should be performed by
routing, not by RSVP. Determining where Ns packets get delivered
should be a routing function; RSVP is concerned only with the total number QoS
of senders those packets that are delivered by routing.

RSVP reservation request messages originate at receivers and are
passed upstream of towards the node.

In addition 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 D and the flowspec, a DF style data flow direction).
When an elementary reservation may
also specify request is received at a list of K filterspecs, for some K in the
range: 0 <= K <= D'. These filterspecs define particular
senders to use node, the D' reservations. Once
RSVP daemon takes two primary actions.

1. Make a DF reservation
has been established,

The flowspec and the receiver may change filter spec are passed to traffic
control. Admission Control determines the set admissibility of
filterspecs to specify a different selection of senders,
without a new admission control check (assuming D'
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
common
flowspec remain unchanged). This is known as "channel
switching", in analogy with a television set.

In order used to provide assured channel switching, each node
along set up the path must reserve enough bandwidth packet scheduler 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
desired QoS and the number Ns of upstream sources changed), or if filter spec is used to set the common flowspec changes, packet
classifier to select the refresh message appropriate data packets.

2. Forward reservation upstream.

The reservation request is treated
as propagated upstream towards the
appropriate senders. The set of senders to which a new given
reservation request is propagated is called the "scope" of
that request.

The reservation request that a node forwards upstream may differ
from the request that it received, for two reasons. First, it is subject
possible (at least in theory) for the kernel to admission control and

Zhang, modify the
flowspec hop-by-hop (although currently no realtime services do

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page September 1995 [Page 7]

Internet Draft RSVP Specification November 1994

may fail.

Like a FF style request, a DF style request causes distinct March 1995

this). Second, reservations for different senders.

As noted earlier, those data packets from senders that are
not currently selected may either different downstream branches of
the multicast distribution tree(s) must be dropped or sent best-
effort.

WF "merged" as
reservations travel upstream. Merging reservations are appropriate for those multicast applications
whose application-level constraints prohibit all data sources from
transmitting simultaneously; one example is audio conferencing,
where a limited number necessary
consequence of people talk at once. Thus, each
receiver might issue multicast distribution, which creates a WF single
stream of data packets in a particular router from any Si,
regardless of the set of receivers downstream. The reservation request
for twice one audio
channel (to allow some over-speaking). On the other hand, Si on a particular outgoing link L should be the FF
and DF styles create independent reservations for "maximum" of
the flows individual flowspecs from
different senders; this is required for video signals, whose
`silence' periods, if any, are uncoordinated among different
senders.

The essential difference between the FF and DF styles is receivers Rj that are downstream
via link L. Merging is discussed further in Section 2.3.

For both of these primary actions, there are options controlled by
the
DF style allows a receiver to switch channels without danger of an
admission denial due to limited resources (unless a topology
change reroutes traffic along making the reservation. These options are combined
into a lower-capacity path or new senders
appear), once control variable called the initial reservations have been made.

Other reservation styles may be defined "style", which is
discussed in section 1.3. One option concerns the future.

2.3 RSVP Protocol Mechanisms

2.3.1 RSVP Messages

Each receiver host sends RSVP reservation (RESV) messages into
the Internet, carrying Flow Descriptors requesting treatment of
reservations for different senders within the desired
reservation; see Figure 2. These same session:
establish a "distinct" reservation messages must
follow for each upstream sender, or
else "mix" all senders' packets into a single reservation.
Another option controls the reverse scope of the routes the data packets will use, request: "unitary" (i.e.,
a single specified sender), an explicit sender list, or a
"wildcard" that implicitly selects all
the way senders upstream to all of the senders. If a
given node.

The basic RSVP reservation request
fails at any node, an RSVP error message model is returned to the
receiver; however, RSVP "one pass": a receiver sends no positive acknowledgment
messages to indicate success. RESV messages are finally
delivered to the sender hosts, so that a
reservation request upstream, and each node in the hosts path can set up
appropriate traffic control parameters for only
accept or reject the first request. This scheme provides no way to make
end-to-end service guarantees; the QoS request is applied
independently at each hop.

Zhang, Braden, et al. Expiration: May 95 FORMFEED[Page 8]

Internet Draft RSVP Specification November 1994

Sender Receiver
_____________________
Path --> ( )
Si =======> ( Multicast ) Path -->
<-- Resv ( ) =========> Rj
( distribution ) <-- Resv
(_____________________)

Figure 2: RSVP Messages

Each sender transmits also supports an optional
reservation model, known as " One Pass With Advertising" (OPWA)
[Shenker94]. In OPWA, RSVP PATH messages forward along the
uni-/multicast routes provided by control packets sent downstream,
following the routing protocol(s).
These "Path" messages store path state in all data paths, are used to gather information on the intermediate
routers.
end-to-end service that would result from a variety of possible
reservation requests. The path state is currently used results ("advertisements") are
delivered by RSVP to route the RESV
messages in the reverse direction from each receiver host, and perhaps to all
selected senders for a given session. In the future, this
function
receiver application. The information may then be assumed used by routing protocols. PATH messages
have other functions; they carry the
receiver to construct an appropriate reservation request.

1.3 Reservation Styles

Each RSVP reservation request specifies a "reservation style".
The following additional
information:

o A sender template, which describes the format reservation styles are defined in this version of data
packets that
the sender will originate. protocol.

1. Wildcard-Filter (WF) Style

The sender template takes the form of two bitstrings
forming a (value, mask) pair. Zero mask bits represent
"don't care" (variable) bits in data packets. If present,
this template is used by RSVP to match WF style specifies the filterspecs in options: "mixing" reservation and
" wildcard" reservation scope. Thus, a RESV message. Without such WF-style reservation
creates 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:

Should sender templates be defined to be precisely
filterspecs, or should templates and filterspecs be
allowed to use different syntax?

o A flowspec defining an upper bound on the traffic that
will be generated. single reservation into which flows from all
upstream senders are mixed. This flowspec can be used by RSVP to prevent over- reservation on the non-shared links starting at the
sender.

Zhang, may be thought

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 9] September 1995 [Page 8]

Internet Draft RSVP Specification November 1994

A (template, flowspec) pair in a PATH message is called a
Sender Descriptor.

2.3.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, and it can be
removed at each node by explicit "Teardown" messages. RSVP
also has March 1995

of a timer-driven cleanup procedure if no message shared "pipe", whose "size" is
received within a cleanup timeout interval.

When the route changes, the next PATH message will initialize
the path state on the new route, and future RESV messages will
establish reservation state while largest of the state on
resource requests for that link from all receivers,
independent of the now-unused
segment number of senders using it. A WF-style
reservation has wildcard scope, i.e., the route times out. Thus, whether a message is
"new" or a "refresh" reservation is determined separately at each node,
depending upon the existence of state at that node. (This
document will use the term "refresh message" in this effective
sense, to indicate an RSVP message that does not modify the
existing state at the node in question.)

RSVP sends
propagated upstream towards all its messages as IP datagrams without any
reliability enhancement. Periodic transmission of refresh
messages by hosts and routers is expected to replace any lost
RSVP messages. However, the traffic control mechanism should
be statically configured to grant high-reliability service senders. A WF-style
reservation automatically extends to
RSVP messages, new senders to protect RSVP messages from severe congestion.

If the set of senders Si or receivers Rj changes, or if any of
session as they appear.

2. Fixed-Filter (FF) Style

The FF style specifies the receivers' options: "distinct" reservation requests change, the RSVP state is
adjusted accordingly. RSVP believes the latest PATH
and RESV
messages (ignoring the possibility of reordering). To modify a
reservation, a receiver simply starts sending the new values.
It is not necessary (although it may sometimes be desirable,
when the resources being consumed are "valuable"), to tear down
the old "unitary" reservation explicitly.

When scope. Thus, an elementary FF-
style reservation request creates a RESV message is received at distinct reservation for
data packets from a router or sender host, the
RSVP module checks whether particular sender, not mixing them with
other senders' packets for the message is same session.

The total reservation on a new or link for a modified
reservation request, or whether it simply refreshes an existing
reservation. A new or modified request given session is passed to the
admission control module
total of the FF reservations for a decision. If all requested senders. On
the reservation is
accepted, RSVP sets up (or modifies) 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
whose application-specific constraints make it unlikely that
multiple data sources will transmit simultaneously. One example is
audio conferencing, where a limited number of people talk at once;
each receiver might issue a WF reservation request for twice one
audio channel (to allow some over-speaking). On the other hand,
the FF style, which creates independent reservations for the flows
from different senders, is appropriate for video signals.

The WF and filter
state. It also forwards FF styles are incompatible and cannot be combined
within a session. Other reservation styles may be defined in the RESV
future (see Appendix C).

2. RSVP Protocol Mechanisms

2.1 RSVP Messages

There are two fundamental RSVP message to types, RESV messages and
PATH messages.

Each receiver host sends RSVP reservation request (RESV) messages
towards the next reverse-
hop router(s) or sender host(s), as determined by senders. These reservation messages must follow in
reverse the path (or
routing) state. If RSVP on routes the node rejects data packets will use, all the reservation
request due way upstream
to admission control failure or the senders within the scope. RESV messages are delivered to some processing

Zhang,
the sender hosts, so that the hosts can set up appropriate traffic

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 10] September 1995 [Page 9]

Internet Draft RSVP Specification November 1994

error, it discards March 1995

control parameters for the RESV message and returns first hop. If a reservation request
fails at any node, an RSVP error message is returned to the originating receiver host. If the request
modifies a previous reservation,
receiver; however, RSVP may immediately remove
the old state, or it may simply let sends no positive acknowledgment messages
to indicate success.

Sender Receiver
_____________________
Path --> ( )
Si =======> ( Multicast ) Path -->
<-- Resv ( ) =========> Rj
( distribution ) <-- Resv
(_____________________)

Figure 3: RSVP Messages

Each sender transmits RSVP PATH messages forward along the old uni-
/multicast routes provided by the routing protocol(s); see Figure
3. These "Path" messages store path state in each node. Path
state time out
since it is no longer being refreshed; used by RSVP to route the details depend upon RESV messages hop-by-hop in the style and
reverse direction. (In the future, some routing protocols may
supply reverse path forwarding information directly, without path
state).

PATH messages may also carry the following information:

o Sender Template

The Sender Template describes the format of data packets that
the sender will originate. This template is in the form of a
filter spec that could be used to select this sender's
packets from others in the same session on the same link.

o Tspec

The PATH message may optionally carry a flowspec containing
only a Tspec, defining an upper bound on the traffic level
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 implementation. sender.

o Adspec

The PATH message may carry a package of OPWA advertising
information, known as an "Adspec".

Braden, Zhang, et al. Expiration: September 1995 [Page 10]

Internet Draft RSVP Specification March 1995

Previous Incoming Outgoing Next
Hops Interfaces Interfaces Hops

_____ _____________________ _____
| | data --> | | data --> | |
| A |-----------| |------------| a c |--------------| C |
|_____| <-- Resv | | <-- Resv |_____|
Path --> | | Path --> _____
_____ | ROUTER | Router |
_____ | | _____
| | data --> | | data --> | |--| D |
| |-----------| |------------| B |--| data-->| | data --> | |_____|
|_____| |--------| b d |-----------|
|<-- Resv| | <-- Resv | _____
_____ | <-- Resv |_____|
Path --> |_____________________| Path-->|_____________________| Path -->

Figure 3: Router Using RSVP

Figure 3 | | |
| | | |--| D' |
| B' |--| | |_____|
|_____| | |

Figure 4: Router Using RSVP

Figure 4 illustrates RSVP's model of a router node. Each data
stream arrives from a previous hop through a corresponding
incoming interface and departs through one or more outgoing
interface(s). Since the same host may be hosting both sender
and receiver applications for a given session, the The same physical interface may act in both the
incoming and outgoing roles (for different data streams).

The interfaces shown flows but the same
session).

As illustrated in Figure 3 may be physical interfaces
(e.g., to point-to-point links), or they 4, there may be logical
interfaces that reach multiple nodes through the same physical
interface. Multiple previous hops
and/or next hops through a given physical interface can interface. This may
result from either the connected 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 2.6). An RSVP to track
both logical and physical interfaces on both daemon must preserve the incoming next and
outgoing sides.

Zhang, Braden, et al. Expiration: May 95 FORMFEED[Page 11]

Internet Draft RSVP Specification November 1994

2.3.3 Merging RSVP Messages

Whenever possible, the control information arriving
previous hop addresses in RSVP
messages for a given session is combined into fewer outgoing
messages; this its reservation and path state,
respectively. A RESV message is known generically as "merging". Those
messages that cause sent with a state change are forwarded without delay,
while the refresh messages may be merged into fewer messages,
perhaps only one per session.

For PATH messages, merging implies collecting together unicast destination
address, the
Sender Descriptors from multiple incoming messages into address of a
single outgoing previous hop. PATH message. For RESV messages, merging
implies that only on the essential (e.g.,
other hand, are sent with the largest) session destination address, unicast
or multicast.

Although multiple next hops may send reservation requests need be forwarded, once per refresh period; redundant
messages are "purged". A successful reservation request will
propagate as far as through
the closest point(s) along same physical interface, the sink tree final effect should be to
the sender(s) where install
a reservation level equal or greater than
that being requested has been made. At on that point, the merging
process interface, which is defined by an effective
flowspec. This effective flowspec will drop it in favor of another, equal or larger,
reservation request.

To allow merging, each node must save the state from received
messages and then periodically generate cumulative PATH and
RESV messages from the saved state, to be forwarded in place of the received messages. Thus, new refresh messages are created
hop-by-hop inside "maximum" of the network, at a rate determined
flowspecs requested by a
"refresh period". Since messages that modify the state in different next hops. In turn, a
node ("new" messages) are RESV
message forwarded without delay, the refresh
period does not affect the rate at which new state propagates
from end to end (when packets are not lost).

Although flowspecs are opaque to RSVP, merging requires the
ability to determine which of two flowspecs is "larger", i.e.
whether one represents a stricter request (and hence represents a larger resource commitment) than the other. However, particular previous hop carries a flowspec may be a complex multi-dimensional vector, so the
"larger-than" relationship may not be defined for a given pair
of flowspecs. For example, consider two flowspecs Fls1 and
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
flowspecs.

(1) Compare the "maximum" over the effective reservations on a single dimension, e.g., compare the
throughput requirement (average bit rate) only.

Zhang,

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 12] September 1995 [Page 11]

Internet Draft RSVP Specification November 1994

(2) Construct a third flowspec that March 1995

corresponding outgoing interfaces. Both cases represent merging,
which is greater than each discussed further below.

There are a number of the two being compared. In the example above, we
could construct ways for a third flowspec Fls3 by combining new reservation request to fail
in a given node.

1. There may be no matching path state (i.e., the higher throughput from Fls1 scope may
empty), which would prevent the reservation being propagated
upstream.

2. Its style may be incompatible with the lower delay
from Fls2.

(3) Treat style(s) of existing
reservations for the compatibility as same session on the same outgoing
interface, so an error that should effective flowspec cannot be
avoided by applications.

The choice of one of these approaches should computed.

3. Its style may be governed by
flags in incompatible with the flowspec itself, not by RSVP.

Note style(s) of
reservations that this problem cannot exist on other outgoing interfaces but will
be avoided by refraining from
merging flowspecs. If incompatible flowspecs were not merged
at with this reservation when a particular node A, then they would arrive at the next node
upstream, say B, in separate RESV messages. This may also
happen if there are multiple next hops across the same outgoing
interface. Node B would have refresh message to make
create a reservation refresh message for the
largest flowspec, if that previous hop.

4. The effective flowspec may fail admission control.

In any of these cases, an error message is defined, or one that dominates all
the given flowspecs; that is, it must merge the unmerged
reservations. Thus, failing returned to merge simply moves the problem
one node upstream.

This mechanism, reserving
receiver(s) responsible for the highest demand at each node,
allows an application to increase an message, but any existing
reservation
request immediately (assuming admission control does not fail
for the larger flowspec). Decreasing is left in place. This prevents a new, very large,
reservation has to be
handled more cautiously, however. The arrival of a RESV
message from disrupting the existing QoS by merging with an apparently decreased
existing reservation might be
caused by the loss of a merged RESV message downstream.
Therefore, an RSVP should not "believe" a and then failing admission control.

2.2 Soft State

To maintain reservation decrease
until the cleanup timeout has passed.

The refresh period state, RSVP keeps "soft state" in router
and the cleanup timeout must obey the
following general principles:

A. The refresh period must be long enough to keep host nodes. RSVP
overhead at an acceptable level.

B. The refresh period should be short enough to allow
quick adaptation to route soft state is created and multicast membership
changes.

Applications may differ in their sensitivity to
service outages, periodically
refreshed by PATH and therefore they should be able to

Zhang, Braden, et al. Expiration: May 95 FORMFEED[Page 13]

Internet Draft RSVP Specification November 1994

adjust the refresh period for their session state.
However, RESV messages. The state is deleted if no
refreshes arrive before the technique expiration of "local repair" (see Section
3.3.3) can provide rapid adaptation despite a long
refresh period.

C. The timeout period must "cleanup timeout"
interval; it may also be long enough to allow for
loss deleted as the result of individual RSVP messages.

2.3.4 Teardown

As an optimization to release explicit
"Teardown" message. It is not necessary (although it may be
desirable, since the resources quickly, RSVP teardown
messages remove being consumed may be "valuable"),
to explicitly tear down an old reservation.

When a route changes, the next PATH message will initialize the
path and reservation state without waiting for on the cleanup timeout period. RSVP new route, and future RESV messages are not delivered
reliably, but will
establish reservation state, while the state on the now-unused
segment of the route will eventually time out even if out. Thus, whether a
teardown message is lost.

Teardown may be initiated either by an end system (sender or
receiver),
"new" or by a router as "refresh" is determined separately at each node,
depending upon the result existence of state timeout. A
router may also initiate a teardown message as at that node. (This
document uses the result of
router or link failures detected by the routing protocol. A
teardown, once initiated, will be forwarded hop-by-hop without
delay.

There are two types of RSVP Teardown message, PTEAR and RTEAR.
A PTEAR message travels towards all receivers downstream from
its point of initiation and tears down path state along the
way, while an RTEAR message tears down reservation state and
travels towards all senders upstream from its point of
initiation.

A particular reservation on a node may be shared among multiple
senders and/or receivers, but it must apply term "refresh message" in this effective sense,
to a unique next
hop (and outgoing interface). The receipt of indicate an RTEAR RSVP message
implies that does not modify the corresponding reservation existing
state has been
removed downstream, so that the reservation can safely be
deleted locally. Again, at the local node will only forward the
teardown message upstream when the state named in question.)

Braden, Zhang, et al. Expiration: September 1995 [Page 12]

Internet Draft RSVP Specification March 1995

In addition to the message
has been entirely removed locally. As cleanup timeout, there is a result, an RTEAR
message will prune "refresh timeout"
period. As messages arrive, the RSVP daemon checks them against
the existing state; if it matches, the cleanup timeout timer on
the reservation state back (only) as far as
possible. Note that is reset and the RTEAR message will cease to be
forwarded at is dropped. At the same node where merging suppresses forwarding expiration
of the corresponding RESV messages.

Consider the router configuration shown in Figure 4 below.
Assume that there are reservations for source S1 on both
outgoing interfaces (c) each refresh timeout period, RSVP scans its state to build and (d),
forward PATH and that the receiver R1 wants RESV refresh messages to tear down succeeding hops.

RSVP sends its reservation state for S1. R1's RTEAR message

Zhang, Braden, et al. Expiration: May 95 FORMFEED[Page 14]

Internet Draft messages as IP datagrams without reliability
enhancement. Periodic transmission of refresh messages by hosts
and routers is expected to replace any lost RSVP Specification November 1994

arriving through interface (c) indicates that all reservation
state for (this session and) sender S1 has been removed
downstream. The current node therefore removes messages. To
tolerate K successive packet losses, the S1
reservation state from interface (c). However, since there
will still effective cleanup timeout
must be an S1 reservation on interface (d), at least K times the RTEAR
message will not be forwarded any further.

However, if refresh timeout. In addition, the outgoing interface connects to a shared medium
or if there is a non-RSVP router immediately downstream, then
there may be multiple next-hop RSVP nodes downstream that are
reached through
traffic control mechanism in the same outgoing interface, say (c). Then a
single reservation may network should be shared among multiple next hops. statically
configured to grant high-reliability service to RSVP must tag each reservation with the next hop(s) from which
the RESV messages came, for use by teardown messages, to avoid deleting
shared state.

Deletion of path
protect RSVP messages from congestion losses.

In steady state, whether refreshing is performed hop-by-hop, which allows
merging and packing as the result of a teardown
message or because of timeout, may force adjustments in related
reservation state to maintain consistency described in the local node.
Consider next section. However, if
the path received state for a sender S; differs from the related reservation stored state, the stored state would be as follows.

o Wildcard-Filter style: If S
is updated. Furthermore, if the only sender result will be to modify the
session, delete the reservation.

o Fixed-Filter style: Delete reservations made for S.

o Dynamic-Filter style: Reduce total reservation if
refresh messages to be generated, these refresh messages must be
generated and forwarded immediately. This will result in changes
propagating end-to-end without delay. However, propagation of a
change stops when and if it now
exceeds 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.

The "soft" router state maintained by RSVP is dynamic; to change
the total number set of remaining senders.

2.4 Examples

We use the following notation for senders Si or receivers Rj or to change any QoS
request, a host simply starts sending revised PATH and/or RESV message:

1. Wildcard-Filter

WF( *{r})

Here "*{r}" represents a Flow Descriptor
messages. The result should be the appropriate adjustment in the
distributed RSVP state, and immediate propagation to the
succeeding nodes.

The RSVP state associated with a "wildcard"
filter (choosing all senders) and session in a flowspec of quantity r.
For simplicity we assume here particular node is
divided into atomic elements that flowspecs are one-
dimensional, defining for example created, refreshed, and
timed out independently. The atomicity is determined by the average throughput,
requirement that any sender or receiver may enter or leave the
session at any time, and its state them as a multiple should be created and timed out
independently. Management of some unspecified base resource
quantity B.

2. Fixed-Filter

Zhang, Braden, et al. Expiration: May 95 FORMFEED[Page 15]

Internet Draft RSVP Specification November 1994

FF( S1{r1}, S2{r2}, ...)

This message carries state is complex because there
may not be a list of (sender, flowspec) pairs,
i.e., Flow Descriptors.

3. Dynamic-Filter

DF( n, {r} ; ) or DF( n, {r} ; S1, S2, ...)

This message carries one-to-one correspondence between state carried in
RSVP control messages and the count n of channels resulting state in nodes. Due to be reserved,
each using common flowspec r. It also carries
merging, a list,
perhaps empty, of filterspecs defining senders.

Figure 4 shows schematically single message contain state referring to multiple
stored elements. Conversely, due to reservation sharing, a router with two previous hops
labeled (a) and (b) and two outgoing interfaces labeled (c) and
(d). This topology will be assumed in single
stored state element may depend upon (typically, the examples that follow.
There are three upstream senders; packets from sender S1 (S2 maximum of)
state values received in multiple control messages.

Braden, Zhang, et al. Expiration: September 1995 [Page 13]

Internet Draft RSVP Specification March 1995

2.3 Merging and
S3) arrive through Packing

A previous hop (a) ((b), respectively). There
are also three downstream receivers; packets bound for R1 and R2
(R3) section explained that reservation requests in RESV
messages are routed via outgoing interface (c) ((d) respectively).

In addition necessarily merged, to the connectivity shown in 4, we must also specify match the multicast routing within this node. Assume first
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 data
packets (hence, PATH messages) from each Si shown being requested has
been made. At that point, the merging process will drop it in Figure 4 is
routed
favor of another, equal or larger, reservation request.

Although flowspecs are opaque to both outgoing interfaces. Under this assumption,
Figures 5, 6, and 7 illustrate Wildcard-Filter reservations,
Fixed-Filter reservations, and Dynamic-Filter reservations,
respectively.

________________
(a)| | (c)
( S1 ) ---------->| |----------> ( R1, R2)
| Router |
(b)| | (d)
( S2,S3 ) ------->| |----------> ( R3 )
|________________|

Figure 4: Router Configuration

In Figure 5, RSVP, an RSVP daemon must be able
to calculate the "Receive" column shows "largest" of a set of flowspecs. This is
required both to calculate the RESV messages received
over outgoing interfaces (c) effective flowspec to install on a
given physical interface (see the discussion in connection with
Figure 4), and () to merge flowspecs when sending a refresh message
upstream. Since flowspecs are generally multi-dimensional vectors
(they contain both Tspec and the "Reserve" column shows
the resulting reservation state for Rspec components, each interface. The "Send"
column shows of which may
itself be multi-dimensional), they are not strictly ordered. When
it cannot take the RESV messages forwarded 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 previous hops (a) be incomparable, which is treated as an error. The definition
and
(b). In the "Reserve" column, each box represents one reservation
"channel", with implementation of the corresponding filter. As a result rules for comparing flowspecs are
outside RSVP proper, but they are defined as part of merging,
only the message with service
templates.

For protocol efficiency, RSVP also allows multiple sets of path
(or reservation) information for the largest flowspec is forwarded upstream same session to each previous hop.

Zhang, Braden, et al. Expiration: May 95 FORMFEED[Page 16]

Internet Draft be "packed"
into a single PATH (or RESV) message, respectively. (For
simplicity, the protocol prohibits packing different sessions into
the same RSVP Specification November 1994

|
Send | Reserve Receive
|
| _______
WF( *{3B} ) <- (a) | (c) | * {3B}| (c) <- WF( *{B} )
| |_______|
|
-----------------------|----------------------------------------
| _______
WF( *{3B} ) <- (b) | (d) | * {B} | (d) <- WF( *{3B} )
| |_______|

Figure 5: 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, message).

2.4 Teardown

RSVP teardown messages remove path and reservation state without
waiting for the message forwarded cleanup timeout period, as an optimization 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} )
release resources quickly. Although teardown messages (like other
RSVP messages) are merged, not delivered reliably, the single message FF( S1{3B} ) is sent
to previous hop (a), towards S1.

For each outgoing interface, there state will time out
even if it is not explicitly deleted.

A teardown request may be initiated either by an application in an
end system (sender or receiver), or by a private reservation for
each source that has been requested, but this private reservation
is shared among router as the receivers that made result of
state timeout. A router may also initiate a teardown message as
the request.

Zhang, result of router or link failures detected by the routing
protocol. Once initiated, a teardown request should be forwarded

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 17] September 1995 [Page 14]

Internet Draft RSVP Specification November 1994

|
Send | Reserve Receive
|
| ________
FF( S1{3B} ) <- (a) | (c) | S1{B} March 1995

hop-by-hop without delay.

To increase the reliability of teardown, Q copies of any given
teardown message can be sent. Note that a node cannot actually
delete the state being torn down until it has sent Q Teardown
messages; it must place the state in a "moribund" status
meanwhile. The appropriate value of Q is an engineering issue. Q
= 1 would be the simplest and may be adequate, since unrefreshed
state will time out anyway; teardown is an optimization. If one
or more Teardown message 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, the longest time to delete
state will seldom exceed one refresh timeout period.

There are two types of RSVP Teardown message, PTEAR and RTEAR. A
PTEAR message travels towards all receivers downstream from its
point of initiation and tears down path state along the way. A
RTEAR message tears down reservation state and travels towards all
senders upstream from its point of initiation. A PTEAR (RTEAR)
message may be conceptualized as a reversed-sense Path message
(Resv message, respectively).

A teardown message deletes the specified state in the node where
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.

Deletion of path state, whether as the result of a teardown
message or because of timeout, may force adjustments in order in
related reservation state to maintain consistency in the local
node. For example, when a PTEAR deletes the path state for a
sender S, the adjustment in reservation depends upon the style: if
the style is WF and S is the only sender to the session, delete
the reservation; if the style is FF, delete only reservations for
sender S. These reservation changes should not trigger an
immediate RESV refresh message, since the teardown message will
have already made the required changes upstream. However, at the
node in which an RTEAR message stops, the change of reservation
state may trigger a RESV refresh starting at that node.

Braden, Zhang, et al. Expiration: September 1995 [Page 15]

Internet Draft RSVP Specification March 1995

2.5 Security

There are two distinct types of security concerns in RSVP.

1. Protecting RSVP Message Integrity

It may be necessary to ensure the integrity of RSVP messages
against corruption or spoofing, hop by hop. RSVP messages
have an optional integrity field that can be created and
verified by neighboring RSVP nodes.

2. Authenticating Reservation Requests

RSVP-mediated resource reservations may reserve network
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.

The RSVP packet formats provide for both; see Section 4.

2.6 Automatic RSVP Tunneling

It is impossible to deploy RSVP (or any new protocol) at the same
moment throughout the entire Internet. Furthermore, 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. Of course, an
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.

RSVP will automatically tunnel through such a non-RSVP cloud.
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.

Braden, Zhang, et al. Expiration: September 1995 [Page 16]

Internet Draft RSVP Specification March 1995

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.

2.7 Session Groups

Section 1.2 explained that a distinct destination address, and
therefore a distinct session, will be used for each of the
subflows in a hierarchically encoded flow. However, these
separate sessions are logically related. For example it may be
necessary to pass reservations for all subflows to Admission
Control at the same time (since it would be nonsense to admit high
frequency components but reject the baseband component of the
session data). Such a logical grouping is indicated in RSVP by
defining a "session group", an ordered set of sessions.

To declare that a set of sessions form a session group, a receiver
includes a data structure we call a SESSION_GROUP object in the
RESV message for each of the sessions. A SESSION_GROUP object
contains four fields: a reference address, a session group ID, a
count, and a rank.

o The reference address is an agreed-upon choice from among the
DestAddress values of the sessions in the group, for example
the smallest numerically.

o The session group ID is used to distinguish different groups
with the same reference address.

o The count is the number of members in the group.

o The rank, an integer between 1 and count, is different in
each session of the session group.

The SESSION_GROUP objects for all sessions in the group will
contain the same values of the reference address, the session
group ID, and the count value. The rank values establishes the
desired order among them.

If RSVP at a given node receives a RESV message containing a
SESSION_GROUP object, it should wait until RESV messages for all
`count' sessions have appeared (or until the end of the refresh

Braden, Zhang, et al. Expiration: September 1995 [Page 17]

Internet Draft RSVP Specification March 1995

cycle) and then pass the RESV requests to Admission Control as a
group. It is normally expected that all sessions in the group
will be routed through the same nodes. However, if not, only a
subset of the session group reservations may appear at a given
node; in this case, the RSVP should wait until the end of the
refresh cycle and then perform Admission Control on the subset of
the session group that it has received. The rank values will
identify which are missing.

Note that routing different sessions of the session group
differently will generally result in delays in establishing or
rejecting the desired QoS. A "bundling" facility could be added
to multicast routing, to force all sessions in a session group to
be routed along the same path.

2.8 Host Model

Before a session can be created, the session identification,
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

Braden, Zhang, et al. Expiration: September 1995 [Page 18]

Internet Draft RSVP Specification March 1995

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:

1. Wildcard-Filter

WF( *{Q})

Here "*{Q}" represents a Flow Descriptor with a "wildcard" scope
(choosing all senders) and a flowspec of quantity Q.

2. Fixed-Filter

FF( S1{Q1}, S2{Q2}, ...)

A list of (sender, flowspec) pairs, i.e., flow descriptors,
packed into a single RESV message.

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.

Figure 5 shows schematically a router with two previous hops labeled
(a) and (b) and two outgoing interfaces labeled (c) and (d). This
topology will be assumed in the examples that follow. There are
three upstream senders; packets from sender S1 (S2 and S3) arrive
through previous hop (a) ((b), respectively). There are also three
downstream receivers; packets bound for R1 and R2 (R3) are routed via
outgoing interface (c) ((d) respectively).

In addition to the connectivity shown in 5, we must also specify the

Braden, Zhang, et al. Expiration: September 1995 [Page 19]

Internet Draft RSVP Specification March 1995

multicast routing within this node. Assume first that data packets
(hence, PATH messages) from each Si shown in Figure 5 is routed to
both outgoing interfaces. Under this assumption, Figures 6 and 7
illustrate Wildcard-Filter reservations and Fixed-Filter
reservations, respectively.

________________
(a)| | (c)
( S1 ) ---------->| |----------> ( R1, R2)
| Router |
(b)| | (d)
( S2,S3 ) ------->| |----------> ( R3 )
|________________|

Figure 5: Router Configuration

In Figure 6, the "Receive" column shows the RESV messages received
over outgoing interfaces (c) and () and the "Reserve" column shows
the resulting reservation state for each interface. The "Send"
column shows the RESV messages forwarded to previous hops (a) and
(b). In the "Reserve" column, each box represents one reservation
"channel", with the corresponding filter. As a result of merging,
only the largest flowspec is forwarded upstream to each previous hop.

|
Send | Reserve Receive
|
| _______
WF( *{3B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} )
| |_______|
|
-----------------------|----------------------------------------
| _______
WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} )
| |_______|

Figure 6: Wildcard-Filter Reservation Example 1

Figure 7 shows Fixed-Filter style reservations. The flow descriptors
for senders S2 and S3, received from outgoing interfaces (c) and (d),
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

Braden, Zhang, et al. Expiration: September 1995 [Page 20]

Internet Draft RSVP Specification March 1995

reservation for each source that has been requested, but this private
reservation is shared among the receivers that made the request.

|
Send | Reserve Receive
|
| ________
FF( S1{3B} ) <- (a) | (c) | S1{B} | (c) <- FF( S1{B}, S2{5B} )
| |________|
| | S2{5B} |
| |________|
---------------------|---------------------------------------------
| ________
<- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} )
FF( S2{5B}, S3{B} ) | |________|
| | S3{B} |
| |________|

Figure 7: Fixed-Filter Reservation Example

The two examples just shown assume full routing, i.e., data packets
from S1, S2, and S3 are routed to both outgoing interfaces. Assume
the routing shown in Figure 8, in which data packets from S1 are not
forwarded to interface (d) (because the mesh topology provides a
shorter path for S1 -> R3 that does not traverse this node).

_______________
(a)| | (c)
( S1 ) ---------->| --------->--> |----------> ( R1, R2)
| / |
| / |
(b)| / | (d)
( S2,S3 ) ------->| ->----------> |----------> ( R3 )
|_______________|

Figure 8: Router Configuration

Under this assumption, Figure 9 shows Wildcard-Filter reservations.
Since there is no route from (a) to (d), the reservation forwarded
out interface (a) considers only the reservation on interface (c), so
no merging takes place in this case.

Braden, Zhang, et al. Expiration: September 1995 [Page 21]

Internet Draft RSVP Specification March 1995

|
Send | Reserve Receive
|
| _______
WF( *{B} ) <- FF( S1{B}, S2{5B} (a) | (c) | * {B} | (c) <- WF( *{B} )
| |________| |_______|
|
-----------------------|----------------------------------------
| _______
WF( *{3B} ) <- (b) | S2{5B} (d) | * {3B}| (d) <- WF( * {3B} )
| |_______|

Figure 9: Wildcard-Filter Reservation Example -- Partial Routing

Braden, Zhang, et al. Expiration: September 1995 [Page 22]

Internet Draft RSVP Specification March 1995

4. RSVP Functional Specification

4.1 RSVP Message Formats

All RSVP messages consist of a common header followed by a
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.

4.1.1 Common Header

0 1 2 3
+-------------+-------------+-------------+-------------+
| Vers | Type | Flags | Message Length |
+-------------+-------------+-------------+-------------+
| RSVP Checksum | |________|
-----------------------|--------------------------------------------- Object Count | ________
<- (b)
+-------------+-------------+-------------+-------------+

The common header fields are as follows:

Vers

Protocol version number. This is version 2.

Type

1 = PATH

2 = RESV

3 = PERR

4 = RERR

5 = PTEAR

6 = RTEAR

Flags

0x01 = Entry-Police

Braden, Zhang, et al. Expiration: September 1995 [Page 23]

Internet Draft RSVP Specification March 1995

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
+-------------+-------------+-------------+-------------+
| (d) Length (bytes) | S1{3B} Class | (d) <- FF( S1{3B}, S3{B} )
FF( S2{5B}, S3{B} ) C-Type | |________|
+-------------+-------------+-------------+-------------+
| | S3{B}
// (Object contents) //
| | |________|

Figure 6: Fixed-Filter Reservation Example

Figure
+-------------+-------------+-------------+-------------+

An object header has the following fields:

Length

Total length in bytes. Must always be a multiple of 4,
and at least 4.

Braden, Zhang, et al. Expiration: September 1995 [Page 24]

Internet Draft RSVP Specification March 1995

Class

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

Braden, Zhang, et al. Expiration: September 1995 [Page 25]

Internet Draft RSVP Specification March 1995

object), in a RESV message.

7 shows = 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 example Adspec containing OPWA data, in a PATH
message.

10 = TIME_VALUES

If present, contains values for the refresh period R
and the state time-to-live T (see section 4.5), to
override the default values of Dynamic-Filter reservations. R and T.

11 = ERROR_SPEC

Specifies an error, in a PERR or RERR message.

12 = CREDENTIAL

Contains user credential and/or information for
policy control and/or accounting.

13 = INTEGRITY

Contains a cryptographic data to authenticate the
originating node, and perhaps verify the contents, of
this RSVP message.

C-Type

Object type; unique within Class. Values defined in
Appendix A.

The Class and C-Type fields may be used together as a 16-bit
number to define a unique type for each object.

The
receivers downstream formats of specific object types are defined in Appendix A.

Braden, Zhang, et al. Expiration: September 1995 [Page 26]

Internet Draft RSVP Specification March 1995

4.1.3 Path Message

PATH messages carry information from interface (d) have requested two
reserved channels, but selected only one sender, S1. senders to receivers along
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
reserves min(2,3) = 2 channels that sent the message (if possible, the
address of size B on the particular interface (d), and through which it
then applies any specified filters to these channels. Since only
one sender was specified, one channel has no corresponding filter, sent).

The format of a PATH message is as shown by `?'.

Similarly, follows:

[ <INTEGRITY> ] [ <TIME_VALUES> ]

<sender descriptor list> ::= <empty > |

[ <SENDER_TSPEC> ] [ <ADVERT> ]

Each sender descriptor defines a sender, and the receivers downstream 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 interface (c) have
requested two channels data packets, the
SENDER_TSPEC object may specify the traffic flow, and selected senders S1 the
CREDENTIAL object may specify the user credentials. There may
also be an ADVERT object carrying advertising (OPWA) data.

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 S2. The two
channels might have been one channel 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).

At each node, a route must be computed independently for each
sender descriptors being forwarded. These routes, obtained
from R1 the uni/multicast routing table, generally depend upon the
(sender host address, DestAddress) pairs, and R2, or two
channels requested by one consist of them, for example.

Zhang, a list
of outgoing interfaces. Then the descriptors being forwarded
through the same outgoing interface can be packed into as few

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 18] September 1995 [Page 27]

Internet Draft RSVP Specification November 1994

|
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 March 1995

PATH messages as possible. Note that multicast routing of path
information is based on the sender address(es) from the sender
descriptors, not reserve more Dynamic-Filter channels than the
number 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
path state, which includes SENDER_TEMPLATE object and possibly
CREDENTIAL, SENDER_TSPEC, and ADVERT objects. If an error is
encountered while processing a PATH message, a PERR message is
sent to all senders implied by the SENDER_TEMPLATEs in the
sender descriptor list.

4.1.4 Resv Messages

RESV messages carry reservation requests hop-by-hop from
receivers to senders, along the reverse paths of upstream sources (three, in data flow for
the router session. The IP destination address of Figure 7).
Since there a RESV message is only one source upstream from previous hop (a),
the
first parameter unicast address of a previous-hop node, obtained from the DF message (the count of channels to
path state. The Next Hop address (in the RSVP_HOP object)
should be
reserved) was decreased to 1 in the forwarded reservations.
However, this is unnecessary, because IP address of the routers upstream will
reserve only one channel, regardless.

When a DF reservation is received, it is labeled with (incoming) interface through
which the RESV message is sent. The IP source address is an
address of the next hop (RSVP-capable) router, downstream from node that sent the
current node. Since message (if possible, the outgoing
address of the particular 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. through which it was sent).

The number N' permissible sequence 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) objects in a RESV from
the ith next-hop node.

The three examples just shown assume full routing, i.e., data
packets from S1, S2, and S3 are routed to both outgoing
interfaces. Assume the routing shown in Figure 8, in which data
packets from S1 are not forwarded to interface (d) (because message depends
upon the
mesh topology provides a shorter path for S1->R3 that does not

Zhang, reservation style specified in the STYLE object.
Currently, object types Style-WF and Style-FF of class STYLE
are defined (see Appendix A).

The RESV message format is as follows:

[ <SESSION_GROUP> ] <RSVP_HOP>

[ <INTEGRITY> ] [ <TIME_VALUES> ]

[ <CREDENTIAL> ]

<Style-WF> [ <FILTER_SPEC> ] <FLOWSPEC> |

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 19] September 1995 [Page 28]

Internet Draft RSVP Specification November 1994

traverse this node).

_______________
(a)| | (c)
( S1 ) ---------->| --------->--> |----------> ( R1, R2)
| / |
| / |
(b)| / March 1995

<Style-FF> <flow descriptor list>

<flow descriptor list> ::= <empty> | (d)
( S2,S3 ) ------->| ->----------> |----------> ( R3 )
|_______________|

Figure 8: Router Configuration

Under this assumption, Figure 9 shows Wildcard-Filter
reservations. Since there is no route from (a) to (d), the

The reservation forwarded out interface (a) considers only scope, i.e., the
reservation on interface (c), so no merging takes place in this
case.

|
Send | Reserve Receive
|
| _______
WF( *{B} ) <- (a) | (c) | * {3B}| (c) <- WF( *{B} )
| |_______|
|
-----------------------|----------------------------------------
| _______
WF( *{3B} ) <- (b) | (d) | * {B} | (d) <- WF( * {3B} )
| |_______|

Figure 9: Wildcard-Filter Reservation Example -- Partial Routing

2.5 Host Model

Before set of senders towards which a session can
particular reservation is to be created, forwarded, is determined by
matching FILTER_SPEC objects against the session socket, comprised of
DestAddress and ResvID, must path state created
from SENDER_TEMPLATE objects, considering any wildcards that
may be assigned present.

4.1.5 Error Messages

There are two types of RSVP error messages:

o PERR messages result from PATH messages and communicated to all travel towards
senders. PERR messages are routed hop-by-hop like RESV
messages; at each hop, the senders IP destination address is the
unicast address of a previous hop.

o RERR messages result from RESV messages and receivers travel hop-
by-hop towards the appropriate receivers, routed by some out-of-band mechanism. In order
to join an RSVP session, the end systems perform
reservation state. At each hop, the following
actions.

H1 A receiver joins IP destination
address is the multicast group specified unicast address of a next-hop node.
Routing is discussed below.

RSVP error messages are triggered only by

Zhang, processing of PATH
and RESV messages; errors encountered while processing error or
teardown messages must not create error messages.

[ <INTEGRITY> ] <ERROR_SPEC>

<sender descriptor list> ::= (see earlier definition)

[ <INTEGRITY> ] <ERROR_SPEC>

[ <CREDENTIAL> ] <style-specific tail>

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 20] September 1995 [Page 29]

Internet Draft RSVP Specification November 1994

DestAddress.

H2 A potential sender starts sending RSVP PATH messages to March 1995

The ERROR_SPEC specifies the DestAddress.

H3 A receiver listens for PATH messages.

H4 A receiver starts sending appropriate RESV messages,
specifying error. It includes the desired Flow Descriptors.

There are several synchronization issues.

o Suppose that a new sender starts sending data but there are
no receivers. There will be no multicast routes beyond IP address
of the
host (or beyond node that detected the first RSVP-capable router) along error, called the
path; Error Node
Address.

When a PATH or RESV message has been "packed" with multiple
sets of elementary parameters, the data will RSVP implementation should
process each set independently and return a separate error
message for each that is in error.

An error message may be dropped at duplicated and forwarded unchanged. In
general, error messages should be delivered to the first hop until
receivers(s) do appear (assuming a multicast routing protocol applications
on all the session nodes that "prunes off" or otherwise avoids unnecessary paths). (may have) contributed to this
error.

o Suppose A PERR message is forwarded to all previous hops for all
senders listed in the Sender Descriptor List.

o The node that creates a RERR message as the result of
processing a new sender starts sending PATH messages (H2)
and immediately starts sending data, and there are receivers
but no RESV messages have reached message should send the sender yet (e.g.,
because RERR message out
the interface through which the RESV arrived.

In succeeding hops, the routing of a RERR message depends
upon its PATH messages have not yet propagated to style and upon routing. In general, a RERR
message is sent out some subset of the
receiver(s)). Then outgoing interfaces
specified for multicast routing, using Error Node Address
as the initial data may arrive at receivers
without source address and DestAddress as the desired QoS.

o If destination.
(This rule is necessary to prevent packet loops; see
Section 4.3 below). Within this set of outgoing
interfaces, a receiver starts sending RESV messages (H4) before any
PATH messages have reached it (and if path state RERR message is being
used sent only to route next hop(s)
whose RESV messages), RSVP will return message(s) created the error; this in turn
depends upon the merging of flowspecs. Assume that a
reservation whose error messages
to is being reported was formed by
merging two flowspecs Q1 and Q2 from different next hops.

- If Q1 = Q2, the receiver.

The receiver may simply choose error message should be forwarded to ignore such
both next hops.

- If Q1 < Q2, the 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 message should be host system dependent.
However, Section 3.6.2 discusses forwarded
only to the next hop for Q2.

- If Q1 and Q2 are incomparable, the general requirements error message
should be forwarded to both next hops, and
presents a generic API.

Zhang, the LUB
flag should be turned on.

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 21] September 1995 [Page 30]

Internet Draft RSVP Specification November 1994

3. Functional Specification March 1995

The ERROR_SPEC and the LUB-flag should be delivered to the
receiver application. In the case of an Admission Control
error, the style-specific tail will contain the FLOWSPEC
object that failed. If the LUB-flag is off, this should
be the same as a FLOWSPEC in a RESV message sent by this
application; otherwise, they may differ.

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

There are currently 6 two types of RSVP messages: PATH, RESV, PTEAR,
RTEAR, PERR, Teardown message, PTEAR and RERR.

3.1 Message Formats

3.1.1 Path Message

0 1 2 3
+-------------+-------------+-------------+-------------+
| Vers | Type | Flags | RSVP Checksum |
+-------------+-------------+-------------+-------------+
| DestAddress |
+-------------+-------------+-------------+-------------+
| ResvID |
+-------------+-------------+-------------+-------------+
| Refresh Period |
+-------------+-------------+-------------+-------------+
| State TTL Time |
+-------------+-------------+-------------+-------------+
| Previous Hop Address |
+-------------+-------------+-------------+-------------+
| /////////////// | SD Count |
+-------------+-------------+-------------+-------------+
| Authentication Field |
// ... //
+-------------+-------------+-------------+-------------+
| Sender Descriptor List |
// ... //
+-------------+-------------+-------------+-------------+

IP Fields:

Protocol

46 RTEAR.

o PTEAR messages delete path state (which in turn may delete
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 Source Address

The
destination address is DestAddress for the session.

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 of is the host or router sending this
message.

IP Destination Address

The IP unicast address of
a previous hop.

[ <INTEGRITY> ]

<sender descriptor list> ::= (see earlier definition)

[ <INTEGRITY> ] [ <CREDENTIAL> ]

Flowspec objects in the data destination (DestAddress).

Zhang, style-specific tail of a RTEAR message

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 22] September 1995 [Page 31]

Internet Draft RSVP Specification November 1994

RSVP Fields:

Vers

Version number. This is version 1.

Type

1 = Path Message

Flags

8 = Drop

If this flag bit is on then data packets March 1995

will be
dropped when they are destined to this session
but their sender is not currently selected by
any filter. ignored and may be omitted.

If this flag bit the state being deleted was created with user credentials
from a CREDENTIAL field, then the matching PTEAR or RTEAR
message must include matching CREDENTIAL field(s).

[There is off, such data
packets will still be forwarded but without a
reservation, i.e., using problem here: tearing down path state may
implicitly delete reservation state. But a best-effort class.

RSVP Checksum

A standard TCP/UDP checksum, over the contents of the
RSVP PTEAR message with does
not have credentials for the checksum field replaced by
zero.

DestAddress, ResvID

The IP address and stream Id identifying reservation state, only for the session,
i.e.,
path state. Some argue that a CREDENTIAL may not be needed in
teardown messages, on the session socket.

Previous Hop Address

The IP address assumption that false teardown
messages can be injected only with the collusion of routers
along the interface through which data path, and in that case, the
host or colluding router last forwarded this message.

The Previous Hop Address is used to support reverse-
path forwarding of can
just as well stop delivering the RESV messages. This field is
initialized by a sender to its messages, which will have
the same effect.]

4.2 Sending RSVP Messages

RSVP messages are sent hop-by-hop between RSVP-capable routers as
"raw" IP address (see datagrams, protocol number 46. Raw IP
Source Address above) and must datagrams are
similarly intended to be updated at each
router hop as used between an end system and the PATH message
first/last hop router; however, it is forwarded.

Refresh Period

This field specifies the refresh timeout period in

Zhang, Braden, et al. Expiration: May 95 FORMFEED[Page 23]

Internet Draft also possible to encapsulate
RSVP Specification November 1994

milliseconds. See Section 3.3 below.

State TTL Time

This field specifies the time-to-live messages as UDP datagrams for soft state, end-system communication, as
described in milliseconds. It determines Appendix C. UDP encapsulation will simplify
installation of RSVP on current end systems, particularly when
firewalls are in use.

Under overload conditions, lost RSVP control messages could cause
the cleanup timeout
period; see Section 3.3 below.

SD Count

Count loss of Sender Descriptors that follow.

Authentication Field

A variable-length authentication field resource reservations. Routers should be configured
to identify
and perhaps authenticate the principal making this
reservation request. The field has the following
form:

+-------------+-------------+-------------+-------------+
| AuthLen | AuthType | |
+-------------+-------------+ +
// Authentication Info //
+-------------+-------------+-------------+-------------+

The AuthLen octet contains the integer length give a preferred class of service to RSVP packets. RSVP should
not use significant bandwidth, but the
field in fullwords, and AuthType specifies the format queueing delay for RSVP
messages needs to be controlled.

An RSVP PATH or RESV message consists of a small root segment
followed by a variable-length list of objects, which may overflow
the field. See Section 3.6.1 for currently
defined authentication field formats. If there capacity of one datagram. IP fragmentation is no
authentication information, AuthLen 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 zero, but processed at the Authentication Field will still occupy one
fullword in receiving node, with a
cumulative effect on the message.

Sender Descriptor List

A list of Sender Descriptors (see below). The order local state. No explicit reassembly is
needed.

Since RSVP messages are normally expected to be generated and sent
hop-by-hop, their MTU should be determined by the MTU of entries each
interface.

Braden, Zhang, et al. Expiration: September 1995 [Page 32]

Internet Draft RSVP Specification March 1995

[There may be rare instances in which this list does not work very
well, and in which manual configuration would not help. The
problem case is irrelevant.

Each sender must periodically send an interface connected to a PATH message containing non-RSVP cloud in
which some particular link far away has a
single Sender Descriptor describing its own data stream. These
messages are addressed smaller MTU. This would
affect only those sessions that happened to the uni-/multicast destination
address use that link.
Proper solution to this case would require MTU discovery
separately for the each interface and each session, which is a very
large amount of machinery and they are forwarded to all
receivers, following the same paths as some overhead for a data packet from rare (?) case.
Best approach seems to be to rely on IP fragmentation and
reassembly for this case.]

4.3 Avoiding RSVP Message Loops

We must ensure that the
same sender. rules for forwarding RSVP control messages
avoid looping. In steady state, PATH and RESV messages are received and processed locally
to create path state at
forwarded on each intermediate router along hop only once per refresh period. This avoids
directly looping packets, but there is still the

Zhang, Braden, et al. Expiration: May 95 FORMFEED[Page 24]

Internet Draft RSVP Specification November 1994

path.

If possibility of an error is encountered while processing
" auto-refresh" loop, clocked by the refresh period. The effect
of such a PATH message, an
RSVP error message loop is sent to all keep state active "forever", even if the sender hosts listed in end
nodes have ceased refreshing it (but the Sender Descriptor List. state will be deleted
when the receivers leave the multicast group and/or the senders
stop sending PATH messages).

In addition, error and teardown messages are distributed from senders forwarded immediately
and are therefore subject to receivers along direct looping.

PATH messages are forwarded using routes determined by the exact paths
appropriate routing protocol. For routing that is source-
dependent (e.g., some multicast routing algorithms), the data will traverse, using uni-
/multicast routing. This distribution actually takes place
hop-by-hop, allowing RSVP in
daemon must route 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 descriptor separately using the IP
source address. This is necessary to prevent loops;
see Section 3.2.

Each Sender Descriptor consists of two variable-length fields:
a sender template that defines addresses found in the format of data packets and a
corresponding Flowspec SENDER_TEMPLATE objects. This
should ensure 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 there will be zero
(but it will still occupy one fullword in the Sender
Descriptor).

The Sender template is retained no auto-refresh loops of PATH
information, even in the Path a topology with cycles.

Since PATH messages don't loop, they create path state in order to
validate filterspecs in RESV messages. Suppose that defining a
filterspec consisted of
loop-free reverse path to each sender. As a simple (value,mask) pair (Vf,Mf) result, RESV and
RTEAR messages directed to
be applied particular senders cannot loop. PERR
messages are always directed to the headers of the data packets (the actual
format particular senders and therefore
cannot loop. However, there 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) potential auto-refresh problem
for the
sender RESV, RTEAR, and RERR messages with template (Vs,Ms), RSVP can then test whether
Vf&(Mf&Ms) = Vs&(M&Ms). wildcard scope, as we now
discuss.

If not, this filterspec cannot
possibly match the data stream from this sender at any node
upstream, and the reservation topology has no loops, then auto-refresh can be rejected avoided,
even for wildcard scope, with an error
message back to the receiver.

Zhang, following rule:

A reservation request received from next hop N must not be
forwarded to N.

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 25] September 1995 [Page 33]

Internet Draft RSVP Specification November 1994

3.1.2 Resv Message March 1995

This rule is illustrated in Figure 10, which shows a transit
router with one sender and one receiver on each interface (and
assumes one next/previous hop per interface). Interfaces a and c
are both outgoing and incoming interfaces for this session. Both
receivers are making wildcard-scope reservations, in which the
RESV messages are sent from receivers forwarded to all previous hops for senders along reverse
paths established by PATH messages.

0 1 2 3
+-------------+-------------+-------------+-------------+
| Vers | Type | Flags | RSVP Checksum |
+-------------+-------------+-------------+-------------+
| DestAddress 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.

________________
a |
+-------------+-------------+-------------+-------------+ | ResvID c
( R1, S1 ) <----->| Router |<-----> ( R2, S2 )
|________________|

Send & Receive on (a) |
+-------------+-------------+-------------+-------------+ Send & Receive on (c)
| Refresh Period
WF( *{3B}) <-- (a) |
+-------------+-------------+-------------+-------------+ (c) <-- WF( *{3B})
| State TTL Time
WF( *{4B}) --> (a) |
+-------------+-------------+-------------+-------------+ (c) --> WF( *{4B})
| Next Hop Address
|
+-------------+-------------+-------------+-------------+
Reserve on (a) | RecvAddress Reserve on (c)
__________ |
+-------------+-------------+-------------+-------------+ __________
| Dynamic Reservation Count * {4B} | FD Count |
+-------------+-------------+-------------+-------------+ | Authentication Field * {3B} |
// ... //
+-------------+-------------+-------------+-------------+
|__________| | Flow Descriptor List |__________|
|
// ... //
+-------------+-------------+-------------+-------------+

The fields are the same as defined earlier for a PATH message,
except for

Figure 10: Avoiding Auto-Refresh in Non-Looping Topology

However, further effort is needed to prevent auto-refresh loops
from wildcard-scope reservations in the following:

IP Fields:

IP Source Address

The IP address presence of cycles in the node sending this message.

IP Destination Address

The IP address
topology. [TBD!!].

We treat routing of the next-hop router or host to
which this message is being sent.

RSVP Fields:

Zhang, Braden, et al. Expiration: May 95 FORMFEED[Page 26]

Internet Draft RSVP Specification November 1994

Type

2 = Resv Message

Flags

The following flag bit combinations define the
reservation style:

001xxxxx = Wildcard-Filter

010xxxxx = Fixed-Filter

011xxxxx = Dynamic-Filter

Next Hop Address

The IP address RERR messages as a special case. They are
sent with unicast addresses of next hops, but the interface through which the
last forwarded this message.

The Next Hop Address multicast
routing is used to support teardown.
This field is initialized by a receiver to its IP
address and must be updated at each router hop as the
RESV message is forwarded.

RecvAddress

The IP address of (one of the) receiver(s) that
originated this message, or one of the RESV prevent loops. As explained above, RERR
messages
that was merged to form this message.

Dynamic Reservation Count

The number of channels are forwarded to be reserved, for a
Dynamic-Filter style reservation.

If subset of the ResvStyle is Dynamic-Filter, multicast tree to
DestAddress, rooted at the node on which the error was discovered.
Since multicast routing cannot create loops, this integer
value must will prevent
loops for RERR messages.

[Open question about Figure 10: should it be constant and equal or greater than (FD
Count). possible to have
incompatible reservation styles on the two interfaces? For other ResvStyles, this field must be
zero.

FD Count

Count of Flow Descriptors in
example, if R1 requests a WF reservation and R2 requests a FF
reservation, it is logically possible to make the Flow Descriptor
List.

Flow Descriptor List

Zhang, corresponding
reservations on the two different interfaces. The current

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 27] September 1995 [Page 34]

Internet Draft RSVP Specification November 1994

A list March 1995

implementation does NOT allow this; instead, it prevents mixing of Flow Descriptors, i.e., (Filterspec,
flowspec) pairs, to define individual reservation
requests. The first entry
incompatible styles in the list may have
special meaning (see below); the order of later
entries is irrelevant.

Each Flow Descriptor has the following form:

+-------------+-------------+-------------+-------------+
| FiltSLen | FiltSType | |
+-------------+-------------+ +
// Filter Spec ... //
+-------------+-------------+-------------+-------------+
| FlowSLen | FlowSType | |
+-------------+-------------+ +
// Flow Spec ... //
+-------------+-------------+-------------+-------------+

Here FiltSLen and FlowSLen same session on a node, even if they
are one-octet fields
specifying on different interfaces.]

4.4 Local Repair

Each RSVP daemon periodically sends refreshes to its next/previous
hops. An important optimization would allow the lengths in fullwords (including local routing
protocol module to notify the
length byte) RSVP daemon of the filterspec and flowspec,
respectively, and FiltSType and FlowSType are one-
octet fields defining the corresponding field
formats. See Section 3.6.1 route changes for currently defined
formats.
particular destinations. The following specific rules hold for different reservation
styles.

o Wildcard-Filter

To obtain Wildcard-Filter service, set FD Count = 1 and
include a single Flow Descriptor whose Filterspec part is
a wild card, i.e., selects all senders. and whose
flowspec part defines RSVP daemon should use this
information to trigger an immediate refresh of state for these
destinations, using the desired flow parameters.

o Fixed-Filter

Include a list new route. This allows fast adaptation to
routing changes without the overhead of FD Count >= 1 Flow Descriptors, each
defining a sender Filterspec and a corresponding flowspec.

o Dynamic-Filter

Include max(1, FD Count) Flow Descriptors in short refresh period.

4.5 Time Parameters

For each element of state, there are two time parameters: the message.
Here
refresh period R and the FD Count time-to-live value T. R specifies the number
period between sending successive refreshes of sender

Zhang, Braden, et al. Expiration: May 95 FORMFEED[Page 28]

Internet Draft 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.

Clearly, a smaller T means increased RSVP Specification November 1994

Filterspecs that are included. overhead. If DC is the Dynamic
Reservation Count, then DC >= FD Count >= 0.

The Flowspec part of the first Flow Descriptor defines router
does not implement local repair, a smaller T improves the
desired size speed of all
adapting to routing changes. With local repair, a router can be
more relaxed about T, since the DC channels that periodic refresh becomes only a
backstop robustness mechanism.

There are reserved.
The Flowspec parts of later Flow Descriptors (if any) three possible ways for a router to determine R and T.

o Default values are
ignored.

Zhang, Braden, et al. Expiration: May 95 FORMFEED[Page 29]

Internet Draft RSVP Specification November 1994

3.1.3 Error Messages

There configured in the router. Current
defaults are two types 30 seconds for T and R.

o A router may adjust the value of RSVP error messages: PERR messages
result from T dynamically to keep a
constant total overhead due to refresh traffic; as more
sessions appear, the period would be lengthened. In this
case, R = T could be used.

o R and T can be specified by the end systems. For this
purpose, PATH messages and travel towards senders, while
RERR messages result from RESV messages and travel towards
receivers. RSVP error may contain the optional
TIM_VALUES object. When messages are triggered only by
processing of PATH merged and RESV messages; errors encountered while
processing error or teardown messages must not create error
messages.

A PERR message forwarded to
the next hop, R should be the minimum R that has been
received, and T should be the following form:

The fields are maximum T that has been
received. Thus, the same as in a PATH message, defined earlier,
except for largest T determines how long state is
retained, and the following:

RSVP Fields:

RSVPType

3 = PERR message

Error Code

Zhang, smallest R determines the responsiveness of

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 30] September 1995 [Page 35]

Internet Draft RSVP Specification November 1994

A one-octet error description.

01 = Insufficient memory

02 = Count Wrong

The SD Count field does not match length of
message.

Error Index

Position of Sender Descriptor that caused the error
within
Sender Descriptor List. An integer between zero
and SD Count - 1.

Error Value

(Unused)

A RERR message has March 1995

RSVP to route changes. In the following form:

Zhang, first hop, they are expected
to be equal. The RSVP API might allow an application to
override the default value for a particular session.

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 31] September 1995 [Page 36]

Internet Draft RSVP Specification November 1994

0 1 2 3
+-------------+-------------+-------------+-------------+
| Vers | Type | Flags | March 1995

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).

4.6.1 Application/RSVP Interface

This section describes a generic interface between an
application and an RSVP control process. The fields are details of a real
interface may be operating-system dependent; the same following can
only suggest the basic functions to be performed. Some of
these calls cause information to be returned asynchronously.

o Register

Call: REGISTER( DestAddress , DestPort

[ , SESSION_object ] , SND_flag , RCV_flag

[ , Source_Address ] [ , Source_Port ]

[ , Sender_Template ] [ , Sender_Tspec ]

[ , Data_TTL ] [ , UserCredential ]

[ , Upcall_Proc_addr ] ) -> Session-id

This call initiates RSVP processing for a session, defined
by DestAddress together with the TCP/UDP port number
DestPort. If successful, the REGISTER call returns
immediately with a local session identifier Session-id,
which may be used in subsequent calls.

The SESSION_object parameter is included as an escape
mechanism to support some more general definition of the
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 RESV message, defined earlier,
except for SESSION
object.

SND_flag should be set true if the following:

RSVP Fields:

RSVPType

4 = RERR message

Error Code

A one-octet error description.

DEFINE THESE VALUES IN AN APPENDIX??

01 = Insufficient memory

02 = Count Wrong host will send data,
and RCV_flag should be set true if the host will receive
data. Setting neither true is an error. The FD Count field does not match length of
message.

Zhang, optional
parameters Source_Address, Source_Port, Sender_Template,

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 32] September 1995 [Page 37]

Internet Draft RSVP Specification November 1994

03 = No path information for this Resv

04 = No Sender information March 1995

Sender_Tspec, and Data_TTL are all concerned with a data
source, and they will be ignored unless SND_flag is true.

If SND_FLAG is true, a successful REGISTER call will cause
RSVP to begin sending PATH messages for this Resv

There session using
these parameters, which are interpreted as follows:

- Source_Address

This is path information, but it does not
include the sender specified in any address of the
Filterspecs listed in interface from which the Resv messager.

05 = Incorrect Dynamic Reservation Count

Dynamic Reservation Count
data will be sent. If it is zero or less
than FD Count.

06 = Filterspec error

07 = Flowspec syntax error

08 = Flowspec value error

Internal inconsistency of values.

[What should omitted, a default
interface will be done with Flowspec Feature
Not Supported?]

09 = Resources unavailable

[Sub-reasons? Depend upon traffic control
and admission control algorithms?]

Error Index

Position of Flow Descriptor that caused used.

- Source_Port

This is the error
within
Flow Descriptor List. An integer between zero UDP/TCP port from which the data will be
sent. If it is omitted or zero, the port is "wild"
and FD Count - 1.

Error Value

Specific cause can match any port in a FILTERSPEC.

- Sender_Template

This parameter is included as an escape mechanism to
support a more general definition of the error described by the Error
Code.

DEFINE THESE VALUES IN AN APPENDIX??

Zhang, Braden, et al. Expiration: May 95 FORMFEED[Page 33]

Internet Draft RSVP Specification November 1994

An error message sender
("generalized source port"). Normally this parameter
may be duplicated and forwarded unchanged.
Since PATH and RESV messages may omitted; if it is supplied, it should be merged, an error condition
must be disseminated
appropriately formatted representation of a
SENDER_TEMPLATE object.

- Sender_Tspec

This parameter is a Tspec describing the traffic flow
to all RSVP client applications whose
requests be sent. It 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 included 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 prevent over-
reservation on the same style flags as initial hops.

- Data_TTL

This is the RESV message (non-default) IP Time-To-Live parameter
that caused the error.

To ease implementation, is being supplied on the error message formats are chosen data packets. It is
needed to
match the formats of the ensure that Path messages whose processing caused the
error. In particular, do not have a PATH or RESV message that encounters
scope larger than multicast data packets.

Finally, Upcall_Proc_addr is the address of an upcall
procedure to receive asynchronous error can be simply converted or event
notification; see below.

o Reserve

Call: RESERVE( session-id, style, style-dependent-parms )

Braden, Zhang, et al. Expiration: September 1995 [Page 38]

Internet Draft RSVP Specification March 1995

A receiver uses this call to make a resource reservation
for the corresponding error
message by overwriting session registered as `session-id'. The style
parameter indicates the reservation style. The rest of
the parameters depend upon the Type style, but generally these
will include appropriate flowspecs and filter specs.

The first RESERVE call will initiate the Refresh Period fields. periodic
transmission of RESV messages. A PERR message is forwarded later RESERVE call may
be given to all previous hops for all
senders listed in modify the Sender Descriptor List. The routing parameters of a
RERR message is more complex.

o An error in a filterspec should be detected at the first
RSVP hop from the receiver application, normally within earlier call (but
note that changing the receiver host. However, an error caused by a
flowspec, normally an reservations may result in
admission control failure, may be
detected somewhere along the path(s) to depending upon the sender(s).

o style).

The router that creates RESERVE call returns immediately. Following a RERR message as RESERVE
call, an asynchronous ERROR/EVENT upcall may occur at any
time.

o Release

Call: RELEASE( session-id )

This call will terminate RSVP state for the result of
processing a RESV message should session
specified by session-id. It may send the RERR message out
the interface through which the RESV arrived. appropriate teardown
messages and will cease sending refreshes for this
session-id.

o In succeeding hops, the routing of a RERR message depends
upon its style. In general, a RERR message is sent on a
pruned version of Error/Event Upcalls

Call: <Upcall_Proc> (session-id, Info_type, List_count

[ ,Error_code ,Error_value ,LUB-flag ]

[ ,Filter_spec_list ] [ ,Flowspec_list ]

[ ,Advert_list ] )

Here "Upcall_Proc" represents the multicast distribution tree for upcall procedure whose
address was supplied in the
session; those branches that do not have reservations for REGISTER call.

This upcall may occur asynchronously at any of the specified senders are pruned off.

A DF-style or WF-style RERR message is forwarded on all
outgoing interfaces for which there is already time after a
REGISTER call and before a
reservation of RELEASE call, to indicate an
error or an event. Currently there are three upcall
types, distinguished by the corresponding style. Info_type parameter:

1. Info_type = Path Event

A FF-style RERR message is forwarded on all outgoing
interfaces for which there is already a FF-style
reservation for Path Event upcall indicates the sender (filterspec) corresponding receipt of a PATH
message, indicating to the error.

At the end host, RSVP delivers a copy of every relevant error

Zhang, application that there is

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 34] September 1995 [Page 39]

Internet Draft RSVP Specification November 1994 March 1995

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 its local which this application clients. It examines contributed.
The Error_code parameter will define the set
of RSVP requests that local clients have made through error, and
Error_value may supply some additional (perhaps
system-specific) data on the API, error.

`List_count' will be 1, and notifies every client Filter_spec_list and
Flowspec_list will contain one FILTER_SPEC and one
FLOWSPEC object. These objects are taken from the
RESV message that contributed to caused the error
message. A match is required between (unless the session, filters
(senders), and reservation styles of LUB-
flag is on, in which case FLOWSPEC may differ).

Although RSVP messages indicating path events or errors
may be received periodically, the error message and API should make the
corresponding state in asynchronous upcall to the latest API requests. A particular
notification should include application only
on the first occurrence, or when the information (e.g.,
filters) relevant to that application.

3.1.4 Teardown Messages

There are two types of RSVP Teardown message, PTEAR and RTEAR.
A PTEAR message tears down path state and travels towards all
receivers downstream from its point of initiation. A RTEAR
message tears down reservation state be
reported changes.

4.6.2 RSVP/Traffic Control Interface

In each router and travels towards all
senders upstream from its point of initiation.

A PTEAR message has the same format as host, enhanced QoS is achieved by a PATH message, except
that in group of
inter-related traffic control functions: a PTEAR message:

o Type field = 5

o Refresh Period packet classifier,

Braden, Zhang, et al. Expiration: September 1995 [Page 40]

Internet Draft RSVP Specification March 1995

an admission control module, and State TTL Time fields are ignored.

A RTEAR message has the same format as a RESV message, except
that in packet scheduler. This
section describes a RTEAR message:

o Type field generic RSVP interface to traffic control.

1. Make a Reservation

Call: Rhandle = 6

o Refresh Period and State TTL Time fields are ignored.

Any TC_AddFlowspec( Flowspec, Police_Flag

[ , Sender_Tspec]

[ , SD_rank , SD_end_flag ] )

This call passes a Flowspec components of Flow Descriptors in defining a RTEAR or PTEAR
message are ignored.

Teardown messages are processed in desired QoS to
admission control. It may also pass Sender_Tspec, the following way.

o PTEAR

Processing
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 PTEAR message member
of a session group. SD_rank is straightforward. For the rank value from the
SESSION_GROUP object. The call is made with each
sender S in of the message,
sessions in the node removes path state for S group, and also deletes all related reservations. Finally, the
node forwards SD_end_flag is set true for the original PTEAR message to all outgoing
interfaces through which data packets from some S in
last one.

This call returns an error code if Flowspec is malformed
or if the
packet would be routed. That is, PTEAR forwarding rules requested resources are unavailable. Otherwise,
it establishes a new reservation channel corresponding to
Rhandle. It returns the same as those opaque number Rhandle for PATH messages.

o RTEAR

Zhang,
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

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 35] September 1995 [Page 41]

Internet Draft RSVP Specification November 1994

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, March 1995

existing filter with no filter (i.e., delete the node checks 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 any, for S on
OI.
reservation. If there new_Flowspec is a reservation and included, it is passed to
Admission Control; if this reservation it is
shared among more than one next hop, then rejected, the only action current flowspec
is to remove NH from the list of next hops sharing this
reservation. left in force. If there new_Flowspec is only a single next hop, then omitted, the
reservation is deleted. Finally, the node forwards 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
original RTEAR message 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 incoming interfaces existing classifier and/or packet scheduler
state for
senders listed in a specified interface.

4.6.3 RSVP/Routing Interface

An RSVP implementation needs the message. That is, RTEAR forwarding
rules are following support from the same as those for RESV messages.

3.2 Avoiding Message Loops

RSVP routes its control messages,
packet forwarding and every routing procedure must
avoid looping packets. The merging mechanism of the node.

o Promiscuous receive mode for RSVP messages delays
forwarding at each node

Any datagram received for up IP protocol 46 is to one refresh period. This may
avoid high-speed loop, but there can still be "slow" loops,
clocked by the refresh period; diverted
to the effect RSVP program for processing, without being
forwarded. The identity of such slow loops the interface on which it is
received should also be available to
keep state active forever, even if the end nodes have ceased
refreshing it. RSVP uses the following rules daemon.

o Route discovery

Braden, Zhang, et al. Expiration: September 1995 [Page 42]

Internet Draft RSVP Specification March 1995

RSVP must be able to prevent looping
messages.

L1: When 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 message is received through
that a particular
incoming interface F, the message specified route has changed.

New_Ucast_Route( DestAddress ) -> new_OutInterface

New_Mcast_Route( SrcAddress, DestAddress )

-> new_OutInterface_list

o Outgoing Link Specification

RSVP must not be forwarded
out F as an able to force a (multicast) datagram to be
sent on a specific outgoing interface. This implies that RSVP
must keep track of virtual link, bypassing the interface through which each
message
normal routing mechanism. A virtual link may be a real
outgoing link or a multicast tunnel. Outgoing link
specification is received, to avoid forwarding it out that
interface. Note that, although necessary because RSVP distinguishes
incoming from may send different
versions of outgoing PATH messages on different
interfaces, in many cases for the same physical interface will play both roles.

L2: Upon receipt of a PATH message in particular, a route source and destination addresses,
and to avoid loops.

o Discover Interface List

RSVP must be computed for each able to learn what real and virtual
interfaces exist.

Braden, Zhang, et al. Expiration: September 1995 [Page 43]

Internet Draft RSVP Specification March 1995

5. Message Processing Rules

This generic description of its sender Flow
Descriptors. These routes, obtained from the
uni/multicast routing table, generally depend upon RSVP operation assumes the
(sender host address, DestAddress) pairs. following data
structures. An actual implementation may use additional or different
structures to optimize processing.

o PSB -- Path State Block

Each route
consists of PSB holds path state for a list of outgoing interfaces; these lists
(with the incoming interfaces deleted particular (session, sender)
pair, defined by rule L1) SESSION and SENDER_TEMPLATE objects,
respectively. PSB contents include a PHOP object and possibly
SENDER_TSPEC, CREDENTIAL, and/or ADVERT objects from PATH
messages.

o RSB -- Reservation State Block

RSB's are used to create merged hold reservation state. Each RSB holds
reservation state for the 4-tuple: (session, next hop, style,
filterspec), defined in SESSION, NHOP (i.e., RSVP_HOP), STYLE,
and FILTER_SPEC objects, respectively. We assume that RSB
contents include the outgoing interface OI that is implied by
NHOP. RSB contents also include a FLOWSPEC object and may
include a CERTIFICATE object.

MESSAGE ARRIVES

Verify version number, checksum, and length fields of common header,
and discard message if it fails.

Further processing depends upon message type.

PATH messages to be forwarded
through MESSAGE ARRIVES

Start with the outgoing interfaces.

Assuming that multicast routing Refresh_Needed flag off.

Each sender descriptor object sequence in the message defines a
sender. Process each sender as follows.

1. If there is free of loops, a CREDENTIAL object, verify it; if it is
unacceptable, build and send a PERR message, drop the PATH messages
cannot loop even in
message, and return.

2. If there is no path state block (PSB) for the (session,
sender) pair then:

o Create a topology with cycles.

Zhang, new PSB.

o Set a cleanup timer for the PSB. If this is the first

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 36] September 1995 [Page 44]

Internet Draft RSVP Specification November 1994

Since PATH messages don't loop, they create path state defining March 1995

PSB for the session, set a
loop-free path to each sender. Similarly, RESV messages directed
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 refresh timer for the
session.

o Copy PHOP into the PSB. Copy into the PSB any of the
following three rules objects that are needed for this purpose.

L3: Each RESV message carries a receiver address present in the
RecvAddress field. When message:
CREDENTIAL, SENDER_TSPEC, and/or ADVERT. Copy the choice of address to place
EntryPolice flag from the common header into the PSB.

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.

3. Otherwise (there is a merged RESV matching PSB):

o If CREDENTIAL differs between message and PSB, verify
new CREDENTIAL. If it is otherwise arbitrary, RSVP
must use acceptable, copy it into
PSB. Otherwise, build and send a PERR message for
"Bad Credential", drop the PATH message, and return.

o Restart cleanup timer.

o Update the PSB with values from the message, as
follows. Copy the ADVERT object, if any, into the
PSB. Copy the EntryPolice flag into the PSB.

If the values of PHOP or SEND_TSPEC differ between the
message and the PSB, copy the new values into the IP address that is numerically largest.

L4: When PSB
and turn on the Refresh_Needed flag. If SEND_TSPEC
has changed, reservations matching S may also change;
this may be deferred until a RESV message is received, refresh arrives.

o Call the Reverse Path
Forwarding rule is applied to appropriate route discovery routine and
compare the receiver address in route mask with the message; that is, ROUTE_MASK value
already in the message must be discarded
unless it arrives PSB; if a new bit (interface) has been
added, turn on the interface that Refresh_Needed flag. Store new
ROUTE_MASK in the PSB.

4. If the Refresh_Needed flag is now set, execute the preferred
route to PATH
REFRESH event sequence (below).

PATH TEAR MESSAGE ARRIVES

o If there is no path state for this destination, drop the receiver.

L5: A RESV
message whose RecvAddress matches one of the IP
addresses and return.

o Forward a copy of the local node must be discarded without
processing.

Figure 10 illustrates PTEAR message using the effect of same rules as

Braden, Zhang, et al. Expiration: September 1995 [Page 45]

Internet Draft RSVP Specification March 1995

for a PATH message (see PATH REFRESH).

o Each sender descriptor in the rule L1 applied to RESV
messages. It shows PTEAR message contains a transit router,
SENDER_TEMPLATE object defines a sender S; process it as
follows.

1. Locate the PSB for the pair: (session, S). If none
exists, continue with one next sender descriptor.

2. Examine the RSB's for this session and one
receiver on each side; interfaces delete any
reservation state associated with sender S, depending
upon the reservation style. For example:

Delete a and c therefore WF reservation for which S is the only
sender.

Delete an FF reservation for S.

3. Delete the PSB.

PATH ERROR MESSAGE ARRIVES

o If there are both
outgoing interfaces no existing PSB's for SESSION then drop the
PERR message and physical previous hops. Both receivers
are making a Wildcard-Filter style reservation, in which return.

o Look up the RESV PSB for (session, sender); sender is defined by
SENDER_TEMPLATE. If no PSB is found, drop PERR message and
return.

o If PHOP in PSB is local API, deliver error to be forwarded to all previous hops for senders application
via an upcall:

Call: <Upcall_Proc>( session-id, Path Error, 1,
Error_code, Error_value, 0,
SENDER_TEMPLATE, NULL, NULL)

Note that CREDENTIAL, SENDER_TSPEC, and ADVERT objects in
the
group, with the exception message is ignored.

Otherwise (PHOP is not local API), forward a copy of the interface through which it
arrived.

Zhang,
PERR message to the PHOP node.

RESV MESSAGE ARRIVES

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 37] September 1995 [Page 46]

Internet Draft RSVP Specification November 1994

________________
a | | c
( R1, S1 ) <----->| Router |<-----> ( R2, S2 )
|________________|

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} |
|__________| | |__________|
|

Figure 10: Example: Rule (1) for Preventing Loops.

The loop-suppression rules for March 1995

A RESV messages also prevent looping
of RTEAR messages. Note that RTEAR messages are otherwise subject
to fast loops, since they are not delayed by a refresh timeout
period.

PERR messages are routed upstream by message arrives through outgoing interface OI.

o Check the same rules used for FF
and DF RESV messages (there is SESSION object.

If there are no equivalent of wildcard-filter existing PSB's for routing SESSION then build and
send a PERR message). Similarly, RERR messages are routed
by message (as described later) specifying "No
Path Information", drop the rules for PATH messages. For reasons explained above, no
special loop-suppression rules are required in either case.

3.3 Soft State Management

The RSVP state associated with a session in a particular node is
divided into atomic elements that are created, refreshed, RESV message, and return.
However, do not send the RERR message if the style has
wildcard reservation scope and
timed out independently. The atomicity this is determined by not the
requirement that any sender or receiver may enter or leave
host itself.

o Check the STYLE object.

If style in the message conflicts with the style of any
reservation for this session at in place on any time, interface,
reject the RESV message by building and its state should be created sending a RERR
message specifying "Bad Style", drop the RESV message, and timed out
independently.

Management
return.

o Check the CREDENTIAL object.

Verify the CREDENTIAL field (if any) to check permission to
create a reservation. [This check may also involve the
CREDENTIAL fields from the PSB's in the scope of RSVP this
reservation; in that case, it would better fit below in
processing the individual flow descriptors.]

o Check for path state is complex because

If there is not generally are no PSB's matching the scope of this
reservation, build and send a one-to-one correspondence between state carried in RSVP control
messages RERR message specifying "No
Sender Information", drop the RESV message, and return.

o Make reservations

Process the resulting state in nodes. Due style-specific tail sequence.

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 merging, indicate
wildcard scope.

1. Find or create a
single message contain state referring to multiple stored
elements. Conversely, due to reservation sharing, a single stored state element may depend upon (typically, block (RSB) for the maximum of) state

Zhang,
4-tuple: (SESSION, NHOP, style, FILTERSPEC).

2. Start or restart the cleanout timer on the RSB.

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 38] September 1995 [Page 47]

Internet Draft RSVP Specification November 1994

values received in multiple control messages.

3.3.1 Time Parameters

For each element, there March 1995

3. Start a refresh timer for this session if none was
started.

4. If the RSB existed and if FLOWSPEC and the
SENDER_TSPEC objects are two time parameters controlling unchanged, drop the RESV
message and return.

5. Compute Sender_Tspec as the
maintenance maximum over the
SENDER_TSPEC objects of soft state: the refresh period R and PSB's within the TTL
(time-to-live) value T. R specifies scope of
the period between
successive refresh messages over reservation.

6. Set Police_flag on if any PSB's in 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
merged and forwarded to scope have the next hop, R should be
EntryPolice flag on, or if the minimum R
that has been received, style is WF and T should be there
is more than one PSB in the scope, otherwise off.

7. Computer K_Flowspec, the effective kernel flowspec, as
the maximum T that has
been received. Thus, of the largest T determines how long state FLOWSPEC values in all RSB's for
the same (SESSION, OI, FILTERSPEC) triple. Similarly,
the kernel filter spec K_filter is retained, 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 smallest R determines RESV
message, and return. Otherwise, record the responsiveness
of RSVP to route changes. In kernel
handle K_handle returned by the first hop, they are expected call in the RSB(s).
Then call:

TC_AddFilter( K_handle, K_Filter)

to be equal. The RSVP API should set the filter, drop the RESV message and return.

/item However, if there was a configurable default
value, which can be overridden by an application for 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
particular session.

To avoid gaps in user service due to lost RSVP messages, RSVP
should be forgiving about missing refresh messages. A node
should not discard an RERR message
specifying "Admission control failed". In any case,
drop the RESV message and return.

Braden, Zhang, et al. Expiration: September 1995 [Page 48]

Internet Draft RSVP state element until K * Tmax has
elapsed without Specification March 1995

If processing a refresh message, where Tmax RESV message finds an error, a RERR message is the maximum
created containing flow descriptor and an ERRORS object. The
Error Node field of the T values it has received. K is some small integer; K-1
successive messages may be lost before state is deleted.
Currently K = 3 ERRORS object (see Appendix A) is suggested.

Let X indicate a particular message type (either "Path" or
"Resv") set to
the IP address of OI, and a particular session. Then each X the message from
node a is sent unicast to node b carries refresh period Rab and TTL time Tab. NHOP.

created

RESV TEAR MESSAGE ARRIVES

A RTEAR message arrives on outgoing interface OI.

o As X messages arrive at node b, If there are no existing PSB's for SESSION then drop the node computes
RTEAR message and
saves both return.

o Process the min over style-specific tail sequence to tear down
reservations.

For FF style, execute the Rab values (min(Rab)) and following steps for each b flow
descriptor, i.e., each (FLOWSPEC, FILTERSPEC) pair. For WF
style execute the
max over following once, using some internal
placeholder "WILD_FILTER" for FILTERSPEC to indicate
wildcard scope.

1. Find matching RSB(s) for the Tab values (max(Tab)) from these messages.

o The node uses K * max(Tab) as its cleanup timeout
interval.

o The node uses min(Rab's) as 4-tuple: (SESSION, NHOP,
style, FILTERSPEC). If no RSB is found, continue with
next flow descriptor, if any.

2. Delete the refresh period.

o Each refresh message forwarded by node b 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 node c has Tbc
= max(Tab) and Rbc = min(Rab)

o A node may impose an upper bound Tmax delete the reservation. Then build and forward a lower bound
Rmin, set by configuration information,
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 enforce: Rmin
<= R <= T <= Tmax.

Zhang, call the kernel
interface module:

TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec)

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 39] September 1995 [Page 49]

Internet Draft RSVP Specification November 1994

The receiver should be conservative about reacting March 1995

to certain
error messages. For example, during a route change a receiver
may get back "No Path" error messages until Path messages have
propagated along update the new route.

3.3.2 Teardown

Teardown messages, like other RSVP messages, are sent as
datagrams reservation, and may 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 lost (although a QoS is used that should
minimize M.

o Determine the chances of congestive loss set of RSVP messages). To
increase RSBs matching the reliability triple: (SESSION,
style, FILTERSPEC). If no RSB is found, drop RERR message
and return.

Recompute the maximum over the FLOWSPEC objects of teardown, Q copies this set
of any given
teardown message can be sent. Note that if RSB's. If the iteration count
Q LUB was used in this computation, turn on initiating teardown messages is > 1, then
the state cannot
actually be deleted until Q teardowns have been sent. The
state would be placed LUB-flag in a "moribund" status meanwhile.

The appropriate value of Q is an engineering issue. Q = 1
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, received RESV message.

o Delete from the router that
failed to receive a teardown message will time out its state set of RSVs any whose OI does not appear in
the bit mask M and initiate a new teardown message beyond whose NHOP is not the loss point.
Assuming that RSVP local API. If
none remain, drop RERR message loss probability is small (but non-
zero), and return.

For each PSB in the longest time to delete state will seldom exceed one
state timeout time K*Tab.

Here resulting set, do the following step.

o If NHOP in PSB is local API, deliver error to application
via an example. upcall:

Call: <Upcall_Proc>( session-id, Resv Error, 1,
Error_code, Error_value, LUB-flag,
FILTER_SPEC, FLOWSPEC, NULL)

Here G1, G2, G3, and G4 are routers
between a sender S and a receiver R. S initiates a PTEAR
message (denoted by "PT"), but this message LUB-flag is lost between
routers G2 and G3. Since G2 has deleted its state for S, G2
will cease refreshing G3 (though G3 taken from the received packet, as
possibly modified above.

Otherwise (NHOP is still refreshing G4,
etc.)

PT PT PT
S ---> G1 ---> G2 -->x G3 G4 R

After a time K*Tab, G3's state will time out, and G3 will
initiate not local API), forward a teardown for S path state:

PT PT
G3 ----> G4 ----> R

If some hop copy of this chain is lost, there will again be state
timeout the
RERR message to continue the teardown. PHOP node.

PATH REFRESH

This process should
terminate in sequence may be entered by either the expiration of the path
refresh timer for a few timeout periods.

Zhang, 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

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 40] September 1995 [Page 50]

Internet Draft RSVP Specification November 1994

3.3.3 Local Repair

To accommodate merging, RSVP uses hop-by-hop refreshing of
state, where each node sends refreshes to its next/previous
hops periodically. However, as an optimization, local events
could be used to trigger the RSVP module to March 1995

and 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 it to trigger an immediate refresh of
state for these destinations along V. To build the new route. This would
allow fast adaptation to routing changes without message, consider each PSB whose
ROUTE_MASK includes V, and do the overhead
of a short refresh period.

3.4 Sending RSVP Messages

Under overload conditions, lost RSVP control messages could cause following:

o Pass the loss of resource reservations. It recommended that routers be
configured ADVERT and SENDER_TSPEC objects present in the PSB to give
the kernel call TC_Advertise, and get back a preferred class of service to RSVP packets.
RSVP should not use significant bandwidth, but modified ADVERT
object. Pack this modified object into the delay of RSVP
packets needs to be controlled.

An RSVP PATH or RESV message consists of a small root segment (24
or 28 bytes) followed by being
built.

o Create a list of descriptors. The descriptors
are bulky sender descriptor sequence containing the
SENDER_TEMPLATE, CREDENTIAL, and there could be a large number of them, resulting SENDER_TSPEC objects, if
present in
potentially very large messages. IP fragmentation is inadvisable,
since it the PSB. Pack the sender descriptor into the PATH
message being built.

o If the PSB has bad error characteristics. Instead, RSVP-level
fragmentation should be used. That is, a the EntryPolice flag on and if interface V is not
capable of policing, turn the EntryPolice flag on in the PATH
message with a long list being built.

o If the maximum size of descriptors will the PATH message is reached, send the
packet out interface V and start packing a new one.

RESV REFRESH

This sequence may be divided into segments that will fit into
individual datagrams, each carrying entered by either the same root fields. Each expiration of
these messages will be processed at the receiving node, with
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
cumulative effect on given PHOP are then
packed into the local state. No explicit reassembly is
needed. same message(s) and sent to that PHOP. The largest RSVP message logic is 556 bytes.

3.5 Automatic Tunneling

It
somewhat different depending upon whether the scope of the
reservations is impractical wildcard or not (they may not be mixed).

For each PSB that does not correspond to deploy RSVP (or any protocol) at the same
moment throughout API, do the following.

o Compute (FLOWSPEC, FILTER_SPEC) Pair

Select each RSB in whose reservation scope the Internet, PSB falls, 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"
compute the maximum over the FLOWSPEC objects of non-RSVP routers.

RSVP will automatically tunnel through such a non-RSVP cloud.
Both RSVP this set of
RSB's. Also, select an appropriate FILTER_SPEC. The scope
depends upon the style and non-RSVP routers forward PATH messages towards the
destination address using their local uni-/multicast routing
table. Therefore, filter spec of the routing RSB:

1. WF: Select every RSB whose OI matches a bit in the
ROUTE_MASK of Path messages will be

Zhang, 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

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 41] September 1995 [Page 51]

Internet Draft RSVP Specification November 1994

unaffected by non-RSVP routers in March 1995

consider wildcards.

In this case, FILTER_SPEC is taken from any of the path. When matching
RSB's. [?? Need to either 'merge' filter specs, which
probably means to remove gratuitous wildcards??]

This computation also yields a PATH 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
traverses a non-RSVP cloud,
being built for destination PHOP (from the copies that emerge will carry as a
Previous Hop address PSB). When the IP address
packet fills, or upon completion of all PSB's with the last RSVP-capable
router before entering same
PHOP, set the cloud. This will cause effectively
construct a tunnel through NHOP address in the cloud for RESV messages, which will
be forwarded directly message to the next RSVP-capable router on interface
address and send the
path(s) back towards packet out that interface to the source.

This automatic tunneling capability of PHOP
address.

Braden, Zhang, et al. Expiration: September 1995 [Page 52]

Internet Draft RSVP has a cost: a PATH
message must carry Specification March 1995

appendix
6. Object Type Definitions

C-types are defined for the session DestAddress two Internet address families IPv4 and
IP6. To accomodate other address families, additional C-types could
easily be defined. These definitions are contained as its IP an Appendix to
ease updating.

6.1 SESSION Class

Currently, SESSION objects contain the pair: (DestAddress,
DestPort), where DestAddress is the data destination
address; it cannot address and
DestPort is the UDP/TCP destination port. Other SESSION C-Types
could be addressed hop-by-hop. As a result, each
RSVP router must have a small change defined in its multicast forwarding
path the future to recognize 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 |
+-------------+-------------+-------------+-------------+

Braden, Zhang, et al. Expiration: September 1995 [Page 53]

Internet Draft RSVP messages (by Specification March 1995

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 |
+-------------+-------------+-------------+-------------+

Braden, Zhang, et al. Expiration: September 1995 [Page 54]

Internet Draft RSVP Specification March 1995

6.3 RSVP_HOP Class

o IPv4 RSVP_HOP object: Class = 3, C-Type = 1

+-------------+-------------+-------------+-------------+
| IPv4 Next/Previous Hop Address |
+-------------+-------------+-------------+-------------+

Braden, Zhang, et al. Expiration: September 1995 [Page 55]

Internet Draft RSVP Specification March 1995

o IP6 RSVP_HOP object: Class = 3, C-Type = 129

+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 Next/Previous Hop Address +
| |
+ +
| |
+-------------+-------------+-------------+-------------+

This object provides 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
can carry information for a list address of senders, and since multicast
routing depends in general upon the sender, it is not possible to
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, interface through 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
unable to perform resource reservation. In
the last RSVP-knowledgeable hop forwarded 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

3.6.1 Reservation Parameters

All variable-length message.

Braden, Zhang, et al. Expiration: September 1995 [Page 56]

Internet Draft RSVP parameters use the same general
format. They begin with a length octet followed by a type
octet, and occupy an integral number of fullwords. Specification March 1995

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 length
octet specifies the total length count of the parameter elements in fullwords
or zero to indicate no parameter. An RSVP implementation can
store and pass such parameters as opaque objects.

o Flowspec Format

Flowspec type 1 is specific to the CSZ packet scheduler
[CSZ92]. It has variable-length object list
that follows. See the following format:

Zhang, RESV message format definition
earlier.

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 42] September 1995 [Page 57]

Internet Draft RSVP Specification November 1994

+-----------+-----------+-----------+-----------+
| FlowSLen=6|FlowSType=1| VFoffset | March 1995

6.5 Flowspec Class

o CSZ FLOWSPEC object: Class = 5, C-Type = 1

+-----------+-----------+-----------+-----------+
| QoS Type (Guaranteed, Predictive, ...) Service Code |
+-----------+-----------+-----------+-----------+
| Max end-to-end delay (ms) b: Token Bucket Depth (bits) |
+-----------+-----------+-----------+-----------+
| r: Average data rate (bits/ms) (bits/sec) |
+-----------+-----------+-----------+-----------+
| Token Bucket Depth (bits) d: Max end-to-end delay (ms) |
+-----------+-----------+-----------+-----------+
| Global Share Handle (For Future Use) |
+-----------+-----------+-----------+-----------+

Flowspec format 2

QoS Service Code

Integer value defining what service is being requested.
The values currently defined in RFC-1363 [Partridge92].

o Filterspec Format

For compactness and simplicity of processing, for this version
of code are:

1 = Guaranteed Service

The Tspec is (b, r), while 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 Rspec is (r). (d)
is ignored.

2 = Bounded-Delay Predictive Service

The Tspec is (b, r), while the following
format:

+-----------+-----------+-----------+-----------+ Rspec is (d).

Braden, Zhang, et al. Expiration: September 1995 [Page 58]

Internet Draft RSVP Specification March 1995

6.6 FILTER_SPEC Class

o IPv4/UDP FILTER_SPEC object: Class = 6, C-Type = 1

+-------------+-------------+-------------+-------------+
| FiltSLen |FiltSType=1| VFoffset IPv4 SrcAddress (4 bytes) |
+-----------+-----------+-----------+-----------+
+-------------+-------------+-------------+-------------+
| Sender IP Address Protocol Id |
+-----------+-----------+-----------+-----------+ --- ////// | V: VF Value Part SrcPort | Nf
/ / octets
/ /
+-----------+-----------+-----------+-----------+ ---
+-------------+-------------+-------------+-------------+

o IP6/UDP FILTER_SPEC object: Class = 6, C-Type = 129

+-------------+-------------+-------------+-------------+
| M: VF Mask Part | Nf
/ / octets
/ /
+-----------+-----------+-----------+-----------+ ---

The value M and the mask V each have length:

Nf = (4*FiltSLen - 8)/2 octets.

M
+ +
| |
+ IP6 SrcAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | ////// | SrcPort |
+-------------+-------------+-------------+-------------+

SrcAddress is an IP address for a host, and V define SrcPort is a filter that uses UDP/TCP
source port, defining a mask-and-match
algorithm applied to the packet at VFoffset octets from
the beginning of the IP header. sender.

Braden, Zhang, et al. Expiration: September 1995 [Page 59]

Internet Draft RSVP Specification March 1995

6.7 SENDER_TEMPLATE Class

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 minimum length most common form of

Zhang, Tspec is a token bucket.

o Token Bucket SENDER_TSPEC object: Class = 8, C-Type = 1

+-----------+-----------+-----------+-----------+
| b: Token Bucket Depth (bits) |
+-----------+-----------+-----------+-----------+
| r: Average data rate (bits/sec) |
+-----------+-----------+-----------+-----------+

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 43] September 1995 [Page 60]

Internet Draft RSVP Specification November 1994

this format of sender template is 7 octets (FiltSLen March 1995

6.9 ADVERT Class

[TBD]

6.10 TIME_VALUES Class

o TIME_VALUES Object: Class = 2).

A wildcard Filterspec, which will match any sender host,
has zero for the Sender IP Address [If VM part zero also,
could shorten to FiltSLen 10, C-Type = 2].

To speed RSVP processing, a filterspec that appears in an 1

+-------------+-------------+-------------+-------------+
| Refresh Period |
+-------------+-------------+-------------+-------------+
| State TTL Time |
+-------------+-------------+-------------+-------------+

Braden, Zhang, et al. Expiration: September 1995 [Page 61]

Internet Draft RSVP message use the following "canonical form".

o
The high-order octet of the mask M must be non-zero
(this can always be achieved by adjusting VFoffset). Specification March 1995

6.11 ERROR_SPEC Class

o The (V,M) part must not include either the sender or
receiver address of the IP header; these are carried
explicitly.
ISSUE:

There are many possible filter rules that cannot be
expressed using a simple mask and value pair. A
compact and general filter encoding is for further
study. IPv4 ERROR_SPEC object: Class = 11, C-Type = 1

+-------------+-------------+-------------+-------------+
| IP4 Error Node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| Error Code | ////////// | Error Value |
+-------------+-------------+-------------+-------------+

o Authenticator Format

The following simple form of authenticator is defined:

+-----------+-----------+-----------+-----------+ IP6 ERROR_SPEC object: Class = 11, C-Type = 129

+-------------+-------------+-------------+-------------+
| | AuthLen
+ +
| AuthType=1| |
+-----------+-----------+
+ IP6 Error Node Address (16 bytes) +
| Mailbox name: user@domain |
// //
+-----------+-----------+-----------+-----------+
+ +
| |
+-------------+-------------+-------------+-------------+
| Error Code | ////////// | Error Value |
+-------------+-------------+-------------+-------------+

Errnor Node

The rules for merging and interpreting this field require
further study.

3.6.2 Application/RSVP Interface

This section describes a generic API from an application to an
RSVP control process. IP address

Error Code

A one-octet error description.

01 = Insufficient memory

02 = Count Wrong

The details of a real interface may be
operating-system dependent; the following can only suggest the
basic functions to be performed. Some FD Count field does not match length of these calls cause
message.

03 = No path information to be returned asynchronously.

An application could directly send and receive RSVP messages,

Zhang, for this Resv

04 = No Sender information for this Resv

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 44] September 1995 [Page 62]

Internet Draft RSVP Specification November 1994

just as an application can do file transfer using UDP.
However, we envision that many applications will March 1995

There is path information, but it does not want to
know include
the details sender specified in any of RSVP operation, nor to provide the timing
services necessary to keep Filterspecs
listed in the state refreshed, any more than
an application wants to handle TCP retransmission timeouts.
Therefore, a host using RSVP may have an RSVP control process
to handle these functions. Using local IPC, applications will
register Resv messager.

05 = Incorrect Dynamic Reservation Count

Dynamic Reservation Count is zero or modify resource requests less than FD
Count.

06 = Filterspec error

07 = Flowspec syntax error

08 = Flowspec value error

Internal inconsistency of values.

[What should be done with this process Flowspec Feature Not
Supported?]

09 = Resources unavailable [Sub-reasons? Depend upon
traffic control and
receive notifications of success or change admission control algorithms?]

10 = Illegal style

Error Value

Specific cause of conditions.

Call: REGISTER( DestAddress, ResvID, SND-flag, RCV-flag,
[, DROP-flag] [, rsvpTTL] [, SenderTemplate] [, flowspec]
[, UserCredentials] ) -> session-id

This call initiates RSVP processing for the session
(DestAddress, ResvID). If successful, error described by the call returns
immediately with Error Code.

Braden, Zhang, et al. Expiration: September 1995 [Page 63]

Internet Draft RSVP Specification March 1995

6.12 CREDENTIAL Class

[TBD]

6.13 INTEGRITY Class

[TBD]

Braden, Zhang, et al. Expiration: September 1995 [Page 64]

Internet Draft RSVP Specification March 1995

7. UDP Encapsulation

As described earlier, RSVP control messages are intended to be
carried as "raw packets", directly within IP datagrams. Implementing
RSVP in a local session identifier "session-id", node will typically require an intercept in the packet
forwarding path for protocol 46, which may be used means a kernel change.
However, for ease of installing RSVP on host systems in subsequent calls. Following this
call, an asynchronous ERROR or EVENT call (see below) the short
term, it may
occur at any time.

SND-flag should be set true if the desirable to avoid host will send data,
and RCV-flag should kernel changes by supporting
UDP encapsulation of RSVP messages. This encapsulation would be set true if used
between hosts and the host last- (or first-) hop router(s). This scheme
will receive
data. Setting neither true is also support the case of an error. intermediate RSVP router whose
kernel supports multicast but does not have the RSVP intercept, by
allowing UDP encapsulation on each interface.

The optional
parameters DROP-flag, rsvpTTL, SenderTemplate, and
Flowspec should be supplied only if SND-flag is true.

DROP-flag indicates that session data packets UDP encapsulation approach must support a domain that do not
match any active filter contains a
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 node should be dropped at
that node; otherwise, such local RSVP packets will be forwarded using
a best-effort QoS. The rsvp-TTL parameter specifies the
IP Time-to-Live field in both formats. We
assume that the only negative impact of this duplication will be used
(negligible) additional packet processing overhead in PATH messages.
The value of rsvp-TTL should match the TTL field raw-capable
hosts and first-hop routers.

[REST TBD]

8. DF Style (Experimental)

In addition 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 transmission of PATH messages.

Reserve

Call: RESERVE( session-id, style [, DF-chan-count]
Flowspec-list, Filterspec-list)

A receiver uses WF and FF styles defined in this call to make specification, a resource reservation

Zhang, Braden, et al. Expiration: May 95 FORMFEED[Page 45]

Internet Draft RSVP Specification November 1994

for the session registered as `session-id'.
Dynamic Filter (DF) style has also been proposed. The following
describes this style and gives examples of its usage. At this time,
DF style
parameter is an integer index indicating the experimental.

8.1 Reservation Styles

A Dynamic-Filter (DF) style reservation
style. The DF-chan-count parameter, indicating the decouples reservations
from filters.

Each DF reservation request specifies a number D of Dynamic Filter channels distinct
reservations to be reserved, should only be
included if made using the style is DF. same specified flowspec, and
these reservations have a wildcard reservation scope, so they go
everywhere. The first RESERVE call will initiate the periodic
transmission of RESV messages. A later RESERVE call may
be given to modify the parameters number of the earlier call (but
note that changing the reservations may result that are actually made in
admission control failure, depending upon
a particular node is D' = min(D,Ns), where Ns is the style).

The RESERVE call returns immediately. Following this
call, an asynchronous ERROR or EVENT call may come at any
time.

Release

Call: RELEASE( session-id )

This call will terminate RSVP state for total number
of senders upstream of the session
specified by session-id. It will send appropriate
"Teardown" messages and cease sending refreshes.

Error Upcall

Call: ERROR( ) -> session-id, error-type, error-code
[, flowspec] [, filterspec]

This upcall may occur asynchronously at any time after node. Like a
REGISTER call and before FF style request, 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 DF
style request causes distinct reservations for different senders.

In addition to
a receiver will specify in `flowspec' the flowspec that
actually failed. This may differ from D and the flowspec
specified by this application in flowspec, a RESERVE call, due to
upstream merging with DF style reservation requests from other
receivers.

Event Upcall

Call: EVENT( ) -> session-id, info-type,
[, flowspec-list] [, filterspec-list]

This upcall may occur asynchronously at any time after a
REGISTER call and before also
specify a RELEASE call, to signal an

Zhang, list of K filterspecs, for some K in the range: 0 <= K

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 46] September 1995 [Page 65]

Internet Draft RSVP Specification November 1994

event March 1995

<= D'. These filterspecs define particular senders to use the D'
reservations, and this list establishes the scope for the filter
specs.

Once a DF reservation has been established, the receiver may
change the set of filterspecs to pass information specify a different selection of
senders, without a new admission control check (assuming D' and
the common flowspec remain unchanged). This is known as "channel
switching", in analogy with a television set.

In order to provide assured channel switching, each node along the application.

The `info-type' field indicates
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 two possible event
types. A Path event indicates upstream sources changed), or if the receipt common flowspec
changes, the refresh message is treated as a new reservation that
is subject to admission control and may fail.

The essential difference between the FF and DF styles is that the
DF style allows a receiver to switch channels without danger of a PATH
message, indicating an
admission denial due to limited resources (unless a topology
change reroutes traffic along a lower-capacity path or new senders
appear), once the application initial reservations have been made. This in
turn implies that there is at
least one active sender. A Reservation event indicates
the receipt of a RESV message, indicating to the
application DF style creates reservations that there is may not
be in use at least one receiver. Although
these messages are repeatedly received, any given time.

The DF style is compatible with the API should
make FF style but not the corresponding asynchronous upcall to WF style.

8.2 Examples

To give an example of the
application only on DF style, we use the first event, following notation:

o DF Style

DF( n, {r} ; ) or when DF( n, {r} ; S1, S2, ...)

This message carries the
information to be reported changes.

ISSUE:

The precise form and function count n of the flowspec-list and
filterspec-list parameters are channels to be determined.

3.6.3 RSVP/Traffic Control Interface

In reserved, each router and host, enhanced QoS is achieved by
using common flowspec r. It also carries a group list, perhaps empty,
of
inter-related functions: a packet Classifier, filterspecs defining senders.

Figure 11 shows 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

Call: Rhandle 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) = TCAddFlow( Flowspec, DropFlag,
[SessionFilterspec [, SenderFilterspec]] )

Returns an internal handle Rhandle for subsequent
references to this reservation.

This call passes Flowspec to admission control 2 channels of size B on interface (d), and returns
an error code if Flowspec is malformed or if the requested
resources are unavailable. Otherwise, it establishes a
new reservation channel corresponding
then applies any specified filters to Rhandle, and if
Filterspecs are supplied, installs a corresponding filter
in the classifier.

For FF reservation requests, RSVP knows about sharing and
calls AddFlow these channels. Since only for distinct source pipes.

For DF reservation requests: suppose that the RESV message

Zhang,
one sender was specified, one channel has no corresponding filter,
as shown by `?'.

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 47] September 1995 [Page 66]

Internet Draft RSVP Specification November 1994

specifies a Dynamic Reservation Count = D, March 1995

Similarly, the receivers downstream of interface (c) have
requested two channels and F flow
descriptors, where 0 <= F <= D. Then RSVP calls AddFlow D
times, selected senders S1 and D - F of those calls S2. The two
channels might have null filterspecs.

2. Switch a Channel

Call: TCModFilter( Rhandle, [new Filterspec])

This call replaces the filter without calling admission
control. It may replace an existing filter with no
filter, modify an existing filter, been one channel each from R1 and R2, or replace no filter two
channels requested by
a filter.

3. Modify Flowspec

Call: TCModFlowspec( Rhandle, oldFlowspec, newFlowspec)

Here newFlowspec may be larger or smaller one of them, for example.

Figure 11: Dynamic-Filter Reservation Example

A router should not reserve more Dynamic-Filter channels than
oldFlowspec.

4. Delete Flow

Call: TCDeleteFlow( Rhandle )

This call kills the reservation and reduces the reference
count of, and deletes if
number of upstream sources (three, in the count is zero, any filter
associated with this handle.

5. Initialize

Call: TCInitialize( )

This call router of Figure 11).
Since there is used when RSVP initializes its state, to
clear out all existing classifier and/or packet scheduler
state.

3.6.4 RSVP/Routing Interface

An RSVP implementation needs the following support only one source upstream from previous hop (a), the
packet forwarding and routing mechanism
first parameter of the node.

o Promiscuous receive mode for RSVP messages

Any datagram received for IP protocol 46 is to be diverted DF message (the count of channels to the RSVP program for processing, without being
forwarded.

Zhang, Braden, et al. Expiration: May 95 FORMFEED[Page 48]

Internet Draft RSVP Specification November 1994

o Route discovery

RSVP must be able
reserved) was decreased to discover 1 in the route(s) that forwarded reservations.
However, this is unnecessary, because the
routing algorithm would have used for forwarding routers upstream will
reserve only one channel, regardless.

When a
specific datagram.

GetUCRoute( DestAddress ) -> NextHop, Interface

GetMCRoute( SrcAddress, DestAddress ) -> Interface

o Outgoing Link Specification

RSVP must 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 able directly
connected to force a (multicast) datagram shared medium network or to a non-RSVP-capable
router, there may be
sent 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 specific outgoing virtual link, bypassing RESV from
the
normal routing mechanism. A virtual link may be ith next-hop node.

For a real
outgoing link or DF reservation request with a multicast tunnel.

This is necessary because Dynamic Reservation Count = C,

Braden, Zhang, et al. Expiration: September 1995 [Page 67]

Internet Draft RSVP may send different versions
of outgoing PATH messages on different interfaces, for the
same source and destination addresses.

o Discover (Virtual) Interface List Specification March 1995

RSVP must be able to learn what real and virtual
interfaces exist.

4. ACKNOWLEDGMENTS

Lixia Zhang, Scott Shenker, Deborah Estrin, Dave Clark, Sugih Jamin,
Shai Herzog, Steve Berson, Steve Deering, Bob Braden, and Daniel
Zappala have all made contributions to should call TC_AddFlowspec C times.

8.3 Resv Messages

Add the design following sequence:

<Style-DF> <FLOWSPEC> <filter spec list>

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 RSVP. We are
grateful channels to Jamin, Herzog, and Berson for prototype implementations.
The original protocol concepts be reserved for RSVP arose out of discussions in
meetings of the End-to-End Research Group. a Dynamic
Filter style reservation. This integer value must not
less than FD Count.

REFERENCES

[CSZ92] Clark, D., Shenker, S., and L. Zhang, "Supporting Real-Time
Applications in an Integrated Services Packet Network: Architecture
and Mechanisms", Proc. SIGCOMM '92, Baltimore, MD, August 1992.

[ISInt93] Braden, R., Clark, D., and S. Shenker, "Integrated Services
in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and
PARC, June 1994.

[IServ93] Shenker, S., Clark, D., and L. Zhang, "A Service Model for an
Integrated Services Internet", Work in Progress, October 1993.

Zhang, Braden, et al. Expiration: May 95 FORMFEED[Page 49]

Internet Draft RSVP Specification November 1994

[Partridge92] Partridge, C., "A Proposed Flow Specification", RFC 1363,
BBN, September 1992.

Braden, Zhang, et al. Expiration: September 1995 [Page 68]

Internet Draft RSVP Specification March 1995

[Shenker94] Shenker, S., "Two-Pass or Not Two-Pass", Current Meeting
Report, RSVP Working Group, Proceedings of the Thirtieth Internet
Engineering Task Force, Toronto, Canada, July 1994.

[RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D.
Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network,
September 1993.

Security Considerations

As noted in

See Section 2.1, the ability to reserve resources will create
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. 2.5.

Authors' Addresses

Lixia Zhang
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304

Phone: (415) 812-4415
EMail: Lixia@PARC.XEROX.COM

Bob Braden
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292

Phone: (310) 822-1511
EMail: Braden@ISI.EDU

Deborah Estrin
Computer Science Department
University of Southern California
Los Angeles, CA 90089-0871

Phone: (213) 740-4524
EMail: estrin@USC.EDU

Zhang,

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 50] September 1995 [Page 69]

Internet Draft RSVP Specification November 1994 March 1995

Shai Herzog

USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Palo Alto, CA 94304

Phone: (310) 822 1511
EMail: Herzog@ISI.EDU

Sugih Jamin
Computer Science Department
University of Southern California
Los Angeles, CA 90089-0871

Phone: (213) 740-6578
EMail: jamin@catarina.usc.edu

Zhang,

Braden, Zhang, et al. Expiration: May 95 FORMFEED[Page 51] September 1995 [Page 70]

----