WDIFF

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

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

Resource ReSerVation Protocol (RSVP) --

Version 1 Functional Specification

March 24,

June 21, 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.

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

Internet Draft RSVP Specification March June 1995

What's Changed Since Toronto Boston IETF

This version of the

The most important changes in this document incorporates many of from the protocol changes
agreed rsvp-spec-05 draft
are:

o Added SE (Shared Explicit) style to at all parts of the December 1994 IETF meeting document.

o Further clarified reservation options and added table in San Jose. The most major
changes are: Figure
3. Defined option vector in STYLE object.

o The RSVP packet format has been reorganized Renamed CREDENTIAL object class to carry most data POLICY_DATA object class, and
rewrote section 2.5 to more fully express its intended usage.

o Clarified the relationship between the wildcard scope
reservation option and wildcards in individual FILTER_SPEC
objects: wildcard is as typed variable-length objects. wildcard does.

o This generality includes provision Added SCOPE object definition and define the rules for 16-byte IP6 addresses.

o Filter specs have been simplified.

o DF style has been moved its use
to an Appendix, as experimental. prevent looping of wildcard-scope messages.

o UDP encapsulation Added TAG object. This is needed to do semantic fragmentation
in certain cases; however, the rules for its use are not yet
written down. Furthermore, there has been included. some debate about
semantic fragmentation.

o OPWA has been included. Added some mechanisms for handling backwards compatibility for
future protocol extensions: (1) High bit of object class number;
(2) unmerged FLOWSPEC C-Type; (3) unmerged POLICY_DATA C-Type.

o The Drop flag has been eliminated. Rewrote Section 4.3 on preventing looping. Included rules for
SCOPE object.

o Session groups have been added. Specified rules for local repair upon route change notification
(Section 4.4).

o The routing of RERR messages has been changed.

1. Introduction

This document defines RSVP, a resource reservation setup protocol
designed Specified for an integrated services Internet [RSVP93,ISInt93].

A host uses each error type whether or not the RSVP protocol to request a specific quality of
service (QoS) from state
information in the network, on behalf of an application data
stream. RSVP erroneous packet is also used to deliver QoS requests to routers along be stored and
forwarded.

o Deleted the path(s) discussion of the data stream and to maintain router and host state
to provide the requested service. This will generally (but not
necessarily) require reserving resources along the data path.

RSVP reserves resources for simplex data streams, i.e., it reserves
resources in only one direction on a link, so that retransmitting a sender Teardown message Q
times; assume Q=1 is
logically distinct from a receiver. However, the same application
may act as both sender sufficient.

o Moved Session Groups to Appendix D, "Experimental and receiver. RSVP operates on top of IP,
occupying the place Open
Issues". Session Groups should be revisited as part of a transport protocol in the protocol stack.
However, like ICMP, IGMP, and routing protocols, RSVP does not
transport application data but is rather an Internet control
protocol. As shown in Figure 1, an implementation of RSVP, like the
implementations larger
context of routing and management protocols, will typically cross-session reservations.

o Changed common header format, removing Object Count (which was

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

Internet Draft RSVP Specification March June 1995

execute in the background, not in

redundant) and rearranging the data forwarding path.

RSVP is not itself a routing protocol; remaining fields. Moved the RSVP daemon consults two
common header flags into objects: Entry-Police into SESSION
object and LUB-used into ERROR_SPEC object.

o Revised the
local routing protocol(s) to obtain routes. Thus, a host sends IGMP
messages to join a multicast group, rules for state timeout (Section 4.5) and it sends RSVP messages to
reserve resources along redefined
the delivery path(s) TIME_VALUES object format.

o Changed the error message format: (1) removed required RSVP_HOP
object from that group. RSVP
is designed to operate with existing and future unicast PERR and multicast
routing protocols.

HOST ROUTER

_________________________ RSVP ______________________
| | .---------------. |
| _______ ______ | . | ________ . ______ |
| | | | | | . || | . | || RSVP
| |Applic-| | RSVP <----- ||Routing | -> RSVP <------>
| | App <----->daemon| | ||Protocol| |daemon||
| | | | | | || daemon <----> ||
| |_______| |___.__| | ||_ ._____| |__.___||
|===|===============v=====| |===v=============v====|
| data .......... | | . ............ |
| | ____v_ ____v____ | | _v__v_ _____v___ |
| | |Class-| | || data | |Class-| | || data
| |=> ifier|=> Packet =============> ifier|==> Packet |======>
| |______| |Scheduler|| | |______| |Scheduler||
| |_________|| | |_________||
|_________________________| |______________________|

Figure 1: RSVP RERR messages; (2) removed CREDENTIAL
(i.e., POLICY_DATA) object from RERR messages; (3) specified
more carefully what may appear in Hosts and Routers

Each router that is capable flow descriptor list of resource reservation passes incoming
data packets to a packet classifier RERR
messages.

o Revised the definitions of error codes and then queues error values, and
moved them as necessary
in into a packet scheduler. The packet classifier determines separate Appendix B.

o No longer require CREDENTIAL (i.e., POLICY_DATA) match for
teardown.

o Revised routing of RERR messages to use SCOPE objects to avoid
wildcard-induced looping.

o Added LIH (logical interface handle) to RSVP_HOP object, for IP
multicast tunnels.

o Added two new upcall event types in the route API: reservation event
and policy data event.

o Generalized the QoS class generic traffic control calls slightly to allow
multiple filter specs per flowspec, for each packet. The scheduler allocates SE style. This
introduced a
particular outgoing link for packet transmission, and it may also
allocate other system resources such as CPU time or buffers.

In order new set of handles, called FHandle. Also added a
preemption upcall.

o Added route change notification to efficiently accommodate heterogeneous receivers and
dynamic group membership and to be consistent with IP multicast, RSVP
makes receivers responsible for requesting resource reservations
[RSVP93]. A QoS request, typically originating in a receiver host
application, will be passed to the local RSVP implementation, shown
as a user daemon in Figure 1. The RSVP protocol is then used to pass the request generic interface to all the nodes (routers and hosts) along
routing.

o Updated the reverse
data path(s) message processing rules (Section 5).

o Rewrote Appendix C on UDP encapsulation.

o Removed specification of FLOWSPEC object format (but int-serv
working group has since reneged on promise to the data source(s). specify it).

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

Internet Draft RSVP Specification March June 1995

At each node, the RSVP program applies

1. Introduction

This document defines RSVP, a local decision procedure,
called "admission control", to determine if it can supply the
requested QoS. If admission control succeeds, resource reservation setup protocol
designed for an integrated services Internet [RSVP93,ISInt93].

A host uses the RSVP program sets
parameters to the packet classifier and scheduler protocol to obtain the
desired QoS. If admission control fails at any node, request a specific quality of
service (QoS) from the RSVP
program returns network, on behalf of an error indication to the application that
originated the request. We refer to the packet classifier, packet
scheduler, and admission control components as "traffic control". data
stream. RSVP is designed also used to scale well for very large multicast groups.
Since deliver QoS requests to routers along
the membership path(s) of a large group will be constantly changing, the RSVP design assumes that data stream and to maintain router and host state for traffic control
to provide the requested service. This will be
built and destroyed incrementally. For this purpose, RSVP uses "soft
state" in generally (but not
necessarily) require reserving resources along the routers, in addition to receiver-initiation. data path.

RSVP protocol mechanisms provide a general facility reserves resources for creating and
maintaining distributed reservation state across a mesh of multicast
or unicast delivery paths. RSVP transfers reservation parameters as
opaque simplex data (except for certain well-defined operations on the data),
which streams, i.e., it simply passes to traffic control for interpretation.
Although the RSVP protocol mechanisms are largely independent of the
encoding of these parameters, the encodings must be defined reserves
resources in the
reservation model only one direction on a link, so that a sender is presented to an application (see Appendix
A).

In summary, RSVP has
logically distinct from a receiver. However, the following attributes:

o RSVP supports multicast or unicast data delivery and adapts to
changing group membership as well same application
may act as changing routes.

o RSVP is simplex.

o both sender and receiver. RSVP is receiver-oriented, i.e., operates on top of IP,
occupying the receiver place of a transport protocol in the protocol stack.
However, like ICMP, IGMP, and routing protocols, RSVP does not
transport application data flow but is
responsible for rather an Internet control
protocol. As shown in Figure 1, an implementation of RSVP, like the initiation and maintenance
implementations of routing and management protocols, will typically
execute in the resource
reservation used for that flow.

o RSVP maintains "soft state" background, not in the routers, enabling it to
gracefully support dynamic membership changes and automatically
adapt to data forwarding path.

RSVP is not itself a routing changes.

o protocol; the RSVP provides several reservation models or "styles" (defined
below) daemon consults the
local routing protocol(s) to fit obtain routes. Thus, a variety of applications.

o host sends IGMP
messages to join a multicast group, and it sends RSVP provides transparent operation through routers that do not
support it.

Further discussion on messages to
reserve resources along the objectives and general justification for delivery path(s) from that group. RSVP design are presented in [RSVP93,ISInt93].
is designed to operate with existing and future unicast and multicast
routing protocols.

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

Internet Draft RSVP Specification March June 1995

The remainder of this section describes the

HOST ROUTER

_________________________ RSVP reservation
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 multicast
destination constitute a session.
| |Applic-| | RSVP treats each session
independently. All <----- ||Routing | -> RSVP <------>
| | App <----->daemon| | ||Protocol| |daemon||
| | | | | | || daemon <----> ||
| |_______| |___.__| | ||_ ._____| |__.___||
|===|===============v=====| |===v=============v====|
| data packets in a particular session are
directed to the same IP destination address DestAddress, and
perhaps to some further demultiplexing point defined in a higher
layer (transport or application). We refer to the latter as a
"generalized destination port".

DestAddress is the group address for multicast delivery, or the
unicast address of a single receiver. A generalized destination
port could be defined by a UDP/TCP destination port field, by an
equivalent field in another transport protocol, or by some
application-specific information. Although the .......... | | . ............ |
| | ____v_ ____v____ | | _v__v_ _____v___ |
| | |Class-| | || data | |Class-| | || data
| |=> ifier|=> Packet =============> ifier|==> Packet |======>
| |______| |Scheduler|| | |______| |Scheduler||
| |_________|| | |_________||
|_________________________| |______________________|

Figure 1: RSVP protocol in Hosts and Routers

Each router that is
designed to be easily extendible for greater generality, the
present version uses only UDP/TCP ports as generalized ports.

Figure 2 illustrates the flow capable of resource reservation passes incoming
data packets to a packet classifier and then queues them as necessary
in a single RSVP
session, assuming multicast data distribution. packet scheduler. The arrows
indicate data flowing from senders S1 and S2 to receivers R1, R2,
and R3, packet classifier determines the route
and the cloud represents QoS class for each packet. The scheduler allocates resources
for transmission on the distribution mesh created particular link-layer medium used by
the multicast routing protocol. Multicast distribution forwards a
copy of each data
interface. If the link-layer medium is QoS-active, i.e., if it has
its own QoS management capability, then the packet from a sender Si scheduler is
responsible for negotiation with the link layer to every receiver Rj; a
unicast distribution session has a single receiver R. Each sender
Si obtain the QoS
requested by RSVP. There are many possible ways this might be
accomplished, and each receiver Rj may correspond to the details will be medium-dependent. The
scheduler itself allocates packet transmission capacity on a unique Internet host, QoS-
passive medium such as a leased line. The scheduler may also
allocate other system resources such as CPU time or buffers.

In order to efficiently accommodate heterogeneous receivers and
dynamic group membership and to be consistent with IP multicast, RSVP
makes receivers responsible for requesting resource reservations
[RSVP93]. A QoS request, typically originating in a single receiver host may contain multiple logical senders and/or
receivers, distinguished by generalized ports.
application, will be passed to the local RSVP implementation, shown
as a user daemon in Figure 1. The RSVP protocol is then used to pass
the request to all the nodes (routers and hosts) along the reverse
data path(s) to the data source(s).

At each node, the RSVP program applies a local decision procedure,
called "admission control", to determine if it can supply the

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

Internet Draft RSVP Specification March June 1995

Senders Receivers
_____________________
( ) ===> R1
S1 ===> ( Multicast )
( ) ===> R2
( distribution )
S2 ===> ( )
( by 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 is called a "flow
descriptor". The flowspec specifies a desired

requested QoS. The filter
spec (together with If admission control succeeds, the DestAddress RSVP program sets
parameters to the packet classifier and scheduler to obtain the generalized
destination port defining
desired QoS. If admission control fails at any node, the session) defines RSVP
program returns an error indication to the set of data
packets -- application that
originated the "flow" -- request. We refer to receive the QoS defined by the
flowspec. The flowspec packet classifier, packet
scheduler, and admission control components as "traffic control".

RSVP is used to set parameters designed to scale well for very large multicast groups.
Since the packet
scheduler in membership of a large group will be constantly changing,
the node (assuming RSVP design assumes that admission router state for traffic control succeeds),
while the filter spec is used to set parameters will be
built and destroyed incrementally. For this purpose, RSVP uses "soft
state" in the packet
classifier.

The flowspec routers, in addition to receiver-initiation.

RSVP protocol mechanisms provide a general facility for creating and
maintaining distributed reservation request will generally include state across a
service type and two sets mesh of numeric parameters: (1) an " Rspec"
(R multicast
or unicast delivery paths. RSVP transfers reservation parameters as
opaque data (except for `reserve'), which defines certain well-defined operations on the desired per-hop reservation,
and (2) a "Tspec" (T for `traffic'), data),
which defines the parameters
that may be used to police the data flow, i.e., to ensure it does
not exceed its promised simply passes to traffic level.

The general control for interpretation.
Although the RSVP reservation model allows filter specs to select
arbitrary subsets protocol mechanisms are largely independent of the packets in a given session. Such subsets
might
encoding of these parameters, the encodings must be defined in terms of senders (i.e., sender IP address and
generalized source port), in terms of a higher-level protocol, or
generally in terms of any fields in any protocol headers in the
packet. For example, filter specs might be used
reservation model that is presented to select
different subflows in a hierarchically-encoded signal, by
selecting on fields in an application-layer header. However,
considerations of both architectural purity application (see Appendix
A).

In summary, RSVP has the following attributes:

o RSVP supports multicast or unicast data delivery and practical
requirements have led adapts to
changing group membership as well as changing routes.

o RSVP is simplex.

o RSVP is receiver-oriented, i.e., the decision receiver of a data flow is
responsible for the initiation and maintenance of the resource
reservation used for that flow.

o RSVP should use
separate sessions for distinct subflows 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) to fit a variety of hierarchically-encoded
signals. For multicast sessions, subflows can be distinguished by
multicast destination address; applications.

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

Further discussion on the objectives and general justification for unicast sessions, they must be
RSVP design are presented in [RSVP93,ISInt93].

The remainder of this section describes the RSVP reservation

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

Internet Draft RSVP Specification March June 1995

distinguished by destination port. As a result

services. Section 2 presents an overview of these
considerations, the present RSVP version includes a quite
restricted definition protocol
mechanisms, while Section 3 gives examples of filter specs, selecting only on sender IP
address and UDP/TCP port number, the services and on protocol id. However,
mechanism. Section 4 contains the
design functional specification of RSVP.
Section 5 presents explicit message processing rules.

1.1 Data Flows

The set of data flows with the protocol would easily handle a more general
definition in future versions.

Any same unicast or multicast
destination constitute a session. RSVP treats each session
independently. All data packets that are addressed to in a particular session but do not
match any of the filter specs for that session will be sent as
best-effort traffic. Under congested conditions, such packets are
likely
directed to experience long delays the same IP destination address DestAddress, and may be dropped. A receiver
may wish
perhaps to conserve network resources by explicitly asking the
network some further demultiplexing point defined in a higher
layer (transport or application). We refer to drop those data packets for which there the latter as a
"generalized destination port".

DestAddress is no
reservation; however, such dropping should the group address for multicast delivery, or the
unicast address of a single receiver. A generalized destination
port could be performed by
routing, not defined by RSVP. Determining where packets get delivered
should be a routing function; UDP/TCP destination port field, by an
equivalent field in another transport protocol, or by some
application-specific information. Although the RSVP protocol is concerned
designed to be easily extendible for greater generality, the
present version uses only with UDP/TCP ports as generalized ports.

Figure 2 illustrates the QoS flow of those data packets that are delivered by routing. in a single RSVP reservation request messages originate at
session, assuming multicast data distribution. The arrows
indicate data flowing from senders S1 and S2 to receivers R1, R2,
and R3, and are
passed upstream towards the sender(s). (Note that this document
always uses cloud represents the directional terms "upstream" vs. "downstream",
"previous hop" vs. "next hop", and "incoming interface" vs
"outgoing interface" with respect to distribution mesh created by
the data flow direction).
When an multicast routing protocol. Multicast distribution forwards a
copy of each data packet from a sender Si to every receiver Rj; a
unicast distribution session has a single receiver R. Each sender
Si and each receiver Rj may correspond to a unique Internet host,
or a single host may contain multiple logical senders and/or
receivers, distinguished by generalized ports.

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

Figure 2: Multicast Distribution Session

Braden, Zhang, et al. Expiration: December 1995 [Page 7]

Internet Draft RSVP Specification June 1995

Even if the destination address is unicast, there may be multiple
receivers, distinguished by the generalized port. There may also
be multiple senders for a unicast destination, i.e., RSVP can set
up reservations for multipoint-to-point transmission.

1.2 Reservation Model

An elementary RSVP reservation request is received at consists of a node, the
RSVP daemon takes two primary actions.

1. Make "flowspec"
together with a reservation "filter spec"; this pair is called a "flow
descriptor". The flowspec and the specifies a desired QoS. The filter
spec are passed to traffic
control. Admission Control determines (together with the admissibility of DestAddress and the request (if it's new); if it fails this test, generalized
destination port defining the
reservation is rejected and RSVP sends back an error message
towards session) defines the responsible receiver(s). If it passes, set of data
packets -- the "flow" -- to receive the QoS defined by the
flowspec. The flowspec is used to set up parameters to the node's
packet scheduler for the
desired QoS and (assuming that admission control succeeds), while
the filter spec is used to set parameters in the packet
classifier
classifier. Note that the action to select control the QoS occurs at the
place where the appropriate data packets.

2. Forward enters the medium, i.e., at the upstream end
of the link, although the RSVP reservation upstream. request originates from
receiver(s) downstream.

The flowspec in a reservation request is propagated upstream towards the
appropriate senders. The set will generally include a
service type and two sets of senders to numeric parameters: (1) an "Rspec" (R
for `reserve'), which defines the desired per-hop reservation, and
(2) a given
reservation request is propagated is called "Tspec" (T for `traffic'), which defines the "scope" of
that request.

The reservation request parameters that a node forwards upstream
may differ
from be used to police the request that it received, for two reasons. First, data flow, i.e., to ensure it is
possible (at least in theory) for does not
exceed its promised traffic level.

The form and contents of Tspecs and Rspecs are determined by the kernel
integrated service model [ServTempl95a], and are generally opaque
to modify the
flowspec hop-by-hop (although currently no realtime services do

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

Internet Draft RSVP. RSVP Specification March 1995

this). Second, reservations from different downstream branches of delivers the multicast distribution tree(s) must be "merged" as
reservations travel upstream. Merging reservations Tspec and Rspec, together with an
indication whether traffic policing is a necessary
consequence of multicast distribution, which creates a single
stream of data packets in a particular router from any Si,
regardless of needed to the set admission
control and packet scheduling components of receivers downstream. The reservation traffic control. A
service that requires traffic policing might for Si on a particular outgoing link L should be example apply it
at the "maximum" edge of the individual flowspecs from the receivers Rj that are downstream
via link L. Merging is discussed further in Section 2.3.

For both of network and at data merge points; RSVP knows
when these primary actions, there are options controlled by
the receiver making occur and must so indicate to the reservation. These options are combined
into a traffic control variable called
mechanism. On the reservation "style", which is
discussed in section 1.3. One option concerns other hand, RSVP cannot interpret the treatment of
reservations for different senders within service
embodied in the same session:
establish flowspec and therefore does not know whether
policing will actually be applied in a "distinct" particular case.

In the general RSVP reservation for each upstream sender, or
else "mix" all senders' model [RSVP93], filter specs may
select arbitrary subsets of the packets into in a single reservation.
Another option controls the scope given session. Such
subsets might be defined in terms of the request: "unitary" senders (i.e.,
a single specified sender), an explicit sender list, or IP
address and generalized source port), in terms of a
"wildcard" that implicitly selects all senders upstream higher-level
protocol, or generally in terms of any fields in any protocol
headers in the
given node.

The basic RSVP reservation model is "one pass": a receiver sends packet. For example, filter specs might be used to
select different subflows in a
reservation request upstream, and each node hierarchically-encoded signal by
selecting on fields in an application-layer header. However, in

Braden, Zhang, et al. Expiration: December 1995 [Page 8]

Internet Draft RSVP Specification June 1995

the path can only
accept or reject the request. This scheme provides no way interest of simplicity (and to make
end-to-end service guarantees; minimize layer violation), the QoS request is applied
independently at each hop.
present RSVP also supports an optional
reservation model, known as " One Pass With Advertising" (OPWA)
[Shenker94]. In OPWA, version uses a much more restricted form of filter
spec: select only on sender IP address, on UDP/TCP port number,
and perhaps on IP protocol id.

RSVP control can distinguish subflows of a hierarchically-encoded signal
if they are assigned distinct multicast destination addresses, or,
for a unicast destination, distinct destination ports. Data
packets sent downstream,
following the data paths, that are used addressed to gather information on the
end-to-end service that would result from a variety particular session but do not
match any of possible
reservation requests. The results ("advertisements") the filter specs for that session are
delivered by RSVP expected to the receiver host, be
sent as best-effort traffic, and perhaps under congested conditions, such
packets are likely to the
receiver application. The information experience long delays, and they may then be used by the
dropped. When a receiver does not wish to construct an appropriate reservation request.

1.3 Reservation Styles

Each RSVP reservation request specifies receive a "reservation style".
The following reservation styles are defined in this version of particular
(sub-)flow, it can economize on network resources by explicitly
asking the protocol.

1. Wildcard-Filter (WF) Style

The WF style specifies network to drop unneeded the options: "mixing" reservation and
" wildcard" reservation scope. Thus, a WF-style reservation
creates a single reservation into data packets; it does so
by leaving the multicast group(s) to which flows from all
upstream senders these packets are mixed. This reservation may
addressed. Thus, determining where packets get delivered should
be thought

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

Internet Draft RSVP Specification March 1995

of a shared "pipe", whose "size" routing function; RSVP is concerned only with the largest QoS of the
resource requests for
those packets that link from all receivers,
independent of the number of senders using it. A WF-style
reservation has wildcard scope, i.e., the are delivered by routing.

RSVP reservation is
propagated request messages originate at receivers and are
passed upstream towards all senders. A WF-style
reservation automatically extends to new senders to the
session as they appear.

2. Fixed-Filter (FF) Style

The FF style specifies sender(s). (This document defines the options: "distinct" reservation
directional terms "upstream" vs. "downstream", "previous hop" vs.
"next hop", and a "unitary" reservation scope. Thus, "incoming interface" vs "outgoing interface" with
respect to the data flow direction.) When an elementary FF-
style
reservation request creates a distinct reservation for
data packets from is received at a particular sender, not mixing them with
other senders' packets for node, the same session. RSVP daemon takes
two primary actions:

1. Daemon makes a reservation

The total flowspec and the filter spec are passed to traffic
control. Admission control determines the admissibility of
the request (if it's new); if this test fails, the
reservation on a link for a given session is rejected and RSVP returns an error message to
the
total of appropriate receiver(s). If admission control succeeds,
the FF reservations node uses the flowspec to set up the packet scheduler for all requested senders. On
the other hand, FF reservations requested by different
receivers Rj but selecting desired QoS and the same sender Si must
necessarily be merged filter spec to share a single set the packet
classifier to select the appropriate data packets.

2. Daemon forwards the reservation in upstream

The reservation request is propagated upstream towards the
appropriate senders. The set of sender hosts to which 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 FF styles are incompatible and cannot be combined
within a session. Other reservation styles may be defined in propagated is called the
future (see Appendix C).

2. RSVP Protocol Mechanisms

2.1 RSVP Messages

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

Each receiver host sends RSVP "scope"
of that request.

The reservation request (RESV) messages
towards the senders. These reservation messages must follow in
reverse the routes the data packets will use, all the way that a node forwards upstream
to the senders within the scope. RESV messages are delivered to may differ
from the sender hosts, so request that the hosts can set up appropriate traffic it received, for two reasons. First, it is

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

Internet Draft RSVP Specification March June 1995

control parameters

possible (in theory) for the first hop. If a reservation request
fails at any node, an RSVP error message is returned kernel to modify the
receiver; however, RSVP sends flowspec hop-
by-hop, although currently no positive acknowledgment messages
to indicate success.

Sender Receiver
_____________________
Path --> ( )
Si =======> ( Multicast ) Path -->
<-- Resv ( ) =========> Rj
( realtime services do this. Second,
reservations from different downstream branches of the multicast
distribution ) <-- Resv
(_____________________)

Figure 3: RSVP Messages

Each sender transmits RSVP PATH messages forward along the uni-
/multicast routes provided by the routing protocol(s); see Figure
3. These "Path" messages store path state in each node. Path
state tree(s) must be "merged" as reservations travel
upstream. Merging reservations is used by RSVP to route the RESV messages hop-by-hop in the
reverse direction. (In the future, some routing protocols may
supply reverse path forwarding information directly, without path
state).

PATH messages may also carry the following information:

o Sender Template

The Sender Template describes the format a necessary consequence of
multicast distribution, which creates a single stream of data
packets that
the sender will originate. This template is in a particular router from any Si, regardless of the form set
of receivers downstream. The reservation for Si on a
filter spec that could particular
outgoing link L should be used to select this sender's
packets from others in the same session on "maximum" of the same link.

o Tspec individual
flowspecs from the receivers Rj that are downstream via link L.
Merging is discussed further in Section 2.2.

The PATH message may optionally carry basic RSVP reservation model is "one pass": a flowspec containing
only receiver sends a Tspec, defining an upper bound on
reservation request upstream, and each node in the traffic level
that path can only
accept or reject the sender will generate. request. This Tspec can be used by
RSVP scheme provides no way to prevent over-reservation (and perhaps unnecessary
Admission Control failure) on make
end-to-end service guarantees, since the non-shared links starting QoS request must be
applied independently at the sender.

o Adspec

The PATH message may carry a package of OPWA advertising
information, each hop. RSVP also supports an optional
reservation model, known as "One Pass With Advertising" (OPWA)
[Shenker94]. In OPWA, RSVP control packets sent downstream,
following the data paths, are used to gather information on the
end-to-end service that would result from a variety of possible
reservation requests. The results ("advertisements") are
delivered by RSVP to the receiver host, and perhaps to the
receiver application. The information may then be used by the
receiver to construct an "Adspec". appropriate reservation request.

1.3 Reservation Styles

A reservation request includes a set of control options. One
option concerns the treatment of reservations for different
senders within the same session: establish a "distinct"
reservation for each upstream sender, or else make a single
reservation that is "shared" all senders' packets. A distinct
reservation requires that the filter spec match exactly one
sender, a wildcard reservation must match at least one. Another
option controls the scope of the request: an " explicit" sender
specification, or a "wildcard" that implicitly selects all sender
hosts upstream of the given node.

These control options are collectively called the reservation
"style", as shown in Figure 3.

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

Internet Draft RSVP Specification March June 1995

Previous Incoming Outgoing Next
Hops Interfaces Interfaces Hops

_____ _____________________ _____
| | data --> | | data --> | |
| A |-----------| a c |--------------| C |
|_____| <-- Resv | | <-- Resv |_____|
Path --> | | Path --> _____
_____ | ROUTER

|| Reservations:
Scope || Distinct | Shared
_________||__________________|____________________
|| | |
Explicit || Fixed-Filter | Shared-Explicit |
|| (FF) style | (SE) Style |
__________||__________________|____________________|
|| | | |--| D
Wildcard || (None defined) | Wildcard-Filter | B |--| data-->|
|| | data --> (WF) Style | |_____|
|_____| |--------| b d |-----------|
|<-- Resv| | <-- Resv | _____
_____ | Path-->|_____________________| Path --> | | |
| | | |--| 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 3: Reservation Attributes and departs through one or more outgoing
interface(s). Styles

The same physical interface may act in both styles currently defined are as follows:

1. Wildcard-Filter (WF) Style

The WF style implies the
incoming options: "shared" reservation and outgoing roles (for different data "
wildcard" reservation scope. Thus, a WF-style reservation
creates a single reservation into which flows but the same
session).

As illustrated in Figure 4, there from all
upstream senders are mixed; this reservation may be multiple previous hops
and/or next hops through a given physical interface. This may
result from the connected network being thought
of as a shared medium or "pipe", whose "size" is the largest of the
resource requests for that link from all receivers,
independent of the existence number of non-RSVP routers in senders using it. A WF-style
reservation has wildcard scope, i.e., the path reservation is
propagated upstream towards all sender hosts. A WF-style
reservation automatically extends to new senders as they
appear.

2. Fixed-Filter (FF) Style

The FF style implies the next RSVP hop
(see Section 2.6). An RSVP daemon must preserve the next options: "distinct" reservations and
previous hop addresses in its
"explicit" reservation and path state,
respectively. A RESV message is sent with scope. Thus, an elementary FF-style
reservation request creates a unicast destination
address, the address of distinct reservation for data
packets from a previous hop. PATH messages, on the
other hand, are sent particular sender, not sharing them with the session destination address, unicast
or multicast.

Although multiple next hops may send reservation requests through other
senders' packets for the same physical interface, the final effect should be to install
a reservation on that interface, which session. It scope is defined
determined by an effective
flowspec. This effective flowspec will be explicit list of senders.

The total reservation on a link for a given session is the "maximum"
total of the
flowspecs FF reservations for all requested by senders. On
the other hand, FF reservations requested by different next hops. In turn, a RESV
message forwarded
receivers Rj but selecting the same sender Si must
necessarily be merged to share a particular previous hop carries single reservation in a flowspec
that is the "maximum" over the effective reservations on the
given node.

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

Internet Draft RSVP Specification March June 1995

corresponding outgoing interfaces. Both cases represent merging,

3. Shared Explicit (SE) Style

The SE style implies the options: "shared" reservation and "
explicit" reservation scope. Thus, an SE-style reservation
creates a single reservation into which is discussed further below.

There flows from all
upstream senders are mixed. However, like a number of ways for a new FF reservation request to fail
in a given node.

1. There may be no matching path state (i.e.,
the set of senders (and therefore its scope may
empty), which would prevent the reservation being propagated
upstream.

2. Its style may be incompatible with (and therefore
the style(s) of existing
reservations for scope) is specified explicitly by the same session on receiver making the same outgoing
interface, so an effective flowspec cannot be computed.

3. Its style may be incompatible with the style(s) of
reservations
reservation.

WF and SE are both shared reservations, appropriate for those
multicast applications whose application-specific constraints make
it unlikely that exist on other outgoing interfaces but multiple data sources will
be merged with this reservation when transmit
simultaneously. One example is audio conferencing, where a refresh message to
create limited
number of people talk at once; each receiver might issue a refresh message WF or
SE reservation request for twice one audio channel (to allow some
over-speaking). On the previous hop.

4. The effective flowspec may fail admission control.

In any of these cases, an error message is returned to other hand, the
receiver(s) responsible FF style, which creates
independent reservations for the message, but any existing
reservation flows from different senders, is left in place. This prevents
appropriate for video signals.

It is not possible to merge shared reservations with distinct
reservations. Therefore, WF and SE styles are incompatible with
FF, but are compatible with each other. Merging a new, very large, WF style
reservation from disrupting the existing QoS by merging with an
existing reservation and then failing admission control.

2.2 Soft State

To maintain SE style reservation state, RSVP keeps "soft state" results in router a WF
reservation.

Other reservation options and host nodes. styles may be defined in the future
(see Appendix D.4, for example).

2. RSVP soft state is created Protocol Mechanisms

2.1 RSVP Messages

There are two fundamental RSVP message types: RESV and periodically
refreshed by PATH and RESV messages. The state is deleted if no
refreshes arrive before .

Each receiver host sends RSVP reservation request (RESV) messages
towards the expiration of a "cleanup timeout"
interval; it may also be deleted as the result of an explicit
"Teardown" message. It is not necessary (although it may be
desirable, since senders. These reservation messages must follow in
reverse the resources being consumed may be "valuable"),
to explicitly tear down an old reservation.

When a route changes, routes the next PATH message data packets will initialize use, all the
path state on way upstream
to the new route, and future sender hosts included in the scope. RESV messages will
establish reservation state, while the state on must be
delivered to the now-unused
segment of sender hosts so that the route will time out. Thus, whether a message is
"new" or a "refresh" is determined separately at each node,
depending upon hosts can set up
appropriate traffic control parameters for the existence of state at first hop.

Also note that node. (This
document uses the term "refresh message" in this effective sense, RSVP sends no positive acknowledgment messages to
indicate an RSVP message that does not modify success (although the existing
state delivery of a reservation request
to a sender could be used to trigger an acknowledgement at the node in question.) a
higher level of protocol.)

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

Internet Draft RSVP Specification March June 1995

In addition to the cleanup timeout, there is a "refresh timeout"
period. As messages arrive, the

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

Figure 4: RSVP daemon checks them against
the existing state; if it matches, Messages

Each sender transmits RSVP PATH messages forward along the cleanup timeout timer on uni-
/multicast routes provided by the state is reset and the message is dropped. At the expiration
of routing protocol(s); see Figure
4. These "Path" messages store path state in each refresh timeout period, RSVP scans its node. Path
state is used by RSVP to build and
forward PATH and route the RESV refresh messages to succeeding hops.

RSVP sends its messages as IP datagrams without reliability
enhancement. Periodic transmission hop-by-hop in the
reverse direction. (In the future, some routing protocols may
supply reverse path forwarding information directly, replacing the
reverse-routing function of refresh path state).

PATH messages by hosts
and routers is expected to replace any lost RSVP messages. To
tolerate K successive packet losses, may also carry the effective cleanup timeout
must be at least K times following information:

o Sender Template

The Sender Template describes the refresh timeout. In addition, format of data packets that
the
traffic control mechanism sender will originate. This template is in the network should form of a
filter spec that could be statically
configured to grant high-reliability service to RSVP messages, used to
protect RSVP messages select this sender's
packets from congestion losses.

In steady state, refreshing is performed hop-by-hop, which allows
merging and packing as described others in the next section. However, if
the received state differs from same session on the stored state, same link.

Like a filter spec, the stored state Sender Template is updated. Furthermore, if less than fully
general at present, specifying only sender IP address,
UDP/TCP sender port, and protocol id. The port number
and/or protocol id can be wildcarded.

o Tspec

PATH message may optionally carry a Tspec that defines an
upper bound on the result traffic level that the sender will
generate. This Tspec can be used by RSVP to modify the
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 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 set of senders Si or receivers Rj or to change any QoS
request, a host simply starts sending revised PATH and/or RESV
messages. The result should be the appropriate adjustment in prevent over-
reservation (and perhaps unnecessary Admission Control
failure) on the
distributed RSVP state, and immediate propagation to non-shared links starting at the
succeeding nodes.

The RSVP state associated with a session in a particular node is
divided into atomic elements that are created, refreshed, and
timed out independently. sender.

o Adspec

The atomicity is determined by the
requirement that any sender or receiver may enter or leave the
session at any time, and its state should be created and timed out
independently. Management of RSVP state is complex because there PATH message may not be carry a one-to-one correspondence between state carried in
RSVP control messages and the resulting state package of OPWA advertising
information, known as an "Adspec". An Adspec received in nodes. Due to
merging, a single
PATH message contain state referring to multiple
stored elements. Conversely, due is passed to reservation sharing, a single
stored state element may depend upon (typically, the maximum of)
state values received in multiple local traffic control messages.

Braden, Zhang, et al. routines,
which return an updated Adspec; the updated version is

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

Internet Draft RSVP Specification March June 1995

2.3 Merging and Packing

forwarded downstream.

Previous Incoming Outgoing Next
Hops Interfaces Interfaces Hops

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

Figure 5: Router Using RSVP

Figure 5 illustrates RSVP's model of a router node. Each data
stream arrives from a previous section explained that reservation requests hop through a corresponding
incoming interface and departs through one or more outgoing
interface(s). The same physical interface may act in RESV
messages are necessarily merged, to match both the multicast
distribution tree.
incoming and outgoing roles (for different data flows but the same
session).

As illustrated in Figure 5, there may be multiple previous hops
and/or next hops through a result, only the essential (i.e., given physical interface. This may
result from the
"largest") reservation requests are forwarded, once per refresh
period. A successful reservation request will propagate as far as connected network being a shared medium or from
the closest point(s) along existence of non-RSVP routers in the sink tree path to the sender(s) where a
reservation level equal or greater than that being requested has
been made. At that point, the merging process will drop it in
favor of another, equal or larger, reservation request.

Although flowspecs are opaque to RSVP, an next RSVP hop
(see Section 2.6). An RSVP daemon must be able
to calculate preserve the "largest" of a set of flowspecs. This next and
previous hop addresses in its reservation and path state,
respectively. A RESV message is
required both to calculate sent with a unicast destination
address, the effective flowspec to install on address of a
given physical interface (see previous hop. PATH messages, on the discussion in connection
other hand, are sent with
Figure 4), and the session destination address, unicast
or multicast.

Although multiple next hops may send reservation requests through
the same physical interface, the final effect should be to merge flowspecs when sending install
a refresh message
upstream. Since flowspecs are generally multi-dimensional vectors
(they contain both Tspec and Rspec components, each of reservation on that interface, which may
itself is defined by an effective
flowspec. This effective flowspec will be multi-dimensional), they are not strictly ordered. When
it cannot take the larger "maximum" of two flowspecs, the
flowspecs requested by the different next hops. In turn, a RESV

Braden, Zhang, et al. Expiration: December 1995 [Page 14]

Internet Draft RSVP must compute and
use Specification June 1995

message forwarded to a particular previous hop carries a third flowspec
that is at least as large as each, i.e., a
"least upper bound" (LUB). It is also possible for two flowspecs
to be incomparable, which is treated as an error. The definition
and implementation of the rules for comparing flowspecs are
outside RSVP proper, but they are defined as part of "maximum" over the service
templates.

For protocol efficiency, RSVP also allows multiple sets effective reservations on the
corresponding outgoing interfaces. Both cases represent merging,
which is discussed further below.

There are a number of path
(or reservation) information ways for the same session a new or modified reservation
request to be "packed"
into fail in a single PATH (or RESV) message, respectively. (For
simplicity, given node:

1. The effective flowspec, computed using the protocol prohibits packing different sessions into new request, may
fail admission control.

2. Administrative policy or control may prevent the same RSVP message).

2.4 Teardown

RSVP teardown messages remove requested
reservation.

3. There may be no matching path and reservation state without
waiting for (i.e., the cleanup timeout period, as an optimization to
release resources quickly. Although teardown messages (like other
RSVP messages) are not delivered reliably, scope may be
empty), which would prevent the state will time out
even if it is not explicitly deleted. reservation being propagated
upstream.

4. A teardown request reservation style that requires a unique sender may be initiated either by an application in an
end system (sender or receiver), or by have a router as
filter spece that matches more than one sender in the result path
state, due to the use of
state timeout. A router wildcards.

5. The requested style may also initiate a teardown message as be incompatible with the result style(s) of router or link failures detected by
existing reservations for the routing
protocol. Once initiated, a teardown request should same session on the same
outgoing interface, so an effective flowspec cannot be forwarded

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

Internet Draft RSVP Specification March 1995

hop-by-hop without delay.

To increase
computed.

6. The requested style may be incompatible with the reliability of teardown, Q copies style(s) of any given
teardown message can be sent. Note
reservations that exist on other outgoing interfaces but will
be merged with this reservation to create a node cannot actually
delete the state being torn down until it has sent Q Teardown
messages; it must place refresh message
for the state in a "moribund" status
meanwhile. The appropriate value previous hop.

In any of Q is these cases, an engineering issue. Q
= 1 would be error message is returned to the simplest and
receiver(s) responsible for the erroneous message, which may or
may not be adequate, since unrefreshed propagated forward along the path. An error message
does not modify state in the nodes through which it passes.
Therefore, any reservations established downstream of the node
where the failure was detected will time out anyway; teardown persist until the receiver(s)
responsible cease attempting the reservation.

In general, if the error is an optimization. If one
or more Teardown message hops are lost, likely to be repeated at every node
further along the router that failed path, it is best to
receive a Teardown message will time out its state and initiate a
new Teardown message beyond drop the loss point. Assuming that RSVP errneous message loss probability
rather than generate a flood of error messages; this is small, the longest time to delete
state will seldom exceed one refresh timeout period.

There are case
for the last four error classes listed above. The first two types error
classes, admission control and administrative policy, may or may
not allow propagation of RSVP Teardown the message, PTEAR depending upon the detailed
reason and RTEAR. A
PTEAR perhaps on local administrative policy and/or the
particular service request. More complete rules are given in the

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

Internet Draft RSVP Specification June 1995

error definitions in Appendix B.

An erroneous FILTER_SPEC object in a RESV message travels towards all receivers downstream will normally be
detected at the first RSVP hop from its
point of initiation and tears down path state the receiver application,
i.e., within the receiver host. However, an admission control
failure caused by a FLOWSPEC or a POLICY_DATA object may be
detected anywhere along the way. A
RTEAR message tears down path(s) to the sender(s).

When admission control fails for a reservation request, any
existing reservation is left in place. This prevents a new, very
large, reservation state and travels towards all
senders upstream from its point of initiation. disrupting the existing QoS by merging
with an existing reservation and then failing admission control
(this has been called the "killer reservation" problem).

A PTEAR (RTEAR)
message node may be conceptualized as a reversed-sense Path message
(Resv message, respectively).

A teardown message deletes the specified state allowed to preempt an established reservation, in the node where
it is received. Like any other state change,
accordance with administrative policy; this will be
propagated immediately also trigger an
error message to all affected receivers.

2.2 Merging and Packing

A previous section explained that reservation requests in RESV
messages are necessarily merged, to match the next node, but only if it represents
a change. multicast
distribution tree. As a result, an RTEAR message will prune only the essential (i.e., the
"largest") reservation state back (only) requests are forwarded, once per refresh
period. A successful reservation request will propagate as far as possible. Note that
the
RTEAR message will cease to be forwarded at closest point(s) along the same node sink tree to the sender(s) where a
reservation level equal or greater than that being requested has
been made. At that point, the merging suppresses forwarding process will drop it in
favor of another, equal or larger, reservation request.

For protocol efficiency, RSVP also allows multiple sets of path
(or reservation) information for the corresponding RESV messages.
The change will same session to be propagated as "packed"
into a new teardown message if single PATH (or RESV) message, respectively. (For
simplicity, the
result has been to remove all state for this session at this node.
However, protocol currently prohibits packing different
sessions into the result may simply same RSVP message). Unlike merging, packing
preserves information.

In order to merge reservations, RSVP must be able to change the propagated
information; thus, merge
flowspecs and to merge filterspecs. Merging flowspecs requires
calculating the receipt of a RTEAR message may result in the immediate forwarding "largest" of a modified RESV refresh message.

Deletion set of path state, whether as flowspecs, which are
otherwise opaque to RSVP. Merging flowspecs is required both to
calculate the result of effective flowspec to install on a teardown
message or because of timeout, may force adjustments in order given physical
interface (see the discussion in
related reservation state connection with Figure 5), and to maintain consistency in the local
node. For example,
merge flowspecs when sending a PTEAR deletes refresh message upstream. Since
flowspecs are generally multi-dimensional vectors (they contain
both Tspec and Rspec components, each of which may itself be
multi-dimensional), they are not strictly ordered. When it cannot
take the path state for larger of two flowspecs, RSVP must compute and use 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 December 1995 [Page 15] 16]

Internet Draft RSVP Specification March June 1995

2.5 Security

There are two distinct types of security concerns in RSVP.

1. Protecting RSVP Message Integrity

third flowspec that is at least as large as each, i.e., a "least
upper bound" (LUB). It may be necessary is also possible for two flowspecs 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
incomparable, which is treated as an error. The definition and
verified by neighboring RSVP nodes.

2. Authenticating Reservation Requests

RSVP-mediated resource reservations may reserve network
resources, providing special treatment
implementation of the rules for a particular set comparing flowspecs are outside
RSVP proper, but they are defined as part of users. Administrative mechanisms will be necessary to
control who gets privileged the service and to collect billing
information. These mechanisms may require secure
authentication of senders and/or receivers responsible templates
[ServTempl95a]

We can now give the complete rules for calculating the reservation. RSVP messages may contain credential
information effective
flowspec (Te, Re), to verify user identity.

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

2.6 Automatic RSVP Tunneling

It be installed on an interface. Here Te is impossible to deploy RSVP (or any new protocol) at
the same
moment throughout effective Tspec and Re is 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, effective Rspec. As an
intermediate cloud that does not support RSVP example,
consider interface (d) in Figure 5.

o Re is unable to perform
resource reservation, so service guarantees cannot be made.
However, calculated as the largest (using an LUB if there is sufficient excess capacity through such a
cloud, acceptable necessary)
of the Rspecs in RESV messages from different next hops
(e.g., D and useful realtime service D') but the same outgoing interface (d).

o The Tspecs supplied in PATH messages from different previous
hops which may still be
possible.

RSVP will automatically tunnel through such a non-RSVP cloud.
Both RSVP send data packets to this reservation (e.g.,
some or all of A, B, and non-RSVP routers forward PATH B' in Figure 5) are summed; call
this sum Path_Te.

o The maximum Tspec supplied in RESV messages towards the
destination address using their local uni-/multicast routing
table. Therefore, from different
next hops (e.g., D and D') is calculated; call this Resv_Te.

o Te is the routing GLB (greatest lower bound) of Path messages will be
unaffected Path_Te and Resv_Te.
For Tspecs defined 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 token bucket parameters, this means to
take the IP address smaller of the last RSVP-capable
router before entering bucket size and the cloud. This will effectively construct
a tunnel rate parameters.

Two filter specs can be merged only they are identical or if one
contains the other through wild-carding. The result is the cloud for RESV messages, which will more
general of the two, i.e., the one with more wildcard fields.

2.3 Soft State

To maintain reservation state, RSVP keeps "soft state" in router
and host nodes. RSVP soft state is created and periodically
refreshed by PATH and RESV messages. The state is deleted if no
refreshes arrive before the expiration of a "cleanup timeout"
interval; it may also be
forwarded directly to deleted as the result of an explicit
"teardown" message.

When a route changes, the next RSVP-capable router PATH message will initialize the
path state on the path(s)
back towards new route, and future RESV messages will
establish reservation state; the source. state on the now-unused segment
of the route will time out. Thus, whether a message is "new" or a
"refresh" is determined separately at each node, depending upon
the existence of state at that node. (This document uses the term
"refresh message" in this effective sense, to indicate an RSVP

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

Internet Draft RSVP Specification March June 1995

Automatic tunneling is

message that does not perfect; modify the existing state at the node in some circumstances it may
distribute path information
question.)

In addition to RSVP-capable routers not included
in the data distribution paths, which may create unused
reservations at these routers. This cleanup timeout, there is because PATH a "refresh timeout"
period. As messages
carry arrive, the IP source address of RSVP daemon checks them against
the previous hop, not of existing state; if it matches, the
original sender, cleanup timeout timer on
the state is reset and multicast routing may depend upon the source
as well as message is dropped. At the destination address. This can be overcome by
manual configuration expiration
of the neighboring each refresh timeout period, RSVP programs, when
necessary.

2.7 Session Groups

Section 1.2 explained that a distinct destination address, scans its state to build 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
forward PATH and RESV messages to pass reservations for all subflows succeeding hops.

RSVP sends its messages as IP datagrams without reliability
enhancement. Periodic transmission of refresh messages by hosts
and routers is expected to Admission
Control at replace any lost RSVP messages. To
tolerate K-1 successive packet losses, the same time (since it would effective cleanup
timeout must be nonsense to admit high
frequency components but reject at least K times the baseband component of refresh timeout. In
addition, the
session data). Such a logical grouping is indicated traffic control mechanism in the network should be
statically configured to grant high-reliability service to 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
messages, to protect RSVP messages from congestion losses.

In steady state, refreshing is performed hop-by-hop, which allows
merging and packing as described in the
RESV message for each of previous section. If 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
received state differs from among the
DestAddress values of stored state, the sessions in stored state is
updated. Furthermore, if the group, for example result will be to modify the smallest numerically.

o The session group ID refresh
messages to be generated, these refresh messages must be generated
and forwarded immediately. This will result in state changes
propagating end-to-end without delay. However, propagation of a
change stops when and if it reaches a point where merging causes
no resulting state change. This minimizes RSVP control traffic
due to changes and is used essential for scaling to distinguish different groups
with the same reference address.

o large multicast
groups.

The count "soft" router state maintained by RSVP is dynamic; to change
the number set of members in the group.

o senders Si or receivers Rj or to change any QoS
request, a host simply starts sending revised PATH and/or RESV
messages. The rank, result should be an integer between 1 and count, is different appropriate adjustment in
each session of the session group.

The SESSION_GROUP objects for
RSVP state and immediate propagation to all sessions in the group will
contain the same values of the reference address, nodes along the path.

The RSVP state associated with a session
group ID, in a particular node is
divided into atomic elements that are created, refreshed, and the count value.
timed out independently. The rank values establishes atomicity is determined by the
desired order among them.

If RSVP
requirement that any sender or receiver may enter or leave the
session at a given node receives a RESV message containing a
SESSION_GROUP object, it any time, so its state should wait until RESV be created and timed out
independently.

2.4 Teardown

RSVP teardown messages for all
`count' sessions have appeared (or until the end of remove path and reservation state without
waiting for the refresh cleanup timeout period, as an optimization to

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

Internet Draft RSVP Specification March June 1995

cycle) and then pass the RESV requests to Admission Control as a
group.

release resources quickly. It is normally expected that all sessions in the group
will not necessary (although it may
be routed through the same nodes. However, if not, only a
subset of desirable, since the session group reservations resources being consumed may appear at a given
node; be
"valuable"), to explicitly tear down an old reservation.

A teardown request may be initiated either by an application in this case, the RSVP should wait until the an
end of the
refresh cycle and then perform Admission Control on system (sender or receiver), or by a router as the subset result of
the session group that it has received. The rank values will
identify which
state timeout. Once initiated, a teardown request should be
forwarded hop-by-hop without delay.

Teardown messages (like other RSVP messages) are missing.

Note that routing different sessions not delivered
reliably. However, loss of a teardown message is not considered a
problem because the session group
differently state will generally result in delays in establishing time out even if it is not
explicitly deleted. If one or
rejecting more teardown message hops are
lost, the desired QoS. A "bundling" facility could be added
to multicast routing, router that failed to force all sessions in receive a session group to
be routed along the same path.

2.8 Host Model

Before teardown message will
time out its state and initiate a session can be created, the session identification,
comprised of DestAddress and perhaps new teardown message beyond the generalized destination
port, must be assigned and communicated to all
loss point. Assuming that RSVP message loss probability is small,
the senders and
receivers by some out-of-band mechanism. In order longest time to join an delete state will seldom exceed one refresh
timeout period.

There are two types of RSVP
session, the following events happen at the end systems.

H1 teardown message, PTEAR and RTEAR. A receiver joins
PTEAR message travels towards all receivers downstream from its
point of initiation and deletes path state along the multicast group specified by
DestAddress, using IGMP.

H2 way. A potential sender starts sending RSVP PATH messages to the
DestAddress, using RSVP.

H3 RTEAR
message deletes reservation state and travels towards all senders
upstream from its point of initiation. A receiver listens for PATH messages.

H4 PTEAR (RTEAR) message
may be conceptualized as a reversed-sense Path message (Resv
message, respectively).

A receiver starts sending appropriate RESV messages,
specifying teardown message deletes 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 specified state in the group (H1). Then there node where
it is received. Like any other state change, this will be no
multicast routes beyond the host (or beyond the first RSVP-
capable router) along the path;
propagated immediately to the data next node, but only if it represents
a net change after merging. As a result, an RTEAR message will be dropped at
prune the first hop until receivers(s) do appear (assuming a
multicast routing protocol that "prunes off" reservation state back (only) as far as possible.

2.5 Admission Policy and Security

RSVP-mediated QoS requests will result in particular user(s)
getting preferential access to network resources. To prevent
abuse, some form of back pressure on users will be required. This
back pressure might take the form of administrative rules, or otherwise
avoids unnecessary paths).

o Suppose of
some form of real or virtual billing for the `cost' of a
reservation. The form and contents of such back pressure is a
matter of administrative policy that may be determined
independently by each administrative domain in the Internet.

Therefore, admission control at each node is likely to contain a new sender starts sending PATH
policy component as well as a resource reservation component. As
input to the policy-based admission decision, RSVP messages (H2)
and immediately starts sending may
carry policy data. This data (H5), and there are may include credentials identifying

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

Internet Draft RSVP Specification March June 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

users or user classes, account numbers, limits, quotas, etc.

To protect the initial data may arrive at
receivers without integrity of the desired QoS.

o If a receiver starts sending RESV messages (H4) before any
PATH messages have reached policy-based admission control
mechanisms, it (H5) (and if path state is
being used may be necessary to route RESV messages), ensure the integrity of RSVP will return error
messages to the receiver. The receiver may simply choose to
ignore such error messages, against corruption or it may avoid them spoofing, hop by waiting
for PATH messages before sending RESV messages.

A specific application program interface (API) for RSVP is not
defined in hop. For this protocol spec, as it
purpose, RSVP messages may carry integrity objects that can be host system dependent.
However, Section 4.6.1 discusses the general requirements
created and
presents verified by neighboring RSVP-capable nodes. These
objects are expected to contain an encrypted part and to assume a generic API.

3. Examples

We use the following notation for
shared secret between neighbors.

User policy data in reservation request messages presents a RESV message:

1. Wildcard-Filter

WF( *{Q})

Here "*{Q}" represents
scaling problem. When a Flow Descriptor with multicast group has a "wildcard" scope
(choosing large number of
receivers, it will not be possible or desirable to carry all senders) the
receivers' policy data upstream to the sender(s). The policy data
will have to be administratively merged, near enough to the
receivers to avoid excessive policy data. Administrative merging
implies checking the user credentials and accounting data and then
substituting a flowspec of quantity Q.

2. Fixed-Filter

FF( S1{Q1}, S2{Q2}, ...) token indicating the check has succeeded. A list chain
of (sender, flowspec) pairs, i.e., flow descriptors,
packed into a single RESV message.

For simplicity we assume here trust established using an integrity field will allow upstream
nodes to accept these tokens.

Note that flowspecs are one-dimensional,
defining the merge points for example policy data are likely to be at the average throughput, and state them as a
multiple
boundaries 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 administrative domains. It may be assumed in the examples that follow. There are
three upstream senders; packets from sender S1 (S2 necessary to
carry accumulated and S3) arrive unmerged policy data upstream through previous hop (a) ((b), respectively). There are also three
downstream receivers; packets bound for R1 and R2 (R3)
multiple nodes before reaching one of these merge points.

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 routed via
outgoing interface (c) ((d) respectively).

In addition 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 such a cloud has sufficient excess capacity, it may
provide acceptable and useful realtime service.

RSVP will automatically tunnel through such a non-RSVP cloud.
Both RSVP and non-RSVP routers forward PATH messages towards the connectivity shown
destination address using their local uni-/multicast routing
table. Therefore, the routing of PATH messages will be unaffected
by non-RSVP routers in 5, we must also specify 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

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

Internet Draft RSVP Specification March June 1995

multicast routing within this node. Assume first that data packets
(hence, PATH messages) from each Si shown in Figure 5

towards the source.

Automatic tunneling 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 not perfect; in some circumstances it may
distribute path information to RSVP-capable routers not included
in the RESV data distribution paths, which may create unused
reservations at these routers. This is because PATH messages received
over outgoing interfaces (c) and () and the "Reserve" column shows
carry the resulting reservation state for each interface. The "Send"
column shows IP source address of the RESV messages forwarded to previous hops (a) hop, not of the
original sender, and
(b). In multicast routing may depend upon the "Reserve" column, each box represents one reservation
"channel", with source
as well as the corresponding filter. As destination address. This can be overcome by
manual configuration of the neighboring RSVP programs, when
necessary.

2.7 Host Model

Before a result session can be created, the session identification,
comprised of merging,
only DestAddress and perhaps the largest flowspec is forwarded upstream generalized destination
port, must be assigned and communicated 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 all the senders S2 and S3, received from outgoing interfaces (c) and (d),
are packed into
receivers by some out-of-band mechanism. When an RSVP session is
being set up, the message forwarded 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 previous hop b. On the
other hand,
DestAddress, using RSVP.

H3 A receiver application receives a PATH message.

H4 A receiver starts sending appropriate RESV messages,
specifying the two different desired flow descriptors for descriptors, using RSVP.

H5 A sender S1 application receives a RESV message.

H6 A sender starts sending data packets.

There are
merged into several synchronization considerations.

o Suppose that a new sender starts sending data (H6) but no
receivers have joined the single message FF( S1{3B} ), which is sent to
previous hop (a), For each outgoing interface, group (H1). Then there is 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 private
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 (H6), and there are
receivers but no RESV messages have reached the sender yet

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

Internet Draft RSVP Specification March June 1995

reservation for each source that has been requested, but this private
reservation is shared among

(e.g., because its PATH messages have not yet propagated to
the receiver(s)). Then the initial data may arrive at
receivers that made without 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 desired QoS. The two examples just shown assume full routing, i.e., data packets
from S1, S2, and S3 are routed to both outgoing interfaces. Assume sender could mitigate
this problem by awaiting arrival of the routing shown in Figure 8, in which data packets from S1 first RESV message
[H5]; however, receivers that are farther away may not
forwarded have
reservations in place yet.

o If a receiver starts sending RESV messages (H4) before any
PATH messages have reached it (H3), RSVP will return error
messages to interface (d) (because the mesh topology provides a
shorter path receiver. The receiver may simply choose to
ignore such error messages, or it may avoid them by waiting
for S1 -> R3 that does PATH messages before sending RESV messages.

A specific application program interface (API) for RSVP is not traverse this node).

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

Figure 8: Router Configuration

Under
defined in this assumption, Figure 9 shows Wildcard-Filter reservations.
Since there is no route from (a) to (d), protocol spec, as it may be host system dependent.
However, Section 4.6.1 discusses the reservation forwarded
out interface (a) considers only general requirements and
presents a generic API.

3. Examples

We use 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} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} )
| |_______|
|
-----------------------|----------------------------------------
| _______
WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- following notation for a RESV message:

1. Wildcard-Filter (WF)

WF( * {3B} )
| |_______| *{Q})

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

2. Fixed-Filter (FF)

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

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

3. Shared Explicit (SE)

SE( (S1,S2,...)Q1, (S3,S4,...)Q2, ...)

A list of shared reservations, each specified by a single
flowspec and a list of senders.

For simplicity we assume here that flowspecs are one-dimensional,
defining for example the average throughput, and state them as a
multiple of some unspecified base resource quantity B.

Figure 9: Wildcard-Filter Reservation Example -- Partial Routing 6 shows schematically a router with two previous hops labeled

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

Internet Draft RSVP Specification March June 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,

(a) and each of the RSVP message
types. For each RSVP message type, there is a set of rules for
the permissible ordering (b) 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

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 two outgoing interfaces labeled (c) and (d). This flag should
topology will be on in a PATH message sent by an
RSVP daemon in a sender host. The first RSVP node
that finds the flag on assumed in a PATH message (i.e., the
first-[RSVP-]hop router) should institute policing 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 flow(s) described connectivity shown in 6, we must also specify the
multicast routing within this message. This flag
should never be forwarded in node. Assume first that data packets
(hence, PATH refresh messages.

0x02 = LUB-Used

This flag is described below messages) from each Si shown in the section on Error
Messages.

Message Length

The total length of this RSVP message, including Figure 6 is routed to
both outgoing interfaces. Under this
common header assumption, Figures 7, 8, and 9
illustrate Wildcard-Filter, Fixed-Filter, and Shared-Explicit
reservations, respectively.

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

Figure 6: Router Configuration

In Figure 7, the objects included in Object Count.

RSVP Checksum

A standard TCP/UDP checksum "Receive" column shows the RESV messages received
over outgoing interfaces (c) and (d) and the contents of "Reserve" column shows
the RSVP
message, with resulting reservation state for each interface. The "Send"
column shows the checksum field replaced by zero.

Object Count

Count of variable-length objects that follow.

4.1.2 Object Formats

An object consists of RESV messages forwarded to previous hops (a) and
(b). In the "Reserve" column, each box represents one or more 32-bit words reservation
"channel", with a one-word
header, in the following format:

0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class | C-Type |
+-------------+-------------+-------------+-------------+
| |
// (Object contents) //
| |
+-------------+-------------+-------------+-------------+

An object header has the following fields:

Length

Total length in bytes. Must always be corresponding filter. As a multiple result of 4,
and at least 4. merging,
only the largest flowspec is forwarded upstream to each previous hop.

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

Internet Draft RSVP Specification March June 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.

Figure 7: Wildcard-Filter Reservation Example 1 = SESSION

Contains the IP destination address (DestAddress)

Figure 8 shows Fixed-Filter (FF) style reservations. The flow
descriptors for senders S2 and
possibly a generalized source port, S3, received from outgoing interfaces
(c) and (d), are packed into the message forwarded to define a
specific session for previous hop b.
On 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 hand, the IP address of two different flow descriptors for sender S1
are merged into the RSVP-capable node that single message FF( S1{3B} ), which is sent this message. This document refers to
previous hop (a). For each outgoing interface, there is a
RSVP_HOP object as a PHOP ("previous hop") object for
downstream messages or as a NHOP ("next hop") object private
reservation for upstream messages.

4 = STYLE

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

Finally, Figure 9 shows a simple example of Shared-Explicit (SE)
style plus style-specific
information reservations. Here each outgoing interface has a single
reservation that is not shared by 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 list of session data packets that should
receive the desired QoS (specified by an FLOWSPEC senders.

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

Internet Draft RSVP Specification March June 1995

object), in a RESV message.

7 = SENDER_TEMPLATE

Contains a sender IP address

Figure 8: Fixed-Filter Reservation Example

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

Figure 9: Shared-Explicit Reservation Example

The three examples just shown assume full routing, i.e., data packets
from S1, S2, and perhaps some
additional demultiplexing information S3 are routed to identify a
sender, in a PATH message.

8 = SENDER_TSPEC

Defines the traffic characteristics both outgoing interfaces. The top
part of a sender's Figure 10 shows another routing assumption: data stream, in a PATH message.

9 = ADVERT

Carries an Adspec containing OPWA data, in packets
from S1 are not forwarded to interface (d), because the mesh topology
provides a PATH
message.

10 = TIME_VALUES

If present, contains values shorter path for the refresh period R
and the state time-to-live T (see section 4.5), to
override the default values S1 -> R3 that does not traverse this
node. The bottom of 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 Figure 10 shows WF style reservations under this
assumption. Since there is no route from (a) to authenticate (d), the
originating node, and perhaps verify reservation
forwarded out interface (a) considers only 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 formats of specific object types are defined reservation on
interface (c); no merging takes place in Appendix A. this case.

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

Internet Draft RSVP Specification March June 1995

4.1.3 Path Message

PATH messages carry information from 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 that sent the message (if possible, the
address of the particular interface through which it was sent).

The format of a PATH message is as follows:

[ <INTEGRITY> ] [ <TIME_VALUES> ]

_______________
(a)| |

[ <SENDER_TSPEC> ] [ <ADVERT> ]

Each sender descriptor defines (c)
( S1 ) ---------->| --------->--> |----------> ( R1, R2)
| / |
| / |
(b)| / | (d)
( S2,S3 ) ------->| ->----------> |----------> ( R3 )
|_______________|

Router Configuration

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

Finally, we note that state that is received through a sender, and particular
interface Iout in never forwarded out the sender
descriptor list allows multiple sender descriptors to same interface.
Conversely, state that is forwarded out interface Iout must be packed
into
computed using only state that arrived on interfaces different from
Iout. A trivial example of this rule is illustrated in Figure 11,
which shows a PATH message. For each 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 list, RESV messages are forwarded to all previous hops for
senders in the
SENDER_TEMPLATE object defines group, with the format exception of data packets, the
SENDER_TSPEC object may specify the traffic flow, and the
CREDENTIAL object may specify next hop from which
they came. These result in independent reservations in 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 replicated as necessary to follow the delivery
path(s) for two
directions.

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

Internet Draft RSVP Specification June 1995

________________
a data packet from the same sender, finally
reaching the applications | | c
( R1, S1 ) <----->| Router |<-----> ( R2, S2 )
|________________|

Send | Receive
|
WF( *{3B}) <-- (a) | (c) <-- WF( *{3B})
|
Receive | Send
|
WF( *{4B}) --> (a) | (c) --> WF( *{4B})
|
Reserve 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 the uni/multicast routing table, generally depend upon the
(sender host address, DestAddress) pairs, and consist of a list
of outgoing interfaces. Then the descriptors being forwarded
through the same outgoing interface can be packed into as few (a) | Reserve on (c)
__________ | __________
| * {4B} | | | * {3B} |
|__________| | |__________|
|

Figure 11: Independent Reservations

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

Internet Draft RSVP Specification March June 1995

PATH

4. RSVP Functional Specification

4.1 RSVP Message Formats

All RSVP messages as possible. Note consist of a common header followed by a
variable number of variable-length typed "objects". The
subsections that multicast routing follow define the formats of path
information is based on the sender address(es) from common header,
the sender
descriptors, not the IP source address; this is necessary to
prevent routing loops; see Section 4.3. PHOP (i.e., the
RSVP_HOP object) of each PATH message should contain the IP
source address, the interface address through which object structures, and each of the RSVP message
is sent.

PATH messages are processed at types.

For 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 RSVP message type, there is
sent to all senders implied by a set of rules for the SENDER_TEMPLATEs
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

The fields in the
sender descriptor list.

4.1.4 Resv Messages common header are as follows:

Vers

Protocol version number. This is version 2.

Flags

(None defined yet)

Type

1 = PATH

2 = RESV messages carry reservation requests hop-by-hop from
receivers to senders, along

3 = PERR

4 = RERR

5 = PTEAR

6 = RTEAR

Braden, Zhang, et al. Expiration: December 1995 [Page 28]

Internet Draft RSVP Specification June 1995

RSVP Checksum

A standard TCP/UDP checksum over the reverse paths contents of data flow for the session. RSVP
message, with the checksum field replaced by zero.

Message Length

The IP destination address total length of a RESV this RSVP message is in bytes, including
this common header and the unicast address variable-length objects that
follow.

4.1.2 Object Formats

An object consists of one or more 32-bit words with a previous-hop node, obtained from one-word
header, in the
path state. The Next Hop address (in the RSVP_HOP object)
should be the IP address of the (incoming) interface through
which the RESV message is sent. The IP source address is an
address of the node that sent following format:

0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| |
// (Object contents) //
| |
+-------------+-------------+-------------+-------------+

An object header has the message (if possible, following fields:

Length

A 16-bit field containing the
address total object length in
bytes. Must always be a multiple of 4, and at least 4.

Class-Num

Identifies the particular interface through which it was sent).

The permissible sequence object class; values of objects this field are
defined in Appendix A. Each object class has a RESV message depends
upon the reservation style specified name,
which will always be capitalized in this document. An
RSVP implementation must recognize the STYLE object.
Currently, following classes:

NULL

A NULL object types Style-WF and Style-FF has a Class-Num of class STYLE
are defined (see Appendix A).

The RESV message format zero, and its C-Type
is as follows:

[ <SESSION_GROUP> ] <RSVP_HOP>

[ <INTEGRITY> ] [ <TIME_VALUES> ]

[ <CREDENTIAL> ]

<Style-WF> [ <FILTER_SPEC> ] <FLOWSPEC> | 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.

Braden, Zhang, et al. Expiration: September December 1995 [Page 28] 29]

Internet Draft RSVP Specification March June 1995

<Style-FF> <flow descriptor list>

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

The reservation scope, i.e.,

SESSION

Contains the set of senders towards which IP destination address (DestAddress) and
possibly a
particular reservation is to be forwarded, is determined by
matching FILTER_SPEC objects against generalized destination port, to define a
specific session for the path state created
from SENDER_TEMPLATE objects, considering any wildcards other objects that
may be present.

4.1.5 Error Messages

There are two types of follow.
Required in every RSVP error messages:

o PERR messages result from PATH messages and travel towards
senders. PERR messages are routed hop-by-hop like RESV
messages; at each hop, message.

RSVP_HOP

Carries the IP destination address is the
unicast address of the RSVP-capable node that
sent this message. This document refers to a previous hop.

o RERR messages result from RESV
RSVP_HOP object as a PHOP ("previous hop") object for
downstream messages or as a NHOP ("next hop") object
for upstream messages.

TIME_VALUES

If present, contains values for the refresh period R
and travel hop-
by-hop towards the appropriate receivers, routed by state time-to-live T (see section 4.5), to
override the default values of R and T.

STYLE

Defines the reservation state. At each hop, style plus style-specific
information that is not a FLOWSPEC or FILTER_SPEC
object, in a RESV message.

FLOWSPEC

Defines a desired QoS, in a RESV message.

FILTER_SPEC

Defines a subset of session data packets that should
receive the desired QoS (specified by an FLOWSPEC
object), in a RESV message.

SENDER_TEMPLATE

Contains a sender IP destination address is and perhaps some
additional demultiplexing information to identify a
sender, in a PATH message.

SENDER_TSPEC

Defines the unicast address traffic characteristics of a next-hop node.
Routing is discussed below.

RSVP error messages are triggered only by processing of sender's
data stream, in a 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> message.

Braden, Zhang, et al. Expiration: September December 1995 [Page 29] 30]

Internet Draft RSVP Specification March June 1995

The

ADSPEC

Carries an Adspec containing OPWA data, in a PATH
message.

ERROR_SPEC specifies the error. It includes the IP address
of the node that detected the

Specifies an error, called the Error Node
Address.

When in a PERR or RERR message.

POLICY_DATA

Carries information that will allow a local policy
module to decide whether an associated reservation is
administratively permitted. May appear in a PATH or
RESV message has been "packed" with multiple
sets of elementary parameters, message.

INTEGRITY

Contains cryptographic data to authenticate the
originating node, and perhaps to verify the contents,
of this RSVP implementation should
process each set independently message.

SCOPE

An explicit specification of the scope for forwarding
a RESV message.

TAG

Encloses a list of one or more objects and return attaches a separate error
message for each that
logical name or "tag" value to them. The tag value
is in error.

An error message may be duplicated and forwarded unchanged. In
general, error messages should be delivered unique to the applications
on all next/previous hop and the session nodes that (may have) contributed to this
error.

o A PERR message
(specified by HOP and SESSION objects, respectively).
The enclosed object list is forwarded to all previous hops for all
senders listed the "tagged sublist", and
the objects in it said to be "tagged" with the Sender Descriptor List.

o The node that creates tag
value. Objects in a RERR message as particular tagged sublist must
all have the result of
processing a RESV message should send the RERR message out
the interface through which the RESV arrived.

In succeeding hops, same class-num.

Tagged objects with the routing same tag value are declared
to be logically related, i.e., to be members of a RERR message depends
upon its style and upon routing. In general, a RERR
message is sent out some subset
larger logical set of objects. Note that the outgoing interfaces
specified for multicast routing, using Error Node Address
as the source address and DestAddress as the destination.
(This rule is necessary to prevent packet loops; see
Section 4.3 below). Within this tagged
sublist implies no ordering; it defines only a set of outgoing
interfaces, a RERR message is sent only to next hop(s)
whose RESV message(s) created
objects.

The meaning of the error; this in turn logical relationship depends upon
the merging class-num of flowspecs. Assume that a
reservation whose error is being reported was formed by
merging two flowspecs Q1 and Q2 from different next hops.

- If Q1 = Q2, the error message should be forwarded to
both next hops.

- If Q1 < Q2, the error message should be forwarded
only to the next hop for Q2.

- If Q1 and Q2 are incomparable, the error message
should be forwarded to both next hops, and the LUB
flag should be turned on. tagged objects.

C-Type

Braden, Zhang, et al. Expiration: September December 1995 [Page 30] 31]

Internet Draft RSVP Specification March June 1995

Object type, unique within Class-Num. Values are defined
in Appendix A.

The ERROR_SPEC maximum object content length is 65528 bytes. The Class-
Num and C-Type fields (together with the LUB-flag should 'Optional' flag bit)
may be delivered used together as a 16-bit number to the
receiver application. In the case define a unique type
for each object.

The high-order bit of an Admission Control
error, the style-specific tail will contain the FLOWSPEC
object that failed. Class-Num is used to determine what
action a node should take if it does not recognize the Class-
Num of an object. If Class-Num < 128, then the LUB-flag is off, this node should
be
ignore 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 but forward it (unmerged). If Class-Num >=
128, the message will
normally should be detected at the first RSVP hop from the
receiver application, i.e., within the receiver host.
However, rejected and an admission control failure caused by a FLOWSPEC
or a CREDENTIAL "Unknown Object
Class" error returned. Note that merging cannot be performed
on unknown object types; as a result, unmerged objects may be detected anywhere along the
path(s)
forwarded to the sender(s).

4.1.6 Teardown Messages

There are two types of RSVP Teardown message, PTEAR first node that does know how to merge them.
The scaling limitations that this imposes must be considered
when defining and RTEAR.

o PTEAR deploying new object types.

4.1.3 Path Message

PATH messages delete path state (which in turn may delete
reservations state) and travel towards all receivers that
are downstream carry information from senders to receivers along
the point of initiation. PTEAR
messages are routed like PATH messages, and their paths used by the data packets. The IP destination address
of a PATH message is the DestAddress for the session.

o RTEAR messages delete reservation state and travel towards
all matching senders upstream from session; the point of teardown
initiation. RTEAR message are routed like RESV messages,
and their IP destination
source address is an address of the node that sent the message
(preferably the unicast address of
a previous hop.

[ <INTEGRITY> ]

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

<ResvTear the interface through which it was
sent). The PHOP (i.e., the RSVP_HOP) object of each PATH
message should contain the IP source address.

The format of a PATH message is as follows:

[ <INTEGRITY> ] [ <CREDENTIAL> <TIME_VALUES> ]

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

Flowspec objects in the style-specific tail of <empty > |

<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]

[ <POLICY_DATA> ] [ <ADSPEC> ]

Each sender descriptor defines a RTEAR message sender, and the sender
descriptor list allows multiple sender descriptors to be packed

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

Internet Draft RSVP Specification March June 1995

will be ignored and may be omitted.

into a PATH message. For each sender in the state being deleted was created with user credentials
from list, the
SENDER_TEMPLATE object defines the format of data packets; in
addition, a CREDENTIAL field, then SENDER_TSPEC object may specify the matching PTEAR or RTEAR
message must include matching CREDENTIAL field(s).

[There is traffic flow, a problem here: tearing down path state
POLICY_DATA object may
implicitly delete reservation state. But specify user credential and accounting
information, and an ADSPEC object may carry advertising (OPWA)
data.

Each sender host must periodically send PATH message(s)
containing a PTEAR message does
not have credentials sender descriptor for each its own data stream(s).
Each sender descriptor is forwarded and replicated as necessary
to follow the reservation state, only delivery path(s) for a data packet from the
path state. Some argue same
sender, finally reaching the applications on all receivers
(except that a CREDENTIAL may it is not be needed looped back to a receiver included in
teardown messages, on
the assumption that false teardown
messages can be injected only with the collusion of routers
along same application process as the data path, and in sender).

It is an error to send ambiguous path state, i.e., two or more
Sender Templates that case, the colluding router can
just as well stop delivering the RESV messages, which will have
the same effect.]

4.2 Sending RSVP Messages

RSVP messages are sent hop-by-hop between RSVP-capable routers different but overlap, due to
wildcards. For example, if we represent a Sender Template as
"raw" IP datagrams,
(IP address, sender port, protocol number 46. Raw IP datagrams are
similarly intended id and use `*' to represent
a wildcard, then each of the following pairs of Sender
Templates would be used between an end system and the
first/last hop router; however, it error:

(10.1.2.3, 34567, *) and (10.1.2.3, *, *)

(10.1.2.3, 34567, *) and (10.1.2.3, 34567, 17)

A PATH message received at a node is also possible processed to encapsulate
RSVP messages as UDP datagrams create path
state for end-system communication, as
described all senders defined by SENDER_TEMPLATE objects in Appendix C. UDP encapsulation will simplify
installation of RSVP on current end systems, particularly when
firewalls the
sender descriptor list. If present, any POLICY_DATA,
SENDER_TSPEC, and ADSPEC objects are also saved in use.

Under overload conditions, lost RSVP control messages could cause the loss of resource reservations. Routers should be configured
to give path
state. If an error is encountered while processing a preferred class of service PATH
message, a PERR message is sent to RSVP packets. RSVP should
not use significant bandwidth, but all senders implied by the queueing delay for RSVP
messages needs
SENDER_TEMPLATEs.

Periodically, the path state is scanned to be controlled.

An RSVP create new PATH or RESV message consists of a small root segment
followed by a variable-length list of objects,
messages which may overflow are forwarded upstream. A node must
independently compute the capacity of one datagram. IP fragmentation is inadvisable,
since it has bad error characteristics; RSVP-level fragmentation
should be used. That is, a message with route for each sender descriptor
being forwarded. These routes, obtained from uni-/multicast
routing, generally depend upon the (sender host address,
DestAddress) pairs and consist of a long list of outgoing
interfaces. The descriptors will being forwarded through the same
outgoing interface may be divided packed into segments as few PATH messages as
possible. Note that will fit into
individual datagrams, each carrying the same root fields. Each multicast routing of
these messages will be processed at the receiving node, with a
cumulative effect path information is
based on the local state. No explicit reassembly sender address(es) from the sender descriptors,
not the IP source address; this is
needed.

Since RSVP messages are normally expected necessary to be generated and sent
hop-by-hop, their MTU should be determined by prevent routing
loops; see Section 4.3.

Multicast routing may also report the MTU of each
interface. expected incoming

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

Internet Draft RSVP Specification March June 1995

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

interface connected to a non-RSVP cloud in
which some particular link far away has a smaller MTU. This would
affect only those sessions that happened (i.e., the shortest path back to use the sender). If so,
any PATH message that link.
Proper solution to this case would require MTU discovery
separately for each arrives on a different interface and each session, which should
be discarded immediately.

It is a very
large amount of machinery and some overhead possible that routing will report no routes for a rare (?) case.
Best approach seems to
(sender, DestAddress) pair; path state for this sender should
be to rely on IP fragmentation and
reassembly for this case.]

4.3 Avoiding RSVP Message Loops

We must ensure that the rules for forwarding RSVP control messages
avoid looping. In steady state, PATH and stored locally but not forwarded.

4.1.4 Resv Messages

RESV messages are
forwarded on each hop only once per refresh period. This avoids
directly looping packets, but there is still carry reservation requests hop-by-hop from
receivers to senders, along the possibility reverse paths of an
" auto-refresh" loop, clocked by data flow for
the refresh period. session. The effect IP destination address of such a loop RESV message is to keep state active "forever", even if
the end
nodes have ceased refreshing it (but unicast address of a previous-hop node, obtained from the state will be deleted
when
path state. The IP source address is an address of the receivers leave node
that sent the multicast group and/or message. The NHOP (i.e., the senders
stop sending PATH messages).

In addition, error and teardown messages are forwarded immediately
and are therefore subject to direct looping.

PATH messages are forwarded using routes determined by RSVP_HOP) object
must contain the
appropriate routing protocol. For routing that is source-
dependent (e.g., some multicast routing algorithms), IP address of the RSVP
daemon must route each sender descriptor separately using (incoming) interface through
which the
source addresses found in RESV message is sent.

The RESV message format is as follows:

[ <INTEGRITY> ] [ <TIME_VALUES> ]

[ <SCOPE> ]

The following style-dependent rules control the SENDER_TEMPLATE objects. This
should ensure that there will be no auto-refresh loops composition of PATH
information, even in
a topology with cycles.

Since PATH messages don't loop, they create path state defining a
loop-free reverse path to each sender. As a result, RESV and
RTEAR messages directed to particular senders cannot loop. PERR
messages are always directed to particular senders and therefore
cannot loop. However, there valid flow descriptor list.

o WF Style:

<flow descriptor list> ::=

<FLOWSPEC> [ <POLICY_DATA> ] [ <FILTER_SPEC> ]

A FILTER_SPEC that is a potential auto-refresh problem
for RESV, RTEAR, and RERR messages with wildcard scope, as we now
discuss.

If the topology has no loops, then auto-refresh can be avoided,
even for entire wildcard scope, with the following rule:

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

o FF style:

<flow descriptor list> ::=

Braden, Zhang, et al. Expiration: September December 1995 [Page 33] 34]

Internet Draft RSVP Specification March June 1995

This rule

| <flow descriptor list> [ <FLOWSPEC> ]

[ <POLICY_DATA> ] <FILTER_SPEC>

Each elementary FF style request 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 defined by a single
(FLOWSPEC, FILTER_SPEC) pair, and c
are both outgoing and incoming interfaces for this session. Both
receivers are making wildcard-scope reservations, in which multiple such requests
may be packed into the flow descriptor list of a single
RESV messages are forwarded message. A FLOWSPEC or POLICY_DATA object can be
omitted if it is identical to all previous hops for senders in
the group, with the exception of the next hop from which they
came. These result in independent reservation requests most recent such object
that appeared in the two
directions, without an auto-refresh loop.

________________
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} |
|__________| list.

o SE style:

| |__________| <flow descriptor list> <SE descriptor>

<SE descriptor> ::= <FLOWSPEC> [ <POLICY_DATA> ]

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

However, further effort <filter spec list> <FILTER_SPEC>

Each elementary SE style request is needed to prevent auto-refresh loops
from wildcard-scope reservations in defined by a single SE
descriptor, which includes a FLOWSPEC defining the presence shared
reservation, possibly a POLICY_DATA object, and a list of cycles in
FILTER_SPEC objects. Multiple elementary requests, each
representing an independent shared reservation, may be
packed into the
topology. [TBD!!].

We treat routing flow descriptor list of RERR messages as a special case. They are
sent with unicast addresses of next hops, but the multicast
routing single RESV
message. A POLICY_DATA object may be omitted if it is used to prevent loops. As explained above, RERR
messages are forwarded to a subset of the multicast tree
identical to
DestAddress, rooted at the node on which most recent such object that appeared in
the error was discovered.
Since multicast routing cannot create loops, this will prevent
loops for RERR messages.

[Open question about Figure 10: should it be possible to have
incompatible list.

The reservation styles on scope, i.e., the two interfaces? For
example, if R1 requests set of sender hosts towards
which a WF particular reservation and R2 requests a FF
reservation, it is logically possible to make be forwarded, is
determined as follows:

o For a style with explicit scope, match each FILTER_SPEC
object against the corresponding
reservations on path state created from SENDER_TEMPLATE
objects to select a particular sender. It is an error if
a FILTER_SPEC matches more than one SENDER_TEMPLATE, due
to wildcarding. A SCOPE object, if present, should be
ignored.

o For a style with wildcard scope, a SCOPE object, if
present, defines the two different interfaces. The current scope with an explicit list of sender

Braden, Zhang, et al. Expiration: September December 1995 [Page 34] 35]

Internet Draft RSVP Specification March June 1995

implementation does NOT allow this; instead, it prevents mixing

IP addresses (see Section 4.3 below). If there is no
SCOPE object, the scope is determined by the relevant set
of
incompatible styles senders in the same session on a node, even if they
are on different interfaces.]

4.4 Local Repair

Each RSVP daemon periodically sends refreshes path state. A SCOPE object must be sent
in any wildcard scope RESV message that is forwarded to its next/previous
hops. An important optimization would allow the local routing
protocol module
more than one previous hop. See Section 4.3 below.

If an outgoing message is too large to notify fit into the RSVP daemon of route changes for
particular destinations. The RSVP daemon should use this
information to trigger an immediate refresh MTU of state for these
destinations, using the new route. This allows fast adaptation
interface, it can be sent as multiple messages, as follows:

o For FF style, the flow descriptor list can be split as
required to
routing changes without fit; the overhead rest of a short refresh period.

4.5 Time Parameters

For each element the message should be
replicated into each packet.

o For WF style, a SCOPE object containing an explicit list
of state, there are two time parameters: sender IP addresses can be split as required to fit;
the
refresh period R and rest of the time-to-live value T. R specifies message should be replicated into each
packet.

o For SE style, the
period between sending successive refreshes of this data. T
controls how long state will flow descriptor list can be retained after refreshes stop
appearing, and depends upon period between receiving successive
refreshes. Specifically, R <= T, and split as
required to fit; the "cleanout time" is K *
T. Here K is a small integer; K-1 successive messages may rest of the message should be lost
before state is deleted. Currently K = 3 is suggested.

Clearly, a smaller T means increased RSVP overhead.
replicated into each packet.

If the router
does not implement local repair, a smaller T improves the speed of
adapting single SE descriptor is too large to routing changes. With local repair, a router fit, its filter
spec list can similarly be
more relaxed about T, since split as required. However,
the periodic refresh becomes only a
backstop robustness mechanism.

There are three possible ways for subsets of a router to determine R and T.

o Default values are configured particular filter spec list must each be
enclosed in TAG objects carrying the router. Current
defaults are 30 seconds for T and R.

o A router may adjust same tag value, so
the value of T dynamically receiver will be able to keep a
constant total overhead due match each FILTER_SPEC object
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, appropriate shared reservation.

4.1.5 Error Messages

There are two types of RSVP error messages.

o PERR messages result from PATH and RESV messages may contain the optional
TIM_VALUES object. When and travel towards
senders. PERR messages are merged and forwarded to routed hop-by-hop using the next
path state; at each hop, R should be the minimum R that has been
received, and T should be the maximum T that has been
received. Thus, the largest T determines how long state IP destination address is
retained, and the smallest R determines the responsiveness
unicast address of

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

Internet Draft RSVP Specification March 1995

RSVP to route changes. In a previous hop.

o RERR messages result from RESV messages and travel towards
the first hop, they appropriate receivers. They are expected
to be equal. The RSVP API might allow an application to
override routed hop-by-hop
using the default value for reservation state; at each hop, the IP
destination address is the unicast address of a particular session. next-hop
node.

Errors encountered while processing error messages must not
create further error messages.

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

Internet Draft RSVP Specification March June 1995

4.6 RSVP Interfaces

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

[ <INTEGRITY> ] <ERROR_SPEC>

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

[ <INTEGRITY> ] <ERROR_SPEC>

The following style-dependent rules control (if it
exists on the host).

4.6.1 Application/RSVP Interface

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

o Register

Call: REGISTER( DestAddress , DestPort

[ , SESSION_object ] , SND_flag , RCV_flag

[ , Source_Address ] [ , Source_Port ]

[ , Sender_Template ] [ , Sender_Tspec ]

[ , Data_TTL ] [ , UserCredential ] WF Style:

<error flow descriptor> ::= <FLOWSPEC> [ , Upcall_Proc_addr <FILTER_SPEC> ] ) -> Session-id

This call initiates RSVP processing for a session, defined
by DestAddress together with

o FF style:

o SE style:

The ERROR_SPEC object specifies the TCP/UDP port number
DestPort. If successful, error and includes 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 IP
address of the
session ("generalized destination port"), should node that be
necessary in detected the future. Normally SESSION_object will be
omitted; if it is supplied, it should be an
appropriately-formatted representation of error (Error Node
Address).

When a SESSION
object.

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

In general, error messages should be set true if delivered to the host will receive
data. Setting neither true is an
applications on all the session nodes that (may have)
contributed to this error. The optional
parameters Source_Address, Source_Port, Sender_Template, More specifically:

o A PERR message is forwarded to all previous hops for all

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

Internet Draft RSVP Specification March June 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

senders listed in the Sender Descriptor List.

o A RERR message is true, a successful REGISTER call will cause
RSVP generally forwarded to begin sending PATH messages for this session using
these parameters, which are interpreted as follows:

- Source_Address

This is the address of the interface from which all receivers
that may have caused the
data will be sent. If it is omitted, error being reported.

The node that creates a default
interface will be used.

- Source_Port

This is RERR message sends the UDP/TCP port RERR
message to the next hop from which the data will be
sent. If it is omitted or zero, erroneous
reservation came. The message must contain the port is "wild"
information required to define the error and can match any port in a FILTERSPEC.

- Sender_Template

This parameter is included as an escape mechanism to
support route the
error message. Thus, it contains the STYLE, a FLOWSPEC,
and one or more general definition of FILTER_SPEC(s) from the sender
("generalized source port"). Normally this parameter
may be omitted; if it is supplied, it should be an
appropriately formatted representation of erroneous RESV
message.

In succeeding hops, a
SENDER_TEMPLATE object.

- Sender_Tspec

This parameter RERR message is a Tspec describing forwarded using the traffic flow
to be sent. It may be included
node's reservation state, to prevent over- the next hops of reservations
that match the FILTER_SPEC(s) and the FLOWSPEC in the RERR
message. Assume that a reservation on whose error is being
reported was formed by merging two flowspecs Q1 and Q2
from different next hops.

- If Q1 = Q2, the initial error message should be forwarded to
both next hops.

- Data_TTL

This is If Q1 < Q2, the (non-default) IP Time-To-Live parameter error message should be forwarded
only to the next hop for Q2.

- If Q1 and Q2 are incomparable, the error message
should be forwarded to both next hops, and the LUB-
Used flag should be turned on.

The RERR message that is being supplied on forwarded should carry the data packets. It
FILTER_SPEC from the corresponding reservation state (thus
`un-merging' the filter spec). For reservations with
wildcard scope, there is
needed an additional limitation on
forwarding RERR messages, to ensure that Path messages do not have avoid loops; see Section 4.3
below.

When a
scope larger than multicast data packets.

Finally, Upcall_Proc_addr is RERR message reaches a receiver, the address STYLE object,
flow descriptor list, and ERROR_SPEC object (which
contains the LUB-Used flag) should be delivered to the
receiver application. In the case of an upcall
procedure Admission Control
error, the flow descriptor list will contain the FLOWSPEC
object that failed. If the LUB-Used flag is off, this
should be `equal' to receive asynchronous error or event
notification; see below.

o Reserve

Call: RESERVE( session-id, style, style-dependent-parms ) (but not necessarily identical to)
the FLOWSPEC originated by this application; otherwise,
they may differ.

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

Internet Draft RSVP Specification March June 1995

A receiver uses this call to make a resource reservation
for the session registered as `session-id'. The style
parameter indicates the reservation style. The rest

4.1.6 Teardown Messages

There are two types of RSVP Teardown message, PTEAR and RTEAR.

o A PTEAR message deletes path state (which may, in turn,
delete reservation state) and travels towards all
receivers that are downstream from the parameters depend upon point of
initiation. A PTEAR message is routed like a PATH
message, and its IP destination address is DestAddress for
the style, but generally these
will include appropriate flowspecs session.

o A RTEAR message deletes reservation state and filter specs.

The first RESERVE call will initiate travels
towards all matching senders upstream from the periodic
transmission point of RESV messages.
teardown initiation. A later RESERVE call RTEAR message is routed like a
corresponding RESV message (using the same scope rules).
Its IP destination address is the unicast address of a
previous hop.

[ <INTEGRITY> ]

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

[ <INTEGRITY> ] [ <SCOPE> ]

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

FLOWSPEC or POLICY_DATA objects in the flow descriptor list of
a RTEAR message will be ignored and may be given omitted.

Note that the RTEAR message will cease to modify be forwarded at the parameters
same node where merging suppresses forwarding of the earlier call (but
note that changing
corresponding RESV messages. The change will be propagated as
a new teardown message if the reservations result has been to remove all
state for this session at this node; otherwise, it may result
in
admission control failure, depending upon the style).

The RESERVE call returns immediately. Following immediate forwarding of a 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 session
specified by session-id. It may send appropriate teardown
messages and will cease sending refreshes for this
session-id.

o 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 upcall procedure whose
address was supplied in modified RESV refresh message.

Deletion of path state, whether as the REGISTER call.

This upcall may occur asynchronously at any time after a
REGISTER call and before result of a RELEASE call, to indicate an
error teardown
message or an event. Currently there are three upcall
types, distinguished by the Info_type parameter:

1. Info_type = Path Event

A Path Event upcall indicates the receipt because of a PATH
message, indicating timeout, may force adjustments in related
reservation state to maintain consistency in the application that there is local node.

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

Internet Draft RSVP Specification March June 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

The adjustment in reservation state depends upon the style.
For example, suppose a Path Event upcall.

2. Info_type = Path Error

An Path Error event indicates an error in processing PTEAR deletes the path state for 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 S. If the error. `List_count'
will style specifies distinct reservations (FF),
only reservations for sender S should be 1, and Filter_spec_list and Flowspec_list
will contain the Sender_Template and deleted; if the Sender_Tspec
supplied in style
specifies shared reservations (WF or SE), delete the REGISTER call; Advert_list will
contain one NULL object.

3. Info_type = Resv Error

An Resv Error event indicates an error in processing
a RESV message to which
reservation if this application contributed.
The Error_code parameter will define the error, and
Error_value may supply some additional (perhaps
system-specific) data on was the error.

`List_count' will be 1, and Filter_spec_list and
Flowspec_list will contain one FILTER_SPEC and one
FLOWSPEC object. last filter spec. These objects are taken from the
reservation changes should not trigger an immediate RESV
refresh message, since the teardown message that caused will have already
made the error (unless required changes upstream. However, at the LUB-
flag is on, node in
which case FLOWSPEC a RTEAR message stops, the change of reservation state
may differ).

Although trigger a RESV refresh starting at that node.

4.2 Sending RSVP Messages

RSVP messages indicating path events or errors
may be received periodically, the API should make the
corresponding asynchronous upcall to the application only
on the first occurrence, or when the information are sent hop-by-hop between RSVP-capable routers as
"raw" IP datagrams with protocol number 46. Raw IP datagrams are
similarly intended to be
reported changes.

4.6.2 RSVP/Traffic Control Interface

In each router used between an end system and host, enhanced QoS the
first/last hop router; however, it is achieved by a group also possible to encapsulate
RSVP messages as UDP datagrams for end-system communication, as
described in Appendix C. UDP encapsulation may simplify
installation of
inter-related traffic control functions: a packet classifier,

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

Internet Draft RSVP Specification March 1995

an admission on current end systems, particularly when
firewalls are in use.

Under overload conditions, lost RSVP control module, and messages could cause
a packet scheduler. This
section describes failure of resource reservations. Routers should be configured
to give a generic preferred class of service to RSVP interface packets. RSVP should
not use significant bandwidth, but queueing delay and dropping of
RSVP messages needs to traffic control.

1. Make a Reservation

Call: Rhandle = TC_AddFlowspec( Flowspec, Police_Flag

[ , Sender_Tspec]

[ , SD_rank , SD_end_flag ] )

This call passes be controlled.

An RSVP PATH or RESV message generally consists of a Flowspec defining small root
segment followed by a desired QoS to
admission control. It potentially unbounded variable-length list
of objects. The variable part may also pass Sender_Tspec, overflow the
maximum traffic characteristics computed over capacity of one
datagram. If RSVP used IP fragmentation and reassembly (or an
equivalent byte-by-byte fragmentation mechanism at the
SENDER_TSPECs RSVP
level), loss 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 single packet would unnecessarily lose the
entire state update for a member
of a session group. SD_rank session. It is instead recommended that
an RSVP implementation use "semantic" fragmentation, using the rank value from the
SESSION_GROUP object. The call is made with each
structure of the
sessions RSVP message.

An unbounded list in the group, and SD_end_flag is set true for the
last one.

This call returns an error code if Flowspec is malformed
or if the requested resources RSVP message in fact consists of
individual atomic elements that are unavailable. Otherwise,
it establishes packed together for
efficiency. Wben sending a new reservation channel corresponding to
Rhandle. It returns message, an RSVP should therefore pack
only what will fit into one packet, and then continue packing with
the opaque number Rhandle for
subsequent references to this reservation.

2. Add Filter

Call: TC_AddFilter( Rhandle, Session, Filterspec )

This call next packet, etc. Each of these messages will be processed
independently at the receiving node, each updating its part of the
session state in the node. No explicit reassembly is used to define a filter corresponding needed.

Since RSVP messages are normally expected 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 be generated and sent

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

Internet Draft RSVP Specification March June 1995

existing filter with no filter (i.e., delete

hop-by-hop, their MTU should be determined by the filter).

4. Modify or Delete Flowspec

Call: TC_ModFlowspec( Rhandle

[, new_Flowspec [ ,Sender_Tspec]] )

This call can modify MTU of each
interface.

Upon the arrival of an existing reservation or delete RSVP message M that changes the
reservation. If new_Flowspec is included, it is passed to
Admission Control; if it is rejected, state, a
node must forward the current flowspec
is left in force. modified state immediatly. If new_Flowspec this is omitted,
implemented as an immediate refresh of all the
reservation state for the
session, then no refresh messages should be sent out the interface
through which M arrived. This rule is deleted and Rhandle is invalidated.

5. OPWA Update

Call: TC_Advertise( interface, Adspec

[ ,Sender_TSpec ] ) -> New_Adspec

This call is used for OPWA to compute the outgoing
advertisement New_Adspec for a specified interface.

6. Initialize Traffic Control

Call: TC_Initialize(interface )

This call is used when RSVP initializes its state, necessary to
clear out all existing classifier and/or prevent packet scheduler
state
storms on broadcast LANs.

Some multicast routing protocols provide for "multicast tunnels",
which encapsulate multicast packets for transmission through
routers that do not have multicast capability. A multicast tunnel
looks like a specified logical outgoing interface that is mapped into some
physical interface.

4.6.3 RSVP/Routing Interface

An A multicast routing protocol that supports
tunnels will describe a route using a list of logical rather than
physical interfaces. RSVP implementation needs can support multicast tunnels in the
following support from manner:

1. When a node N forwards a PATH message out a logical outgoing
interface L, it includes in the
packet forwarding and routing mechanism message some encoding of the node.

o Promiscuous receive mode for RSVP messages

Any datagram received for IP protocol 46
identity of L. This information is carried (in the HOP
object) as a value called the "logical interface handle" or
LIH.

2. The next hop node N' stores the LIH value in its path state.

3. When N' sends a RESV message to be diverted N, it includes the LIH value
from the path state (again, in the HOP object).

4. When the RESV message arrives at N, its LIH value provides
the information necessary to attach the RSVP program for processing, without being
forwarded. The identity of reservation to the interface on which
appropriate logical interface. Note that N creates and
interprets the LIH; it is
received should also be available an opaque value to the RSVP daemon.

o Route discovery

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

Internet Draft RSVP Specification March 1995 N'.

4.3 Avoiding RSVP Message Loops

We must be able to discover the route(s) ensure that the
routing algorithm would have used rules for forwarding a
specific datagram.

GetUcastRoute( DestAddress ) -> OutInterface

GetMcastRoute( SrcAddress, DestAddress )

-> OutInterface_list

o Route Change Notification

Routing may provide an asynchronous notification to RSVP
that a specified route has changed.

New_Ucast_Route( DestAddress ) -> new_OutInterface

New_Mcast_Route( SrcAddress, DestAddress )

-> new_OutInterface_list

o Outgoing Link Specification RSVP must be able to force a (multicast) datagram to be
sent control messages
avoid looping. In steady state, PATH and RESV messages are
forwarded only once per refresh period on each hop. This avoids
directly looping packets, but there is still the possibility of an
" auto-refresh" loop, clocked by the refresh period. The effect
of such a specific outgoing virtual link, bypassing loop is to keep state active "forever", even if the
normal routing mechanism. A virtual link may end
nodes have ceased refreshing it (but the state will be a real
outgoing link or a deleted
when the receivers leave the multicast tunnel. Outgoing link
specification is necessary because RSVP may send different
versions of outgoing group and/or the senders
stop sending PATH messages on different
interfaces, for messages). On the same source other hand, error and destination addresses,
teardown messages are forwarded immediately and are therefore
subject to avoid loops.

o Discover Interface List

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

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

Internet Draft RSVP Specification March June 1995

5. Message Processing Rules

This generic description of RSVP operation assumes the following data
structures. An actual implementation may use additional or different
structures to optimize processing.

o PSB -- Path State Block

Each PSB holds path state for a particular (session, sender)
pair, defined by SESSION and SENDER_TEMPLATE objects,
respectively. PSB contents include a PHOP object and possibly
SENDER_TSPEC, CREDENTIAL, and/or ADVERT objects from PATH
messages.

o RSB -- Reservation State Block

RSB's Messages

PATH messages are used to 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 forwarded using routes determined by the outgoing interface OI
appropriate routing protocol. For routing 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 MESSAGE ARRIVES

Start with source-
dependent (e.g., some multicast routing algorithms), the Refresh_Needed flag off.

Each RSVP
daemon must route each sender descriptor object sequence separately using the
source addresses found in the message defines SENDER_TEMPLATE objects. This
should ensure that there will be no auto-refresh loops of
PATH messages, even in a
sender. Process topology with cycles.

Consider each sender message type.

o PTEAR Messages

PTEAR messages use the same routing as follows.

1. If there is a CREDENTIAL object, verify it; if it is
unacceptable, build PATH messages and send a
therefore cannot loop.

o PERR message, drop the Messages

Since PATH
message, and return.

2. If there is no messages don't loop, they create path state block (PSB) for the (session,
sender) pair then:

o Create
defining a new PSB. loop-free reverse path to each sender. PERR
messages are always directed to particular senders and
therefore cannot loop.

o Set RESV Messages

Like PERR message, RESV messages directed to particular
senders (i.e., with explicit scope) cannot loop. However,
there is a cleanup timer potential for auto-refresh of RESV messages with
wildcard scope; the PSB. solution is presented below.

o RTEAR Messages

RTEAR messages are routed the same as RESV messages and have
an analogous looping problem for wildcard scope.

o RERR Messages

RERR messages for wildcard scope reservations have the same
potential for looping as the reservations themselves, and the
solution presented below is required.

If this the topology has no loops, then looping of wildcard-scoped
messages can be avoided by simply enforcing the rule given
earlier: state that is received through a particular interface
must never be forwarded out the first same interface. However, when the
topology does have cycles then further effort is needed to prevent
auto-refresh loops in wildcard-scope RESV, RTEAR, and RERR

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

Internet Draft RSVP Specification March June 1995

PSB

messages. The solution is for the session, set such messages to carry an explicit
sender address list in a refresh timer for the
session.

o Copy PHOP into the PSB. Copy into the PSB any of SCOPE object.

When a RESV or RTEAR message with wildcard scope is to be
forwarded to a particular previous hop, a new SCOPE object is
computed from the
following SCOPE objects that are present in were received (in messages of
the message:
CREDENTIAL, SENDER_TSPEC, and/or ADVERT. Copy same type). If the
EntryPolice flag from computed SCOPE object is empty, the common header into
message is not forwarded to the PSB.

o Call previous hop; otherwise, 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
message is sent containing the new SCOPE object. The rules for
computing a matching PSB):

o If CREDENTIAL differs between message and PSB, verify new CREDENTIAL. If it is acceptable, copy it into
PSB. Otherwise, build and send SCOPE object for a PERR RESV or RTEAR message for
"Bad Credential", drop the PATH message, and return.

o Restart cleanup timer.

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

If the values
follows:

1. The union is formed of PHOP or SEND_TSPEC differ between the
message and the PSB, copy the new values into sets of sender IP addresses listed
in all SCOPE objects in the PSB
and turn on reservation state for the Refresh_Needed flag. given
session.

If SEND_TSPEC
has changed, reservations matching S may also change;
this may be deferred until reservation state from some NHOP does not contain a RESV refresh arrives.

o Call the appropriate route discovery routine SCOPE
object, a substitute sender list must be created and
compare the route mask with the ROUTE_MASK value
already included
in the PSB; if union. For a new bit (interface) has been
added, turn wildcard scope (WF) message that arrived
on outgoing interface OI, the Refresh_Needed flag. Store new
ROUTE_MASK substitute list is the set of
senders that route to OI. For an explicit scope (SE)
message, it is the set of senders explicitly listed in the PSB.

4.
message.

2. Any local senders are removed from this set.

3. If the Refresh_Needed flag SCOPE object is now set, execute to be sent to PHOP, remove from the PATH
REFRESH event sequence (below).

PATH TEAR MESSAGE ARRIVES

o If there is no path state for this destination, drop the
message and return.

o Forward a copy
set any senders that did not come from PHOP.

Figure 12 shows an example of wildcard-scoped (WF style) RESV
messages. The address lists within SCOPE objects are shown in
square brackets. Note that there may be additional connections
among the PTEAR message using the same rules as nodes, creating looping topology that is not shown.

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

Internet Draft RSVP Specification March June 1995

for

________________
a PATH message (see PATH REFRESH).

o Each sender descriptor in | | c
R4, S4<----->| Router |<-----> R2, S2, S3
| |
b | |
R1, S1<----->| |
|________________|

Figure 12: SCOPE Objects in Wildcard-Scope Reservations

SCOPE objects are not necessary if the PTEAR message contains multicast routing uses
shared trees or if the reservation style has explicit scope.
Furthermore, attaching a
SENDER_TEMPLATE SCOPE object defines to a sender S; process it as
follows. reservation may be
deferred to a node which has more than one previous hop upstream.

The following rules are used for SCOPE objects in wildcard-scoped
RERR messages:

1. Locate The node that detected the PSB for error initiates an RERR message
containing a copy of the pair: (session, S). If none
exists, continue SCOPE object associated with next sender descriptor.

2. Examine the RSB's for this session and delete any
reservation state associated or message in error.

2. Suppose a wildcard-scoped RERR message arrives at a node with sender S, depending
upon
a SCOPE object containing the reservation style. For example:

Delete a WF reservation for which S is sender host address list L.
The node forwards the only
sender.

Delete an FF reservation for S.

3. Delete RERR message using the PSB.

PATH ERROR MESSAGE ARRIVES

o If there are no existing PSB's for SESSION then drop rules of Section
4.1.5. However, the
PERR RERR message and return.

o Look up the PSB for (session, sender); sender is defined forwarded out OI must
contain a SCOPE object derived from L by
SENDER_TEMPLATE. If no PSB is found, drop PERR message and
return.

o including only those
senders that route to OI. If PHOP in PSB this SCOPE object is local API, deliver error to 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 empty, the
RERR message is ignored.

Otherwise (PHOP is should not local API), forward a copy of the
PERR message to the PHOP node.

RESV MESSAGE ARRIVES be sent out OI.

Braden, Zhang, et al. Expiration: September December 1995 [Page 46] 44]

Internet Draft RSVP Specification March June 1995

A RESV message arrives through outgoing interface OI.

o Check the SESSION object.

If there are no existing PSB's for SESSION then build and
send

4.4 Local Repair

When a RERR message (as described later) specifying "No
Path Information", drop route changes, the next PATH or RESV message, and return.
However, do not send the RERR message if the style has
wildcard refresh will establish
path or reservation scope and this is not state (respectively) along the receiver
host itself.

o Check new route. To
provide fast adaptation to routing changes without the STYLE object.

If style in overhead of
short refresh periods, the message conflicts with local routing protocol module can
notify the style RSVP daemon of any
reservation route changes for particular
destinations. The RSVP daemon should use this session in place on any interface,
reject information to
trigger an immediate refresh of state for these destinations,
using the RESV message by building and sending a RERR
message specifying "Bad Style", drop new route.

More specifically, the RESV message, and
return. rules are as follows:

o Check the CREDENTIAL object.

Verify the CREDENTIAL field (if any) to check permission to
create When routing detects a reservation. [This check may also involve change of the
CREDENTIAL fields set of outgoing
interfaces for sending PATH messages for destination G, RSVP
should send immediate PATH refreshes for all sessions G/*
(i.e., for any session with destination G, regardless of
destination port).

o When a PATH message arrives with a Previous Hop address that
differs from the PSB's one stored in the scope of this
reservation; in path state, RSVP should
send immediate RESV refreshes for that case, it would better fit below session.

4.5 Time Parameters

There are two time parameters relevant to each element of RSVP
path or reservation state in
processing a node: the individual flow descriptors.]

o Check refresh period R between
receiving successive refreshes for path state

If there are no PSB's matching the scope of this
reservation, build state, and send a RERR its lifetime L.
Each RSVP RESV or PATH message may contain a TIME_VALUES object
specifying "No
Sender Information", drop the RESV message, and return.

o Make reservations

Process R value that was used to generate this refresh
message; this is used to determine the style-specific tail sequence.

For FF style, execute L when the following steps for each b flow
descriptor, i.e., each (FLOWSPEC, FILTERSPEC) pair. For WF
style execute the following once, using some internal
placeholder "WILD_FILTER" for FILTERSPEC to indicate
wildcard scope. state is
received and stored.

In more detail:

1. Find or create To avoid premature loss of state, we require that L >= (K +
0.5)* R, where K is a reservation small integer. Then K-1 successive
messages may be lost without state block (RSB) for the
4-tuple: (SESSION, NHOP, style, FILTERSPEC). being deleted. Currently
K = 3 is suggested.

2. Start or restart Each message will generally carry a TIME_VALUES object
containing the cleanout timer on R used to generate refreshes; the RSB. recipient
node uses this R to determine L of the stored state.

However, if a default R = Rdef is used, the TIME_VALUES
object may be omitted from a message. Rdef is currently
defined to be 30 seconds.

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

Internet Draft RSVP Specification March June 1995

3. Start a refresh timer This document does not specify the interval R to be used for this session if none was
started.

4.
generating refresh messages. If the RSB existed and if FLOWSPEC and the
SENDER_TSPEC objects are unchanged, drop the RESV
message and return.

5. Compute Sender_Tspec as the maximum over the
SENDER_TSPEC objects node does not implement
local repair of reservations disrupted by route changes, a
smaller R improves the PSB's within the scope speed of
the reservation.

6. Set Police_flag on if any PSB's in the scope have the
EntryPolice flag on, or if the style is WF and there
is adapting to routing changes
(but increases overhead). With local repair, a router can be
more than one PSB in relaxed about R since the scope, otherwise off.

7. Computer K_Flowspec, periodic refresh becomes only
a backstop robustness mechanism. A node may therefore adjust
the effective kernel flowspec, as
the maximum of the FLOWSPEC values in all RSB's for
the same (SESSION, OI, FILTERSPEC) triple. Similarly,
the kernel filter spec K_filter is either R dynamically to limit the
FILTER_SPEC overhead due to
refresh messages.

4. The TIME_VALUES object under consideration (unitary
scope), or it is WILD_FILTER (wildcard scope).

If there was no previous kernel reservation could contain, in place
for (SESSION, OI, FILTERSPEC), call addition to the kernel
interface module:

TC_AddFlowspec( Sender_Tspec, K_flowspec, Police_Flag )

If this call fails, build and send
hop-by-hop R value, an end-to-end upper bound on R, called
Rmax. When Rmax is specified, a RERR message
specifying "Admission control failed", drop the RESV
message, and return. Otherwise, record the kernel
handle K_handle returned by the call in the RSB(s).
Then call:

TC_AddFilter( K_handle, K_Filter)

to node cannot set the filter, drop the RESV message and return.

/item R > Rmax.
However, if there was a previous kernel
reservation with handle K_handle, call the kernel
interface module:

TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec)

If this call fails, build and send a RERR node is allowed to refuse an RSVP message
specifying "Admission control failed". In any case, (i.e.,
drop the RESV message it and return.

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

Internet Draft RSVP Specification March 1995

If processing a RESV message finds return an error, a RERR message is
created containing flow descriptor and error) when it specifies an ERRORS object. The
Error Node field Rmax value
that is so small that it would create unacceptable overhead.
This refusal would look like a kind of the ERRORS object (see Appendix A) admission control
failure.

5. However, when R is set changed dynamically, there is a limit to
how fast it may increase. Specifically, the IP address ratio of OI, and the message is sent unicast to NHOP.

created

RESV TEAR MESSAGE ARRIVES

A RTEAR message arrives on outgoing interface OI.

o If there are no existing PSB's for SESSION then drop the
RTEAR message and return.

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

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

1. Find matching RSB(s) for the 4-tuple: (SESSION, NHOP,
style, FILTERSPEC). If no RSB two
successive values R2/R1 must not exceed 1 + Slew.Max.

Currently, Slew.Max is found, continue with
next flow descriptor, if any.

2. Delete the RSB(s).

3. If there are no more RSBs for the same (SESSION, OI,
FILTERSPEC/) triple, call the kernel interface module:

TC_ModFlowspec( K_handle )

to delete the reservation. Then build and forward 0.30. With K = 3, one packet may be
lost without state timeout while R is increasing 30 percent
per refresh cycle.

6. To improve robustness, a
new RERR message.

- WF style: node may temporarily send refreshes
more often than R after a copy state change (including initial
state establishment).

7. A node should randomize its refresh timeouts to each PHOP among all
matching senders.

- FF style: Send avoid
synchronization and burstiness of refreshes.

8. The values of Rdef, K, and Slew.Max used in an implementation
should be easily modifiable, as experience may lead to PHOP
different values. The possibility of matching PSB.

4. Otherwise (there are other RSB's dynamically changing K
and/or Slew.Max in response to measured loss rates is for the same
reservation), recompute K_Flowspec and call the kernel
interface module:

TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec)
future study.

Braden, Zhang, et al. Expiration: September December 1995 [Page 49] 46]

Internet Draft RSVP Specification March June 1995

4.6 RSVP Interfaces

RSVP on a router has interfaces to update the reservation, routing and then execute the RESV
REFRESH sequence (below). If this kernel call fails,
return; the prior reservation will remain to traffic control
in place.

RESV ERROR MESSAGE ARRIVES

o Call the appropriate route discovery routine, using
DestAddress from SESSION kernel. RSVP on a host has an interface to applications
(i.e, an API) and (for multicast routing)
SrcAddress from also an interface to traffic control (if it
exists on the Error Node field in host).

4.6.1 Application/RSVP Interface

This section describes a generic interface between an
application and an RSVP control process. The details of a real
interface may be operating-system dependent; the ERRORS object.
Let following can
only suggest the resulting routing bit mask basic functions to be M.

o Determine the set performed. Some of RSBs matching the triple: (SESSION,
style, FILTERSPEC). If no RSB is found, drop RERR message
and return.

Recompute the maximum over
these calls cause information to be returned asynchronously.

o Register

Call: REGISTER( DestAddress , DestPort

[ , SESSION_object ] , SND_flag , RCV_flag

[ , Source_Address ] [ , Source_Port ]

[ , Source_ProtID ] [ , Sender_Template ]

[ , Sender_Tspec ] [ , Data_TTL ]

[ , Sender_Policy_Data ]

[ , Upcall_Proc_addr ] ) -> Session-id

This call initiates RSVP processing for a session, defined
by DestAddress together with the FLOWSPEC objects of this set
of RSB's. TCP/UDP port number
DestPort. If successful, the LUB was REGISTER call returns
immediately with a local session identifier Session-id,
which may be used in this computation, turn on
the LUB-flag in the received RESV message.

o Delete from the set of RSVs any whose OI does not appear in
the bit mask M and whose NHOP is not the local API. If
none remain, drop RERR message and return.

For each PSB in the resulting set, do the following step.

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

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

Here LUB-flag subsequent calls.

The SESSION_object parameter is taken from the received packet, included as
possibly modified above.

Otherwise (NHOP is not local API), forward a copy of the
RERR message an escape
mechanism to support some more general definition of the PHOP node.

PATH REFRESH

This sequence may
session ("generalized destination port"), should that be entered by either
necessary in the expiration future. Normally SESSION_object will be
omitted; if it is supplied, it should be an
appropriately-formatted representation of the path
refresh timer for a particular session, or immediately as SESSION
object.

SND_flag should be set true if the result
of processing a PATH message turning on host will send data,
and RCV_flag should be set true if the Refresh_Needed flag.

For each virtual outgoing interface ("vif") V, build a PATH message host will receive

Braden, Zhang, et al. Expiration: September December 1995 [Page 50] 47]

Internet Draft RSVP Specification March June 1995

data. Setting neither true is an error. The optional
parameters Source_Address, Source_Port, Sender_Template,
Sender_Tspec, Data_TTL, and send it to V. To build the message, consider each PSB whose
ROUTE_MASK includes V, and do the following:

o Pass the ADVERT and SENDER_TSPEC objects present in the PSB to
the kernel call TC_Advertise, and get back Sender_Policy_Data are all
concerned with a modified ADVERT
object. Pack this modified object into the PATH message being
built.

o Create a sender descriptor sequence containing the
SENDER_TEMPLATE, CREDENTIAL, data source, and SENDER_TSPEC objects, if
present in 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 session using
these parameters, which are interpreted as follows:

- Source_Address

This is the PSB. Pack address of the sender descriptor into interface from which the PATH
message being built.

o
data will be sent. If the PSB has the EntryPolice flag on and if it is omitted, a default
interface V will be used. This parameter is not
capable of policing, turn the EntryPolice flag needed on in the PATH
message being built.

o If
a multihomed sender host.

- Source_Port

This is the maximum size of UDP/TCP port from which the PATH message data will be
sent. If it is reached, send omitted or zero, the
packet out interface V port is "wild"
and start packing can match any port in a new one.

RESV REFRESH FILTER_SPEC.

- Source_ProtID

This sequence may be entered by either the expiration of is the
reservation refresh timer IP protocol ID for a particular session, the sender data. If
it is omitted or immediately as zero, the result of processing a RESV message.

Each PSB for this session protocol id is considered "wild" and
can match any protocol id in turn, to compute a style-
dependent tail sequence. These sequences for a given PHOP are then
packed into the same message(s) and sent to that PHOP. The logic FILTER_SPEC.

- Sender_Template

This parameter is
somewhat different depending upon whether the scope included as an escape mechanism to
support a more general definition of the
reservations is wildcard or not (they sender
("generalized source port"). Normally this parameter
may not be mixed).

For each PSB that does not correspond to the API, do the following.

o Compute (FLOWSPEC, FILTER_SPEC) Pair

Select each RSB in whose reservation scope the PSB falls, and
compute the maximum over the FLOWSPEC objects of this set of
RSB's. Also, select omitted; if it is supplied, it should be an appropriate FILTER_SPEC. The scope
depends upon the style and the filter spec
appropriately formatted representation of the RSB:

1. WF: Select every RSB whose OI matches a bit in
SENDER_TEMPLATE object.

- Sender_Tspec

This parameter is a Tspec describing the
ROUTE_MASK of traffic flow
to be sent. It may be included to prevent over-
reservation on the PSB.

In this case, FILTER_SPEC initial hops.

- Data_TTL

This is the standard WILD_FILTER.

2. FF: Select every RSB whose FILTER_SPEC matches
SENDER_TEMPLATE in (non-default) IP Time-To-Live parameter
that is being supplied on the RSB. This matching process should data packets. It is

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

Internet Draft RSVP Specification March June 1995

consider wildcards.

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

needed to remove gratuitous wildcards??]

This computation also yields ensure that Path messages do not have a style (since style must be
consistent across RSB's
scope larger than multicast data packets.

- Sender_Policy_Data

This optional parameter passes policy data for given session). [??Again, need
merging rules]]

o Build RESV packets

Append this (FLOWSPEC, FILTER_SPEC pair) to the RESV message
being built for destination PHOP (from
sender. This data may be supplied by a system
service, with the PSB). When application treating it as opaque.

Finally, Upcall_Proc_addr is the
packet fills, or upon completion address of all PSB's with the same
PHOP, set an upcall
procedure to receive asynchronous error or event
notification; see below.

o Reserve

Call: RESERVE( session-id,

style, style-dependent-parms )

A receiver uses this call to make a resource reservation
for the NHOP address in session registered as `session-id'. The style
parameter indicates the message to reservation style. The rest of
the interface
address parameters depend upon the style, but generally these
will include appropriate flowspecs, filter specs, and send
possibly receiver policy data objects.

The first RESERVE call will initiate the packet out that interface periodic
transmission of RESV messages. A later RESERVE call may
be given to modify the PHOP
address. parameters of the earlier call (but
note that changing the reservations may result in
admission control failure, depending upon the style).

The RESERVE call returns immediately. Following a 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 session
specified by session-id. It may send appropriate teardown
messages and will cease sending refreshes for this
session-id.

o Error/Event Upcalls

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

Internet Draft RSVP Specification March June 1995

appendix
6. Object Type Definitions

C-types are defined for

Upcall: <Upcall_Proc>( ) -> session-id, Info_type,

[ Error_code , Error_value , LUB-Used, ]

List_count, [ Flowspec_list,]

[ Filter_spec_list, ] [ Advert_list, ]

[ Policy_data ]

Here "Upcall_Proc" represents the two Internet upcall procedure whose
address families IPv4 was supplied in the REGISTER call.

This upcall may occur asynchronously at any time after a
REGISTER call and
IP6. To accomodate other address families, additional C-types could
easily be defined. These definitions are contained as an Appendix before a RELEASE call, to
ease updating.

6.1 SESSION Class

Currently, SESSION objects contain indicate an
error or an event. Currently there are three upcall
types, distinguished by the pair: (DestAddress,
DestPort), where DestAddress Info_type parameter:

1. Info_type = Path Event

A Path Event upcall indicates to a receiver
application that there is at least one active sender.
It results from receipt of the data destination address first PATH message for
this session.

This upcall provides synchronizing information to the
receiver application, and
DestPort is it may also provide
parallel lists of senders (in Filter_spec_list),
traffic descriptions (in Flowspec_list), and service
advertisements (in Advert_list). `List_count'will be
the UDP/TCP destination port. Other SESSION C-Types
could number in each list; where these objects are
missing, corresponding null objects must appear. The
Error_code, Error_value, LUB-Used flag, and
Policy_data parameters will be defined undefined in the future this
upcall.

2. Info_type = Resv Event

A Resv Event upcall indicates to support other demultiplexing
conventions a sender application
that a reservation for this session in place along
the entire path to at least one receiver. It is
triggered by the transport-layer receipt of the first reservation
message or application layer.

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

+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| //////////// | DestPort |
+-------------+-------------+-------------+-------------+

o IP6/UDP SESSION object: Class = by modification of previous reservation
state, for this session.

`List_count' will be 1, C-Type = 129

+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| //////////// | DestPort |
+-------------+-------------+-------------+-------------+ and Flowspec_list will
contain one FLOWSPEC, the effective QoS that would be

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

Internet Draft RSVP Specification March June 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 address of the interface through which

applicable to the last RSVP-knowledgeable hop forwarded application itself.
Filter_spec_list and Advert_list will contain one
NULL object. The Error_code, Error_value, LUB-Used
flag, and Policy_data parameters will be undefined in
this message.

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

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

3. Info_type = 2

+-------------+-------------+-------------+-------------+
| Style=2 | //////// | //////// | FD Count |
+-------------+-------------+-------------+-------------+

FD Count

The count of elements Path Error

An Path Error event indicates an error in the variable-length object list sender
information that follows. See was specified in the RESV message format definition
earlier. REGISTER call.

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 supplied in the
REGISTER call; Sender_Tspec and Advert_list will each
contain one NULL object. The Policy_data parameter
will be undefined in this upcall.

4. Info_type = Resv Error

An Resv Error event indicates an error in processing
a reservation message to which this application
contributed. The Error_code parameter will define
the error, and Error_value may supply some additional
(perhaps system-specific) data on the error.

Filter_spec_list and Flowspec_list will contain the
FILTER_SPEC and FLOWSPEC objects from the error flow
descriptor (see Section 4.1.5). List_count will
specify the number of FILTER_SPECS in
Filter_spec_list, while there will be one FLOWSPEC in
Flowspec_list. The Policy_data parameter will be
undefined in this upcall.

5. Info_type = Policy Data

A Policy Information upcall passes a Policy_data
parameter containing policy information (accounting,
current costs, prices, quota, etc.) that arrived at
the receiver.

List_count will be zero, and the Error_code,
Error_value, and LUB-Used flag parameters will be
undefined in this upcall.

Although RSVP messages indicating path events or errors

Braden, Zhang, et al. Expiration: September December 1995 [Page 57] 51]

Internet Draft RSVP Specification March June 1995

6.5 Flowspec Class

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

+-----------+-----------+-----------+-----------+
| QoS Service Code |
+-----------+-----------+-----------+-----------+
| b: Token Bucket Depth (bits) |
+-----------+-----------+-----------+-----------+
| r: Average data rate (bits/sec) |
+-----------+-----------+-----------+-----------+
| d: Max end-to-end delay (ms) |
+-----------+-----------+-----------+-----------+
| (For Future Use) |
+-----------+-----------+-----------+-----------+

QoS Service Code

Integer value defining what service is being requested.
The values currently defined for this code are:

1 = Guaranteed Service

The Tspec is (b, r), while

may be received periodically, the Rspec is (r). (d) API should make the
corresponding asynchronous upcall to the application only
on the first occurrence, or when the information to be
reported changes.

4.6.2 RSVP/Traffic Control Interface

In each router and host, enhanced QoS is ignored.

2 achieved by a group of
inter-related traffic control functions: a packet classifier,
an admission control module, and a packet scheduler. This
section describes a generic RSVP interface to traffic control.

1. Make a Reservation

Call: Rhandle = Bounded-Delay Predictive Service

The Tspec TC_AddFlowspec( Interface, Flowspec

[ , Sender_Tspec]

, E_Police_Flag , M_Police_Flag )

This call passes a Flowspec defining a desired QoS to
admission control. It may also pass Sender_Tspec, the
maximum traffic characteristics computed over the
SENDER_TSPECs of senders that will contribute data packets
to this reservation.

E_Police_Flag and M_Police_Flag are Boolean parameters.
E_Police_Flag is on if this is (b, r), an entry node, while
M_Police is on if this node is an interior data merge
point for a shared reservation style. These flags are
used to enable traffic policing or shaping when
appropriate, in accordance with the Rspec service.

This call returns an error code if Flowspec is (d). malformed
or if the requested resources are unavailable. Otherwise,
it establishes a new reservation channel corresponding to
Rhandle. It returns the opaque number Rhandle for
subsequent references to this reservation.

2. Modify Reservation

Call: TC_ModFlowspec( Rhandle, new_Flowspec

[ , Sender_Tspec] , Police_flag )

This call can modify an existing reservation. If

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

Internet Draft RSVP Specification March June 1995

6.6 FILTER_SPEC Class

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

+-------------+-------------+-------------+-------------+
| IPv4 SrcAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Protocol Id | ////// | SrcPort |
+-------------+-------------+-------------+-------------+

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

new_Flowspec is included, it is passed to Admission
Control; if it is rejected, the current flowspec is left
in force. The corresponding filter specs, if any, are not
affected.

3. Delete Flowspec

Call: TC_DelFlowspec( Rhandle )

This call will delete an existing reservation, including
the flowspec and all associated filter specs.

4. Add Filter Spec

Call: FHandle = 129

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

SrcAddress TC_AddFilter( Rhandle, Session , FilterSpec )

This call is used to associate an IP address for additional filter spec
with the reservation specified by the given Rhandle,
following a host, and SrcPort successful TC_AddFlowspec call. This call
returns a filter handle FHandle.

5. Delete Filter Spec

Call: TC_DelFilter( FHandle )

This call is used to remove a UDP/TCP
source port, defining specific filter, specified
by FHandle.

6. OPWA Update

Call: TC_Advertise( interface, Adspec

[ ,Sender_TSpec ] ) -> New_Adspec

This call is used for OPWA to compute the outgoing
advertisement New_Adspec for a sender. specified interface.
Sender_TSpec is also passed if it is available.

7. Preemption Upcall

Upcall: TC_Preempt() -> RHandle, Reason_code

In order to grant a new reservation request, the admission

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

Internet Draft RSVP Specification March June 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 most common form

control and/or policy modules may be allowed to preempt an
existing reservation. This might be reflected in an
upcall to RSVP, passing the RHandle of Tspec is a token bucket. the preempted
reservation, and some indication of the reason.

4.6.3 RSVP/Routing Interface

An RSVP implementation needs the following support from the
packet forwarding and routing mechanisms of the node.

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: September 1995 [Page 60]

Internet Draft Promiscuous receive mode for RSVP Specification March 1995

6.9 ADVERT Class

[TBD]

6.10 TIME_VALUES Class messages

Any datagram received for IP protocol 46 must be diverted
to the RSVP program for processing, without being
forwarded. The identity of the interface on which it is
received should also be available to the RSVP daemon.

o TIME_VALUES Object: Class = 10, C-Type = 1

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

RSVP must be able to query the routing daemon for the
route(s) for forwarding a specific datagram.

Ucast_Route_Query( DestAddress, Notify_flag ) -> OutInterface

Mcast_Route_Query( SrcAddress, DestAddress, Notify_flag )

-> OutInterface_list

If the Notify_flag is True, routing will save state
necessary to issue unsolicited route change notification
callbacks whenever the specified route changes. This will
continue until routing receives a route query call with
the Notify_Flag set False.

o Route Change Notification

If requested by a route query with the Notify_flag True,
the routing daemon may provide an asynchronous callback to
RSVP that a specified route has changed.

Ucast_Route_Change( ) -> DestAddress, OutInterface

Mcast_Route_Change( )

-> SrcAddress, DestAddress, OutInterface_list

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

Internet Draft RSVP Specification March June 1995

6.11 ERROR_SPEC Class

o IPv4 ERROR_SPEC object: Class = 11, C-Type = 1

+-------------+-------------+-------------+-------------+
| IP4 Error Node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| Error Code | ////////// | Error Outgoing Link Specification

RSVP must be able to force a (multicast) datagram to be
sent on a specific outgoing virtual link, bypassing the
normal routing mechanism. A virtual link may be a real
outgoing link or a multicast tunnel. Outgoing link
specification is necessary because RSVP may send different
versions of outgoing PATH messages for the same source and
destination addresses on different interfaces. It is also
necessary in some cases to avoid routing loops.

o Discover Interface List

RSVP must be able to learn what real and virtual
interfaces are active, with their IP addresses.

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

Internet Draft RSVP Specification June 1995

5. Message Processing Rules

This generic description of RSVP operation assumes the following data
structures. An actual implementation may use additional or different
structures to optimize processing.

o PSB -- Path State Block

Each PSB holds path state for a particular (session, sender)
pair, which are defined by SESSION and SENDER_TEMPLATE objects,
respectively. PSB contents include a PHOP object and possibly
SENDER_TSPEC, POLICY_DATA, and/or ADSPEC objects from PATH
messages.

o RSB -- Reservation State Block

Each RSB holds reservation state for a particular 4-tuple:
(session, next hop, style, filterspec), which are defined in
SESSION, NHOP, STYLE, and FILTER_SPEC objects, respectively.
RSB contents also include a FLOWSPEC object and may include a
POLICY_DATA object. We assume that RSB contents include the
outgoing interface OI that is implied by NHOP.

MESSAGE ARRIVES

Verify version number, checksum, and length fields of common header,
and discard message if any mismatch is found.

Further processing depends upon message type.

PATH MESSAGE ARRIVES

Start with the Refresh_Needed flag off.

Each sender descriptor object sequence in the message defines a
sender. Process each sender as follows, starting the
Path_Refresh_Needed and Resv_Refresh_Needed flags off.

1. If there is a POLICY_DATA object, verify it; if it is
unacceptable, build and send a "Administrative Rejection"
PERR message, drop the PATH message, and return.

2. Call the appropriate Route_Query routine, using DestAddress
from SESSION and (for multicast routing) SrcAddress from
SENDER_TEMPLATE. This provides a routing bit mask
ROUTE_MASK and (for a multicast destination) an
EXPECTED_INTERFACE.

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

Internet Draft RSVP Specification June 1995

3. If the message arrived on an interface different from
EXPECTED_INTERFACE, drop it and return.

4. Search for a path state block (PSB) whose (SESSION,
SENDER_TEMPLATE) pair matches the corresponding objects in
the message.

If there is a match considering wildcards in the
SENDER_TEMPLATE objects, but the two SENDER_TEMPLATEs
differ, build and send a "Ambiguous Path" PERR message,
drop the PATH message, and return.

5. If there is no matching PSB for the (SESSION,
SENDER_TEMPLATE) pair then:

o Create a new PSB.

o Set a cleanup timer for the PSB. If this is the first
PSB for the session, set a refresh timer for the
session.

o Copy the SESSION, TIME_VALUES, and PHOP objects into
the PSB. Copy into the PSB any of the following
objects that are present: POLICY_DATA, SENDER_TSPEC,
and ADSPEC.

o Store ROUTE_MASK and EXPECTED_INTERFACE in the PSB.

o Turn on the Path_Refresh_Needed flag.

6. Otherwise (there is a matching PSB):

o Restart cleanup timer.

o If the SENDER_TSPEC and/or ADSPEC values differ
between the message and the PSB, copy the new values
into the PSB and turn on the Path_Refresh_Needed flag.
Note that if SEND_TSPEC has changed, reservations
matching S may also change; this may be deferred until
a RESV refresh arrives.

o If the new ROUTE_MASK differs from that stored in the
PSB, turn on the Path_Refresh_Needed flag, and store
the new ROUTE_MASK into the PSB.

o If the new EXPECTED_INTERFACE differs from that stored
in the PSB, turn on the Resv_Refres_Needed flag and
store the new EXPECTED_INTERFACE value into the PSB.

Braden, Zhang, et al. Expiration: December 1995 [Page 57]

Internet Draft RSVP Specification June 1995

7. Save the IP TTL with which the message arrived in the PSB .

8. If the Refresh_Needed flag is now set, execute the PATH
REFRESH event sequence (below); however, send no PATH
refresh messages out the interface through which the PATH
message arrived.

9. If the Resv_Needed flag is now set, execute the RESV
REFRESH event sequence (below).

PATH TEAR MESSAGE ARRIVES

o If there is no path state for this destination, drop the
message and return.

o Forward a copy of the PTEAR message using the same rules as
for a PATH message (see PATH REFRESH).

o Each sender descriptor in the PTEAR message contains a
SENDER_TEMPLATE object defining a sender S; process it as
follows.

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

2. Examine the RSB's for this session and delete
reservation state that is associated with sender S and
no other sender.

3. Delete the PSB.

o Drop the PTEAR message and return.

PATH ERROR MESSAGE ARRIVES

o If there are no existing PSB's for SESSION then drop the
PERR message and return.

o Look up the 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 application
via an upcall:

Call: <Upcall_Proc>( session-id, Path Error,

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

Internet Draft RSVP Specification June 1995

Error_code, Error_value, 0,
1, SENDER_TEMPLATE, NULL, NULL, NULL)

Any POLICY_DATA, SENDER_TSPEC, or ADSPEC object in the
message is ignored.

o Otherwise (PHOP is not local API), forward a copy of the
PERR message to the PHOP node.

RESV MESSAGE ARRIVES

A RESV message arrives through outgoing interface OI.

o Check the SESSION object.

If there are no existing PSB's for SESSION then build and
send a RERR message (as described later) specifying "No
path information", drop the RESV message, and return.
However, do not send the RERR message if the style has
wildcard reservation scope and this is not the receiver
host itself.

o Check the STYLE object.

If the style in the message conflicts with the style of any
reservation for this session in place on any interface,
reject the RESV message by building and sending a RERR
message specifying "Conflicting Style", drop the RESV
message, and return.

o Check the POLICY_DATA object.

Verify the POLICY_DATA field (if any) to check permission
to create a reservation. If it is unacceptable, build and
send an "Administrative rejection" RERR message, drop the
RESV message, and return.

o Make reservations

Process the STYLE object and the flow descriptor list.

For FF style, execute the following steps for each b flow
descriptor, i.e., for each (FLOWSPEC, FILTER_SPEC) pair.
For SE style, execute the following steps for each
FILTER_SPEC in the list, using the given FLOWSPEC. For WF
style, execute the following once, using an internal

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

Internet Draft RSVP Specification June 1995

placeholder "WILD_FILTER" for FILTERSPEC if it is omitted.

1. Find or create a reservation state block (RSB) for the
4-tuple: (SESSION, NHOP, style, FILTER_SPEC).

2. Start or restart the cleanout timer on the RSB. Start
a refresh timer for this session if none was started.

3. If the RSB existed and contains state matching this
flow descriptor, continue with the next flow
descriptor. Otherwise (the state is new or modified),
continue processing the current flow descriptor with
the following steps.

4. Scan the set of PSBs (senders) whose SENDER_TSPECs
match FILTER_SPEC.

- If this set is empty, build and send an error
message specifying "No sender information", and
continue with the next flow descriptor.

- If this set contains more than one PSB and if the
style has the explicit option (e.g., FF or SE),
build and send an error message specifying
"Ambiguous filter spec" and continue with the
next flow descriptor.

- Set K_E_Police_flag on if any of these PSBs have
the E_Police flag on, otherwise set
K_E_Police_flag off. Set K_M_Police_flag on if
the style has wildcard scope and there is more
than one PSB in the scope, otherwise, set
K_M_Police_flag off.

- Compute K_Tspec as the sum of the SENDER_TSPEC
objects, if any, in this set of PSBs.

5. Compute the parameters for the effective reservation,
by considering all RSB's for the same (SESSION, OI,
FILTERSPEC) triple.

- Compute the effective kernel flowspec,
K_Flowspec, as the maximum of the FLOWSPEC values
in these RSB's

- Compute the effective kernel filter spec K_Filter
by merging the FILTER_SPEC objects in these
RSB's.

Braden, Zhang, et al. Expiration: December 1995 [Page 60]

Internet Draft RSVP Specification June 1995

6. If this reservation has wildcard scope and this is not
the first flow descriptor in the message, one of the
filter specs must have changed; delete the old one and
install the new:

TC_DelFilter( old_Fhandle );

Fhandle = TC_AddFilter( Rhandle, SESSION, K_filter)

Then continue with the next flow descriptor.

7. Otherwise, if there was no previous kernel reservation
in place for (SESSION, OI, FILTERSPEC), call the
kernel interface module:

Rhandle = TC_AddFlowspec( OI, K_flowspec, K_Tspec,
K_E_Police_flag, K_M_Police_flag )

If this call fails, build and send a RERR message
specifying "Admission control failed", and continue
with the next flow descriptor. Otherwise, record the
kernel handle Rhandle returned by the call in the
RSB(s). Then call:

TC_AddFilter( Rhandle, SESSION, K_Filter)

to set the filter, and continue with the next flow
descriptor.

However, if there was a previous kernel reservation
with handle Rhandle, and the flowspec has changed,
call:

TC_ModFlowspec( Rhandle, K_Flowspec, K_Tspec,
K_E_Police_flag, K_M_Police_flag )

If this call fails, build and send a RERR message
specifying "Admission control failed". In any case,
drop the RESV message and return.

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

Internet Draft RSVP Specification June 1995

If the flowspec is unchanged but the filter spec has
changed, install the new:

TC_DelFilter( old_Fhandle )
Fhandle = TC_AddFilter( Rhandle, SESSION, K_filter)

Then continue with the next flow descriptor.

If processing a RESV message finds an error, a RERR message is
created containing flow descriptor and an ERRORS object. The
Error Node field of the ERRORS object (see Appendix A) is set to
the IP address of OI, and the message is sent unicast to NHOP.

RESV TEAR MESSAGE ARRIVES

A RTEAR message arrives on outgoing interface OI.

o If there are no existing PSB's for SESSION then drop the
RTEAR message and return.

o Process the flow descriptor list sequence to tear down
reservations.

1. Find matching RSB(s) for the 4-tuple: (SESSION, NHOP,
style, FILTERSPEC). If no RSB is found, continue with
next flow descriptor, if any.

2. Delete the RSB(s).

3. If there are no more RSBs for the same (SESSION, OI,
FILTERSPEC/) triple, call the kernel interface module:

TC_DelFlowspec( K_handle )

to delete the reservation. Then build and forward a
new RTEAR message.

- WF style: send a copy to each PHOP among all

Braden, Zhang, et al. Expiration: December 1995 [Page 62]

Internet Draft RSVP Specification June 1995

matching senders.

- FF style: Send to PHOP of matching PSB.

4. Otherwise (there are other RSB's for the same
reservation), recompute K_Flowspec and call the kernel
interface module:

TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec)

to update the reservation, and then execute the RESV
REFRESH sequence (below). If this kernel call fails,
return; the prior reservation will remain in place.

RESV ERROR MESSAGE ARRIVES

o Call the appropriate route discovery routine, using
DestAddress from SESSION and (for multicast routing)
SrcAddress from the Error Node Address field in the ERRORS
object. Let the resulting routing bit mask be M.

o Determine the set of RSBs matching the triple: (SESSION,
style, FILTERSPEC). If no RSB is found, drop RERR message
and return.

Recompute the maximum over the FLOWSPEC objects of this set
of RSB's. If the LUB was used in this computation, turn on
the LUB-Used flag in the received RESV message.

o Delete from the set of RSVs any whose OI does not appear in
the bit mask M and whose NHOP is not the local API. If
none remain, drop RERR message and return.

For each PSB in the resulting set, do the following step.

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

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

Here LUB-Used flag is taken from the received packet, as

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

Internet Draft RSVP Specification June 1995

possibly modified above.

Otherwise (NHOP is not local API), forward a copy of the
RERR message to the PHOP node.

PATH REFRESH

This sequence may be entered by either the expiration of the path
refresh timer for a particular session, or immediately as the result
of processing a PATH message turning on the Refresh_Needed flag.

For each outgoing interface OI, build a PATH message and send it to
OI. To build the message, consider each PSB whose ROUTE_MASK
includes OI, and do the following:

o Pass the ADSPEC and SENDER_TSPEC objects present in the PSB to
the kernel call TC_Advertise, and get back a modified ADSPEC
object. Pack this modified object into the PATH message being
built.

o Create a sender descriptor sequence containing the
SENDER_TEMPLATE, SENDER_TSPEC, and POLICY_DATA objects, if
present in the PSB. Pack the sender descriptor into the PATH
message being built.

o If the PSB has the E_Police flag on and if interface OI is not
capable of policing, turn the E_Police flag on in the PATH
message being built.

o Compute the IP TTL for the PATH message as one less than the
maximum of the TTL values from the senders included in the
message. However, if the result is zero, return without sending
the PATH message.

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

RESV REFRESH

This sequence may be entered by either the expiration of the
reservation refresh timer for a particular session, or immediately as
the result of processing a RESV or RTEAR message.

For each PHOP defined by the path state, scan the RSBs, merge the
style, FLOWSPECs and FILTER_SPECs appropriately, build a new RESV
message, and send it to PHOP. Each message carries a NHOP object
containing the local address of the interface through which it is

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

Internet Draft RSVP Specification June 1995

sent.

The details of building the RESV messages depend upon the
shared/distinct option of the style. For each PHOP, do the
following:

o Distinct style

Select each sender Si (PSB) for PHOP, and do the following:

1. Select all RSB's whose FILTER_SPECs match the
SENDER_TEMPLATE object for Si and whose OI matches a bit in
the ROUTE_MASK of the PSB for Si.

2. Compute the maximum over the FLOWSPEC objects of this set
of RSB's, and merge their FILTER_SPEC, STYLE, and
POLICY_DATA objects.

3. Append the (FLOWSPEC, FILTER_SPEC pair) to the RESV message
being built for destination PHOP. When the packet fills,
or upon completion of all PSB's with the same PHOP, send
it.

o Shared style

1. Select each sender Si (PSB) for PHOP, and select all RSB's
that: (a) have an OI matching a bit in the ROUTE_MASK for
Si, and (b) contain at least one FILTER_SPEC that matches
the SENDER_TEMPLATE object for Si.

2. For all selected RSB's for all Si corresponding to a given
PHOP:

- Compute the maximum over the FLOWSPEC objects of this
set of RSB's.

- Merge the metching FILTER_SPEC objects; this will in
general result in a list of non-overlapping
FILTER_SPECs, but where there are overlaps due to
wildcards, use the `wildest'.

- Merge the STYLE and POLICY_DATA objects.

- Place the resulting merged objects into a RESV message
and send it to PHOP.

3. If the scope is wildcard, a forwarded RESV must contain a
SCOPE object. The set of IP addresses in the SCOPE object

Braden, Zhang, et al. Expiration: December 1995 [Page 65]

Internet Draft RSVP Specification June 1995

sent to a given PHOP is formed as follows.

- Take the union of the senders listed in SCOPE objects
in all RSB's.

- Intersect that set with the set of sender hosts listed
in path state for PHOP.

- If the resulting set is empty, no RESV should be
forwarded to this PHOP.

Braden, Zhang, et al. Expiration: December 1995 [Page 66]

Internet Draft RSVP Specification June 1995

APPENDIX A. Object Definitions

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

All unused fields should be sent as zero and ignored on receipt.

A.1 SESSION Class

SESSION Class = 1.

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

+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| ////// | Flags | DestPort |
+-------------+-------------+-------------+-------------+

o IP/UDP SESSION object: Class = 1, C-Type = 2

+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| /////// | Flags | DestPort |
+-------------+-------------+-------------+-------------+

DestAddress

The IP unicast or multicast destination address of the
session.

Flags

0x01 = E_Police flag

The E_Police flag is used in PATH messages to determine

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

Internet Draft RSVP Specification June 1995

the effective "edge" of the network, to control traffic
policing. If the sender host is not itself capable of
traffic policing, it will set this bit on in PATH
messages it sends. The first node whose RSVP is capable
of traffic policing will do so (if appropriate to the
service) and turn the flag off.

[It might make more sense to include this flag in ADSPEC
object.]

DestPort

The UDP/TCP destination port for the session. Zero may be
used to indicate a `wildcard', i.e., any port.

Other SESSION C-Types could be defined in the future to
support other demultiplexing conventions in the transport-
layer or application layer.

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

Internet Draft RSVP Specification June 1995

A.2 RSVP_HOP Class

RSVP_HOP class = 3.

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

+-------------+-------------+-------------+-------------+
| IPv4 Next/Previous Hop Address |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+

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

+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 Next/Previous Hop Address +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+

This object provides the IP address of the interface through which
the last RSVP-knowledgeable hop forwarded this message. The
Logical Interface Handle is a 32-bit number which may be used to
distinguish logical outgoing interfaces as described in Section
4.2; it should be identically zero if there is no logical
interface handle.

Braden, Zhang, et al. Expiration: December 1995 [Page 69]

Internet Draft RSVP Specification June 1995

A.3 INTEGRITY Class

INTEGRITY class = 4.

See draft-ietf-rsvp-md5-00.txt.

A.4 TIME_VALUES Class

TIME_VALUES class = 5.

o TIME_VALUES Object: Class = 5, C-Type = 1

+-------------+-------------+-------------+-------------+
| Refresh Period |
+-------------+-------------+-------------+-------------+
| Max Refresh Period |
+-------------+-------------+-------------+-------------+

Refresh Period

The refresh timeout period R used to generate this message;
in milliseconds.

Max Refresh Period

The largest R value that a node is allowed to apply to the
downstream state for this session. A node may refuse to
accept this requirement, by ignoring the message containing
this TIME_VALUES object and sending a "R too small" error
message.

If this value is zero, no limit is set.

Braden, Zhang, et al. Expiration: December 1995 [Page 70]

Internet Draft RSVP Specification June 1995

A.5 ERROR_SPEC Class

ERROR_SPEC class = 6.

o IPv4 ERROR_SPEC object: Class = 6, C-Type = 1

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

o IP6 ERROR_SPEC object: Class = 6, C-Type = 2

+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 Error Node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+

Error Node Address

The IP address of the node in which the error was detected.

Flags

0x01 = LUB-Used

The use of this flag is described in section 4.1.5.

Error Code

A one-octet error description.

Error Value

A two-octet field containing additional information about the

Braden, Zhang, et al. Expiration: December 1995 [Page 71]

Internet Draft RSVP Specification June 1995

error. Its contents depend upon the Error Type.

The values for Error Code and Error Value are defined in Appendix
B.

A.6 SCOPE Class

SCOPE class = 7.

This object contains a list of IP addresses, used for routing
messages with wildcard scope without loops. The addresses must be
listed in ascending numerical order.

o IPv4 SCOPE List object: Class = 7, C-Type = 1

+-------------+-------------+-------------+-------------+
| IP4 Src Address (4 bytes) |
+-------------+-------------+-------------+-------------+
// //
+-------------+-------------+-------------+-------------+
| IP4 Src Address (4 bytes) |
+-------------+-------------+-------------+-------------+

o IP6 SCOPE list object: Class = 7, C-Type = 2

+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 Src Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
// //
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 Src Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+

Braden, Zhang, et al. Expiration: December 1995 [Page 72]

Internet Draft RSVP Specification June 1995

A.7 STYLE Class

STYLE class = 8.

o STYLE object: Class = 8, C-Type = 1

+-------------+-------------+-------------+-------------+
| Style ID | Option Vector |
+-------------+-------------+-------------+-------------+

Style ID

An integer identifying the style, as follows:

0 = No ID assigned; use option vector.

1 = WF

2 = FF

3 = SE

Option Vector

A set of bit fields giving values for the reservation
options. If new options are added in the futre,
corresponding fields in the option vector will be assigned
from the least-significant end. If a node does not recognize
a style ID, it may interpret as much of the option vector as
it can, ignoring new fields that may have been defined.

The option vector bits are assigned (from the left) as
follows:

19 bits: Reserved

2 bits: Sharing control

00b: Reserved

01b: Distinct reservations

10b: Shared reservations

11b: Reserved

Braden, Zhang, et al. Expiration: December 1995 [Page 73]

Internet Draft RSVP Specification June 1995

3 bits: Scope control

000b: Reserved

001b: Wildcard scope

010b: Explicit scope

011b - 111b: Reserved

The low order bits of the option vector are determined by the
style id, as follows:

WF 10001b
FF 01010b
SE 10010b

Braden, Zhang, et al. Expiration: December 1995 [Page 74]

Internet Draft RSVP Specification June 1995

A.8 FLOWSPEC Class

FLOWSPEC class = 9.

The following C-Types for service types are defined. The
corresponding object contents are specified in service template
documents created by the int-serv working group.

o Class = 9, C-Type = 1: Controlled-Delay Quality of Service

o Class = 9, C-Type = 2: Predictive Quality of Service

o Class = 9, C-Type = 3: Guaranteed Quality of Service

There is also a container C-Type, used to enclose a set of
FLOWSPEC objects that could not be merged at a downstream node
because they include unrecognized C-Types.

o Class = 9, C-Type = 254: Controlled-Delay Quality of Service

+-------------+-------------+-------------+-------------+
| |
// FLOWSPEC object 1 //
| |
+-------------+-------------+-------------+-------------+
| |
// FLOWSPEC object 2 //
| |
+-------------+-------------+-------------+-------------+
// //
// //
+-------------+-------------+-------------+-------------+
| |
// FLOWSPEC object k //
| |
+-------------+-------------+-------------+-------------+

Braden, Zhang, et al. Expiration: December 1995 [Page 75]

Internet Draft RSVP Specification June 1995

A.9 FILTER_SPEC Class

FILTER_SPEC class = 10.

o IPv4 FILTER_SPEC object: Class = 10, C-Type = 1

o IP6 FILTER_SPEC object: Class = 10, C-Type = 2

o IP6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3

+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 SrcAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| /////// | Flow Label (24 bits) |
+-------------+-------------+-------------+-------------+

SrcAddress

The IP source address for a sender host, or zero to indicate
a `wildcard'.

Braden, Zhang, et al. Expiration: December 1995 [Page 76]

Internet Draft RSVP Specification June 1995

Protocol Id

The IP protocol Identifier, or zero to indicate a `wildcard'.

SrcPort

The UDP/TCP source port for a sender, or zero to indicate a
`wildcard' (i.e., any port).

Flow Label

A 24-bit Flow Label, defined in IP6. This value may be used
by the packet classifier to efficiently identify the packets
belonging to a particular (sender->destination) data flow.

Braden, Zhang, et al. Expiration: December 1995 [Page 77]

Internet Draft RSVP Specification June 1995

A.10 SENDER_TEMPLATE Class

SENDER_TEMPLATE class = 11.

o IPv4/UDP SENDER_TEMPLATE object: Class = 11, C-Type = 1

Definition same as IPv4/UDP FILTER_SPEC object.

o IP6/UDP SENDER_TEMPLATE object: Class = 11, C-Type = 2

Definition same as IP6/UDP FILTER_SPEC object.

A.11 SENDER_TSPEC Class

SENDER_TSPEC class = 12.

The only current form of Tspec is a token bucket.

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

Braden, Zhang, et al. Expiration: December 1995 [Page 78]

Internet Draft RSVP Specification June 1995

A.12 ADSPEC Class

ADSPEC class = 13.

[TBD]

Braden, Zhang, et al. Expiration: December 1995 [Page 79]

Internet Draft RSVP Specification June 1995

A.13 POLICY_DATA Class

POLICY_DATA class = 14.

o Type 1 POLICY_DATA object: Class = 14, C-Type = 1

[TBD]

o Unmerged POLICY_DATA object: Class = 14, C-Type = 254

This object is a container for a list of POLICY_DATA objects
(none of which may have C-Type = 254). The contained objects
have not yet been merged.

+-------------+-------------+-------------+-------------+
| |
// POLICY_DATA object 1 //
| |
+-------------+-------------+-------------+-------------+
| |
// POLICY_DATA object 2 //
| |
+-------------+-------------+-------------+-------------+
// //
// //
+-------------+-------------+-------------+-------------+
| |
// POLICY_DATA object k //
| |
+-------------+-------------+-------------+-------------+

Braden, Zhang, et al. Expiration: December 1995 [Page 80]

Internet Draft RSVP Specification June 1995

A.14 TAG class

TAG class = 20.

o TAG object: Class = 20, C-Type = 1

+-------------+-------------+-------------+-------------+
| Tag Value |
+-------------+-------------+-------------+-------------+
| |
// Tagged Sublist //
| |
+-------------+-------------+-------------+-------------+

Tag Value

The value of the tag being attached to the objects in
the Tagged Sublist. The tag value is unique for each
session and next/previous hop.

Tagged Sublist

A list of objects with the same class-num (but not
necessarily the same C-Type).

Braden, Zhang, et al. Expiration: December 1995 [Page 81]

Internet Draft RSVP Specification June 1995

APPENDIX B. Error Codes and Values

The following Error Codes are defined.

o Error Code = 01: Admission failure

Reservation rejected by admission control.

For this Error Code, the 16 bits of the Error Value field are:

suur cccc cccc cccc

where the bits are:

s = 0: RSVP should reject the message without updating local
state.

s = 1: RSVP may use message to update local state and propagate
it.

uu = 00: Low order 12 bits contain a globally-defined sub-code
(values listed below).

uu = 10: Low order 12 bits contain a sub-code that is specific
to local organization. RSVP is not expected to be able to
interpret this except as a numeric value.

uu = 11: Low order 12 bits contain a sub-code that is specific
to the service. RSVP is not expected to be able to
interpret this except as a numeric value. Since the
traffic control mechanism might substitute a different
service, this encoding may include some representation of
the service in use.

r: Reserved bit, should be zero.

cccc cccc cccc: 12 bit code.

The following globally-defined sub-codes may appear in the low-
order 12 bits when uu = 00:

Braden, Zhang, et al. Expiration: December 1995 [Page 82]

Internet Draft RSVP Specification June 1995

- Sub-code = 1: Delay bound cannot be met

- Sub-code = 2: Requested bandwidth unavailable

- Sub-code = 11: Service conflict

- Sub-code = 12: Service unsupported

Traffic control can provide neither the requested service
nor an acceptable substitute.

- Sub-code = 13: Bad Flowspec or Tspec value

Unreasonable request. High order 4 bits should be 000r, so
that RSVP will reject the message.

- Sub-code = 14: Rmax value too small.

Rmax would result in excessive refresh overhead.

o Error Code = 02: Administrative rejection

Reservation has been rejected for administrative reasons.

For this Error Code, the high order 4 bits of the Error Value
field are assigned as for Code = 01 (above). For this case, the
following global sub-codes may be used:

- Sub-code = 1: Required credential(s) not presented.

- Sub-code = 2: Request too large

Reservation request exceeds allowed value for this user
class.

- Sub-code = 3: Insufficient quota or balance.

- Sub-code = 4: Administrative preemption

o Error Code = 03: No path information for this Resv

RSVP should reject the message.

o Error Code = 04: No sender information for this Resv

There is path information, but it does not include the sender
specified in any of the Filterspecs listed in the Resv message.
RSVP should reject the message.

Braden, Zhang, et al. Expiration: December 1995 [Page 83]

Internet Draft RSVP Specification June 1995

o Error Code = 05: Ambiguous path

Sender specification is ambiguous with existing path state.
RSVP should reject the message.

o Error Code = 06: Ambiguous filter spec

Filter spec matches more than one sender, in style that requires
a unique match. RSVP should reject the message.

o Error Code = 07: Conflicting or unknown style

Reservation style conflicts with style(s) of existing
reservation state, or it is unknown. If the high-order bit of
Error Value is zero, RSVP should reject the message.

o Error Code = 11: Missing required object

RSVP was unable to find or construct required object data from
message. Error Value will be Class-Num that is missing. RSVP
should reject the message.

o Error Code = 12: Unknown object class

Error Value will contain 16-bit value composed of (Class-Num,
C-Type) of unknown object. This error should be sent only if
RSVP is going to reject the message.

o Error Code = 13: Unknown object C-Type

Error Value will contain 16-bit value composed of (Class-Num,
C-Type) of object. This error should be sent only if RSVP is
going to should reject the message.

o Error Code = 14: Object error

A non-specific error indicating bad format or contents of an
object. The Error Value will contain 16-bits value (Class-Num,
C-Type) from header of bad object. RSVP should reject the
message.

o Error Code = 21: Traffic Control error

Some system error was detected and reported by the traffic
control modules. The Error Value will contain a system-specific
value giving more information about the error.

o Error Code = 22: RSVP System error

Braden, Zhang, et al. Expiration: December 1995 [Page 84]

Internet Draft RSVP Specification June 1995

The Error Value field will provide implementation- dependent
information on the error.

Braden, Zhang, et al. Expiration: December 1995 [Page 85]

Internet Draft RSVP Specification June 1995

APPENDIX C. UDP Encapsulation

As described earlier, RSVP control messages are intended to be
carried directly within IP datagrams as "raw packets". Implementing
RSVP in a node will require an intercept in the packet forwarding
path for protocol 46, and the necessary kernel change is incorporated
in the recent releases of IP multicasting

There are particular circumstances where it may be desirable to
encapsulate RSVP messages in UDP packets, as a short-term measure.

1. UDP encapsulation can be used between hosts and the last- (or
first-) hop router(s). This may ease installing RSVP on some
host systems, by avoiding a kernel change for the RSVP
intercept.

2. UDP encapsulation may be useful for legal penetration of
firewalls.

3. UDP encapsulation might be used on each interface of an
intermediate RSVP router whose kernel supported multicast but
which did not have the RSVP intercept.

In the following discussion, we concentrate on (1) and (2).

Figure 13 shows a typical situation for a host running RSVP. Here
two RSVP-capable hosts Hu and Hr within a corporation are connected
to the Internet through some arbitrarily complex set of networks and
routers that is labelled the "Corporate cloud". The border router R
is assumed to be RSVP-capable, but the corporate cloud is not.

_ _ _ _
______ ( ) RSVP-capable
|
+-------------+-------------+-------------+-------------+

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

+-------------+-------------+-------------+-------------+ | ( ) router
|
+ + Hu |-----( Corporate ) ______
|______| ( ) a| |b
( cloud )-----| R |---->Internet
______ ( ) |______|
| |
+ IP6 Error ( )
| Hr |------( )
|______| (_ _ _ _ _)

Figure 13: End Host Situation

We assume that Hu is a "UDP-only" host that requires UDP
encapsulation, while Hr is a "raw-capable" host that can use raw RSVP

Braden, Zhang, et al. Expiration: December 1995 [Page 86]

Internet Draft RSVP Specification June 1995

packets. The UDP encapsulation scheme should allow RSVP
interoperation among an arbitrary topology of Hr hosts and Hu hosts
as well as routers R.

RESV messages are always sent unicast; once path state has been
established, the unicast destination address of each RESV message is
known. If the path state also indicates whether the next host node
needs UDP encapsulation, a RESV message can simply be sent to the
next-hop node, either in raw mode or with UDP encapsuation.

UDP encapsulation of PATH messages poses a more difficult problem.
To solve it, we define two new well-known multicast addresses G1 and
G2, and a well-known UDP port Pu. Then the table in Figure 14 shows
the rules. Under the `Send' column, the notation is <mode>(destaddr,
destport, TTL), where TTL is the IP-layer hop count. The `Receive'
column shows the group that is joined and, where relevant, the UDP
Listen port. T1 and T2 are configured IP TTL values used for
encapsulation, while Tr is the local TTL value of the specific PATH
message. Finally, D is the DestAddress for the particular session.

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

Errnor Node Type Send Receive
___ __________ _______________ _______________
Hu UDP-only host UDP(G1,Pu,T1) UDP(G1,Pu)
and UDP(G2,Pu)

Hr Raw-mode host UDP(G1,Pu,T1) UDP(G1,Pu)
and Raw(D,,Tr) and Raw()

R Router
Interface a: UDP(G2,Pu,T2) UDP(G1,Pu)
and Raw(D,,Tr) and Raw()

Interface b: Raw(D,,Tr) Raw()

Figure 14: UDP Encapsulation Rules for Path Messages

Note that R and Hr must send their PATH messages twice, once with UDP
encapsulation and once in raw mode. In two cases (Hr -> R and Hr ->
Hr), each PATH message will be delivered twice. The router may take
steps to ignore the duplicates, but this redundancy actually has no
ill effect other than overhead for processing the extra messages.

A router must keep track of which of its interfaces are using UDP
encapsulation and which are not. A node can always listen for
UDP(G1,Pu) on each interface, and if it receives a UDP-encapsulated

Braden, Zhang, et al. Expiration: December 1995 [Page 87]

Internet Draft RSVP Specification June 1995

PATH message, mark the corresponding path state as UDP-needed. Then
matching RESV messages will be correctly encapsulated.

Two provisions are necessary for this automatic determination of
encapsulation to work.

C1 A router must use different groups G1 and G2 for sending and
receiving, as already shown.

C2 The TTL value T1 used by a host must be exactly enough to reach
the router R.

If T1 is too small to pass through the corporate cloud, of course
PATH messages will not be forwarded. If T1 is too large, multicast
routing in R will forward the UDP packet into the Internet until its
hop count expires. This will turn on UDP encapsulation between
routers within the Internet, causing bogus UDP traffic. (Note that
UDP packets addressed to G2 by a router will not be received by a
neighboring router).

However, there are possible situations where it will be impossible to
find a value of T1 that meets condition C2. Within the corporate
cloud there might be a multicast tunnel with an outgoing threshold
larger than the hop count through the cloud. Another possibility is
that there might be more than one border router R, with different
TTL's. There are several possible ways that C2 might be satisfied in
such cases.

1. It might be possible to configure the hosts' RSVP daemons with
the IP address

Error Code for R; the daemons could then "unicast" PATH
messages to this address. This solution will be feasible as
long as the number of Hr and Hu hosts is small.

2. A one-octet error description.

01 = Insufficient memory

02 = Count Wrong particular host on the LAN including Hu could be designated as
an "RSVP relay host". This system would listen on (G1,Pu) and
be configured with the IP address of R. It could then forward
any (PATH) messages it received directly to R, and T1 could be
set only large enough to reach local hosts and the relay.

Finally, manual configuration of T1 could be replaced by an expanding
ring search conducted by host RSVP daemons. This possibility is for
future study.

APPENDIX D. Experimental and Open Issues

Braden, Zhang, et al. Expiration: December 1995 [Page 88]

Internet Draft RSVP Specification June 1995

D.1 RSVP MTU

The FD Count field spec says that the MTU for RSVP messages, which are sent hop
by hop, is determined by the MTU at each interface. There may be
rare instances in which this does not match length work very well, and in which
manual configuration would not help. The problem case is an
interface connected to a non-RSVP cloud in which some particular
link far away has a smaller MTU. This would affect only those
sessions that happened to use that link. Proper solution to this
case would require MTU discovery separately for each interface and
each session, which is a very large amount of
message.

03 = No path information machinery and some
overhead for a rare (?) case. The best approach seems to be to
rely on IP fragmentation and reassembly for this Resv

04 = No Sender information case.

D.2 Reservation Compatability

How strong is the requirement for compatability of reservations in
different directions? For example, see Figure 11; should it be
possible to have incompatible reservation styles on the two
interfaces? If R1 requests a WF reservation and R2 requests a FF
reservation, it is logically possible to make the corresponding
reservations on the two different interfaces. The current
implementation does NOT allow this; instead, it prevents mixing of
incompatible styles in the same session on a node, even if they
are on different interfaces.

D.3 Session Groups (Experimental)

Section 1.2 explained that a distinct destination address, and
therefore a distinct session, will be used for each of the
subflows in a hierarchically encoded flow. However, these
separate sessions are logically related. For example it may be
necessary to pass reservations for this Resv

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

Internet Draft RSVP Specification March 1995

There is path information, but all subflows to Admission
Control at the same time (since it does not include would be nonsense to admit high
frequency components but reject the sender specified in any baseband component of the Filterspecs
listed in the Resv messager.

05 = Incorrect Dynamic Reservation Count

Dynamic Reservation Count
session data). Such a logical grouping is zero or less than FD
Count.

06 = Filterspec error

07 = Flowspec syntax error

08 = Flowspec value error

Internal inconsistency indicated in RSVP by
defining a "session group", an ordered set of values.

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

09 = Resources unavailable [Sub-reasons? Depend upon
traffic control and admission control algorithms?]

10 = Illegal style

Error Value

Specific cause 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 error described by
RESV message for each of the 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 sessions. A SESSION_GROUP object
contains four fields: a node will typically require reference address, a session group ID, a
count, and a rank.

o The reference address is an intercept agreed-upon choice from among the
DestAddress values of the sessions in the packet
forwarding path for protocol 46, which means a kernel change.
However, group, for ease of installing RSVP on host systems in example
the short
term, it may be desirable to avoid host kernel changes by supporting
UDP encapsulation of smallest numerically.

Braden, Zhang, et al. Expiration: December 1995 [Page 89]

Internet Draft RSVP messages. This encapsulation would be Specification June 1995

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 hosts 1 and count, is different in
each session of the last- (or first-) hop router(s). This scheme session group.

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

If RSVP router whose
kernel supports multicast but does not 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 RSVP intercept, by
allowing UDP encapsulation on each interface.

The UDP encapsulation approach must support end of the refresh
cycle) and then pass the RESV requests to Admission Control as a domain
group. It is normally expected that contains all sessions in the group
will be routed through the same nodes. However, if not, only a
mix
subset 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 the session group reservations may appear at a given
node; in this case, the local
domain, once as a raw packet RSVP should wait until the end of the
refresh cycle and once with UDP encapsulation; these
nodes then perform Admission Control on the subset of
the session group that it has received. The rank values will also receive some local RSVP packets in both formats. We
assume
identify which are missing.

Note that the only negative impact routing different sessions of this duplication the session group
differently will generally result in delays in establishing or
rejecting the desired QoS. A "bundling" facility could be
(negligible) additional packet processing overhead added
to multicast routing, to force all sessions in a session group to
be routed along the raw-capable
hosts and first-hop routers.

[REST TBD]

8. same path.

D.3.1 Resv Messages

Add:

[ <SESSION_GROUP> ]

after the SESSION object.

D.3.2 SESSION_GROUP Class

SESSION_GROUP class = 2.

o IPv4 SESSION_GROUP Object: Class = 2, C-Type = 1:

Braden, Zhang, et al. Expiration: December 1995 [Page 90]

Internet Draft RSVP Specification June 1995

o IP6 SESSION_GROUP Object: Class = 2, C-Type = 2:

The variables are defined in above.

D.4 DF Style (Experimental)

In addition to the WF and FF styles defined in this specification,
a Dynamic Filter (DF) style has also been proposed. The following
describes this style and gives examples of its usage. At this
time, DF style is experimental.

8.1

D.4.1 Reservation Styles

A Dynamic-Filter (DF) style reservation makes "distinct"
reservations with "wildcard" scope, but it decouples
reservations from filters.

o Each DF reservation request specifies a number D of
distinct reservations to be made using the same specified flowspec, and
these flowspec.
These reservations have a are distributed with wildcard reservation scope, so they go
everywhere.
i.e., to all senders.

The number of reservations that are actually made in a
particular node is D' = min(D,Ns), where Ns is the total
number of senders upstream of the node. Like a FF style request, a DF
style request causes distinct reservations for different senders. upstream of the node.

o In addition to D and the flowspec, a DF style reservation

Braden, Zhang, et al. Expiration: December 1995 [Page 91]

Internet Draft RSVP Specification June 1995

may also specify a list of K filterspecs, for some K in
the range: 0 <= K

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

Internet Draft RSVP Specification 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 specify a different
selection of senders, without a new admission control
check (assuming D' and the common flowspec remain
unchanged). This is known as "channel switching", in
analogy with a television set.

In order to provide assured channel switching, each node along
the path must reserve enough bandwidth for all D' channels,
even though some of this bandwidth may be unused at any one
time. If D' changes (because the receiver changed D or because
the number Ns of upstream sources changed), or if the common
flowspec changes, the refresh message is treated as a new
reservation that is subject to admission control and may fail.

The essential difference between the FF and DF styles is that the DF style allows a receiver to switch channels without
danger of an admission denial due to limited resources (unless
a topology change reroutes traffic along a lower-capacity path
or new senders appear), once the initial reservations have been
made. This in turn implies that the DF style creates
reservations that may not be in use at any given time.

The DF style is compatible with the FF style but not the WF or
SE style.

8.2

D.4.2 Examples

To give an example of the DF style, we use the following
notation:

o DF Style

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

This message carries the count n of channels to be reserved,
each using common flowspec r. It also carries a list, perhaps
empty, of filterspecs defining senders.

Figure 11 15 shows an example of Dynamic-Filter reservations. The
receivers downstream from interface (d) have requested two
reserved channels, but selected only one sender, S1. The node
reserves min(2,3) = 2 channels of size B on interface (d), and
it then applies any specified filters to these channels. Since

Braden, Zhang, et al. Expiration: December 1995 [Page 92]

Internet Draft RSVP Specification June 1995

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

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

Internet Draft RSVP Specification March 1995

Similarly, the receivers downstream of interface (c) have
requested two channels and selected senders S1 and S2. The two
channels might have been one channel each from R1 and R2, or
two channels requested by one of them, for example.

|
Send | Reserve Receive
|
| ________
DF( 1,{B}; S1) <- (a) | (c) | S1{B} | (c) <- DF( 2,{B}; S1, S2)
| |________|
| | S2{B} |
| |________|
|
------------------------|-------------------------------------------
| ________
DF( 2,{B}; S2) <- (b) | (d) | S1{B} | (d) <- DF( 2,{B}; S1)
| |________|
| | ?{B} |
| |________|

Figure 11: 15: Dynamic-Filter Reservation Example

A router should not reserve more Dynamic-Filter channels than
the number of upstream sources (three, in the router of Figure 11).
15). Since there is only one source upstream from previous hop
(a), the first parameter of the DF message (the count of
channels to be reserved) was decreased to 1 in the forwarded
reservations. However, this is unnecessary, because the
routers upstream will reserve only one channel, regardless.

When a DF reservation is received, it is labeled with the IP
address of the next hop (RSVP-capable) router, downstream from
the current node. Since the outgoing interface may be directly
connected to a shared medium network or to a non-RSVP-capable
router, there may be more than one next-hop node downstream; if
so, each sends independent DF RESV messages for a given
session. The number N' of DF channels reserved on an outgoing
interface is given by the formula:

N' = min( D1+D2+...Dn, Ns),

where Di is the D value (channel reservation count) in a RESV

Braden, Zhang, et al. Expiration: December 1995 [Page 93]

Internet Draft RSVP Specification June 1995

from the ith next-hop node.

For a DF reservation request with a Dynamic Reservation Count =
C,

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

Internet Draft RSVP Specification March 1995 RSVP should call TC_AddFlowspec C times.

8.3

D.4.3 Resv Messages

Add the following sequence:

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

<filter spec

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

8.4

D.4.4 STYLE Class

o STYLE-DF object: Class = 4, 8, C-Type = 3 2

+-------------+-------------+-------------+-------------+
| Style=3 Style ID=4 | Attribute Vector 0...0101001b |
+-------------+-------------+-------------+-------------+
| //////// ////// /////// | Dyn Dynamic Resv Cnt| FD Count |
+-------------+-------------+-------------+-------------+
+-------------+-------------+---------------------------+

Style

3 ID

4 = Dynamic-Filter

Dyn (DF)

Attribute Vector

18 bits: Reserved

1 bit: Decoupled if 1.

2 bits: Sharing control (as before)

3 bits: Scope control (as before)

Dynamic Resv Count

The number of channels to be reserved for a Dynamic
Filter style reservation. This integer value must
not less than FD Count.

REFERENCES the number of FILTER_SPEC objects in
filter spec list.

Braden, Zhang, et al. Expiration: December 1995 [Page 94]

Internet Draft RSVP Specification June 1995

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.

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

Braden,

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

[ServTempl95a] Shenker, S., "Network Element Service Specification
Template", Internet Draft RSVP Specification draft-ietf-intserv-svc-template-00.txt,
Integrated Services Working Group, March 1995 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

See Section 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

Braden, Zhang, et al. Expiration: December 1995 [Page 95]

Internet Draft RSVP Specification June 1995

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

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

Internet Draft RSVP Specification 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

Braden, Zhang, et al. Expiration: September December 1995 [Page 70] 96]

----