WDIFF

draft-ietf-rsvp-spec-08.txt --> draft-ietf-rsvp-spec-09.txt

Internet Draft R. Braden, Ed.
Expiration: May August 1996 ISI
File: draft-ietf-rsvp-spec-08.txt draft-ietf-rsvp-spec-09.txt L. Zhang
PARC
S. Berson
ISI
S. Herzog
ISI
J. Wroclaswki
MIT
S. Jamin
USC

Resource ReSerVation Protocol (RSVP) --

Version 1 Functional Specification

November 22, 1995

February 12, 1996

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: May August 1996 [Page 1]

Internet Draft RSVP Specification November 1995 February 1996

Table of Contents

1. Introduction ........................................................5 ........................................................4
1.1 Data Flows ......................................................8 ......................................................7
1.2 Reservation Model ...............................................9 ...............................................8
1.3 Reservation Styles ..............................................11 ..............................................10
1.4 Examples of Styles ..............................................14 ..............................................13
2. RSVP Protocol Mechanisms ............................................18
2.1 RSVP Messages ...................................................18
2.2 Port Usage ......................................................20
2.3 Merging Flowspecs ...............................................21
2.4 Soft State ......................................................22
2.5 Teardown ........................................................24
2.6 Errors and Acknowledgments ......................................25 ..........................................................25
2.7 Confirmation ....................................................27
2.8 Policy and Security .............................................27
2.8
2.9 Automatic RSVP Tunneling ........................................28
2.9
2.10 Host Model ......................................................28 .....................................................29
3. RSVP Functional Specification .......................................30 .......................................31
3.1 RSVP Message Formats ............................................30 ............................................31
3.2 Sending RSVP Messages ...........................................42 ...........................................44
3.3 Avoiding RSVP Message Loops .....................................44 .....................................45
3.4 Blockade State ..................................................49
3.5 Local Repair ....................................................48
3.5 ....................................................51
3.6 Time Parameters .................................................48
3.6 .................................................52
3.7 Traffic Policing and TTL ........................................50
3.7 Non-Integrated Service Hops ................53
3.8 Multihomed Hosts ................................................51
3.8 ................................................54
3.9 Future Compatibility ............................................52
3.9 ............................................56
3.10 RSVP Interfaces .................................................55 ................................................58
4. Message Processing Rules ............................................65 ............................................70
5. Acknowledgments .....................................................89
APPENDIX A. Object Definitions .........................................82 .........................................90
APPENDIX B. Error Codes and Values .....................................97 .....................................106
APPENDIX C. UDP Encapsulation ..........................................101
APPENDIX D. Experimental and Open Issues ...............................103 ..........................................111

Braden, Zhang, et al. Expiration: May August 1996 [Page 2]

Internet Draft RSVP Specification November 1995 February 1996

What's Changed

The most important changes in this document from the rsvp-spec-07 rsvp-spec-08 draft
are:

o The role and interpretation handling of reservation errors has been fundamentally
changed, to prevent the IP Protocol Id is changed.
The Protocol Id "second killer reservation problem".
A new kind of state has been introduced into a node,
"blockade state", which is now created by a required part of the session
definition, RERR message with
Error Code = 01, and filter specs which controls the merging process for
generating reservation refresh messages [Sections 2.6 and sender templates
3.4].

o RSVP now assume carries two flag bits in the Protocol Id from SESSION object to
indicate to a receiver whether there are non-RSVP-capable
nodes along the session rather than stating it
explicitly. path to a given sender [Sections 2.9 and
3.7].

o A "soft" reservation confirmation message The optional INTEGRITY object is added. now specified to immediately
follow the common header and to appear in every fragment
[Section 3.1].

o There are now two flag bits in an ERROR_SPEC object: InPlace
and NotGuilty [Section 3.10].

o The text now states explicitly that an erroneous reservation implementations should be as
permissive as possible in accepting objects in any order
within a message (and required ordering is not forwarded. A mechanism to allow specified), but
they should follow the BNF-implied order in creating a receiver
more flexible control over forwarding
message.

o The text now states that IP fragmentation of its messages after
an admission control failure has not been designed and data packets is
therefore
generally not included possible when RSVP is in this version of use, since the protocol. TCP/UDP
port fields may be required for classification [Section 1.2].

o A terminology confusion is eliminated. The term "scope" was
used both for a set of senders and for a set of sender hosts.
A new term "sender selection" is introduced for the first,
leaving "scope" rules for the second.

o The FILTER_SPEC handling an unrecognized object is dropped from a wildcard sender
selection (WF) style reservation, which now selects "all
senders" without qualification.

o The StyleID byte is dropped from a STYLE object, as
redundant.

o An SE style flow descriptor is simplified class are
changed to include a single
flowspec.

o The IP Router Alert option is now required in PATH, PTEAR,
and RACK messages.

o The TIME_VALUES object is now required in RESV third possibility: ignore and PATH
messages; there is no default.

o Policing at branch points is now defined in a new section on
policing (3.6).

o A 2-second delay is inserted into local repair.

o Merging of SE with WF objects is no longer allowed.

Braden, Zhang, et al. Expiration: May 1996 [Page 3]

Internet Draft RSVP Specification November 1995

o The Rmax end-to-end bound on do not
forward the refresh rate R is removed,
since its utility was unclear.

o A rule for randomizing refresh timeouts is included.

o The suggestion that TCP could be used for carrying RSVP state
through a congested non-RSVP cloud is removed.

o SENDER_TSPECS are now required in PATH| messages. object [Section 3.9].

o There All generic Traffic Control calls are new sections on multihomed hosts (3.7) and future
compatibility (3.8). The latter section makes clear that a
message containing modified to include an object with unknown C-Type should
interface specification, allowing the Thandle to be
rejected. Any more forgiving treatment seems too complex.
interface-specific [Section 3.10.2].

o Appendix C on UDP encapsulation Disabling an interface for RSVP is completely changed.

o Some text was rearranged in Sections 1 and 2. allowed [Section 3.10.3].

Braden, Zhang, et al. Expiration: May August 1996 [Page 4] 3]

Internet Draft RSVP Specification November 1995 February 1996

1. Introduction

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

On behalf of

The RSVP protocol is used by a host, on behalf of an application data
stream, a host uses the RSVP
protocol to request a specific quality of service (QoS) from the
network. The RSVP delivers protocol is also used by routers to deliver QoS
requests to routers all nodes along the path(s) of the data stream and maintains router to
establish and host maintain state to provide the requested service. RSVP
requests will generally, although not necessarily, result in
resources being reserved along the data path.

RSVP requests resources for simplex data streams, i.e., it requests
resources in only one direction. Therefore, RSVP treats a sender is as
logically distinct from a receiver, although the same application
process may act as both a sender and a receiver at the same time.
RSVP operates on top of IP (either IPv4 or IP6), occupying the place
of a transport protocol in the protocol stack. However, like ICMP, IGMP, and
routing protocols, RSVP does
not transport application data but is rather an Internet control protocol.
protocol, like ICMP, IGMP, or routing protocols. Like the
implementations of routing and management protocols, an
implementation of RSVP will typically execute in the background, not
in the data forwarding path, as shown in Figure 1.

RSVP is not itself a routing protocol; RSVP is designed to operate
with current and future unicast and multicast routing protocols. The An
RSVP daemon consults the local routing protocol(s) database(s) to obtain routes.
In the multicast case, for example, a host sends IGMP messages to
join a multicast group and then sends RSVP messages to reserve
resources along the delivery path(s) of that group. Routing
protocols determine where packets get forwarded; RSVP is only concerns
concerned with the QoS of those packets that are forwarded by in
accordance with routing.

Braden, Zhang, et al. Expiration: May August 1996 [Page 5] 4]

Internet Draft RSVP Specification November 1995 February 1996

HOST ROUTER

_________________________ RSVP _____________________________
| | .--------------. |
| _______ ______ | / | ________ . ______ |
| | | | | | / || | . | | | RSVP
| |Applic-| | RSVP <----/ ||Routing | -> RSVP <---------->
| | App <----->daemon| | ||Protocol| |daemon| _____ |
| | | | | | || daemon <----> | | >|Polcy||
| |_______| |___.__| | ||_ ._____| |__.__.| | |__.__.||Cntrl||
| | | | | | | . | .|_____||
|===|===============|=====| |===|=============|====.======|
| data .........| | | | ...........| .____ |
| | ____V_ ____V____ | | _V__V_ _____V___ | Adm.|| |Admis||
| | |Class-| | || data | |Class-| | ||Cntrl||
| |=> ifier|=> Packet ============> ifier|==> Packet ||_____|| data
| |______| |Scheduler|| | |______| |Scheduler|===========>
| |_________|| | |_________| |
|_________________________| |_____________________________|

Figure 1: RSVP in Hosts and Routers

Each router node that is capable of resource reservation passes incoming
data packets through a packet classifier and then queues them as
necessary in a packet scheduler. The packet classifier "packet classifier", which determines the
route and the QoS class for each packet. There is For each outgoing
interface, a scheduler " packet scheduler" then makes forwarding decisions for
each interface, packet to allocate resources for transmission achieve the promised QoS on the particular link-layer
medium used by that interface.

If the link-
layer link-layer medium is QoS-active, i.e., if it has its own QoS
management capability, then the packet scheduler is responsible for
negotiation with the link layer to obtain the QoS requested by RSVP.
This mapping to the link layer QoS may be accomplished in a number of
possible ways; the details will be medium-dependent. On a QoS-
passive medium such as a leased line, the scheduler itself allocates
packet transmission capacity. 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, RSVP makes receivers responsible for
requesting resource reservations QoS [RSVP93]. A QoS request, which typically originates
from a receiver host application, is passed to the local RSVP
implementation, shown as a user daemon process in Figure 1. The RSVP
protocol then carries 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 daemon communicates with a local decision

Braden, Zhang, et al. Expiration: May August 1996 [Page 6] 5]

Internet Draft RSVP Specification November 1995

module, called February 1996

At each node, the RSVP daemon communicates with two local decision
modules, "admission control", to determine if control" and "policy control". Admission control
determines whether the router can node has sufficient available resources to
supply the requested QoS. If the admission Policy control check determines whether the user
has administrative permission to make the reservation. If both
checks succeeds, the RSVP daemon sets parameters in the packet
classifier and scheduler to obtain the desired QoS. If the admission control either check
fails, the RSVP program immediately returns an error notification to the
application process that originated the request. We refer to the
packet classifier, packet scheduler, and admission control components
as " traffic "traffic control".

RSVP is designed to scale well for very large multicast groups.
Since both the membership of a large group and the topology of large
multicast trees are likely to change with time, the RSVP design
assumes that router state for traffic control will be built and
destroyed incrementally. For this purpose, RSVP uses "soft state" in
the routers. That is, RSVP sends periodic refresh messages to
maintain the state along the reserved path(s); in absence of
refreshes, the state will automatically time out and be deleted.

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

In summary, RSVP has the following attributes:

o RSVP makes resource reservations for both unicast and many-to-
many multicast applications, adapting dynamically to changing
group membership as well as changing routes.

o RSVP is simplex, i.e., it reserves for a data flow in one
direction only.

o RSVP is receiver-oriented, i.e., the receiver of a data flow
initiates and maintains the resource reservation used for that
flow.

o RSVP maintains "soft state" in the routers, providing graceful
support for dynamic membership changes and automatic adaptation
to routing changes.

Braden, Zhang, et al. Expiration: August 1996 [Page 6]

Internet Draft RSVP Specification February 1996

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

Braden, Zhang, et al. Expiration: May 1996 [Page 7]

Internet Draft RSVP Specification November 1995

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

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

The remainder of this section describes the RSVP reservation
services. Section 2 presents an overview of the RSVP protocol
mechanisms. Section 3 contains the functional specification of RSVP,
while Section 4 presents explicit message processing rules. Appendix
A defines the variable-length typed data objects used in the RSVP
protocol. Appendix B defines error codes and values. Appendix C
defines an extension for UDP encapsulation of RSVP messages.
Finally, some experimental RSVP features are documented in Appendix D
for future reference.

1.1 Data Flows

RSVP defines a "session" as a data flow with a particular
destination and transport-layer protocol. The destination for of a
particular
session is generally defined by DestAddress, the IP destination
address of the data packets, and perhaps by DstPort, a
" generalized
"generalized destination port", i.e., some further demultiplexing
point in the transport or application protocol layer. RSVP treats
each session independently, and this document often assumes the
qualification "for the same session".

DestAddress is a group address for multicast delivery or the
unicast address of a single receiver. DstPort 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 RSVP protocol is designed to be easily
extendible
extensible for greater generality, the present version supports
only UDP/TCP ports as generalized ports.

Figure 2 illustrates the flow of data packets

Note that it is not strictly necessary to include ports in a single RSVP the
session assuming multicast data distribution. The arrows indicate
data flowing from senders definition when DestAddress is multicast, since different
sessions can always have different multicast addresses. However,
destination ports are necessary to allow more than one unicast
session to the same receiver host.

Figure 2 illustrates the flow of data packets in a single RSVP
session, assuming multicast data distribution. The arrows
indicate data flowing from senders S1 and S2 to receivers R1, R2,
and R3, and the cloud represents the distribution mesh created by

Braden, Zhang, et al. Expiration: August 1996 [Page 7]

Internet Draft RSVP Specification February 1996

multicast routing. 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
be running in a unique Internet host, or a single host may contain
multiple senders and/or receivers, senders, distinguished by generalized source ports.

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

Internet Draft RSVP Specification November 1995

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

Figure 2: Multicast Distribution Session

For unicast transmission, there will be a single destination host
but there may be multiple senders; RSVP can set up reservations
for multipoint-to-single-point transmission.

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 QoS. The filter
spec, together with a session definition, specifies specification, defines the set of
data packets -- the "flow" -- to receive the QoS defined by the
flowspec. The flowspec is used to set parameters to the node's
packet scheduler (assuming that admission control succeeds), while
the filter spec is used to set parameters in the packet
classifier. Data packets that are addressed to a particular
session but do not match any of the filter specs for that session
are handled as best-effort traffic.

Note that the action to control QoS occurs at the place where the
data enters the medium, i.e., at the upstream end of the link,
although an RSVP reservation request originates from receiver(s)
downstream. In this document, we define the directional terms
"upstream" vs. "downstream", "previous hop" vs. "next hop", and
"incoming interface" vs "outgoing interface" with respect to the
direction of data flows. flow.

The flowspec in a reservation request will generally include a

Braden, Zhang, et al. Expiration: August 1996 [Page 8]

Internet Draft RSVP Specification February 1996

service class and two sets of numeric parameters: (1) an "Rspec"
(R for `reserve') that defines the desired QoS, and (2) a "Tspec"
(T for `traffic') that describes the data flow. The formats and
contents of Tspecs and Rspecs are determined by the integrated
service model [ServTempl95a], and are generally opaque to RSVP.

Braden, Zhang, et al. Expiration: May 1996 [Page 9]

Internet Draft RSVP Specification November 1995

In the most general approach [RSVP93], filter specs may select
arbitrary subsets of the packets in a given session. Such subsets
might 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 to select
different subflows in a hierarchically-encoded signal by selecting
on fields in an application-layer header. However, in In the interest of
simplicity (and to minimize layer violation), the present RSVP
version uses a much more restricted form of filter spec,
consisting of sender IP address and optionally the UDP/TCP port
number SrcPort.

Because the UDP/TCP port numbers are used for packet
classification, each router must be able to examine these fields.
As a result, it is generally necessary to avoid IP fragmentation
of a data stream for which a resource reservation is desired.

RSVP reservation request messages originate at receivers and are
passed upstream towards the sender(s). When a reservation request
is received at a At each intermediate node,
two general actions are taken. taken on the request.

1. Make a reservation

The flowspec and the filter spec are request is passed to traffic
control. Admission admission control determines the admissibility of
the request (if it's new); if this and policy
control. If either test fails, the reservation is rejected
and RSVP returns an error message to the appropriate
receiver(s). If admission control succeeds, both succeed, the node uses the flowspec to
set up the packet scheduler for the desired QoS and the
filter spec to set the packet classifier to select the
appropriate data packets.

2. Forward the request upstream

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

The reservation request that a node forwards upstream may differ
from the request that it received from downstream, for two
reasons. First, it is possible in theory for the traffic control

Braden, Zhang, et al. Expiration: August 1996 [Page 9]

Internet Draft RSVP Specification February 1996

mechanism to modify the flowspec hop-by-hop, although none of the
currently defined services does so. Second, reservations for the
same sender, or the same set of senders, from different downstream
branches of the multicast tree(s) are "merged" as reservations
travel upstream; that is, a node forwards upstream only the reservation
request with the "maximum" flowspec.

When a receiver originates a reservation request, it can also
request a confirmation message to indicate that its request was
(probably) installed in the network. A successful reservation

Braden, Zhang, et al. Expiration: May 1996 [Page 10]

Internet Draft RSVP Specification November 1995
request propagates as far as the closest point(s) upstream along the sink multicast tree to the sender(s) until it
reaches a point where there is an existing reservation level is equal or greater
than that being requested. At that point, the arriving request will be dropped in favor of is
merged with the equal or larger reservation in place; place, and need not be forwarded
further, and the node may then send a reservation confirmation
message back to the receiver. Note that the receipt of a
confirmation is only a high-probability indication, not a
guarantee
guarantee, that the requested service is in place all the way to
the sender(s), as explained in Section 2.6. 2.7.

The basic RSVP reservation model is "one pass": a receiver sends a
reservation request upstream, and each node in the path either
accepts or rejects the request. This scheme provides no easy way
for a receiver to find out the resulting end-to-end service.
Therefore, RSVP supports an enhancement to one-pass service known
as "One Pass With Advertising" (OPWA) [Shenker94]. With OPWA,
RSVP control packets are sent downstream, following the data
paths, to gather information that may be used to predict the end-
to-end QoS. The results ("advertisements") are delivered by RSVP
to the receiver hosts and perhaps to the receiver applications.
The advertisements may then be used by the receiver to construct,
or to dynamically adjust, an appropriate reservation request.

1.3 Reservation Styles

A reservation request includes a set of control options, which are
collectively called the reservation "style".

One reservation 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" "shared" among all packets of selected
senders.

Another reservation option controls the selection of senders: an "explicit" "
explicit" list of all selected senders, or a "wildcard" that
implicitly selects all the senders to the session. In an explicit-selection explicit
sender-selection reservation, each filter spec must match exactly one sender, while
in a wildcard-selection no filter spec is needed.

Braden, Zhang, et al. Expiration: May August 1996 [Page 11] 10]

Internet Draft RSVP Specification November 1995 February 1996

one sender, while in a wildcard sender-selection no filter spec is
needed.

Sender || Reservations:
Selection || Distinct | Shared
_________||__________________|____________________
|| | |
Explicit || Fixed-Filter | Shared-Explicit |
|| (FF) style | (SE) Style |
__________||__________________|____________________|
|| | |
Wildcard || (None defined) | Wildcard-Filter |
|| | (WF) Style |
__________||__________________|____________________|

Figure 3: Reservation Attributes and Styles

The styles currently defined are as follows (see Figure 3):

o Wildcard-Filter (WF) Style

The WF style implies the options: "shared" reservation and "
wildcard" sender selection. Thus, a WF-style reservation
creates a single reservation into which flows from all
upstream senders are mixed; this mixed. This reservation may be thought
of as a shared "pipe", whose "size" is the largest of the
resource requests from all receivers, independent of the
number of senders using it. A WF-style reservation is
propagated upstream towards all sender hosts, and
automatically extends to new senders as they appear.

Symbolically, we can represent a WF-style reservation request
by:

WF( * {Q})

where the asterisk represents wildcard sender selection and Q
represents the flowspec.

o Fixed-Filter (FF) Style

The FF style implies the options: "distinct" reservations and
"explicit" sender selection. Thus, an elementary FF-style

Braden, Zhang, et al. Expiration: August 1996 [Page 11]

Internet Draft RSVP Specification February 1996

reservation request creates a distinct reservation for data
packets from a particular sender, not sharing them with other
senders' packets for the same session.

Braden, Zhang, et al. Expiration: May 1996 [Page 12]

Internet Draft RSVP Specification November 1995

The total reservation on a link for a given session is the
total of the FF reservations for all requested senders. On
the other hand, FF reservations requested by different
receivers Rj but selecting the same sender Si must be merged
to share a single reservation.

Symbolically, we can represent an elementary FF reservation
request by:

FF( S{Q})

where S is the selected sender and Q is the corresponding
flowspec; the pair forms a flow descriptor. RSVP allows
multiple elementary FF-style reservations to be requested at
the same time, using a list of flow descriptors:

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

o Shared Explicit (SE) Style

The SE style implies the options: "shared" reservation and "
explicit" sender selection. Thus, an SE-style reservation
creates a single reservation into which flows from all
upstream senders are mixed. However, like the FF style, the
SE style allows a receiver to explicitly specify the set of
senders.

Symbolically, we can represent an SE reservation request by:

SE( (S1,S2,...){Q} ),

i.e., a flow descriptor composed of a flowspec Q and a list
of senders S1, S2, etc.

Both WF and SE are styles create shared reservations, appropriate for
those multicast applications whose application-specific constraints properties make it unlikely
that multiple data sources will transmit simultaneously.
Packetized audio is an example of an application suitable for
shared reservations; since a limited number of people talk at
once, each receiver might issue a WF or SE reservation request for
twice the bandwidth required for one sender (to allow some over-speaking). over-

Braden, Zhang, et al. Expiration: August 1996 [Page 12]

Internet Draft RSVP Specification February 1996

speaking). On the other hand, the FF style, which creates
independent reservations for the flows from different senders, is
appropriate for video signals.

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

Internet Draft RSVP Specification November 1995

The RSVP rules disallow merging of shared reservations with
distinct reservations, since these modes are fundamentally
incompatible. They also disallow merging explict explicit sender
selection with wildcard sender selection, since this might produce
an unexpected service for a receiver that specified explicit
selection. As a result of these prohibitions, WF, SE, and FF
styles are all mutually incompatible.

It would seem possible to simulate the effect of a WF reservation
using the SE style. When an application asked for WF, the RSVP
daemon on the receiver host could use local path state to create
an equivalent SE reservation that explicitly listed all senders.
However, an SE reservation forces the packet classifier in each
node to explicitly select each sender in the list, while a WF
allows the packet classifier to simply "wild card" the sender
address and port. When there is a large list of senders, a WF
style reservation can therefore result in considerably less
overhead than an equivalent SE style reservation. For this
reason, both SE and WF are included in the protocol.

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

1.4 Examples of Styles

This section presents examples of each of the reservation styles
and show shows the effects of merging.

Figure 4 shows schematically illustrates a router with two incoming interfaces through
which data streams will arrive, labeled (a) and (b), and two
outgoing interfaces through which data will be forwarded, labeled
(c) and (d). This topology will be assumed in the examples that
follow. There are three upstream senders; packets from sender S1
(S2 and S3) arrive through previous hop (a) ((b), respectively).
There are also three downstream receivers; packets bound for R1
(R2 and R3) are routed via outgoing interface (c) ((d),
respectively). We furthermore assume that R2 and R3 arrive via
different next hops, e.g., via the two routers D and D' in Figure
9. This illustrates the effect of a non-RSVP cloud or a broadcast
LAN on interface (d).

In addition to the connectivity shown in 4, we must also specify
the multicast routes within this node. Assume first that data
packets from each Si shown in Figure 4 is routed to both outgoing
interfaces. Under this assumption, Figures 5, 6, and 7 illustrate

Braden, Zhang, et al. Expiration: August 1996 [Page 13]

Internet Draft RSVP Specification February 1996

Wildcard-Filter, Fixed-Filter, and Shared-Explicit reservations,
respectively.

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

Figure 4: Router Configuration

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

Internet Draft RSVP Specification November 1995

For simplicity, these examples show flowspecs as one-dimensional
multiples of some base resource quantity B. The "Receive" column
shows the RSVP reservation requests received over outgoing
interfaces (c) and (d), and the "Reserve" column shows the
resulting reservation state for each interface. The "Send"
column shows the reservation requests that are sent upstream to
previous hops (a) and (b). In the "Reserve" column, each box
represents one reserved "pipe" on the outgoing link, with the
corresponding flow descriptor.

Figure 5, showing the WF style, illustrates the two possible
merging situations. Each of the two next hops on interface (d)
results in a separate RSVP reservation request, as shown. These
two requests are merged into the effective flowspec 3B, which is
used to make the reservation on interface (d). To forward the
reservation requests upstream, the reservations on the interfaces
(c) and (d) are merged; as a result, the larger flowspec 4B is
forwarded upstream to each previous hop.

Braden, Zhang, et al. Expiration: August 1996 [Page 14]

Internet Draft RSVP Specification February 1996

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

Figure 5: Wildcard-Filter (WF) Reservation Example

Figure 6 shows Fixed-Filter (FF) style reservations. The flow
descriptors for senders S2 and S3, received from outgoing
interfaces (c) and (d), are packed into the request forwarded to
previous hop (b). On the other hand, the three different flow
descriptors for sender S1 are merged into the single request FF(
S1{4B} ), which is sent to previous hop (a). For each outgoing
interface, there is a separate reservation for each source that
has been requested, but this reservation is shared among all the
receivers that made the request.

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

Internet Draft RSVP Specification November 1995

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

Figure 6: Fixed-Filter (FF) Reservation Example

Figure 7 shows an example of Shared-Explicit (SE) style

Braden, Zhang, et al. Expiration: August 1996 [Page 15]

Internet Draft RSVP Specification February 1996

reservations. When SE-style reservations are merged, the
resulting filter spec is the union of the original filter specs.

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

Figure 7: Shared-Explicit (SE) Reservation Example

The three examples just shown assume that data packets from S1,
S2, and S3 are routed to both outgoing interfaces. The top part
of Figure 8 shows another routing assumption: data packets from S2
and S3 are not forwarded to interface (c), e.g., because the
network topology provides a shorter path for these senders towards
R1, not traversing this node. The bottom part of Figure 8 shows

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

Internet Draft RSVP Specification November 1995
WF style reservations under this assumption. Since there is no
route from (b) to (c), the reservation forwarded out interface (b)
considers only the reservation on interface (d).

Braden, Zhang, et al. Expiration: August 1996 [Page 16]

Internet Draft RSVP Specification February 1996

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

Router Configuration

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

Figure 8: WF Reservation Example -- Partial Routing

Braden, Zhang, et al. Expiration: May August 1996 [Page 17]

Internet Draft RSVP Specification November 1995 February 1996

2. RSVP Protocol Mechanisms

2.1 RSVP Messages

Previous Incoming Outgoing Next
Hops Interfaces Interfaces Hops

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

Figure 9: Router Using RSVP

Figure 9 illustrates RSVP's model of a router node. Each data
stream arrives from a "previous hop" through a corresponding
"incoming interface" and departs through one or more "outgoing
interface(s)".
interface"(s). The same physical interface may act in both the
incoming and outgoing roles for different data flows in the same
session. Multiple previous hops and/or next hops may be reached
through a given physical interface, as a result of the connected
network being a shared medium, or the existence of non-RSVP
routers in the path to the next RSVP hop (see Section 2.8). 2.9). An
RSVP daemon preserves the next and previous hop addresses in its
reservation and path state, respectively.

There are two fundamental RSVP message types: RESV and PATH.

Each receiver host sends RSVP reservation request (RESV) messages
upstream towards the senders. These reservation messages must
follow exactly the reverse of the routes the data packets will
use, upstream to all the sender hosts included in the sender
selection. RESV messages must be are delivered to the sender hosts
themselves so that the hosts can set up appropriate traffic
control parameters for the first hop.

Braden, Zhang, et al. Expiration: May August 1996 [Page 18]

Internet Draft RSVP Specification November 1995 February 1996

Each RSVP sender host transmits RSVP PATH messages downstream
along the uni-/multicast routes provided by the routing
protocol(s), following the paths of the data. These "Path"
messages store " path "path state" in each node along the way. This path
state includes at least the unicast IP address of the previous hop
node, which is used to route the RESV messages hop-
by-hop 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 path state).

A PATH message may carry the following information in addition to
the previous hop address:

o Sender Template

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

Like a filter spec, the Sender Template is less than fully
general at present, specifying only the sender IP address and
optionally the UDP/TCP sender port. It assumes the protocol
Id specified for the session.

o Sender Tspec

A PATH message is required to carry a Sender Tspec, which
defines the traffic characteristics of the data stream that
the sender will generate. This Tspec is used by traffic
control to prevent over-reservation (and perhaps unnecessary
Admission Control failure) on all links on which the named
sender is the only source sending to the session. upstream links.

o Adspec

A PATH message may optionally carry a package of OPWA
advertising information, known as an "Adspec". An Adspec
received in a PATH message is passed to the local traffic
control, which returns an updated Adspec; the updated version
is then forwarded in PATH messages sent downstream.

For protocol efficiency, RSVP also allows multiple sets of
reservation information for the same session to be "packed" into a
single RESV message. Unlike merging, packing preserves
information. For simplicity, however, the protocol currently
prohibits packing reservations of different sessions into the same

Braden, Zhang, et al. Expiration: May 1996 [Page 19]

Internet Draft RSVP Specification November 1995

RSVP message.

PATH messages are sent with the same source and destination
addresses as the data, so that they will be routed correctly
through non-RSVP clouds (see Section 2.8). 2.9). On the other hand,
RESV messages are sent hop-by-hop; each RSVP-speaking node
forwards a RESV message to the unicast address of a previous RSVP
hop.

Braden, Zhang, et al. Expiration: August 1996 [Page 19]

Internet Draft RSVP Specification February 1996

2.2 Port Usage

At present an RSVP session is defined by the triple: (DestAddress,
ProtocolId, DstPort). Here DstPort is a UDP/TCP destination port
field (i.e., a 16-bit quantity carried at octet offset +2 in the
transport header). DstPort may be omitted (set to zero) if the
ProtocolId specifies a protocol that does not have a destination
port field in the format used by UDP and TCP.

RSVP allows any value for ProtocolId. However, end-system
implementations of RSVP may know about certain values for this
field, and in particular must know about the values for UDP and
TCP (17 and 6, respectively). An end system should give an error
to an application that either:

o specifies a non-zero DstPort for a protocol that does not
have UDP/TCP-like ports, or

o specifies a zero DstPort for a protocol that does have
UDP/TCP-like ports.

Filter specs and sender templates are defined by specify the pair: (SrcAddress,
SrcPort), where SrcPort is a UDP/TCP source port field (i.e., a
16-bit quantity carried at octet offset +0 in the transport
header). SrcPort may be omitted (set to zero) in certain cases.

The following rules hold for the use of zero DstPort and/or
SrcPort fields in RSVP.

1. Destination ports must be consistent.

Path state and/or reservation state for the same DestAddress
and ProtocolId must have DstPort values that are all zero or
all non-zero. Violation of this condition in a node is a
"Conflicting Dest Port" error.

2. Destination ports rule.

If DstPort in a session definition is zero, all SrcPort
fields used for that session must also be zero. The

Braden, Zhang, et al. Expiration: May 1996 [Page 20]

Internet Draft RSVP Specification November 1995
assumption here is that the protocol does not have TCP/UDP- UDP/TCP-
like ports. Violation of this condition in a node is a
"Conflicting Src Port" error.

3. Source Ports must be consistent.

A sender host must not send path state both with and without
a zero SrcPort. Violation of this condition is an "Ambiguous

Braden, Zhang, et al. Expiration: August 1996 [Page 20]

Internet Draft RSVP Specification February 1996

Path" error.

2.3 Merging Flowspecs

As noted earlier, a single physical interface may receive multiple
reservation request requests from different next hops for the same session
and with the same filter spec, but RSVP should install only one
reservation on that interface. This The installed reservation should
have an effective flowspec that is the "maximum" "largest" of the flowspecs
requested by the different next hops. Similarly, a RESV message
forwarded to a previous hop should carry a flowspec that is the
"maximum"
"largest" of the flowspecs requested by the different next hops.
Both hops
(however, in certain cases the "smallest" is taken rather than the
largest, see Section 3.4). These cases all represent flowspec
merging.

Merging flowspecs

Flowspec merging requires calculating calculation of the "largest" of a set of
flowspecs, which
flowspecs. However, since flowspecs are otherwise opaque to RSVP. Since flowspecs
are multi-dimensional generally multi-
dimensional vectors (they may contain both Tspec and Rspec
components, each of which may itself be multi-dimensional),
generally speaking they cannot it may
not be possible to strictly ordered. However, in
many cases one can easily determine the "larger" of order two flowspecs,
such as when both request the same bandwidth but one requests a
tighter delay, or when flowspecs. For example, if
one of the two requests both request calls for a higher bandwidth and another calls for a
tighter delay bound. When the bound, one is not "larger" than the other. In such
a case, instead of taking the two
cannot be determined, larger, RSVP must compute and use a
third flowspec that is at least as large as each, i.e., a "least each. Mathematically,
RSVP merges flowspecs using the " least upper bound"
(LUB). If (LUB) instead
of the two flowspecs maximum. Typically, the LUB is calculated by creating a
new flowspec whose components are incomparable, their comparison
will treated as an error. individually either the max or
the min of corresponding components of the flowspecs being merged.
For example, the LUB of Tspecs defined by token bucket parameters
is computed by taking the maximums of the bucket size and the rate
parameters. In several cases, the GLB (Greatest Lower Bound) is
used instead of the LUB; this simply interchanges max and min
operations.

We can now give the complete rules for calculating the effective
flowspec (Te, Re) to be installed on an interface. Here Te is the
effective Tspec and Re is the effective Rspec. As an example,
consider interface (d) in Figure 9.

1. Re is calculated as the largest (using an LUB if necessary)
of the Rspecs in RESV messages from different next hops
(e.g., D and D') but the same outgoing interface (d).

2. All Tspecs that were supplied in PATH messages from different
previous hops (e.g., some or all of A, B, and B' in Figure 9)
are summed; call this sum Path_Te.

Braden, Zhang, et al. Expiration: May August 1996 [Page 21]

Internet Draft RSVP Specification November 1995 February 1996

3. The maximum Tspec supplied in RESV messages from different
next hops (e.g., D and D') is calculated; call this Resv_Te.

4. Te is the GLB (greatest lower bound) of Path_Te and Resv_Te.
For Tspecs defined by token bucket parameters, this means to
take the smaller of the bucket size and the rate parameters.

Flowspecs, Tspecs, and Adspecs are opaque to RSVP. Therefore, the
last of these steps is actually performed by traffic control. The
definition and implementation of the rules for comparing
flowspecs, calculating LUB's, LUBs and GLBs, and summing Tspecs are
outside the definition of RSVP [ServTempl95a]. Section 3.9.4 3.10.4
shows generic calls that an RSVP daemon could use for these
functions.

2.4 Soft State

RSVP takes a "soft state" approach to managing the reservation
state in routers and hosts. RSVP soft state is created and
periodically refreshed by PATH and RESV messages. The state is
deleted if no matching refresh messages arrive before the
expiration of a "cleanup timeout" interval. It State may also be
deleted by an explicit "teardown" message, described in the next
section. At the expiration of each "refresh timeout" period and
after a state change, RSVP scans its state to build and forward
PATH and RESV refresh messages to succeeding hops.

PATH and RESV messages are idempotent. When a route changes, the
next PATH message will initialize the path state on the new route,
and future RESV messages will establish reservation state there;
the state on the now-unused segment of the route will time out.
Thus, whether a message is "new" or a "refresh" is determined
separately at each node, depending upon the existing state at that
node.

RSVP sends its messages as IP datagrams with no reliability
enhancement. Periodic transmission of refresh messages by hosts
and routers is expected to handle the occasional loss of an RSVP
messages.
message. If the effective cleanup timeout is set to K times the
refresh timeout period, then RSVP can tolerate K-1 successive RSVP
packet losses without falsely erasing a reservation. We recommend
that the network traffic control mechanism be statically
configured to grant some minimal bandwidth for RSVP messages to
protect them from congestion losses.

The state maintained by RSVP is dynamic; to change the set of
senders Si or to change any QoS request, a host simply starts
sending revised PATH and/or RESV messages. The result should will be an
appropriate adjustment in the RSVP state in all nodes along the
path.

Braden, Zhang, et al. Expiration: May August 1996 [Page 22]

Internet Draft RSVP Specification November 1995

path. February 1996

In steady state, refreshing is performed hop-by-hop hop-by-hop, to allow
merging. If When the received state differs from the stored state,
the stored state is updated. If this update results in
modification of state to be forwarded in refresh messages, these
refresh messages must be generated and forwarded immediately, so
that state changes can be propagated 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.

State that is received through a particular interface I* should
never be forwarded out the same interface. Conversely, state that
is forwarded out interface I* must be computed using only state
that arrived on interfaces different from I*. A trivial example
of this rule is illustrated in Figure 10, which shows a transit
router with one sender and one receiver on each interface (and
assumes one next/previous hop per interface). Interfaces (a) and
(c) serve as both outgoing and incoming interfaces for this
session. Both receivers are making wildcard-scope reservations,
in which the RESV messages are forwarded to all previous hops for
senders in the group, with the exception of the next hop from
which they came. The result is independent reservations in the
two directions.

There is an additional rule governing the forwarding of RESV
messages: state from RESV messages received from outgoing
interface Io should be forwarded to incoming interface Ii only if
PATH messages from Ii are forwarded to Io.

Braden, Zhang, et al. Expiration: May August 1996 [Page 23]

Internet Draft RSVP Specification November 1995 February 1996

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

Send | Receive
|
WF( *{3B}) <-- (a) | (c) <-- WF( *{3B})
|
Receive | Send
|
WF( *{4B}) --> (a) | (c) --> WF( *{4B})
|
Reserve on (a) | Reserve on (c)
__________ | __________
| * {4B} | | | * {3B} |
|__________| | |__________|
|

Figure 10: Independent Reservations

2.5 Teardown

Upon arrival, RSVP "teardown" messages remove path and reservation
state immediately. Although it is not necessary to explicitly
tear down an old reservation, we recommend that all end hosts send
a teardown request as soon as an application finishes.

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

A teardown request may be initiated either by an application in an
end system (sender or receiver), or by a router as the result of
state timeout. Once initiated, a teardown request must be
forwarded hop-by-hop without delay. A teardown message deletes
the specified state in the node where it is received. As always,
this state change will be propagated immediately to the next node,
but only if there will be a net change after merging. As a
result, an RTEAR message will prune the reservation state back
(only) as far as possible.

Like all other RSVP messages, teardown requests are not delivered

Braden, Zhang, et al. Expiration: May August 1996 [Page 24]

Internet Draft RSVP Specification November 1995 February 1996

Like all other RSVP messages, teardown requests are not delivered
reliably. The loss of a teardown request message will not cause a
protocol failure because the unused state will eventually time out
even though it is not explicitly deleted. If a teardown message
is lost, the router that failed to receive that message will time
out its state and initiate a new teardown message beyond the loss
point. Assuming that RSVP message loss probability is small, the
longest time to delete state will seldom exceed one refresh
timeout period.

2.6 Errors and Acknowledgments

There are two RSVP error messages, RERR and PERR, and a
reservation confirmation message RACK.

There PERR. PERR messages
are a number of ways for a syntactically valid reservation
request to fail at some very simple. They are simply sent upstream to the sender that
created the error, and they do not change path state in the nodes
though which they pass. There are only a few possible causes of
path errors.

However, there are a number of ways for a syntactically valid
reservation request to fail at some node along the path, triggering a RERR
message: for
example:

1. The effective flowspec that is computed using the new request
may fail admission control.

2. Administrative policy may prevent the requested reservation.

3. There may be no matching path state, so that the request
cannot be forwarded towards the sender(s).

4. A reservation style that requires the explicit selection of a
unique sender may have a filter spec that is ambiguous, i.e.,
that matches more than one sender in the path state, due to
the use of wildcard fields in the filter spec.

5. The requested style may be incompatible with the style(s) of
existing reservations. The incompatibility may occur among
reservations for the same session on the same outgoing
interface, or among effective reservations on different
outgoing interfaces.

In any of these cases, a RERR message is returned to the
receiver(s) responsible for the erroneous request.

A node may also decide to preempt an established reservation. A preemption
will trigger a

The handling of RERR message messages is somewhat complex (Section 3.4).
Since a request that fails may be the result of merging a number
of requests, a reservation error must be reported to all affected receivers. 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 occurred will persist until the
responsible
receiver(s) explicitly tear down the state or allow it to time
out. receivers. In this version of RSVP, detection of an error in addition, merging heterogeneous
requests creates a reservation potential difficulty known as the "killer

Braden, Zhang, et al. Expiration: May August 1996 [Page 25]

Internet Draft RSVP Specification November 1995

request not only generates a RERR message, it also prevents the February 1996

reservation" problem, in which one request from being forwarded further. This may not always be the
desirable behavior; for example, could deny service to
another. There are actually two killer-reservation problems.

1. The first killer reservation problem (KR-I) arises when there
is already a reservation Q0 in place. If another receiver may want
now makes a larger reservation
request to propagate all the way to the sender despite an
admission control failure at a particular link along Q1 > Q0, the path.
However, design result of the appropriate mechanism has proved difficult, merging
Q0 and therefore this version take the simplest approach.

When Q1 may be rejected by admission control in some
upstream node. This must not deny service to Q0.

The solution to this problem is simple: when admission
control fails for a reservation request, any existing
reservation is left in place. This prevents a new, very
large,

2. The second killer reservation from disrupting problem (KR-II) is the existing QoS by merging
with an existing reservation and then failing admission control
(this has been called
converse: the "killer reservation" problem).

To request receiver making a confirmation for its reservation request, Q1 is persistent
even though Admission Control is failing for Q1 in some node.
This must not prevent a different receiver
Rj includes in the RESV message from now
establishing a confirmation-request object
containing its IP address. At smaller reservation Q0 that will succeed.

To solve this problem, a RERR message establishes additional
state, called "blockade state", in each merge point, only node through which it
passes. Blockade state in a node modifies the largest merging
procedure to omit the offending flowspec and any accompanying confirmation-request object is
forwarded upstream. If (Q1 in the reservation request example)
from Rj is equal
to or smaller than the reservation in place on merge, allowing a node, its RESV
are not smaller request to be forwarded further,
and if the RESV included an
confirmation-request object, a RACK message established. The Q1 reservation state is sent back said to Rj.
This mechanism has the following consequences:

o be
"blockaded". Detailed rules are presented in Section 3.4.

A new reservation request with a flowspec larger than any that fails Admission Control creates
blockade state but is left in place for a session will normally result in either a RERR or
a RACK message back to nodes downstream of the receiver
failure point. It has been suggested that these reservations
downstream from each sender. In
this case, the RACK message failure represent "wasted" reservations and
should be timed out if not actively deleted. However, in general
the downstream reservations will not be an end-to-end
confirmation. "wasted".

o The receipt of a RACK gives no guarantees. Assume the first
two reservation requests from receivers R1 and R2 arrive at
the node where they There are merged. R2, whose reservation was
the second to arrive at that node, may receive two possible reasons for a RACK from
that node while R1's request has not yet propagated all receiver persisting in a
failed reservation: (1) it is polling for resource
availability along the
way entire path, or (2) it wants to a matching sender and may still fail. In this obtain
the desired QoS along as much of the path as possible.
Certainly in the second case,
R2 will receive a RACK although there is no end-to-end
reservation and perhaps in place. Furthermore, if the two flowspecs are
equal, R2 may receive a RACK followed by a RERR. However, if
its flowspec is smaller, R2 first case,
the receiver will receive only want to hold onto the RACK. reservations it has
made downstream from the failure.

o Despite If these uncertainties, receipt downstream reservations were not retained, the
responsiveness of RSVP to certain transient failures would be
impaired. For example, suppose a RACK indicates a
high probability route "flaps" to an
alternate route that the reservation is congested, so an existing reservation
suddenly fails, then quickly recovers to the original route.
The blockade state in place.

o Finally, note that RERR and/or RACK messages may be lost. each downstream router must not remove

Braden, Zhang, et al. Expiration: May August 1996 [Page 26]

Internet Draft RSVP Specification November 1995

2.7 Policy and Security

RSVP-mediated QoS requests will result in particular user(s)
getting preferential access to network resources. To February 1996

the state or prevent
abuse, some form of back pressure on users is likely its immediate refresh.

o If we did not refresh the downstream reservations, they might
time out, to be
required. This back pressure might take the form of
administrative rules, or of some form of real or virtual billing restored every Td seconds. Such on/off
behavior might be very distressing for the "cost" of users.

2.7 Confirmation

To request a reservation. The form and contents of such
back pressure is confirmation for its reservation request, a matter of administrative policy that may be
determined independently by each administrative domain receiver
Rj includes in the
Internet.

Therefore, admission control at RESV message a confirmation-request object
containing Rj's IP address. At each node merge point, only the largest
flowspec and any accompanying confirmation-request object is likely to contain a
policy component in addition to a resource
forwarded upstream. If the reservation component.
As input request from Rj is equal
to the policy-based admission decision, RSVP messages may
carry policy data. This data may include credentials identifying
users or user classes, account numbers, limits, quotas, etc.

To protect the integrity of the policy-based admission control
mechanisms, it may be necessary to ensure smaller than the integrity of RSVP
messages against corruption or spoofing, hop by hop. For this
purpose, RSVP messages may carry integrity objects that can be
created and verified by neighbor RSVP-capable nodes. These
objects reservation in place on a node, its RESV
are expected to contain an encrypted part not forwarded further, and to assume if the RESV included a
shared secret between neighbors.

User policy data in
confirmation-request object, a RACK message is sent back to Rj.
This mechanism has the following consequences:

o A new reservation request messages presents a
scaling problem. When with a multicast group has flowspec larger than any in
place for a large number of
receivers, it session will be impossible or undesirable to carry all
receivers' policy data upstream normally result in either a RERR or
a RACK message back to the sender(s). The policy data receiver from each sender. In
this case, the RACK message will have to be administratively merged an end-to-end
confirmation.

o The receipt of a RACK gives no guarantees. Assume the first
two reservation requests from receivers R1 and R2 arrive at places near
the
receivers, to avoid excessive policy data. Administrative merging
implies checking node where they are merged. R2, whose reservation was
the user credentials and accounting data and then
substituting second to arrive at that node, may receive a token indicating the check RACK from
that node while R1's request has succeeded. A chain
of trust established using an integrity field will allow upstream
nodes to accept these tokens.

In summary, different administrative domain in not yet propagated all the Internet may
have different policies regarding their resource usage
way to a matching sender and
reservation. The role of RSVP may still fail. Thus, R2 may
receive a RACK although there is to carry policy data associated
with each no end-to-end reservation in
place; furthermore, R2 may receive a RACK followed by a RERR.

2.8 Policy and Security

RSVP-mediated QoS requests will result in particular user(s)
getting preferential access to the network as needed. Note that the
merge points for policy data are resources. To prevent
abuse, some form of back pressure on users is likely to be at
required. This back pressure might take the boundaries form of
administrative domains. It may be necessary to carry accumulated
and unmerged policy data upstream through multiple nodes before
reaching one rules, or of these merge points.

Braden, 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, there will be policy control as well as admission

Braden, Zhang, et al. Expiration: May August 1996 [Page 27]

Internet Draft RSVP Specification November 1995

2.8 Automatic RSVP Tunneling

It is impossible to deploy RSVP (or any new protocol) at the same
moment throughout February 1996

control over the entire Internet. Furthermore, establishment of reservations. As input to
policy control, RSVP messages may
never carry policy data. Policy data
may include credentials identifying users or user classes, account
numbers, limits, quotas, etc. Like flowspecs, policy data will be deployed everywhere. RSVP must therefore provide correct
protocol operation even when two RSVP-capable routers are joined
by an arbitrary "cloud" of non-RSVP routers. Of course, an
intermediate cloud that does not support RSVP is unable
opaque to perform
resource reservation. However, if such a cloud has sufficient
capacity, RSVP, which will simply pass it may still provide acceptable realtime service.

RSVP automatically tunnels through such to a non-RSVP cloud. Both
RSVP and non-RSVP routers forward PATH messages towards the
destination address using their local uni-/multicast routing
table. Therefore, "Local Policy
Module" (LPM) for a decision.

To protect the routing integrity of PATH messages will be unaffected
by non-RSVP routers in the path. When a PATH message traverses a
non-RSVP cloud, policy control mechanisms, it carries may
be necessary to ensure the next RSVP-capable node the IP
address integrity of the last RSVP-capable router before entering the cloud.
This effectively constructs a tunnel through the cloud for RESV
messages, which can then RSVP messages against
corruption or spoofing, hop by hop. For this purpose, RSVP
messages may carry integrity objects that can be forwarded directly created and
verified by neighbor RSVP-capable nodes. These objects use a
keyed cryptographic digest technique and assume that RSVP
neighbors share a secret [Baker96].

User policy data in reservation request messages presents a
scaling problem. When a multicast group has a large number of
receivers, it will be impossible or undesirable to carry all
receivers' policy data upstream to the next RSVP-
capable router on sender(s). The policy data
will have to be administratively merged at places near the path(s) back towards
receivers, to avoid excessive policy data. Administrative merging
implies checking the source.

Some interconnection topologies of RSVP user credentials and non-RSVP routers can
cause RESV messages accounting data and then
substituting a token indicating the check has succeeded. A chain
of trust established using integrity fields will allow upstream
nodes to arrive at accept these tokens.

In summary, different administrative domains in the wrong RSVP-capable node, or Internet may
have different policies regarding their resource usage and
reservation. The role of RSVP is to carry policy data associated
with each reservation to arrive at the wrong interface at network as needed. Note that the correct node. An RSVP
daemon must be prepared
merge points for policy data are likely to handle either situation. When a RESV
message arrives, its IP destination address should normally be at the
address boundaries of
administrative domains. It may be necessary to carry accumulated
and unmerged policy data upstream through multiple nodes before
reaching one of these merge points.

This document does not specify the local interfaces. If so, contents of policy data, the reservation
should
structure of an LPM, or any generic policy models. These will be made on
defined in the addressed interface, even if it future.

2.9 Automatic RSVP Tunneling

It is not the
one on which the message arrived. If the destination address does
not match impossible to deploy RSVP (or any local interface and the message is not a PATH or
PTEAR, it should be forwarded without further processing by this
node.

2.9 Host Model

Before a session can be created, new protocol) at the session identification,
comprised of DestAddress and perhaps same
moment throughout the generalized destination
port, must entire Internet. Furthermore, RSVP may
never be assigned and communicated to all the senders and
receivers deployed everywhere. RSVP must therefore provide correct
protocol operation even when two RSVP-capable routers are joined
by some out-of-band mechanism. When an arbitrary "cloud" of non-RSVP routers. Of course, an
intermediate cloud that does not support RSVP session is
being set up, the following events happen at the end systems.

H1 A receiver joins the multicast group specified by
DestAddress, using IGMP.

H2 A potential sender starts sending RSVP PATH messages unable to the
DestAddress. perform
resource reservation. However, if such a cloud has sufficient

Braden, Zhang, et al. Expiration: May August 1996 [Page 28]

Internet Draft RSVP Specification November 1995

H3 A receiver application receives February 1996

capacity, it may still provide acceptable realtime service.

RSVP automatically tunnels through such a non-RSVP cloud. Both
RSVP and non-RSVP routers forward PATH message.

H4 A receiver starts sending appropriate RESV messages,
specifying messages towards the desired flow descriptors.

H5 A sender application receives a RESV message.

H6 A sender starts sending data packets.

There are several synchronization considerations.

o H1 and H2 may happen
destination address using their local uni-/multicast routing
table. Therefore, the routing of PATH messages will be unaffected
by non-RSVP routers in either order.

o Suppose that the path. When a new sender starts sending data (H6) but there
are no multicast routes because no receivers have joined PATH message traverses a
non-RSVP cloud, it carries to the
group (H1). Then next RSVP-capable node the data will be dropped at some IP
address of the last RSVP-capable router
node (which node depends upon before entering the routing protocol) until
receivers(s) appear.

o Suppose that cloud.
This effectively constructs a new sender starts sending PATH messages (H2)
and data (H6) simultaneously, and there are receivers but no
RESV messages have reached tunnel through the sender yet (e.g., because its
PATH messages have not yet propagated cloud for RESV
messages, which can then be forwarded directly to the receiver(s)).
Then next RSVP-
capable router on the initial data may arrive at receivers without path(s) back towards the
desired QoS. The sender could mitigate this problem by
awaiting arrival of source.

Even though RSVP operates correctly through a non-RSVP cloud, the first RESV message (H5); however,
receivers that are farther away may not have reservations
non-RSVP-capable nodes will in
place yet.

o If general perturb the QoS provided to
a receiver starts sending RESV messages (H4) before
receiving any PATH messages (H3), receiver. Therefore, RSVP will return error
messages tries to inform the receiver.

The receiver may simply choose when
there are non-RSVP-capable hops in the path to ignore such error messages,
or it may avoid them a given sender, by waiting for PATH messages before
sending RESV messages. [LZ: should recommend that
means of two flag bits in the SESSION object of a receiver
wait for at least PATH message;
see Section 3.7 and Appendix A.

Some topologies of RSVP routers and non-RSVP routers can cause
RESV messages to arrive before sending RESV
messages.]

A specific application program at the wrong RSVP-capable node, or to
arrive at the wrong interface (API) for of the correct node. An RSVP daemon
must be prepared to handle either situation. If the destination
address does not match any local interface and the message is not
defined in
a PATH or PTEAR, the message must be forwarded without further
processing by this protocol spec, as it may node. When a RESV message does arrive at the
addessed node, the IP destination address (or the LIH, defined
later) must be host system dependent.
However, Section 3.9.1 discusses used to determine the general requirements interface to receive the
reservation.

2.10 Host Model

Before a session can be created, the session identification,
comprised of DestAddress and perhaps the generalized destination
port, must be assigned and communicated to all the senders and
presen
receivers by some out-of-band mechanism. When an RSVP session is
being set up, the following events happen at the end systems.

H1 A receiver joins the multicast group specified by
DestAddress, using IGMP.

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

H3 A receiver application receives a PATH message.

H4 A receiver starts sending appropriate RESV messages,

Braden, Zhang, et al. Expiration: May August 1996 [Page 29]

Internet Draft RSVP Specification November 1995

3. RSVP Functional Specification

3.1 RSVP Message Formats

An RSVP message consists of a common header followed by a variable
number of variable-length, typed "objects". The subsections February 1996

specifying the desired flow descriptors.

H5 A sender application receives a RESV message.

H6 A sender starts sending data packets.

There are several synchronization considerations.

o H1 and H2 may happen in either order.

o Suppose that
follow define a new sender starts sending data (H6) but there
are no multicast routes because no receivers have joined the formats of
group (H1). Then the common header, data will be dropped at some router
node (which node depends upon the object
structures, routing protocol) until
receivers(s) appear.

o Suppose that a new sender starts sending PATH messages (H2)
and each data (H6) simultaneously, and there are receivers but no
RESV messages have reached the sender yet (e.g., because its
PATH messages have not yet propagated to the receiver(s)).
Then the initial data may arrive at receivers without the
desired QoS. The sender could mitigate this problem by
awaiting arrival of the RSVP message types.

For each RSVP first RESV message type, there is (H5); however,
receivers that are farther away may not have reservations in
place yet.

o If a set of rules receiver starts sending RESV messages (H4) before
receiving any PATH messages (H3), RSVP will return error
messages to the receiver.

The receiver may simply choose to ignore such error messages,
or it may avoid them by waiting for PATH messages before
sending RESV messages.

A specific application program interface (API) for RSVP is not
defined in this protocol spec, as it may be host system dependent.
However, Section 3.10.1 discusses the
permissible choice general requirements and ordering of object types. These rules
outlines a generic interface.

Braden, Zhang, et al. Expiration: August 1996 [Page 30]

Internet Draft RSVP Specification February 1996

3. RSVP Functional Specification

3.1 RSVP Message Formats

An RSVP message or message fragment consists of a common header,
an optional integrity-check data structure, and a body consisting
of a variable number of variable-length, typed "objects". The
integrity-check data structure is itself an object, of class
INTEGRITY [Baker96]. In a fragmented message, INTEGRITY objects
must occur either in every fragment or else in no fragment.
Fragmentation of a message allows division of an object across two
(or more) successive fragments.

The following subsections define the formats of the common header,
the object structures, and each of the RSVP message types. For
each RSVP message type, there is a set of rules for the
permissible choice of object types. These rules are specified
using Backus-Naur Form (BNF) augmented with square brackets
surrounding optional sub-sequences. The BNF implies an order for
the objects in a message. However, in many (but not all) cases,
object order makes no logical difference. An implementation
should create messages with the objects in the order shown here,
but accept the objects in any order except where the order is
logically required (as noted in the following).

3.1.1 Common Header

The fields in the common header are as follows:

Vers: 4 bits

Protocol version number. This is version 1.

Flags: 4 bits

(None defined yet)

Braden, Zhang, et al. Expiration: August 1996 [Page 31]

Internet Draft RSVP Specification February 1996

0x01 = INTEGRITY object present

This flag indicates that an INTEGRITY object follows
immediately after the common header. The use of the
INTEGRITY object is described in [Baker96].

0x02 = UDP': UDP encapsulation marker flag

This flag is reserved for use by UDP encapsulation
[Appendix C].

Type: 8 bits

1 = PATH

2 = RESV

3 = PERR

4 = RERR

Braden, Zhang, et al. Expiration: May 1996 [Page 30]

Internet Draft RSVP Specification November 1995

5 = PTEAR

6 = RTEAR

7 = RACK

RSVP Checksum: 16 bits

A standard TCP/UDP checksum over

The one's complement of the contents one's complement sum of the RSVP
message,
message (fragment), with the checksum field replaced by zero.
zero for the purpose of computing the checksum. An all-
zero value means that no checksum was transmitted.

RSVP Length: 16 bits

The total length of this RSVP packet in bytes, including
the common header and the variable-length objects that
follow. If the MF flag is on or the Fragment Offset field
is non-zero, this is the length of the current fragment of
a larger message.

Send_TTL: 8 bits

The IP TTL value with which the message was sent.

Message ID: 32 bits

Braden, Zhang, et al. Expiration: August 1996 [Page 32]

Internet Draft RSVP Specification February 1996

A label shared by all fragments of one message from a
given next/previous RSVP hop. An RSVP implementation
assigns a unique Message ID to each message it sends.

MF: More Fragments Flag: 1 bit

This flag is the low-order bit of a byte; the seven high-
order bits are reserved. It is on for all but the last
fragment of a message.

Fragment Offset: 24 bits

This field gives the byte offset of the current fragment
in the complete message.

3.1.2 Object Formats

Every object consists of one or more 32-bit words with a one-
word header, in the following format:

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

Braden, Zhang, et al. Expiration: May 1996 [Page 31]

Internet Draft RSVP Specification November 1995
+-------------+-------------+-------------+-------------+
| |
// (Object contents) //
| |
+-------------+-------------+-------------+-------------+

An object header has the following fields:

Length

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

Class-Num

Identifies the object class; values of this field are
defined in Appendix A. Each object class has a name,
which is always capitalized in this document. An RSVP
implementation must recognize the following classes:

NULL

A NULL object has a Class-Num of zero, and its C-Type
is ignored. Its length must be at least 4, but can

Braden, Zhang, et al. Expiration: August 1996 [Page 33]

Internet Draft RSVP Specification February 1996

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.

SESSION

Contains the IP destination address (DestAddress),
the IP protocol id, and a generalized destination
port, to define a specific session for the other
objects that follow. Required in every RSVP message.

RSVP_HOP

Carries the IP address of the RSVP-capable node that
sent this message. This document refers to a
RSVP_HOP object as a PHOP ("previous hop") object for
downstream messages or as a NHOP ("next hop") object
for upstream messages.

TIME_VALUES

Contains the value for the refresh period R used by
the creator of the message; see 3.5. 3.6. Required in

Braden, Zhang, et al. Expiration: May 1996 [Page 32]

Internet Draft RSVP Specification November 1995
every PATH and RESV message.

STYLE

Defines the reservation style plus style-specific
information that is not in FLOWSPEC or FILTER_SPEC
objects. Required in every 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 address and perhaps some
additional demultiplexing information to identify a
sender, in a PATH message.

SENDER_TSPEC

Braden, Zhang, et al. Expiration: August 1996 [Page 34]

Internet Draft RSVP Specification February 1996

Defines the traffic characteristics of a sender's
data stream, in a PATH message.

ADSPEC

Carries OPWA data, in a PATH message.

ERROR_SPEC

Specifies an error, 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.

INTEGRITY

Contains cryptographic data to authenticate the
originating node, node and perhaps to verify the contents,

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

Internet Draft RSVP Specification November 1995 contents of this
RSVP message. See [Baker96].

SCOPE

An explicit list of sender hosts towards which to
forward a message. May appear in a RESV, RERR, or
RTEAR message.

RESV_CONFIRM

Carries the IP address of a receiver that requested a
confirmation. May appear in a RESV or RACK message.

C-Type

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

The maximum object content length is 65528 bytes. The Class-
Num and C-Type fields may be used together as a 16-bit number
to define a unique type for each object.

The high-order bit two bits of the Class-Num is used to determine
what action a node should take if it does not recognize the Class-
Num
Class-Num of an object; see Section 3.8. 3.9.

Braden, Zhang, et al. Expiration: August 1996 [Page 35]

Internet Draft RSVP Specification February 1996

3.1.3 Path Message Messages

Each sender host periodically sends a PATH message containing a
description of each data stream it originates. The PATH
message travels from a sender to receiver(s) along the same
path(s) used by the data packets. The IP source address of a
PATH message is an address of the sender it describes, while
the destination address is the DestAddress for the session.
These addresses assure that the message will be correctly
routed through a non-RSVP cloud.

Each RSVP-capable node along the path(s) captures PATH messages
and processes them to build local path state. The node then
forwards the PATH messages towards the receiver(s), replicating
it as dictated by multicast routing, while preserving the
original IP source address. PATH messages eventually reach the
applications on all receivers; however, they are not looped
back to a receiver running in the same application process as
the sender.

The format of a PATH message is as follows:

Braden, Zhang, et al. Expiration: May 1996 [Page 34]

Internet Draft RSVP Specification November 1995

<Path Message> ::= <Common Header> <SESSION> <RSVP_HOP> [ <INTEGRITY> ]

<TIME_VALUES>

[ <POLICY_DATA> ] [ <ADSPEC> ]

If the INTEGRITY object is present, there must be an INTEGRITY
object immediately following the common header in every
fragment of the message, in this and all other messages. The
objects included in the sender descriptor must occur after all
other objects in the message.

The PHOP (i.e., the RSVP_HOP) object of each PATH message
contains the address of the interface through which the PATH
message was most recently sent. The SENDER_TEMPLATE object
defines the format of data packets from this sender, while the
SENDER_TSPEC object specifies the traffic characteristics of
the flow. Optionally, there may be a POLICY_DATA object
specifying user credential and accounting information and/or an

Braden, Zhang, et al. Expiration: August 1996 [Page 36]

Internet Draft RSVP Specification February 1996

ADSPEC object carrying advertising (OPWA) data.

A PATH message received at a node is processed to create path
state for the sender defined by the SENDER_TEMPLATE and SESSION
objects. Any POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are
also saved in the path state. If an error is encountered while
processing a PATH message, a PERR message is sent to the
originating sender of the PATH message. PATH messages must
satisfy the rules on SrcPort and DstPort in Section 2.2.

Periodically, the RSVP daemon at a node scans the path state to
create new PATH messages to forward downstream. Each message
contains a sender descriptor defining one sender. The RSVP
daemon forwards these messages using routing information it
obtains from the appropriate uni-/multicast routing daemon.
The route depends upon the session DestAddress, and for some
routing protocols also upon the source (sender's IP) address.
The routing information generally includes the list of none or
more outgoing interfaces to which the PATH message to be
forwarded. Because each outgoing interface has a different IP
address, the PATH messages sent out different interfaces
contain different PHOP addresses. In addition, any ADSPEC or
POLICY_DATA objects carried in PATH messages will also
generally differ for different outgoing interfaces.

Some IP multicast routing protocols (e.g., DVMRP, PIM, and
MOSPF) also keep track of the expected incoming interface for
each source host to a multicast group. Whenever this
information is available, RSVP should check the incoming
interface of each PATH message and immediately discard those

Braden, Zhang, et al. Expiration: May 1996 [Page 35]

Internet Draft RSVP Specification November 1995
messages that have arrived on the wrong interface.

3.1.4 Resv Messages

RESV messages carry reservation requests hop-by-hop from
receivers to senders, along the reverse paths of data flows for
the session. The IP destination address of a RESV message is
the unicast address of a previous-hop node, obtained from the
path state. The IP source address is an address of the node
that sent the message.

The RESV message format is as follows:

<Resv Message> ::= <Common Header> <SESSION> <RSVP_HOP> [ <INTEGRITY> ]

<TIME_VALUES> [ <S_POLICY_DATA> ]

Braden, Zhang, et al. Expiration: August 1996 [Page 37]

Internet Draft RSVP Specification February 1996

[ <RESV_CONFIRM> ] [ <SCOPE> ]

<S_POLICY_DATA> ::= <POLICY_DATA>

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

The NHOP (i.e., the RSVP_HOP) object contains the IP address of
the (incoming) interface through which the RESV message is was sent. The
appearance of a RESV_CONFIRM object signals a request for a
reservation confirmation and carries the IP address of the
receiver to which the RACK should be sent. The S_POLICY_DATA
object is a POLICY_DATA object that is associated with the
entire session. There may also be flow-specific
POLICY_DATA F_POLICY_DATA
objects, as described below.

The BNF above defines a STYLE object followed by the flow descriptor list must
occur at the end of the message.

The BNF above defines a flow descriptor list as simply a list
of flow descriptors. The following style-dependent rules
specify in more detail the composition of a valid flow
descriptor list for each of the reservation styles. styles; the order
shown must be used.

o WF Style:

Braden, Zhang, et al. Expiration: May 1996 [Page 36]

Internet Draft RSVP Specification November 1995

<WF flow descriptor> ::= <FLOWSPEC> [ <F_POLICY_DATA> ]

<F_POLICY_DATA> ::= <POLICY_DATA>

o FF style:

<flow descriptor list> ::= <First FF flow descriptor> |

<First FF flow descriptor> ::=

Braden, Zhang, et al. Expiration: August 1996 [Page 38]

Internet Draft RSVP Specification February 1996

<FF flow descriptor> ::=

[ <FLOWSPEC> ] [ <F_POLICY_DATA> ] <FILTER_SPEC>

Each elementary FF style request is defined by a single
(FLOWSPEC, FILTER_SPEC) pair, and multiple such requests
may be packed into the flow descriptor list of a single
RESV message. A FLOWSPEC object can be omitted if it is
identical to the most recent such object that appeared in
the list; the first FF flow descriptor must contain a
FLOWSPEC.

Each flow descriptor in the list must be processed
independently, and a separate RERR message must be
generated for each one that is in error.

o SE style:

<SE flow descriptor> ::=

| <filter spec list> <FILTER_SPEC>

Each elementary SE style request is defined by a single SE
descriptor, which includes a FLOWSPEC defining the shared
reservation, optionally a POLICY_DATA object, and a list
of FILTER_SPEC objects.

The reservation scope, i.e., the set of senders towards which a

Braden, Zhang, et al. Expiration: May 1996 [Page 37]

Internet Draft RSVP Specification November 1995
particular reservation is to be forwarded, is determined as
follows:

o Explicit sender selection

Match

Select a particular sender by matching each FILTER_SPEC
object against the path state created from SENDER_TEMPLATE objects to select a
particular sender.
objects. An ambiguous match, i.e., a FILTER_SPEC matching
more than one SENDER_TEMPLATE (e.g. through use of a
wildcard port), is an error. Any SCOPE
object associated with the reservation should be ignored
in this case.

o Wildcard sender selection

All senders that route to the given outgoing interface
match this request. A SCOPE object, if present, contains
an explicit list of sender IP addresses. If there is no

Braden, Zhang, et al. Expiration: August 1996 [Page 39]

Internet Draft RSVP Specification February 1996

SCOPE object, the scope is determined by the relevant set
of senders in the path state.

Whenever a RESV message with wildcard sender selection is
forwarded to more than one previous hop, a SCOPE object
must be included in the message. See Section 3.3 below.

3.1.5 Error and Confirmation Teardown Messages

There are three two types of RSVP error/confirmation messages. Teardown message, PTEAR and RTEAR.

o PERR messages result from PATH messages A PTEAR message deletes path state (which in turn deletes
any reservation state for that sender) and travel travels towards
senders. PERR messages
all receivers that are routed hop-by-hop using the
path state; at each hop, downstream from the initiating
node. A PTEAR message is routed like a PATH message, and
its IP destination address is DestAddress for the
unicast address of a previous hop. session.

o RERR messages result from RESV messages A RTEAR message deletes reservation state and travel travels
towards all matching senders upstream from the appropriate receivers. They are routed hop-by-hop
using the reservation state; at each hop, the IP
destination address is the unicast address of a next-hop initiating
node.

o RACK messages are sent to (probabilistically) acknowledge
reservation requests. A RACK RTEAR message is sent as the
result of the appearance of a RESV_CONFIRM object routed in the same way as a
corresponding RESV message, and contains a copy of that RESV_CONFIRM.
The RACK message its IP destination address
is sent to the unicast address of a
receiver host; the address is obtained from the
RESV_CONFIRM object. A RACK message is forwarded to the
receiver hop-by-hop by (to accommodate the hop-by-hop
integrity check mechanism).

Braden, Zhang, et al. Expiration: May 1996 [Page 38]

Internet Draft RSVP Specification November 1995

Errors encountered while processing error messages must cause
the error message to be discarded without creating further
error messages; however, logging of such events may be useful.

None of these messages modify the state of any node through
which they pass; instead, they are only reported to the end
application.

<PathErr message> previous hop.

<PathTear Message> ::= <Common Header> [<INTEGRITY>]

[ <INTEGRITY> ] <ERROR_SPEC> <RSVP_HOP>

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

<ResvErr

<ResvTear Message> ::= <Common Header> [<INTEGRITY>]

[ <INTEGRITY> ] <ERROR_SPEC>

[S_POLICY_DATA] <RSVP_HOP>

[ <SCOPE> ] <STYLE> <error flow descriptor>

[ <INTEGRITY> ] <ERROR_SPEC>

<RESV_CONFIRM>

<STYLE>

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

The RESV_CONFIRM object

FLOWSPEC or POLICY_DATA objects in a RACK message is a copy of the
object from the RESV message that triggered the confirmation.

The following style-dependent rules define the composition flow descriptor list of
a
valid error flow descriptor:

o WF Style:

Braden, Zhang, et al. Expiration: May
descriptor list are as given earlier for PATH and RESV
messages.

Braden, Zhang, et al. Expiration: August 1996 [Page 39] 40]

Internet Draft RSVP Specification November 1995

o FF style:

o SE style:

The ERROR_SPEC object specifies the error and includes the IP
address of the node that detected the error (Error Node
Address). POLICY_DATA objects are included in error messages
in cases where they may provide relevant information (i.e.,
when an administrative failure February 1996

Note that, unless it is being reported). In accidentally dropped along the way, a RACK
message,
PTEAR message will reach all receivers down stream from its
origination. On the ERROR_SPEC is used only other hand, a RTEAR message will cease to carry
be forwarded at the IP address same node where merging suppresses
forwarding of the originating node, in corresponding RESV messages. In each node N
along the Error Node Address; way, if the error
specification is a special value that indicates a confirmation.

When a RESV RTEAR message contains a list of flow descriptors (e.g.,
FF style), causes the RSVP implementation should process each flow
descritor independently and return a separate RERR message removal of all
state for
each that is in error.

Generally speaking, this session, N will create a RERR new teardown message should to
be forwarded towards
all receivers that may have caused propagated further upstream; otherwise, the error being reported.
More specifically:

o The node that detects an error RTEAR message
may result in the immediate forwarding of a reservation request
sends modified RESV
refresh message.

Deletion of path state as the result of a RERR message to the next hop from which the
erroneous reservation came.

The PTEAR message or a
timeout must contain the information cause any adjustments in related reservation state
required to
define the error and to route maintain consistency in the error message. Routing
requires at least a STYLE object and one or more
FILTER_SPEC object(s) from local node. The
adjustment in reservation state depends upon the erroneous RESV message. style. For an admission control failure, for
example, suppose a PTEAR deletes the
erroneous FLOWSPEC must be included.

o Succeeding nodes forward path state for a sender S.
If the RERR message using their
local style specifies explicit sender selection (FF or SE),
any reservation state, to the next hops of reservations
that match the FILTER_SPEC(s) in the message. For
reservations with a filter spec matching S should be
deleted; if the style has wildcard scope, there is an additional
limitation on forwarding RERR messages, to avoid loops;
see Section 3.3.

When sender selection (WF), the error is an admission control failure, a node
reservation should be deleted if S is
allowed (but not required) to match the FLOWSPEC as well as the

Braden, Zhang, et al. Expiration: May 1996 [Page 40]

Internet Draft RSVP Specification November 1995

FILTER_SPEC object(s), last sender to limit the distribution of a RERR
message to those receivers that `caused'
session. These reservation changes should not trigger an
immediate RESV refresh message, since the error. Suppose
that a RERR PTEAR message contains a FLOWSPEC Qerr that is being
matched against have
already made the FLOWSPEC Qlocal in required changes upstream. However, at the local reservation
state in
node N. Qerr, which originated in which a node upstream
from N, resulted from merging of flowspecs that included
Qlocal. Generally, a RERR RTEAR message can be forwarded to the
receiver(s) that specified the `biggest' flowspec. The
comparison of Qerr against a particular Qlocal to determine
whether Qlocal qualifies as (one of) the `biggest', may be
called `de-merging'. As with merging, stops, the details change of de-
merging depend upon the service and the FLOWSPEC format, and
are outside RSVP itself.

A RERR message that is forwarded should carry the FILTER_SPEC
from the corresponding reservation
state (thus `de-merging' the
filter spec).

When a RERR or RACK message reaches may trigger a receiver, the 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 Admission Control error, the
flow descriptor list will contain the FLOWSPEC object RESV refresh starting at that
failed. If the LUB-Used flag is off, this should be
semantically equivalent (but not necessarily identical) to the
FLOWSPEC originated by this application; otherwise, they may
differ. node.

3.1.6 Teardown Error Messages

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

o A PTEAR message deletes path state (which in turn deletes
the reservation state for that sender, if there is any)
and travels towards all receivers that are downstream PERR messages result from
the point of initiation. A PTEAR message is routed like a PATH message, and its IP destination address is
DestAddress for the session.

o A RTEAR message deletes reservation state messages and travels
towards all matching senders travel
upstream from towards the point of
teardown initiation. A RTEAR message is senders. PERR messages are routed in
hop-by-hop using the
same way as a corresponding RESV message (using path state; at each hop, the same
scope rules). Its IP
destination address is the unicast address of a previous
hop.

Braden, Zhang, et al. Expiration: May 1996 [Page 41]

Internet Draft RSVP Specification November 1995

[ <INTEGRITY> PERR messages do not modify the state of any node
through which they pass; instead, they are only reported
to the sender application.

o RERR messages result from RESV messages and travel
downstream towards the appropriate receivers. They are
routed hop-by-hop using the reservation state; at each
hop, the IP destination address is the unicast address of
a next-hop node.

An error encountered while processing an error message must
cause the error message to be discarded without creating
further error messages; however, logging of such events may be
useful.

Braden, Zhang, et al. Expiration: August 1996 [Page 41]

Internet Draft RSVP Specification February 1996

<PathErr message> ::= <Common Header> [ <INTEGRITY> ]

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

<ResvTear

<ResvErr Message> ::= <Common Header> <SESSION> <RSVP_HOP> [ <INTEGRITY> ]

[S_POLICY_DATA] [ <SCOPE> ]

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

FLOWSPEC or <error flow descriptor>

The ERROR_SPEC object specifies the error and includes the IP
address of the node that detected the error (Error Node
Address). POLICY_DATA objects are included in the flow descriptor list of
a RTEAR message will be ignored and error messages
in cases where they may be omitted.

Note that, unless it provide relevant information (i.e.,
when an administrative failure is accidentally dropped along being reported). The STYLE
object is copied from the way, a
PTEAR RESV message will reach all the receivers down stream from its
origination. On in error. The use of
the other hand, SCOPE object in a RTEAR RERR message will cease to
be forwarded at is defined below in Section
3.3.

The following style-dependent rules define the same node where merging suppresses
forwarding composition of a
valid error flow descriptor; the corresponding RESV messages. In each node N
along the way, if the RTEAR message causes the removal of all
state object order requirements are
as given earlier for this session, N will create a new teardown message to
be propagated further upstream; otherwise, the RTEAR message
may result in the immediate forwarding of a modified RESV
refresh message.

Deletion of path state as the result of

o WF Style:

o FF style:

o SE style:

Note that a PTEAR RERR message or a
timeout may force adjustments in related reservation state, to
maintain state consistency in the local node. The adjustment
in reservation state depends upon the style. For example,
suppose a PTEAR deletes the path state for a sender S. If the
style specifies explicit sender selection (FF or SE), delete
any reservation with contains only one flow descriptor.
Therefore, a filter spec matching S; otherwise, the
style is wildcard sender selection (WF) and the reservation
should be deleted if S is the last sender to the session.
These reservation changes should not trigger an immediate RESV
refresh message, since the PTEAR message have already made the
required changes upstream. However, at the node in which a
RTEAR message stops, the change of reservation state may
trigger a RESV refresh starting at that node.

3.2 Sending RSVP Messages

RSVP messages are sent hop-by-hop between RSVP-capable routers as
"raw" IP packets with protocol number 46. Raw IP packets are contains N > 1 flow descriptors

Braden, Zhang, et al. Expiration: May August 1996 [Page 42]

Internet Draft RSVP Specification November 1995

intended February 1996

(FF style) may create up to N separate RERR messages.

Generally speaking, a RERR message should be used between an end system and the first/last hop
router, although it is also possible to encapsulate RSVP messages
as UDP datagrams for end-system communication, as described in
Appendix C. UDP encapsulation is needed for systems forwarded towards
all receivers that cannot
do raw network I/O.

PATH, PTEAR, and RACK messages must be sent with the Router Alert
IP option [Katz95] in their IP headers. This option may be used
by in have caused the fast forwarding path of a high-speed router to detect
datagrams error being reported.
More specifically:

o The node that require special processing.

Upon the arrival of detects an RSVP message M that changes the state, error in a
node must forward the modified state immediately. However, this
must not trigger sending an reservation request
sends a RERR message out to the interface through next hop from which M arrived (as could happen if the implementation simply
triggered an immediate refresh of all state for the session).
erroneous reservation came.

This rule is necessary to prevent packet storms on broadcast LANs.

An RSVP message must be fragmented when necessary to fit into contain the
MTU of information required to
define the interface through which it will be sent. All fragments
of error and to route the error message should carry the same unique value in later
hops. It therefore includes an ERROR_SPEC object, a copy
of the Message
ID field, as well as appropriate Fragment Offset STYLE object, and MF bits, in
their common headers. When the appropriate error flow
descriptor. If the error is an RSVP message arrives, it must be
reassembled before it can be processed. The refresh period R can admission control failure,
any reservation already in place will be used as an appropriate reassembly timeout time.

Since RSVP messages are normally generated left in place,
and sent hop-by-hop,
using the RSVP-level fragmentation mechanism should avoid further
fragmentation at InPlace flag bit must be on in the IP level. However, IP fragmentation may
still occur when RSVP messages travel through a non-RSVP cloud.
In case ERROR_SPEC of IP6, which does not support IP fragmentation at
routers, an RSVP implementation must use Path MTU Discovery or
hand configuration
the RERR message.

o Succeeding nodes forward the RERR message to obtain next hops
that have local reservation state. For reservations with
wildcard scope, there is an appropriate MTU between adjacent
RSVP neighbors.

RSVP recovers from occasional packet losses by its periodic
refresh mechanism. Under network overload, however, substantial
losses additional limitation on
forwarding RERR messages, to avoid loops; see Section 3.3.
There is also a rule restricting the forwarding of RSVP RESV
messages could cause for Admission Control failures; see Section 3.4.

A RERR message that is forwarded should carry the
FILTER_SPEC from the corresponding reservation state.

o When a failure of resource
reservations. To control RERR message reaches a receiver, the queueing delay STYLE object,
flow descriptor list, and dropping of RSVP
packets, routers ERROR_SPEC object (including its
flags) should be configured delivered to offer them a preferred
class of service. If RSVP packets experience noticeable losses
when crossing a congested non-RSVP cloud, a larger value can be
used for the timeout factor K (see section 3.5 below).

Some multicast routing protocols provide for "multicast tunnels",
which encapsulate multicast packets for transmission through
routers that do not have multicast capability. receiver application.

3.1.7 Confirmation Messages

RACK messages are sent to (probabilistically) acknowledge
reservation requests. A multicast tunnel
looks like RACK message is sent as the result of
the appearance of a logical outgoing interface that RESV_CONFIRM object in a RESV message.

A RACK message is mapped into some sent to the unicast address of a receiver
host; the address is obtained from the RESV_CONFIRM object.
However, a RACK message is forwarded to the receiver hop-by-
hop, to accommodate the hop-by-hop integrity check mechanism.

<ERROR_SPEC>

Braden, Zhang, et al. Expiration: May August 1996 [Page 43]

Internet Draft RSVP Specification November 1995

physical interface. A multicast routing protocol that supports
tunnels will describe a route using February 1996

<RESV_CONFIRM>

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

The RESV_CONFIRM object is a list copy of logical rather than
physical interfaces. RSVP can run through multicast tunnels that object in the following manner:

1. When a node N forwards a PATH RESV
message out a logical outgoing
interface L, it includes in that triggered the message some encoding of confirmation. The ERROR_SPEC is
used only to carry the
identity IP address of L, called the "logical interface handle" or LIH.
The LIH value is carried originating node, in
the RSVP_HOP object.

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

3. When N' sends a RESV message Error Code and Value are zero to N, it includes
indicate a confirmation. The object order requirements within
the LIH value
from the path state (again, in the RSVP_HOP object).

4. When flow descriptor list are the same as those given earlier
for a RESV message arrives at N, its LIH value provides
the information necessary to attach the reservation message.

3.2 Sending RSVP Messages

RSVP messages are sent hop-by-hop between RSVP-capable routers as
"raw" IP packets with protocol number 46. Raw IP packets are
intended to the
appropriate logical interface. Note that N creates be used between an end system and
interprets the LIH; first/last hop
router, although it is an opaque value also possible to N'.

3.3 Avoiding RSVP Message Loops

Forwarding of encapsulate RSVP messages must avoid looping. In steady state,
PATH
as UDP datagrams for end-system communication, as described in
Appendix C. UDP encapsulation is needed for systems that cannot
do raw network I/O.

PATH, PTEAR, and RESV RACK messages are forwarded only once per refresh period
on each hop. must be sent with the Router Alert
IP option [Katz95] in their IP headers. This avoids looping packets, but there is still option may be used
in the
possibility fast forwarding path of an " auto-refresh" loop, clocked by a high-speed router to detect
datagrams that require special processing.

Upon the refresh
period. Such auto-refresh loops keep state active "forever", even
if arrival of an RSVP message M that changes the end nodes have ceased refreshing it, until either state, a
node must forward the
receivers leave modified state immediately. However, this
must not trigger sending an message out the multicast group and/or interface through
which M arrived (as could happen if the senders stop
sending PATH messages. On implementation simply
triggered an immediate refresh of all state for the other hand, error and teardown
messages are forwarded immediately and are therefore subject session).
This rule is necessary to
looping.

Consider each prevent packet storms on broadcast LANs.

An RSVP message type.

o PATH Messages

PATH messages are forwarded in exactly must be fragmented when necessary to fit into the same way as IP
data packets. Therefore there should
MTU of the interface through which it will be no loops sent. All fragments
of PATH
messages, even in a topology with cycles.

o PTEAR Messages

PTEAR messages use the message should carry the same routing unique value of the Message
ID field, as PATH messages well as appropriate Fragment Offset and
therefore cannot loop.

o PERR Messages MF bits, in
their common headers. When an RSVP message arrives, it must be
reassembled before it can be processed. The refresh period R can
be used as an appropriate reassembly timeout time.

Between adjacent RSVP-capable routers, RSVP-level fragmentation
mechanism should normally be used in lieu of fragmentation at the
IP level. However, IP-level fragmentation may still occur when

Braden, Zhang, et al. Expiration: May August 1996 [Page 44]

Internet Draft RSVP Specification November 1995

Since PATH February 1996

RSVP messages do not loop, they create path state
defining travel through a loop-free reverse path non-RSVP cloud. In case of IP6,
which does not support IP fragmentation at routers, an RSVP
implementation must use Path MTU Discovery or hand configuration
to each sender. PERR
messages are always directed obtain an appropriate MTU between adjacent RSVP neighbors.

RSVP uses its periodic refresh mechanisms to particular senders and
therefore cannot loop.

o RESV Messages

RESV recover from
occasional packet losses. Under network overload, however,
substantial losses of RSVP messages directed to particular senders (i.e., with
explicit sender selection) cannot loop. However, RESV
messages with wildcard sender selection (WF style) have could cause a
potential for auto-refresh looping.

o RTEAR Messages

Although RTEAR messages are routed the same as RESV messages,
during failure of
resource reservations. To control the second pass around a loop there will be no state
so any RTEAR message will queueing delay and dropping
of RSVP packets, routers should be dropped. Hence there is no
looping problem here.

o RERR Messages

RERR messages for WF style reservations may loop for
essentially the same reasons that RESV messages loop.

o RACK Messages

RACK messages are forwarded towards configured to offer them a fixed unicast receiver
address and cannot loop.

If the topology has no loops, then looping
preferred class of "wildcard" RESV and
RERR messages, i.e., messages with wildcard sender selection, service. If RSVP packets experience noticeable
losses when crossing a congested non-RSVP cloud, a larger value
can be avoided by simply enforcing used for the rule given earlier: state timeout factor K (see section 3.6 below).

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 logical outgoing interface that is received mapped into some
physical interface. A multicast routing protocol that supports
tunnels will describe a route using a list of logical rather than
physical interfaces. RSVP can run through multicast tunnels in
the following manner:

1. When a particular interface must never be forwarded node N forwards a PATH message out a logical outgoing
interface L, it includes in the same interface. However, when the topology does have
cycles, further effort is needed to prevent auto-refresh loops message some encoding of
wildcard RESV messages and fast loops the
identity of wildcard RERR messages. L, called the "logical interface handle" or LIH.
The solution to this problem adopted by this protocol
specification LIH value is for such messages to carry an explicit sender
address list carried in a SCOPE the RSVP_HOP object.

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

3. When N' sends a RESV message with WF style is to be forwarded to a
particular previous hop, a new SCOPE object is computed N, it includes the LIH value
from the
SCOPE objects that were received path state (again, in matching RESV messages. If the computed SCOPE object is empty, RSVP_HOP object).

4. When the RESV message is not forwarded arrives at N, its LIH value provides
the information necessary to attach the previous hop; otherwise, reservation to the message is sent containing
appropriate logical interface. Note that N creates and
interprets the
new SCOPE object. The rules for computing a new SCOPE object for
a LIH; it is an opaque value to N'.

3.3 Avoiding RSVP Message Loops

Forwarding of RSVP messages must avoid looping. In steady state,
PATH and RESV message messages are as follows:

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

Internet Draft RSVP Specification November 1995

1. The union forwarded only once per refresh period
on each hop. This avoids looping packets, but there is formed of still the sets
possibility of sender IP addresses listed
in all SCOPE objects in an "auto-refresh" loop, clocked by the reservation refresh
period. Such auto-refresh loops keep state for the given
session.

If reservation state from some NHOP does not contain a SCOPE
object, a substitute sender list must be created and included
in the union. For a message that arrived on outgoing
interface OI, active "forever", even
if the substitute list is end nodes have ceased refreshing it, until either the set of senders that
route to OI.

2. Any local senders (i.e., any sender applications on this
node) are removed from this set.

3. If
receivers leave the SCOPE object is to be sent to PHOP, remove from multicast group and/or the
set any senders that did not come from PHOP.

Figure 11 shows an example of wildcard-scoped (WF style) RESV stop
sending PATH messages. The address lists within SCOPE objects are shown in
square brackets. Note that there may be additional connections
among On the nodes, creating looping topology that is not shown. other hand, error and teardown

Braden, Zhang, et al. Expiration: May August 1996 [Page 46] 45]

Internet Draft RSVP Specification November 1995

________________
a | | c
R4, S4<----->| Router |<-----> R2, S2, S3
| |
b | |
R1, S1<----->| |
|________________|

Figure 11: SCOPE Objects in Wildcard-Scope Reservations

SCOPE objects February 1996

messages are not necessary if the multicast routing uses
shared trees or if the reservation style has explicit sender
selection. Furthermore, attaching a SCOPE object to a reservation
may be deferred forwarded immediately and are therefore subject to a node which has more than one previous hop
upstream.

The following rules
looping.

Consider each message type.

o PATH Messages

PATH messages are used for SCOPE objects forwarded in RERR messages
with WF style:

1. The node that detected exactly the error initiates an RERR message
containing a copy same way as IP
data packets. Therefore there should be no loops of the SCOPE object associated PATH
messages, even in a topology with cycles.

o PTEAR Messages

PTEAR messages use the
reservation same routing as PATH messages and
therefore cannot loop.

o PERR Messages

Since PATH messages do not loop, they create path state or message in error.

2. Suppose a wildcard-scoped RERR message arrives at
defining a node loop-free reverse path to each sender. PERR
messages are always directed to particular senders and
therefore cannot loop.

o RESV Messages

RESV messages directed to particular senders (i.e., with
explicit sender selection) cannot loop. However, RESV
messages with wildcard sender selection (WF style) have a SCOPE object containing
potential for auto-refresh looping.

o RTEAR Messages

Although RTEAR messages are routed the sender host address list L.
The node forwards same as RESV messages,
during the RERR second pass around a loop there will be no state
so any RTEAR message using the rules of Section
3.1.5. However, the will be dropped. Hence there is no
looping problem here.

o RERR message Messages

RERR messages for WF style reservations may loop for
essentially the same reasons that RESV messages loop.

o RACK Messages

RACK messages are forwarded out OI must
contain towards a SCOPE object derived from L by including only those
senders that route to OI. fixed unicast receiver
address and cannot loop.

If this SCOPE object is empty, the topology has no loops, then looping of RESV and RERR

Braden, Zhang, et al. Expiration: May August 1996 [Page 47] 46]

Internet Draft RSVP Specification November 1995

RERR message should not February 1996

messages with wildcard sender selection can be sent out OI.

3.4 Local Repair

When a route changes, avoided by simply
enforcing the next PATH or RESV refresh message will
establish path or reservation rule given earlier: state (respectively) along that is received through a
particular interface must never be forwarded out the new
route. To provide fast adaptation to routing changes without same
interface. However, when the
overhead topology does have cycles, further
effort is needed to prevent auto-refresh loops of short refresh periods, the local routing protocol
module can notify the RSVP daemon wildcard RESV
messages and fast loops of route changes for particular
destinations. wildcard RERR messages. The RSVP daemon should use solution
to this information problem adopted by this protocol specification is for such
messages to
trigger carry an explicit sender address list in a quick refresh of state for these destinations, using the
new route.

More specifically, the rules are as follows:

o SCOPE
object.

When routing detects a change of the set of outgoing
interfaces for destination G, RSVP should wait for a short
period W, and then send PATH refreshes for all sessions G/*
(i.e., for any session RESV message with destination G, regardless of
destination port).

The short wait period before sending PATH refreshes WF style is to
allow the routing protocol getting settled with the new
change(s), and the exact value for W should be chosen
accordingly. Currently W = 2 sec is suggested; however, this
value should be configurable per interface.

o When forwarded to a PATH message arrives with
particular previous hop, a Previous Hop address that
differs new SCOPE object is computed from the one stored
SCOPE objects that were received in the path state, RSVP should
send immediate matching RESV refreshes messages. If
the computed SCOPE object is empty, the message is not forwarded
to the previous hop; otherwise, the message is sent containing the
new SCOPE object. The rules for that session.

3.5 Time Parameters

There computing a new SCOPE object for
a RESV message are two time parameters relevant to each element as follows:

1. The union is formed of RSVP
path or reservation state in a node: the refresh period R between
generation sets of successive refreshes for sender IP addresses listed
in all SCOPE objects in the reservation state by for the neighbor
node, given
session.

If reservation state from some NHOP does not contain a SCOPE
object, a substitute sender list must be created and included
in the local state's lifetime L. Each RSVP RESV or PATH
message may contain union. For a TIME_VALUES object specifying message that arrived on outgoing
interface OI, the R value substitute list is the set of senders that was used
route to generate OI.

2. Any local senders (i.e., any sender applications on this (refresh) message. This R value
node) are removed from this set.

3. If the SCOPE object is
then used to determine the value for L when be sent to PHOP, remove from the state is received
and stored. The values for R and L may vary
set any senders that did not come from hop to hop.

In more detail:

1. Floyd and Jacobson [FJ94] have PHOP.

Figure 11 shows an example of wildcard-scoped (WF style) RESV
messages. The address lists within SCOPE objects are shown that periodic messages
generated by independent network nodes can become
synchronized. This can lead to disruption in network
services as
square brackets. Note that there may be additional connections
among the periodic messages contend with other network nodes, creating looping topology that is not shown.

Braden, Zhang, et al. Expiration: May August 1996 [Page 48] 47]

Internet Draft RSVP Specification November 1995

traffic for link and forwarding resources. Since RSVP sends
periodic refresh messages, it must avoid message
synchronization and ensure that any synchronization that may
occur is February 1996

________________
a | | c
R4, S4<----->| Router |<-----> R2, S2, S3
| |
b | |
R1, S1<----->| |
|________________|

Figure 11: SCOPE Objects in Wildcard-Scope Reservations

SCOPE objects are not stable.

For this reason, necessary if the refresh timer should multicast routing uses
shared trees or if the reservation style has explicit sender
selection. Furthermore, attaching a SCOPE object to a reservation
may be randomly set deferred to a value in the range [0.5R, 1.5R].

2. To avoid premature loss of state, L must satisfy L >= (K +
0.5)*1.5*R, where K is a small integer. Then node which has more than one previous hop
upstream.

The following rules are used for SCOPE objects in the worst
case, K-1 successive RERR messages may be lost without state being
deleted. To compute a lifetime L for a collection of state
with different R values R0, R1, ..., replace R by max(Ri).

Currently K = 3 is suggested as WF style:

1. The node that detected the default. However, it may
be necessary to set error initiates an RERR message
containing a larger K value for hops copy of the SCOPE object associated with high loss
rate. K may be set either by manual configuration per
interface, or by some adaptive technique that has not yet
been specified.

3. Each message that creates the
reservation state (PATH or RESV message)
carries message in error.

2. Suppose a TIME_VALUES wildcard-scoped RERR message arrives at a node with
a SCOPE object containing the R used to
generate refreshes; the recipient sender host address list L.
The node uses this R to
determine L of forwards the stored state.

4. R is chosen locally by each node. If RERR message using the node does not
implement local repair rules of reservations disrupted Section
3.1.6. However, the RERR message forwarded out OI must
contain a SCOPE object derived from L by including only those
senders that route
changes, a smaller R speeds up adaptation to routing changes,
while increasing OI. If this SCOPE object is empty, the

Braden, Zhang, et al. Expiration: August 1996 [Page 48]

Internet Draft RSVP overhead. With local repair, a
router can Specification February 1996

RERR message should not be more relaxed about R since the periodic refresh
becomes only sent out OI.

3.4 Blockade State

The basic rule for creating a backstop robustness mechanism. A node may
therefore adjust the effective R dynamically RESV refresh message is to control merge the
amount
flowspecs of overhead due the reservation requests in place in the node, by
computing their LUB. However, this rule is modified by the
existence of "blockade state" resulting from RERR messages, to refresh messages.
solve the KR-II problem (Section 2.6). The current suggested default for R is 30 seconds. However, blockade state also
enters into the default should be configurable per interface.

5. routing of RERR messages for Admission Control
failure.

When R a RERR message for an Admission Control failure is changed dynamically, there received,
its flowspec Qe is a limit used to how fast
it may increase. Specifically, create or refresh an element of local
blockade state. Each element of blockade state consists of a
blockade flowspec Qb taken from the ratio flowspec of two successive
values R2/R1 must not exceed 1 + Slew.Max.

Currently, Slew.Max the last RERR, and
an associated blockade timer Tb. When the blockade timer expires,
the blockade state is 0.30. With K = 3, one packet deleted.

The granularity of blockade state depends upon the style of the
RERR message that created it. For an explicit style, there may be
lost without
a blockade state element (Qb(S),Tb(S)) for each sender S. For a
wildcard style, blockade state timeout while R is increasing 30 percent per refresh cycle.

6. To improve robustness, previous hop P.

An element of blockade state with flowspec Qb is said to
"blockade" a node may temporarily send refreshes

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

Internet Draft RSVP Specification November 1995

more often reservation with flowspec Qi if Qb is not (strictly)
greater than R after Qi. For example, suppose that the LUB of two
flowspecs is computed by taking the max of each of their
corresponding components. Then Qb blockades Qi if for some
component j, Qb[j] <= Qi[j].

Suppose that a state change (including initial
state establishment).

7. The values node receives a RERR message from previous hop P
(or, if style is explicit, sender S) as the result of Rdef, K, and Slew.Max used in an implementation
should be easily modifiable per interface, as experience may
lead to different values. The possibility Admission
Control failure upstream. Then:

1. An element of dynamically
adapting K and/or Slew.Max in response to measured loss rates blockade state is created for future study.

3.6 Traffic Policing and TTL

RSVP P (or S) if it
did not exist.

2. Qb(P) (or Qb(S)) is required to compute and pass several service-related flags set equal to traffic control: policing flags and a non-RSVP flag.

Some QoS services may require traffic policing at some or all of
(1) the edge of flowspec Qe from the network, (2) a merging point
RERR message.

3. A corresponding blockade timer Tb(P) (or Tb(S)) is started or
restarted for data from
multiple senders, and/or (3) a branch point where traffic flow
from upstream may be greater than time Kb*R. Here Kb is a fixed multiplier and
R is the downstream reservation. refresh interval for reservation state. Kb should
be configurable.

4. If there is some local reservation state that is not
blockaded (see below), an immediate reservation refresh for P

Braden, Zhang, et al. Expiration: August 1996 [Page 49]

Internet Draft RSVP knows where such points occur and must so indicate Specification February 1996

(or S) is generated.

5. The RERR message is forwarded to next hops in the
traffic control mechanism. On following
way. If the other hand, RSVP does not
interpret the service embodied in InPlace bit is off, the flowspec and therefore does
not know whether policing will actually be applied in any
particular case.

The RSVP daemon passes RERR message is
forwarded to traffic control a separate policing flag all next hops for each of these three situations.

o E_Police_Flag -- Entry Policing

This flag which there is set in reservation
state. If the first-hop RSVP node that implements
traffic control (and InPlace bit is therefore capable of policing).

For example, sender hosts must implement RSVP but currently
many of them do not implement traffic control. In this case,
the E_Police_Flag should be off in on, the sender host, and it
should RERR message is
forwarded only be set on when to the first hop capable of traffic
control is reached. This next hops whose Qi is controlled blockaded by Qb.

Finally, we present the E_Police flag
in SESSION objects.

o M_Police_Flag -- Merge Policing

This flag should be set on modified rule for merging flowspecs to
create a reservation using refresh message.

o If there are any local reservation requests Qi that are not
blockaded, these are merged by computing their LUB. The
blockaded reservations are ignored; this allows forwarding of
a smaller reservation that has not failed and may perhaps
succeed, after a larger reservation fails.

o Otherwise (all local requests Qi are blockaded), they are
merged by taking the GLB (Greatest Lower Bound) of the Qi's.

This refresh merging algorithm is applied separately to each flow
(each sender or PHOP) contributing to a shared
style reservation (WF or SE) when flows from more than one sender are
being merged.

o B_Police_Flag -- Branch Policing

This flag should be set on when
SE style).

Figure 12 shows an example of the flowspec being installed the application of blockade
state for a shared reservation (WF style). There are two previous
hops labelled (a) and (b), and two next hops labelled (c) and (d).
The larger reservation 4B arrived from (c) first, but it failed
somewhere upstream via PHOP (a), but not via PHOP (b). The
figures show the final "steady state" after the smaller
reservation 2B subsequently arrived from (d). This steady state
is perturbed roughly every Kb*R seconds, when the blockade state
times out. The next refresh then sends 4B to previous hop (a);
presumably this will fail, sending a RERR message that will re-
establish the blockade state, returning to the situation shown in
the figure. At the same time, the RERR message will be forwarded
to next hop (c) and to all receivers downstream responsible for
the 4B reservations.

Braden, Zhang, et al. Expiration: May August 1996 [Page 50]

Internet Draft RSVP Specification November 1995

is smaller than, or incomparable to, February 1996

Send Blockade| Reserve Receive
State|
|
| ________
(a) <- WF(*{2B}) {4B} | | * {4B} | WF(*{4B}) <- (c)
| |________|
|
---------------------------|-------------------------------
|
| ________
(b) <- WF(*{4B}) (none)| | * {2B} | WF(*{2B}) <- (d)
| |________|

Figure 12: Blockading with Shared Style

3.5 Local Repair

When a FLOWSPEC in place on
any other interface, for route changes, the same FILTER_SPEC and SESSION.

RSVP must also detect and report next PATH or RESV refresh message will
establish path or reservation state (respectively) along the new
route. To provide fast adaptation to receivers routing changes without the presence
overhead of
non-RSVP hops in short refresh periods, the local routing protocol
module can notify the path. For this purpose, an RSVP daemon must
place into each PATH message that it sends the value of the IP TTL
with which the message was sent. route changes for particular
destinations. The RSVP-capable node that
receives this message compares this field to the TTL with which
the message was actually received, and if they differ it turns on
the Non_RSVP flag. This flag is carried forward to receivers in
the ADSPEC [??].

3.7 Multihomed Hosts

Accommodating multihomed hosts requires some special rules in
RSVP. We RSVP daemon should use the term `multihomed host' this information to cover both hosts (end
systems) with more than one network interface [could ref. section
3.3.4 of RFC-1122], and routers that are supporting local
application programs.

An application executing on
trigger a multihomed host may explicitly
specify which interface any given flow will use for sending and/or quick refresh of state for receiving data packets, to override these destinations, using the system-specified
default interface.
new route.

The RSVP daemon must be aware of the default,
and if an application sets a specific interface, it must also pass
that information to RSVP. rules are as follows:

o Sending Data

A sender application uses an API call (SENDER in Section
3.9.1) to declare to RSVP the characteristics of the data
flow it will originate. This call may optionally include the
local IP address When routing detects a change of the sender. If it is set by the
application, this parameter must be the interface address of outgoing
interfaces for
sending the data packets; otherwise, the system default
interface is implied.

The destination G, RSVP daemon on the host should wait for a short
period W, and then sends send PATH messages refreshes for this
application out the specified interface (only).

o Making Reservations

A receiver application uses an API call (called RESERVE in
Section 3.9.1) all sessions G/*
(i.e., for any session with destination G, regardless of
destination port).

The short wait period before sending PATH refreshes is to request a reservation from RSVP. This call
may optionally include
allow the local IP address of routing protocol getting settled with the receiver,
i.e., new
change(s), and the interface address exact value for receiving data packets. In
the case of multicast sessions, this W should be chosen
accordingly. Currently W = 2 sec is suggested; however, this
value should be configurable per interface.

o When a PATH message arrives with a Previous Hop address that
differs from the interface on
which the group has been joined. If one stored in the parameter is path state, RSVP should
send immediate RESV refreshes for that session.

Braden, Zhang, et al. Expiration: May August 1996 [Page 51]

Internet Draft RSVP Specification November 1995

omitted, the system default interface is used.

In general, the February 1996

3.6 Time Parameters

There are two time parameters relevant to each element of RSVP daemon should send RESV messages
path or reservation state in a node: the refresh period R between
generation of successive refreshes for
application out the specified interface. However, when state by the
application is executing on a router neighbor
node, and the session is
multicast, a more complex situation arises. Suppose in this
case that local state's lifetime L. Each RSVP RESV or PATH
message may contain a receiver application joins TIME_VALUES object specifying the group on an
interface Iapp R value
that differs from Isp, the shortest-path
interface was used to generate this (refresh) message. This R value is
then used to determine the sender. Then there are two possible ways value for multicast routing L when the state is received
and stored. The values for R and L may vary from hop to deliver data packets hop.

In more detail:

1. Floyd and Jacobson [FJ94] have shown that periodic messages
generated by independent network nodes can become
synchronized. This can lead to disruption in network
services as the
application. The periodic messages contend with other network
traffic for link and forwarding resources. Since RSVP daemon sends
periodic refresh messages, it must determine which case holds
by examining avoid message
synchronization and ensure that any synchronization that may
occur is not stable.

For this reason, the path state, to decide which incoming
interface refresh timer should be randomly set to use for sending RESV messages.

1. The multicast routing protocol may create
a separate
branch value in the range [0.5R, 1.5R].

2. To avoid premature loss of state, L must satisfy L >= (K +
0.5)*1.5*R, where K is a small integer. Then in the multicast distribution `tree' to deliver
to Iapp. In this worst
case, there will K-1 successive messages may be path lost without state being
deleted. To compute a lifetime L for
both Isp and Iapp. The path state on Iapp should only
match a reservation from collection of state
with different R values R0, R1, ..., replace R by max(Ri).

Currently K = 3 is suggested as the local application; default. However, it must may
be marked "Local_only" by the RSVP daemon. If
"Local_only" path state necessary to set a larger K value for Iapp exists, the RESV
message should hops with high loss
rate. K may be sent out Iapp.

Note that it is possible for the path state blocks for
Isp and Iapp to have the same next hop, if there is an
intervening non-RSVP cloud.

2. The multicast routing protocol may forward data within
the router from Isp to Iapp. In this case, Iapp will
appear in the list of outgoing interfaces of the path
state for Isp, and the RESV set either by manual configuration per
interface, or by some adaptive technique that has not yet
been specified.

3. Each message should be sent out
Isp.

3.8 Future Compatibility

We may expect that in the future new object C-Types will be
defined for existing object classes, and perhaps new creates state (PATH or RESV message)
carries a TIME_VALUES object
classes will be defined. It will be desirable containing the R used to employ such new
objects within
generate refreshes; the Internet using older implementations that do
not recognize them. Unfortunately, recipient node uses this is only possible R to a
limited degree with reasonable complexity. The rules are as
follows.

1. Unknown Class

There are two possible ways that an RSVP implementation can
treat an object with unknown class. This choice
determine L of the stored state.

4. R is
determined chosen locally by each node. If the high-order bit node does not
implement local repair of reservations disrupted by route
changes, a smaller R speeds up adaptation to routing changes,
while increasing the Class-Num octet, as RSVP overhead. With local repair, a
router can be more relaxed about R since the periodic refresh
becomes only a backstop robustness mechanism. A node may

Braden, Zhang, et al. Expiration: May August 1996 [Page 52]

Internet Draft RSVP Specification November 1995

follows.

o Class-Num >= 128

In this case, the entire message should be rejected and
an "Unknown Object Class" error returned.

o Class-Num < 128

In this case, the node should ignore February 1996

therefore adjust the object but
forward it, unexamined and unmodified, in all messages
resulting from effective R dynamically to control the state contained in this message.

For example, suppose that a RESV message that is
received contains an object
amount of unknown class. Such an
object should be saved in the reservation state without
further examination; however, only overhead due to refresh messages.

The current suggested default for R is 30 seconds. However,
the latest object
with a given (unknown class, C-Type) pair default should be
saved. configurable per interface.

5. When a RESV message R is changed dynamically, there is forwarded, it should
include copies of such saved unknown-class objects from
all reservations that are merged to form the new RESV
message.

Note that objects with unknown class cannot be merged;
however, unmerged objects may be forwarded until they
reach a node that knows limit on how to merge them. Forwarding
objects with unknown class enables incremental
deployment of new objects; however, fast
it may increase. Specifically, the scaling
limitations ratio of doing so two successive
values R2/R1 must be carefully examined
before a new object class not exceed 1 + Slew.Max.

Currently, Slew.Max is deployed with Class-Num <
128.

These rules should 0.30. With K = 3, one packet may be considered when any new Class-Num
lost without state timeout while R is
defined.

2. Unknown C-Type for Known Class

One might expect the known Class-Num to provide information
that could allow intelligent handling of such an object.
However, in practice such class-dependent handling is
complex, increasing 30 percent
per refresh cycle.

6. To improve robustness, a node may temporarily send refreshes
more often than R after a state change (including initial
state establishment).

7. The values of Rdef, K, and Slew.Max used in many cases it is not useful.

Generally, the appearance of an object with unknown C-Type implementation
should result in rejection of the entire message and
generation of an error message (RERR or PERR be easily modifiable per interface, as appropriate).
The error message will include the Class-Num and C-Type that
failed (see Appendix B); the end system that originated the
failed message experience may be able to use this information
lead to retry

Braden, Zhang, et al. Expiration: May 1996 [Page 53]

Internet Draft RSVP Specification November 1995

the request using a different C-Type object, repeating this
process until it runs out of alternatives or succeeds.

Objects values. The possibility of certain classes (FLOWSPEC, ADSPEC, and
POLICY_DATA) are opaque to RSVP, which simply hands them dynamically
adapting K and/or Slew.Max in response to measured loss rates
is for future study.

3.7 Traffic Policing and Non-Integrated Service Hops

Some QoS services may require traffic control policing at some or policy modules. Depending upon its
internal rules, either all of
(1) the latter modules may reject edge of the network, (2) a C-
Type and inform merging point for data from
multiple senders, and/or (3) a branch point where traffic flow
from upstream may be greater than the downstream reservation being
requested. RSVP daemon; RSVP should then reject the
message knows where such points occur and send an error, as described must so
indicate to the traffic control mechanism. On the other hand,
RSVP does not interpret the service embodied in the previous
paragraph. flowspec and
therefore does not know whether policing will actually be applied
in any particular case.

The RSVP daemon passes to traffic control a separate policing flag
for each of these three situations.

o E_Police_Flag -- Entry Policing

This flag is set in the first-hop RSVP node that implements
traffic control (and is therefore capable of policing).

For example, sender hosts must implement RSVP but currently
many of them do not implement traffic control. In this case,
the E_Police_Flag should be off in the sender host, and it
should only be set on when the first node capable of traffic

Braden, Zhang, et al. Expiration: May August 1996 [Page 54] 53]

Internet Draft RSVP Specification November 1995

3.9 RSVP Interfaces

RSVP February 1996

control is reached. This is controlled by the E_Police flag
in SESSION objects.

o M_Police_Flag -- Merge Policing

This flag should be set on for a router has interfaces to routing and to traffic control.
RSVP on reservation using a host has an interface to applications (i.e, an API) and
also an interface to traffic control (if it exists shared
style (WF or SE) when flows from more than one sender are
being merged.

o B_Police_Flag -- Branch Policing

This flag should be set on when the host).

3.9.1 Application/RSVP Interface

This section describes flowspec being installed
is smaller than, or incomparable to, a generic interface between an
application FLOWSPEC in place on
any other interface, for the same FILTER_SPEC and an SESSION.

RSVP control process. The details of a real
interface may be operating-system dependent; must also detect and report to receivers the following can
only suggest presence of
non-RSVP (which implies non-integrated-service compliant) hops in
the basic functions to be performed. Some path. For this purpose, an RSVP daemon sets the Non_RSVP flag
bit in SESSION object of
these calls cause information to be returned asynchronously.

o Register Session

Call: SESSION( DestAddress , ProtocolId, DstPort ,

[ , SESSION_object ]

[ , Upcall_Proc_addr ] ) -> Session-id

This call initiates PATH messages. With normal IP
forwarding, RSVP processing for can detect a session, defined non-RSVP hop by DestAddress together comparing the IP TTL
with ProtocolId and possibly which a
port number DstPort. If successful, PATH message is sent to the SESSION call
returns immediately TTL with a local session identifier
Session-id, which may be used it is
received, and set the Non_RSVP bit on. For this purpose, the
transmission TTL is placed in subsequent calls.

The Upcall_Proc_addr parameter defines the address of an
upcall procedure to receive asynchronous error or event
notification; see below. The SESSION_object parameter common header.

However, the TTL is
included as an escape mechanism to support some more
general definition not always a reliable indicator of the session ("generalized
destination port"), should that non-RSVP
hops, and other means must be necessary in used. For example, if the
future. Normally SESSION_object routing
protocol uses IP encapsulating tunnels, then the routing protocol
must inform RSVP when non-RSVP hops are included. If no automatic
mechanism will work, manual configuration will be omitted.

o Define Sender

Call: SENDER( Session-id,

[ , Source_Address ] [ , Source_Port ]

[ , Sender_Template ]

[ , Sender_Tspec ] [ , Data_TTL ]

[ , Sender_Policy_Data ] ) required.
Finally, there may still be cases where an RSVP cannot reliably
determine whether or not a non-RSVP hop was used. To report this
to the receiver, the SESSION object carries another flag bit,
Maybe_RSVP.

3.8 Multihomed Hosts

Accommodating multihomed hosts requires some special rules in
RSVP. We use the term `multihomed host' to cover both hosts (end
systems) with more than one network interface [could ref. section
3.3.4 of RFC-1122], and routers that are supporting local
application programs.

An application executing on a multihomed host may explicitly
specify which interface any given flow will use for sending and/or
for receiving data packets, to override the system-specified
default interface. The RSVP daemon must be aware of the default,
and if an application sets a specific interface, it must also pass
that information to RSVP.

Braden, Zhang, et al. Expiration: May August 1996 [Page 55] 54]

Internet Draft RSVP Specification November 1995 February 1996

o Sending Data

A sender application uses this an API call (SENDER in Section
3.10.1) to define, or declare to modify the
definition of, RSVP the attributes characteristics of the data stream. The
first SENDER call for the session registered as `Session-
id' will cause RSVP to begin sending PATH messages for
this session; later calls
flow it will modify the path
information.

The SENDER parameters are interpreted as follows:

- Source_Address originate. This is call may optionally include the
local IP address of the interface from which the
data will be sent. sender. If it is omitted, a set by the
application, this parameter must be the interface address for
sending the data packets; otherwise, the system default
interface will be used. This parameter is needed implied.

The RSVP daemon on
a multihomed sender host.

- Source_Port

This is the UDP/TCP port from which the data will be
sent. If it is omitted or zero, host then sends PATH messages for this
application out the port is "wild"
and can match any port in a FILTER_SPEC.

- Sender_Template

This parameter is included as specified interface (only).

o Making Reservations

A receiver application uses an escape mechanism API call (RESERVE in Section
3.10.1) to
support request a more general definition reservation from RSVP. This call may
optionally include the local IP address of the sender
("generalized source port"). Normally receiver,
i.e., the interface address for receiving data packets. In
the case of multicast sessions, this parameter
may be omitted.

- Sender_Tspec

This optional parameter describes is the traffic flow to
be sent. It may be included to prevent over-
reservation interface on
which the initial hops.

- Data_TTL

This is group has been joined. If the (non-default) IP Time-To-Live parameter
that is being supplied on
omitted, the data packets. It system default interface is
needed to ensure that Path used.

In general, the RSVP daemon should send RESV messages do not have a
scope larger than multicast data packets.

- Sender_Policy_Data

This optional parameter passes policy data for an
application out the
sender. This data may be supplied by a system
service, with specified interface. However, when the
application treating it as opaque.

Braden, Zhang, et al. Expiration: May 1996 [Page 56]

Internet Draft RSVP Specification November 1995

o Reserve

Call: RESERVE( session-id, [ receiver_address , ]

[ ACK_flag, ] style, style-dependent-parms )

A receiver uses this call to make or to modify is executing on a resource
reservation for router and the session registered as `session-id'.
The first RESERVE call will initiate the periodic
transmission of RESV messages. A later RESERVE call may
be given to modify the parameters of the earlier call (but
note that changing existing reservations may result is
multicast, a more complex situation arises. Suppose in
admission control failure).

The optional `receiver_address' parameter may be used by this
case that a receiver application joins the group on a multihomed host (or router); it is an
interface Iapp that differs from Isp, the IP
address of one of shortest-path
interface to the node's interfaces. The ACK_flag
should be set on if a reservation ACK is desired, off
otherwise. sender. Then there are two possible ways
for multicast routing to deliver data packets to the
application. The `style' parameter indicates RSVP daemon must determine which case holds
by examining the
reservation style. path state, to decide which incoming
interface to use for sending RESV messages.

1. The rest multicast routing protocol may create a separate
branch of the parameters depend upon
the style, but generally these multicast distribution `tree' to deliver
to Iapp. In this case, there will include appropriate
flowspecs, filter specs, be path state for
both Isp and possibly receiver policy data
objects. Iapp. The RESERVE call returns immediately. Following path state on Iapp should only
match a RESERVE
call, an asynchronous ERROR/EVENT upcall may occur at any
time.

o Release

Call: RELEASE( session-id )

This call removes reservation from the local application; it must
be marked "Local_only" by the RSVP daemon. If
"Local_only" path state for Iapp exists, the session specified by
session-id. The node then sends appropriate teardown
messages and ceases sending refreshes RESV
message should be sent out Iapp.

Note that it is possible for this session-id.

o Error/Event Upcalls

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

[ Error_code , Error_value ,

Error_Node , LUB-Used, ]

List_count, [ Flowspec_list,]

[ Filter_spec_list, ] [ Advert_list, ] the path state blocks for
Isp and Iapp to have the same next hop, if there is an
intervening non-RSVP cloud.

Braden, Zhang, et al. Expiration: May August 1996 [Page 57] 55]

Internet Draft RSVP Specification November 1995

[ Policy_data ]

Here "Upcall_Proc" represents the upcall procedure whose
address was supplied in the SESSION call.

This upcall February 1996

2. The multicast routing protocol may occur asynchronously at any time after a
SESSION call and before a RELEASE call, to indicate an
error or an event. Currently there are five upcall types,
distinguished by forward data within
the Info_type parameter:

1. Info_type = Path Event

A Path Event upcall results router from receipt of the first
PATH message for this session, indicating to a
receiver application that there is at least one
active sender.

This upcall provides synchronizing information Isp 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' will
be the number in each list; where these objects are
missing, corresponding null objects must appear. The
Error_code, Error_value, LUB-Used flag, and
Policy_data parameters Iapp. In this case, Iapp will be undefined
appear in this
upcall.

2. Info_type = Resv Event

A Resv Event upcall is triggered by the receipt list of
the first reservation message or by modification outgoing interfaces of a
previous reservation state, the path
state for this session.

`List_count' will be 1, Isp, and Flowspec_list will
contain one FLOWSPEC, the effective QoS that would RESV message should be
applicable to sent out
Isp.

3.9 Future Compatibility

We may expect that in the application itself.
Filter_spec_list and Advert_list future new object C-Types will contain one
NULL object. The Error_code, Error_value, LUB-Used
flag, be
defined for existing object classes, and Policy_data parameters perhaps new object
classes will be undefined in defined. It will be desirable to employ such new
objects within the Internet using older implementations that do
not recognize them. Unfortunately, this upcall.

3. Info_type is only possible to a
limited degree with reasonable complexity. The rules are as
follows (`b' represents a bit).

1. Unknown Class

There are three possible ways that an RSVP implementation can
treat an object with unknown class. This choice is
determined by the two high-order bits of the Class-Num octet,
as follows.

o Class-Num = Path Error

An Path Error event indicates 0bbbbbbb

The entire message should be rejected and an "Unknown
Object Class" error returned.

o Class-Num = 10bbbbbb

The node should ignore the object, neither forwarding it
nor sending an error message.

o Class-Num = 11bbbbbb

The node should ignore the object but forward it,
unexamined and unmodified, in sender
information all messages resulting
from the state contained in this message.

For example, suppose that was specified a RESV message that is received
contains an object of unknown class number 11bbbbbb. Such an
object should be saved in the reservation state without
further examination; however, only the latest object with a SENDER call.
given (unknown class, C-Type) pair should be saved. When a
RESV message is forwarded, it should include copies of such
saved unknown-class objects from all reservations that are
merged to form the new RESV message.

Braden, Zhang, et al. Expiration: May August 1996 [Page 58] 56]

Internet Draft RSVP Specification November 1995

The Error_code parameter will define the error, and
Error_value may supply some additional (perhaps
system-specific) data about the error. The
Error_Node parameter will specify the IP address of
the February 1996

Note that objects with unknown class cannot be merged;
however, unmerged objects may be forwarded until they reach a
node that detected knows how to merge them. Forwarding objects with
unknown class enables incremental deployment of new objects;
however, the error.

`List_count' will scaling limitations of doing so must be 1, and Filter_spec_list will
contain
carefully examined before a new object class is deployed with
both high bits on.

These rules should be considered when any new Class-Num is
defined.

2. Unknown C-Type for Known Class

One might expect the Sender_Template supplied known Class-Num to provide information
that could allow intelligent handling of such an object.
However, in the SENDER
call; Flow_Spec_list practice such class-dependent handling is
complex, and Advert_list will each
contain one NULL object. The Policy_data parameter
will contain any POLICY_DATA objects in many cases it is not useful.

Generally, the PERR
message.

4. Info_type = Resv Error/Confirmation

An Resv Error/Confirmation event indicates appearance of an error object with unknown C-Type
should result in a reservation message to which this application
contributed, or the receipt rejection of a RACK message. The
Error_code parameter will define the entire message and
generation of an error message (RERR or
confirmation. For an error, Error_value may supply
some additional (perhaps system-specific) data. PERR as appropriate).
The
Error_Node parameter error message will specify the IP address of include the node Class-Num and C-Type that detected
failed (see Appendix B); the event being reported.

Filter_spec_list and Flowspec_list will contain end system that originated the
FILTER_SPEC and FLOWSPEC objects from
failed message may be able to use this information to retry
the error flow
descriptor (see Section 3.1.5). List_count will
specify the number request using a different C-Type object, repeating this
process until it runs out of FILTER_SPECS in
Filter_spec_list, while there will be one FLOWSPEC in
Flowspec_list. For an error, the Policy_data
parameter will contain any POLICY_DATA objects in the
RERR message.

Although RSVP messages indicating path alternatives or resv events may
be received periodically, the API should make the
corresponding asynchronous upcall succeeds.

Objects of certain classes (FLOWSPEC, ADSPEC, and
POLICY_DATA) are opaque to the application only
on the first occurrence RSVP, which simply hands them to
traffic control or when policy modules. Depending upon its
internal rules, either of the information to be
reported changes. All error latter modules may reject a C-
Type and confirmation events inform the RSVP daemon; RSVP should be reported to then reject the application.

3.9.2 RSVP/Traffic Control Interface

In
message and send an RSVP-capable node, enhanced QoS is achieved by a group of
inter-related traffic control functions: a packet classifier, error, as described in the previous
paragraph.

Braden, Zhang, et al. Expiration: May August 1996 [Page 59] 57]

Internet Draft RSVP Specification November 1995

an admission control module, February 1996

3.10 RSVP Interfaces

RSVP on a router has interfaces to routing and to traffic control.
RSVP on a packet scheduler. host has an interface to applications (i.e, an API) and
also an interface to traffic control (if it exists on the host).

3.10.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 following can
only suggest the basic functions to traffic control. be performed. Some of
these calls cause information to be returned asynchronously.

o Make a Reservation Register Session

Call: Rhandle = TC_AddFlowspec( Interface, TC_Flowspec,

TC_Tspec, E_Police_Flag,

M_Police_Flag, B_Police_Flag SESSION( DestAddress , ProtocolId, DstPort ,

[ , SESSION_object ]

[ , Upcall_Proc_addr ] ) -> Session-id

This call initiates RSVP processing for a session, defined
by DestAddress together with ProtocolId and possibly a
port number DstPort. If successful, the SESSION call
returns immediately with a local session identifier
Session-id, which may be used in subsequent calls.

The TC_Flowspec Upcall_Proc_addr parameter defines the desired effective
QoS address of an
upcall procedure to admission control; its value receive asynchronous error or event
notification; see below. The SESSION_object parameter is computed
included as an escape mechanism to support some more
general definition of the
maximum over session ("generalized
destination port"), should that be necessary in the flowspecs
future. Normally SESSION_object will be omitted.

o Define Sender

Call: SENDER( Session-id,

[ , Source_Address ] [ , Source_Port ]

[ , Sender_Template ]

[ , Sender_Tspec ] [ , Data_TTL ]

[ , Sender_Policy_Data ] )

Braden, Zhang, et al. Expiration: August 1996 [Page 58]

Internet Draft RSVP Specification February 1996

A sender uses this call to define, or to modify the
definition of, the attributes of different next hops (see the
Compare_Flowspecs data stream. The
first SENDER call below). It contains the effective
reservation Tspec Resv_Te (although for the session registered as `Session-
id' will cause RSVP daemon itself
has no means to extract begin sending PATH messages for
this session; later calls will modify the Tspec). path
information.

The TC_Tspec
parameter defines the effective sender Tspec Path_Te (see
Section 2.3). We assume that traffic control takes SENDER parameters are interpreted as follows:

- Source_Address

This is the
min address of Resv_Te and Path_Te (see step (4) in Section 2.3).

E_Police_Flag, M_Police_Flag, and B_Police_Flag are
Boolean parameters whose values should be set as described
in Section 3.6.

The TC_AddFlowspec call returns an error code if Flowspec
is malformed or if the requested resources are
unavailable. Otherwise, interface from which the
data will be sent. If it establishes is omitted, a new reservation
channel corresponding to Rhandle. It returns the opaque
number Rhandle for subsequent references to this
reservation.

o Modify Reservation

Call: TC_ModFlowspec( Rhandle, new_Flowspec,

Sender_Tspec, E_Police_flag,

M_Police_Flag, B_Police_Flag ) default
interface will be used. This call can modify an existing reservation. If
new_Flowspec parameter is included, it needed on
a multihomed sender host.

- Source_Port

This is passed to Admission
Control; if the UDP/TCP port from which the data will be
sent. If it is rejected, omitted or zero, the current flowspec port is left
in force. The corresponding filter specs, if any, are not
affected. The other parameters are defined as "wild"
and can match any port in
TC_AddFlowspec.

Braden, Zhang, et al. Expiration: May 1996 [Page 60]

Internet Draft RSVP Specification November 1995

o Delete Flowspec

Call: TC_DelFlowspec( Rhandle ) a FILTER_SPEC.

- Sender_Template

This call will delete parameter is included as an existing reservation, including escape mechanism to
support a more general definition of the flowspec and all associated filter specs.

o Add Filter Spec

Call: FHandle = TC_AddFilter( Rhandle, Session , FilterSpec ) sender
("generalized source port"). Normally this parameter
may be omitted.

- Sender_Tspec

This call is used to associate an additional filter spec
with optional parameter describes the traffic flow to
be sent. It may be included to prevent over-
reservation specified by on the given Rhandle,
following a successful TC_AddFlowspec call. This call
returns a filter handle FHandle.

o Delete Filter Spec

Call: TC_DelFilter( FHandle ) initial hops.

- Data_TTL

This call is used to remove a specific filter, specified
by FHandle.

o OPWA Update

Call: TC_Advertise( interface, Adspec,

[ , Non_RSVP_flag ] ) -> New_Adspec

This call the (non-default) IP Time-To-Live parameter
that is used for OPWA to compute being supplied on the outgoing
advertisement New_Adspec for a specified interface.

o Preemption Upcall

Upcall: TC_Preempt() -> RHandle, Reason_code

In order data packets. It is
needed to grant ensure that Path messages do not have a new reservation request, the admission
control and/or
scope larger than multicast data packets.

- Sender_Policy_Data

This optional parameter passes policy modules may be allowed to preempt an
existing reservation. data for the
sender. This might data may be reflected in an
upcall to RSVP, passing the RHandle of the preempted
reservation, and some indication of supplied by a system
service, with the reason. application treating it as opaque.

Braden, Zhang, et al. Expiration: May August 1996 [Page 61] 59]

Internet Draft RSVP Specification November 1995

3.9.3 RSVP/Routing Interface

An RSVP implementation needs February 1996

o Reserve

Call: RESERVE( session-id, [ receiver_address , ]

[ CONF_flag, ] style, style-dependent-parms )

A receiver uses this call to make or to modify a resource
reservation for the following support from session registered as `session-id'.
The first RESERVE call will initiate the
packet forwarding and routing mechanisms periodic
transmission of the node.

o Promiscuous Receive Mode for RSVP Messages

Any packet received for IP protocol 46 must RESV messages. A later RESERVE call may
be diverted given to modify the RSVP program for processing, without being forwarded.
On a router, the identity parameters of the interface, real or
virtual, on which it is received must also be available to
the RSVP daemon.

o Route Query

To forward PATH and PTEAR messages, an RSVP daemon must be
able to query the routing daemon(s) for routes.

Ucast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag )

-> OutInterface

Mcast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag )

-> [ IncInterface, ] OutInterface_list

Depending upon the routing protocol, the query earlier call (but
note that changing existing reservations may or result in
admission control failures).

The optional `receiver_address' parameter may
not depend upon SrcAddress, i.e., upon the sender be used by a
receiver on a multihomed host IP
address, which (or router); it is also the IP source
address of one of the
message. Here IncInterface node's interfaces. The CONF_flag
should be set on if a reservation confirmation is desired,
off otherwise. The `style' parameter indicates the interface through which
reservation style. The rest of the packet is expected to arrive; some multicast routing
protocols may not provide it.

If parameters depend upon
the Notify_flag is True, routing style; generally these will save include appropriate
flowspecs, filter specs, and possibly receiver policy data
objects.

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 removes RSVP state
necessary to issue unsolicited route change notification
callbacks (see below) whenever for the session specified route
changes. Such callbacks will be enabled until routing
receives by
session-id. The node then sends appropriate teardown
messages and ceases sending refreshes for this session-id.

o Error/Event Upcalls

The general form of a route query call with the Notify_Flag set
False.

A multicast route query may return an empty
OutInterface_list if there are no receivers downstream of
a particular router. A route query may also return a `No
such route' error, probably upcall is as a result of a transient
inconsistency in the routing (since a PATH or PTEAR
message for follows:

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

information_parameters

Here "Upcall_Proc" represents the requested route did arrive at this node).
In either case, upcall procedure whose
address was supplied in the local state should be updated as SESSION call. This upcall may

Braden, Zhang, et al. Expiration: May August 1996 [Page 62] 60]

Internet Draft RSVP Specification November 1995

requested by the message, although it cannot be forwarded
further. Updating local state will make path state
available immediately for February 1996

occur asynchronously at any time after a new local receiver, SESSION call and
before a RELEASE call, to indicate an error or it will
tear down path state immediately.

o Route Change Notification

If requested an event.

Currently there are five upcall types, distinguished by a route query with
the Notify_flag True, Info_type parameter. The selection of information
parameters depends upon the routing daemon may provide an asynchronous callback to type.

1. Info_type = PATH_EVENT

A Path Event upcall results from receipt of the RSVP daemon that first
PATH message for this session, indicating to a specified route has changed.

Ucast_Route_Change( ) -> DestAddress, OutInterface

Mcast_Route_Change(
receiver application that there is at least one
active sender.

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

Info_type=PATH_EVENT,

flags,

Sender_Tspec, Sender_Template,

[ SrcAddress, , Advert ] DestAddress, [ IncInterface, , Policy_data ] OutInterface_list

o Outgoing Link Specification

RSVP must be able to force

This upcall presents the Sender_Tspec and the
Sender_Template from 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 to send different versions of
an outgoing PATH message on different interfaces. It is message; it also necessary in some cases to avoid routing loops.

o Source Address Specification

RSVP must be able to specify passes
the IP source address to be
used when sending PATH messages.

o Interface List Discovery

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

3.9.4 Service-Dependent Manipulations

Flowspecs, Tspecs, advertisement and Adspecs are opaque objects to RSVP;
their contents policy data if they are defined in service specification documents.
In order to manipulate these objects, RSVP daemon must have
available
present. The possible flags correspond to it Non_RSVP
and Maybe_RSVP flags of the following service-dependent routines.

o Compare Flowspecs SESSION object.

2. Info_type = RESV_EVENT

A Resv Event upcall is triggered by the receipt of
the first RESV message, or by modification of a
previous reservation state, for this session.

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

Info_type=RESV_EVENT,

Style, Flowspec, Filter_Spec_list,

[ , Policy_data ]

Here `Flowspec' will be the effective QoS that has
been received. Note that an FF-style RESV message

Braden, Zhang, et al. Expiration: May August 1996 [Page 63] 61]

Internet Draft RSVP Specification November 1995

Compare_Flowspecs( Flowspec_1, Flowspec_2 February 1996

may result in multiple RESV_EVENT upcalls, one for
each flow descriptor.

3. Info_type = PATH_ERROR

An Path Error event indicates an error in sender
information that was specified in a SENDER call.

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

Info_type=PATH_ERROR,

Error_code , Error_value ,

Error_Node , Sender_Template,

[ Policy_data ]

The possible result_codes indicate: flowspecs are equal,
Flowspec_1 is greater, Flowspec_2 is greater, flowspecs
are incomparable but LUB can be computed, or flowspecs are
incompatible.

Note that comparing two flowspecs implicitly compares Error_code parameter will define the
Tspecs error, and
Error_value may supply some additional (perhaps
system-specific) data about the error. The
Error_Node parameter will specify the IP address of
the node that are contained. Although detected the RSVP daemon
cannot itself parse a flowspec to extract error. The Policy_data
parameter, if present, will contain the Tspec, it
can use POLICY_DATA
object from the Compare_Flowspecs call failed PATH message.

4. Info_type = RESV_ERR

An Resv Error event indicates an error in a
reservation message to implicitly calculate
Resv_Te (see Section 2.3).

o Compute LUB of Flowspecs

LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
Flowspec_LUB

o Compare Tspecs

Compare_Tspecs( Tspec_1, Tspec_2 which this application
contributed.

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

Info_type=RESV_ERROR,

Error_code , Error_value ,

Error_Node , Error_flags ,

Flowspec, Filter_spec_list,

[ Policy_data ]

The possible result_codes indicate: Tspecs are equal, or
Tspecs are unequal.

o Sum Tspecs

Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum

This call is used to compute Path_Te (see Section 2.3). Error_code parameter will define the error and
Error_value may supply some additional (perhaps

Braden, Zhang, et al. Expiration: May August 1996 [Page 64] 62]

Internet Draft RSVP Specification November 1995

4. Message Processing Rules

This section provides a generic description February 1996

system-specific) data. The Error_Node parameter will
specify the IP address of the rules node that detected the
event being reported.

There are two Error_flags:

- InPlace

This flag may be on for RSVP
operation. It is intended an Admission Control
failure, to outline indicate that there was, and is, a
reservation in place at the failure node. This
flag is set of algorithms that will
accomplish at the needed function. An actual implementation may use
different but equivalent algorithms. This section assumes the
generic interface calls defined in Section 3.9 and the following data
structures. An actual implementation may use additional or different
data structures failure point and interfaces.

[NOTE: forwarded
in RERR messages.

- NotGuilty

This section is always the last to flag may be updated when changes are
made, and it is neither correct nor complete at on for an Admission Control
failure, to indicate that the present time.
Therefore, when flowspec requested
by this section disagrees with the rest of receiver was strictly less than the text, you
should believe
flowspec that got the rest of error. This flag is set
at the text!]

o PSB -- Path State Block

Each PSB holds path state for a particular (session, sender)
pair, defined by SESSION receiver API.

Filter_spec_list and SENDER_TEMPLATE objects,
respectively, received in a PATH message.

PSB contents include Flowspec will contain the following values from a PATH message:

- The previous hop IP address
corresponding objects from a PHOP object (required)

- LIH, the Logical Interface Handle from error flow descriptor
(see Section 3.1.6). List_count will specify the previous hop,
from a PHOP object (required).

-
number of FILTER_SPECS in Filter_spec_list. The remaining IP TTL (required)

- SENDER_TSPEC (required)

-
Policy_data _list parameter will contain any
POLICY_DATA and/or ADSPEC objects (optional)

- Non_RSVP flag (required); see Section 3.6.

In addition, the PSB contains the following information provided
by routing: OutInterface_list, the list of outgoing interfaces
for this (sender, destination), and IncInterface, in the expected
incoming interface. For RERR message.

5. Info_type = RESV_CONFIRM

A Confirmation event indicates that a unicast destination,
OutInterface_list contains one entry and IncInterface is
undefined.

o RSB -- Reservation State Block

Each RSB holds a reservation request that arrived RACK message
was received.

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

Info_type=RESV_CONFIRM,

Style, List_count,

Flowspec, Filter_spec_list,

[ Policy_data ]

The parameters are interpreted as in a
particular RESV message, corresponding to the triple: (session,
next hop, filter_spec_list). Here "filter_spec_list" may be a Resv Error
upcall.

Braden, Zhang, et al. Expiration: May August 1996 [Page 65] 63]

Internet Draft RSVP Specification November 1995

list of FILTER_SPECs (for SE style), a single FILTER_SPEC (FF
style), February 1996

Although RSVP messages indicating path or empty (WF style). We use resv events may
be received periodically, the symbol "FILTER_SPEC*" API should make the
corresponding asynchronous upcall to indicate such a FILTER_SPEC list.

RSB contents include:

- The outgoing (logical) interface OI the application only
on which the
reservation is to be made first occurrence or has been made (required).

- FLOWSPEC*, list of FLOWSPEC objects (required)

- The style (required)

- A POLICY_DATA object (optional)

- A SCOPE object (optional, depending on style)

- A RESV_CONFIRM object (optional)

o TCSB -- Traffic Control State Block

TCSB's hold when the reservation specifications that have been handed information to traffic control for specific outgoing interfaces. be
reported changes. All error and confirmation events
should be reported to the application.

3.10.2 RSVP/Traffic Control Interface

In
general, information in TCSB's an RSVP-capable node, enhanced QoS is derived from RSB's for the
same outgoing interface. Each TCSB defines achieved by a single reservation
for group of
inter-related traffic control functions: a particular triple: (session, OI, filter_spec_list). TCSB
contents include:

- packet classifier,
an admission control module, and a packet scheduler. This
section describes a generic RSVP interface to traffic control.

o Make a Reservation

Call: Rhandle = TC_AddFlowspec( Interface, TC_Flowspec,

TC_Tspec, Police_Flags )

The TC_Flowspec parameter defines the desired effective flowspec, i.e., the maximum over
the corresponding FLOWSPEC values from matching RSB's.
TC_Flowspec is passed to traffic control
QoS to make admission control; its value is computed as the actual
reservation. The Tspec part
maximum over the flowspecs of TC_Flowspec is different next hops (see the
Compare_Flowspecs call below). It contains the effective
reservation Tspec Resv_Te (Section 2.3).

- TC_Tspec, equal (although the RSVP daemon itself
has no means to extract the Tspec). The TC_Tspec
parameter defines the effective sender Tspec Path_Te.

- Police Flags Path_Te (see
Section 2.3). We assume that traffic control takes the
GLB of Resv_Te and Path_Te (see step (4) in Section 2.3).
The Police_Flags parameter carries the three flags
E_Police_Flag, M_Police_Flag,and B_Police_Flag
are defined in M_Police_Flag, and B_Police_Flag; see
Section 3.6.

- Rhandle, F_Handle_list

Handles returned by 3.7.

The TC_AddFlowspec call returns an error code if Flowspec
is malformed or if the traffic control interface, requested resources are
unavailable. Otherwise, it establishes a new reservation
channel corresponding to Rhandle. It returns the reservation (flowspec) and opaque
number Rhandle for subsequent references to the list
of filter specs.

Boolean flags Path_Refresh_Needed, Resv_Refresh_Needed, and this
reservation.

o Modify Reservation

Call: TC_ModFlowspec( Interface, Rhandle, new_Flowspec,

Sender_Tspec, Police_flags )

Braden, Zhang, et al. Expiration: May August 1996 [Page 66] 64]

Internet Draft RSVP Specification November 1995

Tear_Needed will also be February 1996

This call is used in this section.

[LZ: It might be very helpful to have a short section to summarize
the management of all the timers.]

MESSAGE ARRIVES

Verify version number and checksum fields of common header, and
discard message if any mismatch modify an existing reservation.
New_Flowspec is found.

Reassemble a fragmented message.

Parse the sequence of objects in the message passed to verify the length
field of the common header; discard message Admission Control; if there it is a mismatch.

If
rejected, the message type current flowspec is not PATH or PTEAR and left in force. The
corresponding filter specs, if the IP destination
address does any, are not match any of the addresses of the local interfaces,
then forward the message to IP destination address and return.

Verify the INTEGRITY object, if any. If the check fails, discard the
message and return.

Further processing depends upon message type.

PATH MESSAGE ARRIVES

Process the sender descriptor object sequence in the message as
follows. affected. The flags Path_Refresh_Needed and Resv_Refresh_Needed
flags
other parameters are initially off. defined as in TC_AddFlowspec.

o If there is a POLICY_DATA object, verify it; if it is
unacceptable, build and send a "Administrative Rejection"
PERR message, drop Delete Flowspec

Call: TC_DelFlowspec( Interface, Rhandle )

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

o If the DstPort in the SESSION object Add Filter Spec

Call: FHandle = TC_AddFilter( Interface, Rhandle,

Session , FilterSpec )

This call is zero but used to associate an additional filter spec
with the
SrcPort in reservation specified by the SENDER_TEMPLATE object is non-zero, build given Rhandle,
following a
send successful TC_AddFlowspec call. This call
returns a "Conflicting Src Port" PERR message, drop the PATH
message, and return. filter handle FHandle.

o Search for Delete Filter Spec

Call: TC_DelFilter( Interface, FHandle )

This call is used to remove a path state block (PSB) whose (SESSION,
SENDER_TEMPLATE) pair matches the corresponding objects in
the message, considering any wildcard ports. specific filter, specified
by FHandle.

o If, during the PSB search, a PSB OPWA Update

Call: TC_Advertise( Interface, Adspec )

-> New_Adspec

This call is found whose session
matches the DestAddress and Protocol Id fields of the
received SESSION object, but used for OPWA to compute the DstPorts differ and one is
zero, then build and send outgoing
advertisement New_Adspec for a "Conflicting Dst Port" PERR
message, drop the PATH message, and return. specified interface.

o Preemption Upcall

Upcall: TC_Preempt() -> RHandle, Reason_code

Braden, Zhang, et al. Expiration: May August 1996 [Page 67] 65]

Internet Draft RSVP Specification November 1995

o If, during the PSB search, a PSB is found with a matching
sender host (in SENDER_TEMPLATE) but the SrcPorts differ
and one is zero, then build and send a "Ambiguous Path"
PERR message, drop the PATH message, and return.

o If there was no matching PSB, then:

1. Create February 1996

In order to grant a new PSB.

2. Call reservation request, the appropriate Route_Query routine, using
DestAddress from SESSION and (for multicast routing)
SrcAddress from SENDER_TEMPLATE. Store admission
control and/or policy modules may preempt an existing
reservation. This might be reflected in an upcall to
RSVP, passing the values RHandle of
OutInterface_list the preempted reservation and IncInterface into
a sub-code indicating the PSB.
However, if reason.

3.10.3 RSVP/Routing Interface

An RSVP implementation needs the sender is following support from the local API, then
instead
packet forwarding and routing mechanisms of invoking routing, set OutInterface_List the node.

o Promiscuous Receive Mode for RSVP Messages

Packets received for IP protocol 46 but not addressed to
the single interface whose address matches node must be diverted to the sender
address; IncInterface is undefined in this case.

3. If IncInterface is defined and if RSVP program for
processing, without being forwarded. On a multicast message
arrived on an interface different from IncInterface,
drop router, the message and return.

4. Set a cleanup timer for
identity of the PSB. If this interface, real or virtual, on which it is
received must also be available to the first
PSB for the session, set a refresh timer for RSVP daemon.

The RSVP messages to be diverted will carry the
session.

5. Copy contents Router
Alert IP option, which can be used to pick them out of a
high-speed forwarding path. Alternatively, the SESSION, SENDER_TEMPLATE,
SENDER_TSPEC, and PHOP (IP address node can
intercept all protocol 46 packets.

o Route Query

To forward PATH and LIH) objects
into PTEAR messages, an RSVP daemon must be
able to query the PSB. Store routing daemon(s) for routes.

Ucast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag )

-> OutInterface

Mcast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag )

-> [ IncInterface, ] OutInterface_list

Depending upon the received TTL into routing protocol, the PSB.
Copy into query may or may
not depend upon SrcAddress, i.e., upon the PSB either of sender host IP
address, which is also the following objects that
are present: POLICY_DATA and ADSPEC.

6. Turn on IP source address of the Path_Refresh_Needed flag.

o Otherwise (there
message. Here IncInterface is a matching PSB and there the interface through which
the packet is no dest
port conflict):

1. expected to arrive; some multicast routing
protocols may not provide it. If there the Notify_flag is no True,
routing will save state necessary to issue unsolicited
route change notification in place,
call callbacks (see below) whenever
the appropriate Route_Query routine using
DestAddress from SESSION and (for specified route changes.

Braden, Zhang, et al. Expiration: August 1996 [Page 66]

Internet Draft RSVP Specification February 1996

A multicast routing)
SrcAddress from SENDER_TEMPLATE.

- If the route query may return an empty
OutInterface_list that is returned differs
from that if there are no receivers downstream of
a particular router. A route query may also return a `No
such route' error, probably as a result of a transient
inconsistency in the PSB, execute the PATH LOCAL
REPAIR event sequence below.

- If routing (since a multicast message arrived on an interface
different from IncInterface, drop the message and

Braden, Zhang, et al. Expiration: May 1996 [Page 68]

Internet Draft RSVP Specification November 1995

return.

2. If the PHOP IP address, the LIH, PATH or SENDER_TSPEC
differs between the PTEAR
message and the PSB, copy the new
value into the PSB, execute the RESV REFRESH event
sequence for the sender defined by the PSB, and turn
on requested route did arrive at this node).
In either case, the Path_Refresh_Needed flag.

[LZ: [When] local state should ADSPEC change trigger a refresh?]

However, if be updated as
requested by the PATH message being processed came from
a message, which cannot be forwarded
further. Updating local application and if there is reservation state
for this session, then will make path state
available immediately for a Resv Event upcall to
that application instead of executing the RESV REFRESH
sequence.

Call: <Upcall_Proc>( session-id, Resv Event, 1,
{Flowspec}, NULL, NULL, NULL )

3. Restart the cleanup timer. new local receiver, or it will
tear down path state immediately.

o Route Change Notification

If the message arrived with requested by a TTL different from Send_TTL
in the RSVP common header, set route query with the Non_RSVP flag on in Notify_flag True,
the
PSB.

o If routing daemon may provide an asynchronous callback to
the Path_Refresh_Needed flag is now set then:

1. If this PATH message came from a network interface and
not from a local application, make RSVP daemon that a Path Event upcall
for each local application for this session:

Call: <Upcall_Proc>( session-id, Path Event, 1,
{SENDER_TSPEC}, {SENDER_TEMPLATE},
{ADSPEC}, {POLICY_DATA} specified route has changed.

Ucast_Route_Change( )

2. Execute the PATH REFRESH event sequence (below) for
the sender defined by the PSB.

PATH TEAR MESSAGE ARRIVES -> [ SrcAddress, ] DestAddress,

OutInterface

Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,

[ IncInterface, ] OutInterface_list

o Search for Outgoing Link Specification

RSVP must be able to force a PSB whose (SESSION, SENDER_TEMPLATE) pair
matches the corresponding objects in (multicast) datagram to be
sent on a specific outgoing virtual link, bypassing the message. If no
matching PSB
normal routing mechanism. A virtual link may be a real
outgoing link or a multicast tunnel. Outgoing link
specification is found, drop the PTEAR necessary to send different versions of
an outgoing PATH message and return. on different interfaces. It is
also necessary in some cases to avoid routing loops.

o Forward a copy of Source Address Specification

RSVP must be able to specify the PTEAR message IP source address to each outgoing be
used when sending PATH messages.

o Interface List Discovery

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

It should be possible to logically disable an interface

Braden, Zhang, et al. Expiration: May August 1996 [Page 69] 67]

Internet Draft RSVP Specification November 1995 February 1996

for RSVP. When an interface listed in OutInterface_list of the PSB.

o Find each RSB is disabled for RSVP, a PATH
message should never be forwarded out that matches this PSB, i.e., whose
FILTER_SPEC object matches the SENDER_TEMPLATE in the PSB interface, and whose OI
if an RSVP message is included in OutInterface_list.

If this RSB matches no other PSB, then tear down the RSB,
as described below under RESV TEAR MESSAGE ARRIVES.

o Delete the PSB.

o Drop received on that interface, the PTEAR
message should be silently discarded (perhaps with local
logging).

3.10.4 Service-Dependent Manipulations

Flowspecs, Tspecs, and return.

PATH ERROR MESSAGE ARRIVES

o Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair
matches the corresponding Adspecs are opaque objects to RSVP;
their contents are defined in service specification documents.
In order to manipulate these objects, RSVP daemon must have
available to it the message. If no
matching PSB is found, drop the PERR message and return. following service-dependent routines.

o If the previous hop address in the PSB Compare Flowspecs

Compare_Flowspecs( Flowspec_1, Flowspec_2 ) -> result_code

The possible result_codes indicate: flowspecs are equal,
Flowspec_1 is the local API,
make an error upcall to the application:

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

Any POLICY_DATA, SENDER_TSPEC, or ADSPEC object in the
message greater, Flowspec_2 is ignored. [LZ: Why we don't send these objects
up to application? They might of some help to understand greater, flowspecs
are incomparable but LUB can be computed, or flowspecs are
incompatible.

Note that comparing two flowspecs implicitly compares the errors.] Drop
Tspecs that are contained. Although the PERR message and return.

o Otherwise, send RSVP daemon
cannot itself parse a copy of the PERR message flowspec to extract the PHOP IP
address, drop the PERR message, and return.

RESV MESSAGE ARRIVES

Initially, the Resv_Refresh_PHOP* list is empty and Tspec, it
can use the
Resv_Refresh_Needed flag is off. These variables are used Compare_Flowspecs call to
control immediate reservation refreshes.

o Process the NHOP object implicitly calculate
Resv_Te (see Section 2.3).

o Compute LUB of Flowspecs

LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
Flowspec_LUB

o Compute GLB of Flowspecs

GLB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
Flowspec_GLB

o Compare Tspecs

Compare_Tspecs( Tspec_1, Tspec_2 ) -> result_code

Braden, Zhang, et al. Expiration: August 1996 [Page 68]

Internet Draft RSVP Specification February 1996

The logical outgoing interface OI is taken from the LIH in
the NHOP object. (If the physical interface possible result_codes indicate: Tspecs are equal, or
Tspecs are unequal.

o Sum Tspecs

Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum

This call is not implied used to compute Path_Te (see Section 2.3).

Braden, Zhang, et al. Expiration: May August 1996 [Page 70] 69]

Internet Draft RSVP Specification November 1995

by February 1996

4. Message Processing Rules

This section provides a generic description of the LIH, it can be learned from rules for RSVP
operation. It is intended to outline a set of algorithms that will
accomplish the interface matching needed function, omitting some details.

This section assumes the IP destination address).

o Check generic interface calls defined in Section
3.10 and the SESSION object.

If there following data structures. An actual implementation may
use additional or different data structures and interfaces. The data
structure fields that a shown are no existing PSB's required unless they are explicitly
labelled as optional.

o PSB -- Path State Block

Each PSB holds path state for a particular (session, sender)
pair, defined by SESSION then build and
send SENDER_TEMPLATE objects,
respectively, received in a RERR message (as described later) specifying "No
path information", drop PATH message.

PSB contents include the RESV message, following values from a PATH message:

- Session

- Sender_Template

- Sender_Tspec

- The previous hop IP address and return.
However, do not send the RERR message if the style has
wildcard reservation scope and this is the receiver host
itself.

[LZ: Explain this?]

o Check the S_POLICY_DATA object.

If there is an S_POLICY_DATA object in the message, check
permission to create Logical Interface
Handle (LIH) from a reservation for the session. If the
check fails, build and send an "Administrative rejection"
RERR message, drop the RESV message, and return.
Otherwise, copy the S_POLICY_DATA object into the RSB.

Now process the STYLE PHOP object

- The remaining IP TTL

- POLICY_DATA and/or ADSPEC objects (optional)

- Non_RSVP and Maybe_RSVP flags; see Section 3.7.

- E_Police flag (Section 3.7)

- Local_Only flag (Section 3.8)

In addition, the flow descriptor list to
make reservations, as follows.

For FF style, execute the following steps independently for each
b flow descriptor, i.e., for each (FLOWSPEC, FILTER_SPEC) pair.
For FF style, FILTER_SPEC* consists of the single FILTER_SPEC
from the flow descriptor.

For SE style, execute PSB contains the following steps once, with
FILTER_SPEC* consisting of information provided
by routing: OutInterface_list, which is the list of FILTER_SPEC objects from outgoing
interfaces for this (sender, destination), and IncInterface,
which is the flow descriptor. expected incoming interface. For WF style, execute the following steps once, with
FILTER_SPEC* consisting of a single internal placeholder
"WILD_FILTER".

o If the DstPort in the SESSION object is zero but the
SrcPort in the FILTER_SPEC object unicast
destination, OutInterface_list contains one entry and
IncInterface is non-zero, build undefined.

o RSB -- Reservation State Block

Braden, Zhang, et al. Expiration: August 1996 [Page 70]

Internet Draft RSVP Specification February 1996

Each RSB holds a send reservation request that arrived in a "Conflicting Src Port" RERR message, drop the
particular RESV message, and return.

o Find corresponding to the triple: (session,
next hop, Filter_spec_list). Here "Filter_spec_list" may be a
list of FILTER_SPECs (for SE style), a single FILTER_SPEC (FF
style), or create empty (WF style). We define a virtual object type
"FILTER_SPEC*" for such a data structure.

RSB contents include:

- Session specification

- Next hop IP address

- Filter_spec_list

- The outgoing (logical) interface OI on which the
reservation state block (RSB) is to be made or has been made (required).

- Style

- Flowspec

- A POLICY_DATA object (optional)

- A SCOPE object (optional, depending on style)

- A RESV_CONFIRM object (optional)

o TCSB -- Traffic Control State Block

Each TCSB holds the reservation specification that has been
handed to traffic control for a specific outgoing interface. In
general, TCSB information is derived from RSB's for the same
outgoing interface. Each TCSB defines a single reservation for
a particular triple: (SESSION, NHOP, FILTER_SPEC*). Call this (session, OI, Filter_spec_list). TCSB
contents include:

- Session

- OI

- Filter_spec_list

- TC_Flowspec, the
"active RSB".

o If effective flowspec, i.e., the RSB maximum over
the corresponding FLOWSPEC values from matching RSB's.
TC_Flowspec is not new and if its style passed to traffic control to make the actual
reservation. The Tspec part of TC_Flowspec is incompatible with the
effective reservation Tspec Resv_Te (Section 2.3).

Braden, Zhang, et al. Expiration: May August 1996 [Page 71]

Internet Draft RSVP Specification November 1995 February 1996

- TC_Tspec, equal to Path_Te, the STYLE object effective sender Tspec.

- Police Flags

The flags E_Police_Flag, M_Police_Flag, and B_Police_Flag
are defined in Section 3.7.

- Rhandle, F_Handle_list

Handles returned by the message, build and send a RERR
message specifying "Conflicting Style", drop traffic control interface,
corresponding to the RESV
message, reservation (flowspec) and return.

o Start or restart to the cleanup timer on list
of filter specs.

o BSB -- Blockade State Block

Each BSB contains an element of blockade state. Depending upon
the reservation style in use, the active RSB.

o BSB's may be per (session,
sender_template) or per (session, PHOP). In practice, an
implementation might embed a BSB within a PSB; however, for
clarity we describe BSB's independently.

The contents of a BSB include:

- Session

- Sender_Template (which is also a filter spec)

- PHOP

- FLOWSPEC Qb

- Blockade timer Tb

The following other variables are also used in this section: Boolean
flags Path_Refresh_Needed, Resv_Refresh_Needed, Tear_Needed,
Need_Scope, B_Merge, and NeworMod, and Refresh_PHOP_list, a
variable-length list of PHOPs to be refreshed.

MESSAGE ARRIVES

Verify version number and RSVP checksum, and discard message if any
mismatch is found.

If the active RSB message type is not new, check whether FLOWSPEC PATH or
SCOPE objects have changed. If not, continue with PTEAR and if the next
flow descriptor in IP destination
address does not match any of the RESV message, addresses of the local interfaces,
then forward the message to IP destination address and return.

Verify the INTEGRITY object, if any.

o If the active RSB is new, set its OI check fails, discard the

Braden, Zhang, et al. Expiration: August 1996 [Page 72]

Internet Draft RSVP Specification February 1996

message and style, return.

Reassemble fragments of message.

Parse the sequence of objects in the message, and copy discard message if
any FLOWSPEC, POLICY_DATA, and/or SCOPE required objects into it.

o If are missing. Verify the length field of the
common header, and discard message if there is a RESV_CONFIRM in mismatch.

Verify the message, turn on
Resv_Refresh_Needed and save consistent use of port fields. If the object DstPort in the RSB.

o The active RSB must be new or changed. Compute the traffic
control parameters, using
SESSION object is zero but the following steps.

1. Locate SrcPort in a SENDER_TEMPLATE or
FILTER_SPEC object is non-zero, the set of PSBs (senders) whose
SENDER_TEMPLATEs match FILTER_SPEC* the message has a "conflicting
source port" error; discard the message and return.

Further processing depends upon message type.

PATH MESSAGE ARRIVES

Process the sender descriptor object sequence in the active RSB message as
follows. The Path_Refresh_Needed and whose OutInterface_list includes OI. Resv_Refresh_Needed flags
are initially off.

o If this set there is empty, a POLICY_DATA object, verify it; if it is
unacceptable, build and send an error message
specifying "No sender information", a "Administrative Rejection"
PERR message, drop the PATH message, and continue with return.

o Search for a path state block (PSB) whose (session,
sender_template) pair matches the next flow descriptor corresponding objects in
the RESV message.

2. If this set contains more than one

o If, during the PSB search, a PSB is found whose session
matches the DestAddress and if Protocol Id fields of the
style has explicit sender selection (e.g., FF or SE),
received SESSION object, but the DstPorts differ and one is
zero, then build and send an error message specifying "Ambiguous
filter spec" and continue with the next flow
descriptor.

3. Add a "Conflicting Dst Port" PERR
message, drop the PHOP from PATH message, and return.

o If, during the PSB to the Resv_Refresh_PHOP*
list, if the PHOP is not already on the list.

4. Set TC_E_Police_flag on if any of these PSBs have
their E_Police flag on. Set TC_M_Police_flag on if it search, a PSB is found with a shared style matching
sender host but the SrcPorts differ and there is more than one PSB in of the set.

5. Compute Path_Te as the sum of SrcPorts
is zero, then build and send an "Ambiguous Path" PERR
message, drop the SENDER_TSPEC objects
in this set of PSBs.

6. Scan all RSB's PATH message, and return.

o If there was no matching PSB, then:

1. Create a new PSB.

2. Copy contents of the SESSION SESSION, SENDER_TEMPLATE,
SENDER_TSPEC, and
Filter_Spec_list from PHOP (IP address and LIH) objects
into the message.

- If any of these RSB's has a style that is PSB.

Braden, Zhang, et al. Expiration: May August 1996 [Page 72] 73]

Internet Draft RSVP Specification November 1995

incompatible with February 1996

3. Calculate initial routing information. If the specifying "Conflicting
Style", drop sender
is from the RESV message, delete local API, OutInterface_List is set to the RSB if
it has just been created,
single interface whose address matches the sender
address, and return.

- Set TC_B_Police_flag on if TC_Flowspec IncInterface is smaller
than, or incomparable to, any FLOWSPEC in those
RSB's.

7. Consider undefined. Otherwise,
call the set appropriate Route_Query routine, using
DestAddress from SESSION and (for multicast routing)
SrcAddress from SENDER_TEMPLATE. Store the values of RSB's for
OutInterface_list and IncInterface into the same (SESSION, OI,
Filter_Spec_list) triple PSB.

4. If IncInterface is defined and if a multicast message
arrived on an interface different from IncInterface,
turn on the message.

- Compute Local_Only flag in the effective kernel flowspec,
TC_Flowspec, as PSB.

5. If this is the maximum of first PSB for the FLOWSPEC
values in these RSB's.

- Compute session, set a
refresh timer for the effective kernel filter spec (list),
TC_Filter*. by merging session.

6. Turn on the FILTER_SPEC* object
(lists) from these RSB's. Path_Refresh_Needed flag.

o Search for Otherwise (there is a TCSB matching the triple (SESSION, OI,
FILTER_SPEC*), taken from the RSB.

1. If none PSB and there is found but style is SE, search for a TCSB
matching (SESSION, OI). no dest
port conflict):

1. If find one and if TCSB's
TC_Flowspec, Path_Te, and police flags match there is no route change notification in place,
call the
computed values, then

- Make an appropriate set of TC_DelFilter Route_Query routine using
DestAddress from SESSION and
TC_AddFilter calls to transform (for multicast routing)
SrcAddress from Sender_Template.

- If the
Filter_Spec_list OutInterface_list that is returned differs
from that in the TCSB into the
Filter_Spec_list from PSB, then execute the message. PATH LOCAL
REPAIR event sequence below.

- Set Resv_Refresh_Needed on, drop If a multicast message arrived on an interface
different from IncInterface, then execute the
RESV
message, and return. REFRESH event sequence below for the
previous hop.

2. Otherwise, if none is found:

- Create a If the PHOP IP address, the LIH, or Sender_Tspec
differs between the message and the PSB, copy the new TCSB.

- Store TC_Flowspec, Filter_Spec_list, Path_Te,
value into the PSB and turn on the police flags Path_Refresh_Needed
flag.

o If the message contains an ADSPEC object, copy it into TCSB.

[SCOPE?]

- Set Resv_Refresh_Needed on.

- Make the traffic control call:
PSB.

o Start or Restart the cleanup timer for the PSB.

o Copy E_Police flag from SESSION object into PSB.

o Store the received TTL into the PSB.

Braden, Zhang, et al. Expiration: May August 1996 [Page 73] 74]

Internet Draft RSVP Specification November 1995

Rhandle = TC_AddFlowspec( OI, TC_flowspec, Path_Te,
TC_E_Police_flag, TC_M_Police_flag,
TC_B_Police_flag ) February 1996

If this call fails, build and send a RERR message
specifying "Admission control failed", and
continue with the next flow descriptor.
Otherwise, record Rhandle in the TCSB.

- For each filter_spec F received TTL differs from Send_TTL in Filter_Spec_list, call:

Fhandle = TC_AddFilter( Rhandle, SESSION, F)

and record the returned Fhandle RSVP
common header, set the Non_RSVP flag on in the TCSB.

- Continue with PSB.

o The Path_Refresh_Needed flag is now set if the next flow descriptor. path state
is new or modified. If so:

1. If this PATH message came from a network interface and
not from a local application, make a Path Event upcall
for each local application for this session:

Call: <Upcall_Proc>( session-id, PATH_EVENT,
flags, sender_tspec, sender_template,
[ADSPEC], [POLICY_DATA] )

2. Execute the PATH REFRESH event sequence (below) for
the sender defined by the PSB.

3. Otherwise (found existing TCSB), check whether
TC_Flowspec, Path_Te, and/or any of If there is no reservation state for this SESSION
(i.e., no RSB's exist), then drop the police flags
has changed, PATH message and if so:
return.

4. Otherwise (there is reservation state):

- Store TC_Flowspec, Filter_Spec_list, Path_Te, and Execute the police flags into it.

[SCOPE?]

- Set Resv_Refresh_Needed on.

- Make event sequence UPDATE TRAFFIC CONTROL
below, to update the local traffic control call:

TC_ModFlowspec( Rhandle, K_Flowspec, Path_Te,
TC_E_Police_flag, TC_M_Police_flag,
TC_B_Police_flag )

4. Continue with the next flow descriptor.

o If state
if necessary. This will turn on the
Resv_Refresh_Needed flag is now on, if the traffic control
state changes; if so, execute the RESV REFRESH
event sequence (below) for each PHOP the sender in the
Resv_Refresh_PHOP* set.

If processing a RESV PSB.

However, if the PATH message finds an error, came from 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 local
application, then make a RESV_EVENT upcall to
that application.

o Drop the IP address of OI, and the PATH message is sent unicast to NHOP.

Braden, Zhang, et al. Expiration: May 1996 [Page 74]

Internet Draft RSVP Specification November 1995

RESV and return.

PATH TEAR MESSAGE ARRIVES

A RTEAR message arrives with an IP destination address matching
outgoing interface OI. Flags Tear_Needed and
Resv_Refresh_Needed are initially off and Resv_Refresh_PHOP*
list is empty.

o Process the STYLE object and the flow descriptor list in
the RTEAR message to tear down local reservation state, as
follows.

For FF style, execute the following steps for each b flow
descriptor, i.e., Search for each (FLOWSPEC, FILTER_SPEC) pair
independently, with Filter_Spec_list consisting of a single
FILTER_SPEC object.

For SE style, execute the following steps once, with
Filter_Spec_list consisting of a list of FILTER_SPEC
objects.

For WF style, execute the following steps once, with
Filter_Spec_list consisting of a single internal
placeholder "WILD_FILTER".

1. Find matching RSB for PSB whose (Session, Sender_Template) pair
matches the 4-tuple: (SESSION, NHOP,
style, Filter_Spec_list); call this corresponding objects in the active RSB. message. If no active RSB
matching PSB is found, continue with next flow
descriptor.

2. Delete the active RSB.

3. Find TCSB for the triple: (SESSION, OI,
Filter_Spec_list).

4. Consider drop the set PTEAR message and return.

o Forward a copy of RSB's matching this TCSB. If
there are none:

- Call the traffic control PTEAR message to each outgoing
interface routine:

TC_DelFlowspec( Rhandle )

- Delete the TCSB and set Tear_Needed flag on.

- Continue with the next flow descriptor.

5. Otherwise (there are other RSB's for listed in OutInterface_list of the same TCSB), PSB.

o Find each RSB that matches this PSB, i.e., that whose

Braden, Zhang, et al. Expiration: May August 1996 [Page 75]

Internet Draft RSVP Specification November 1995

recompute TC_Flowspec February 1996

Filter_spec_list matches Sender_Template in the PSB and Path_Te (see
whose OI is included in OutInterface_list.

If this RSB matches no other PSB, then tear down the RSB,
as described below under RESV TEAR MESSAGE
ARRIVES). (This also adds ARRIVES.

o Delete the appropriate PHOP
addresses to PSB.

o Drop the Resv_Refresh_PHOP* list>) If either
changed, update the TCSB, set flag Resv_Refresh_Needed
on, PTEAR message and call the traffic control interface module:

TC_ModFlowspec( Rhandle, TC_Flowspec, Path_Te)
TC_E_Police_flag, TC_M_Police_flag,
TC_B_Police_flag )

This kernel call should not fail, since the
reservation can only be reduced.

[LZ: Suppose receiver R has return.

PATH ERROR MESSAGE ARRIVES

o Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair
matches the credential to make corresponding objects in the
reservation and others took a ride on top of R's
credential. Now R tears down its request, what should
happen? Shouldn't TEAR take policy data as input?]

o message. If Tear_Needed and Resv_Refresh_Needed flags are both off,
then no
matching PSB is found, drop the RTEAR PERR message and return.

o If Tear_Needed is off but Resv_Refresh_Needed is on, then
execute the RESV REFRESH sequence for each PHOP previous hop address in the
Resv_Refresh_PHOP* set, drop the RTEAR message, and return.

o Otherwise (Tear_Needed PSB is on), need to forward RTEAR and/or
RESV refresh messages.

Do the following for each PSB whose OutInterface_list
includes local API,
make an error upcall to the outgoing interface OI:

1. Pick each flow descriptor Fj application:

Call: <Upcall_Proc>( session-id, PATH_ERROR,
Error_code, Error_value,
Node_Addr, Sender_Template,
[Policy_Data] )

Any SENDER_TSPEC or ADSPEC object in the RTEAR message
whose FILTER_SPEC matches the PSB, and do the
following.

- If there is no RSB whose FILTER_SPEC matches
ignored.

Otherwise, send a copy of the
PSB, then add Fj PERR message to the new RTEAR message being
built.

- Otherwise (there is a matching RSB), note PHOP IP
address.

o Drop the PSB
as needing a RESV refresh PERR message and set return.

RESV MESSAGE ARRIVES

Initially, Refresh_PHOP_list is empty and the
Resv_Refresh_Needed flag True.

2. If the new RTEAR message contains any flow
descriptors, send it and NeworMod flags are off. These variables
are used to PHOP in the PSB. control immediate reservation refreshes.

o Determine the Outgoing Interface OI

The logical outgoing interface OI is taken from the LIH in
the NHOP object. (If the physical interface is not implied
by the LIH, it can be learned from the interface matching
the IP destination address).

Braden, Zhang, et al. Expiration: May August 1996 [Page 76]

Internet Draft RSVP Specification November 1995 February 1996

o If the Resv_Refresh_Needed flag is now on, execute the RESV
REFRESH sequence (below) for each PHOP in Check the
Resv_Refresh_PHOP* set. SESSION object.

If the Refresh_Needed flag is true, then execute the RESV
REFRESH sequence for the there are no existing PSB's that have been noted.

o Drop the RTEAR message for SESSION then build and return.

RESV ERROR MESSAGE ARRIVES

A
send a RERR message arrives through the (real) incoming interface
In_If.

o If there is no (as described later) specifying "No
path state for SESSION, information", drop the RERR
message RESV message, and return.

o Do Check the following with each RSB for this SESSION whose OI
does not match In_If and whose FILTER_SPEC matches that S_POLICY_DATA object.

If there is an S_POLICY_DATA object in the RERR message.

1. Copy message, check
permission to create a reservation for the error flow descriptor from session. If the incoming
check fails, build and send an "Administrative rejection"
RERR
message.

2. Compare the FLOWSPEC in message, drop the RERR message with RESV message, and return.
Otherwise, copy the
FLOWSPEC in S_POLICY_DATA object into the RSB.

o Check for incompatible styles.

If they don't match along any
coordinate (i.e., if the existing RSB FLOWSPEC for the session has a style that is strictly
`smaller'), continue
incompatible with the next RSB.

If they agree on some but not all coordinates, turn on
the LUB-used flag.

3. If NHOP in RSB is style of the local API, deliver an error
upcall to application:

Call: <Upcall_Proc>( session-id, Resv Error,
Error_code, Error_value, Node_Addr,
LUB-Used,
Flowspec, Filter_Spec_List,
NULL, NULL) message, build and continue with send
a RERR message specifying "Conflicting Style", drop the next RSB. Here k,
Filter_Spec_List,
RESV message, and Flowspec_List are constructed return.

Process the flow descriptor list to make reservations, as
follows, depending upon the style. The following uses a filter
spec list struct Filtss, of type FILTER_SPEC* (defined earlier).

For FF style: execute the following steps independently for each
flow descriptor in the message, i.e., for each (FLOWSPEC,
Filtss) pair. Here the structure Filtss consists of the
FILTER_SPEC from the flow descriptor.

For SE style, execute the following steps once for (FLOWSPEC,
Filtss), with Filtss consisting of the list of FILTER_SPEC
objects from the error flow descriptor.

For WF style, execute the following steps once for (FLOWSPEC,
Filtss), with Filtss an empty list.

o If the DstPort in the SESSION object is zero but the
SrcPort in a FILTER_SPEC object (in Filtss) is non-zero,
build nd send a "Conflicting Src Port" RERR message, drop
the RESV message, and return.

o Check the path state, as follows.

1. Locate the set of PSBs (senders) whose
SENDER_TEMPLATEs match Filtss and whose
OutInterface_list includes OI.

Braden, Zhang, et al. Expiration: May August 1996 [Page 77]

Internet Draft RSVP Specification November 1995

4. February 1996

If the RESV this set is empty, build and send an error message has wildcard sender selection, use
its SCOPE object SC.In to construct a SCOPE object
SC.Out to be forwarded. SC.Out should contain those
specifying "No sender addresses that appeared in SC.In information", and that route
to OI [LIH?], as determined by scanning the PSB's. If
SC.Out is empty, continue with
the next RSB.

5. Create a new RERR message containing the error flow descriptor and send to in the NHOP address specified by
the RSB. Include SC.Out if RESV message.

2. If the style has explicit sender selection is
wildcard.

6. Continue with the next RSB.

o Drop the (e.g., FF
or SE) and if any FILTER_SPEC included in Filtss
matches more than one PSB, build and send a RERR
message specifying "Ambiguous filter spec" and return.

RESV CONFIRMATION ARRIVES

If
continue with the (unicast) IP address found next flow descriptor in its RESV_CONFIRM object
matches an interface of the node, a confirmation upcall is made
to RESV
message.

3. Add the matching application:

Call: <Upcall_Proc>( session-id, Resv Confirm,
Error_code, Error_value, Node_Addr,
LUB-Used, nlist, Flowspec,
Filter_Spec_List, NULL, NULL )

Otherwise, PHOP from the RACK message is forwarded immediately PSB to Refresh_PHOP_list, if the
address in
PHOP is not already on the IP address in its RESV_CONFIRM object.

PATH REFRESH

This sequence sends list.

o Find or create a path refresh reservation state block (RSB) for a particular sender,
i.e., a PSB. This sequence may be entered by either the
expiration of the path refresh timer or directly as
triple: (session, NHOP, Filtss). Call this the result
of "active
RSB".

o If the Path_Refresh_Needed flag being turned on during active RSB is new:

1. Set the
processing session, NHOP, OI and style of a received PATH message.

o Compute the IP TTL for RSB from
the PATH message as one less than message.

2. Copy Filtss into the maximum Filter_spec_list of the TTL values RSB.

3. Copy the FLOWSPEC and any SCOPE object from the senders included in
message into the message. However, if RSB.

4. Set NeworMod flag on.

o Start or restart the result is zero, return
without sending cleanup timer on the PATH message.

o Insert TIME_VALUES and PHOP objects into the PATH message
being built.

Braden, Zhang, et al. Expiration: May 1996 [Page 78]

Internet Draft RSVP Specification November 1995 active RSB.

o Create If there is a sender descriptor containing the SENDER_TEMPLATE,
SENDER_TSPEC, and POLICY_DATA objects, if present RESV_CONFIRM in the
PSB, and pack it into the PATH message being built.

o Pass any ADSPEC message, turn on
Resv_Refresh_Needed and SENDER_TSPEC objects present in the PSB
to the traffic control call TC_Advertise. Insert save the
modified ADSPEC object that is returned into in the PATH
message being built. RSB.

o If the PSB has the E_Police flag on and if interface OI active RSB is not capable of policing, new, check whether STYLE, FLOWSPEC
or SCOPE objects have changed; if so, copy changed object
into RSB and turn the E_Police flag on in the
PATH message being built. NeworMod flag.

o Send a copy of If NeworMod flag is off, continue with the PATH message to each interface next flow
descriptor in
OutInterfact_list. Before sending each copy, insert into
its PHOP object the interface address and the LIH for the
interface. RESV REFRESH

This sequence sends a reservation refresh towards a particular
previous hop with IP address PH. This sequence may be entered
by either message, if any.

o Otherwise (the NeworMod flag is on, i.e., the expiration of a reservation refresh timer active RSB is
new or
directly as the result of modified), execute the Resv_Refresh_Needed flag being
turned on as UPDATE TRAFFIC CONTROL event
sequence (below). If the result of processing a RESV or RTEAR message.

In general, this sequence considers each of is to modify the PSB's with PHOP
address PH. For a given PSB, traffic
control state, it scans the RSBs for matching
reservations and merges will turn on the styles, FLOWSPECs and FILTER_SPEC*'s
appropriately. It then builds a RESV message and sends it to
PH. The details depend upon the attributes of the style(s)
included in the reservations.

o If there are PSB's from more than one PHOP and if the
multicast routing protocol does not use shared trees, set
the Need_Scope flag on, otherwise set it off.

o Create an output message containing SESSION, RSVP_HOP,
INTEGRITY, and TIME_VALUES objects.

o Select each sender PSB whose PHOP has address PH.

1. Select all RSB's whose FILTER_SPEC*'s match the
SENDER_TEMPLATE object in the PSB and whose OI appears
in the OutInterface_list of the PSB.

2. Get a STYLE object from the first RSB and move it into Resv_Refresh_Needed
flag.

Braden, Zhang, et al. Expiration: May August 1996 [Page 79] 78]

Internet Draft RSVP Specification November 1995

the output message. (Note that February 1996

o For any local sender, make an RESV_EVENT upcall to the present set of
styles are never themselves merged; if future styles
can be merged, these rules will become more complex).

3. Compute
application:

Call: <Upcall_Proc>( session-id, RESV_EVENT,
style, Flowspec, Filter_spec_list,
[POLICY_DATA] )

where the maximum/LUB over parameters come from the FLOWSPEC objects of
this set of RSB's.

4. While computing active RSB.

o Continue with the maximum/LUB, next flow descriptor.

o When all flow descriptors have been processed, check the
Resv_Refresh_Needed flag. If it is now on, execute the
RESV REFRESH sequence (below) for a
RESV_CONFIRM object in each RSB. PHOP in
Refresh_PHOP_list.

o Drop the RESV message and return.

If processing a RESV_CONFIRM
object RESV message finds an error, a RERR message is found
created containing flow descriptor and if an ERRORS object. The
Error Node field of the FLOWSPEC in that RSB ERRORS object is
larger than all other flowspecs being compared, then
save this RESV_CONFIRM object. If a RESV_CONFIRM
object is found but the corresponding FLOWSPEC is
equal or smaller than the largest, or if set to the result IP address
of
merging was a LUB, then create OI, and send a RACK the message is sent unicast to the NHOP.

RESV TEAR MESSAGE ARRIVES

A RTEAR message arrives with an IP destination address in the RESV_CONFIRM object.

- Include the RESV_CONFIRM object in matching
outgoing interface OI. Flags Tear_Needed and
Resv_Refresh_Needed are initially off and Refresh_PHOP_list is
empty.

o Process the RACK
message.

- Build a confirmation ERROR_SPEC STYLE object and
include it in the RACK message. The Error_Node
parameter flow descriptor list in this object should be
the IP address RTEAR message to tear down local reservation state, as
follows.

The following uses a filter spec list struct Filtss, of OI from
type FILTER_SPEC* (defined earlier).

For FF style: execute the RSB.

Then delete following steps independently for
each flow descriptor in the RESV_CONFIRM object from message, i.e., for each
(FLOWSPEC, Filtss) pair. Here the RSB.

5. Merge structure Filtss
consists of the matching FILTER_SPEC objects from this set
of RSB's. The merging rule depend upon the style:

Explicit sender selection (FF, SE) styles:

Use the SENDER_TEMPLATE as the merged
FILTER_SPEC.

Wildcard sender selection (WF) style:

There is no filter spec to merge.

6. If the Need_Scope flag is on, compute a new SCOPE
object as flow descriptor.

For SE style, execute the union following steps once for
(FLOWSPEC, Filtss), with Filtss consisting of the SCOPE objects found in the
RSB's.

7. Merge the F_POLICY_DATA list of
FILTER_SPEC objects from the RSB's.

8. (All matching RSB's have been processed). The next flow descriptor.

For WF style, execute the following steps once for

Braden, Zhang, et al. Expiration: May August 1996 [Page 80] 79]

Internet Draft RSVP Specification November 1995

step depends upon the style attributes.

Distinct reservation (FF) style

Pack the merged February 1996

(FLOWSPEC, FILTER_SPEC,
F_POLICY_DATA) triplet into the message as a flow
descriptor.

Shared reservation (SE, WF) styles

Merge (take the maximum) across all PSB's Filtss), with Filtss an empty list.

1. Find matching RSB for the
merged FLOWSPECS from triple: (SESSION, NHOP,
Filtss); call this the RSB's. active RSB. If the sender selection is not wildcard (i.e., if
it no active RSB
is SE), form the union of found, continue with next flow descriptor.

2. Delete the FILTER_SPECs
obtained from active RSB.

3. Execute the RSB's. For Wildcard sender
selection (WF) style, there is not filter spec event sequence UPDATE TRAFFIC CONTROL
(below) to
merge.

9. If the Need_Scope flag is on, remove from update the merged
SCOPE object all sender addresses that do not match traffic control state to be
consistent with the set of PSB's reservation state.

4. Search for a TCSB remaining for PH, and all senders addresses
that are local. If the resulting (session, OI,
Filtss) triple; if not, set is empty, no
RESV should be forwarded to this PHOP; return;
otherwise (set is not empty), move the new SCOPE
object into Tear_Needed flag on.

5. Continue with the message. next flow descriptor.

o (All PSB's have been processed). If a shared reservation
style is being built, move the final merged FLOWSPEC,
F_POLICY_DATA, Tear_Needed and FILTER_SPEC (if SE) objects into Resv_Refresh_Needed flags are both off,
then drop the
message. RTEAR message and return.

o If a RESV_CONFIRM object was saved earlier, copy it into Tear_Needed is off but Resv_Refresh_Needed is on, then
execute the new RESV message and delete it from the RSB REFRESH sequence for each PHOP in which it
was found.
Refresh_PHOP_list, drop the RTEAR message, and return.

o Set Otherwise (Tear_Needed is on), need to forward RTEAR and/or
RESV refresh messages.

Do the RSVP_HOP object following for each PSB whose OutInterface_list
includes the outgoing interface OI:

1. Pick each flow descriptor Fj in the RTEAR message to contain
whose FILTER_SPEC matches the
IncInterface address through which it will be sent PSB, and do the
LIH from (one of)
following.

- If there is no RSB whose FILTER_SPEC matches the PSB's.

o Send
PSB, then add Fj to the new RTEAR message being
built.

- Otherwise (there is a matching RSB), note the PSB
as needing a RESV refresh message and set the
Resv_Refresh_Needed flag True.

2. If the new RTEAR message contains any flow
descriptors, send it to PHOP in the address PH. PSB.

o If the Resv_Refresh_Needed flag is now on, execute the RESV
REFRESH sequence (below) for each PHOP in
Refresh_PHOP_list.

Braden, Zhang, et al. Expiration: May August 1996 [Page 81] 80]

Internet Draft RSVP Specification November 1995

APPENDIX A. Object Definitions

C-Types are defined for February 1996

o Drop the two Internet address families IPv4 RTEAR message and
IP6. To accommodate 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 return.

RESV ERROR MESSAGE ARRIVES

A RERR message arrives through the (real) incoming interface
In_If.

o If there is no path state for SESSION, drop the RERR
message and ignored on receipt.

A.1 SESSION Class

SESSION Class = 1. return.

o IPv4/UDP SESSION object: Class = 1, C-Type If the Error Code = 1

+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+

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

+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+

DestAddress

The IP unicast 01 (Admission Control failure), do
special processing as follows:

1. Find or multicast destination address of create a Blockade State Block (BSB), in the
session. This parameter must
following style-dependent manner.

For WF (wildcard) style, there will be supplied.

Protocol Id

The IP Protocol Identifier for the data flow. This parameter
must one BSB per
(session, PHOP) pair.

For FF style, there will be supplied.

Braden, Zhang, et al. Expiration: May 1996 [Page 82]

Internet Draft RSVP Specification November 1995

Flags

0x01 = E_Police flag

The E_Police flag is used one BSB per (session,
filter_spec) pair. Note that an FF style RERR message
carries only one flow descriptor.

For SE style, there will be one BSB per (session,
filter_spec), for each filter_spec contained in PATH messages to determine the effective "edge"
filter spec list of the network, flow descriptor.

2. For each BSB in the preceding step, set (or replace)
its FLOWSPEC Qb with FLOWSPEC from the message, and
set (or reset) its timer Tb to control traffic
policing. Kb*R seconds [Section
3.4]. If the sender host BSB is not itself capable of
traffic policing, it will new, set this bit on in PATH
messages it sends. The first node whose RSVP is capable
of traffic policing will do so (if appropriate its PHOP value, and set
its Sender_Template equal to the
service) and turn appropriate
filter_spec from the message.

3. Partially execute the RESV REFRESH event sequence
shown below, for the previous hop PHOP.

In particular, execute the refresh sequence with the
B_Merge flag off.

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

DstPort

The UDP/TCP destination port for no refresh
messages being generated, because all matching
reservations are blockaded, do not turn B_Merge on but
instead exit the session. Zero may be
used to indicate a `wildcard', i.e., any port.

Other SESSION C-Types could be defined refresh sequence and return here.

o For all RERR messages, execute the following for each RSB
for this session whose OI differs from In_If and whose
Filter_spec_list has at least one filter spec in common
with the future to
support other demultiplexing conventions FILTER_SPEC* in the transport-
layer or application layer. RERR message. For WF style,

Braden, Zhang, et al. Expiration: May August 1996 [Page 83] 81]

Internet Draft RSVP Specification November 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 February 1996

empty FILTER_SPEC* structures are assumed to match.

1. If Error_Code = 2

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

This object provides 01 and the IP address InPlace flag is 1 and one
or more of the interface through which
the last RSVP-knowledgeable hop forwarded this message. The
Logical Interface Handle is BSB's found/created above has a 32-bit number which may be used to
distinguish logical outgoing interfaces as described Qb that
is strictly greater than Flowspec in Section
3.2; it should be identically zero the RSB, then
continue with the next matching RSB, if there any.

2. If NHOP in the RSB is no logical
interface handle.

Braden, Zhang, et al. Expiration: May 1996 [Page 84]

Internet Draft RSVP Specification November 1995

A.3 INTEGRITY Class

INTEGRITY class = the local API, then:

- If the FLOWSPEC in the RERR message is strictly
greater than the RSB Flowspec, then turn on the
NotGuilty flag in the ERROR_SPEC.

- Deliver an error upcall to application:

Call: <Upcall_Proc>( session-id, RESV_ERROR,
Error_code, Error_value,
Node_Addr, Error_flags,
Flowspec, Filter_Spec_List,
[Policy_data] )

and continue with the next RSB.

3. If the style has wildcard sender selection, use the
SCOPE object SC.In from the RERR message to construct
a SCOPE object SC.Out to be forwarded. SC.Out should
contain those sender addresses that appeared in SC.In
and that route to OI [LIH?], as determined by scanning
the PSB's. If SC.Out is empty, continue with the next
RSB.

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

A.4 TIME_VALUES Class

TIME_VALUES class = Create a new RERR message containing the error flow
descriptor and send to the NHOP address specified by
the RSB. Include SC.Out if the style has wildcard
sender selection.

5. Continue with the next RSB.

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

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

Refresh Period

The refresh timeout period R used to generate this message; Drop the RERR message and return.

RESV CONFIRM ARRIVES

o If the (unicast) IP address found in milliseconds. the RESV_CONFIRM
object in the RACK message matches an interface of the
node, a confirmation upcall is made to the matching

Braden, Zhang, et al. Expiration: May August 1996 [Page 85] 82]

Internet Draft RSVP Specification November 1995

A.5 ERROR_SPEC Class

ERROR_SPEC class = 6. February 1996

application:

Call: <Upcall_Proc>( session-id, RESV_CONFIRM,
Error_code, Error_value, Node_Addr,
LUB-Used, nlist, Flowspec,
Filter_Spec_List, NULL, NULL )

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 Otherwise, the RACK message is forwarded immediately to the
address of in the node IP address in which its RESV_CONFIRM object.

o Drop the error was detected.

Flags

0x01 = LUB-Used RACK message and return.

UPDATE TRAFFIC CONTROL

The use of this flag sequence is described in section 3.1.5.

Error Code

A one-octet error description.

Error Value

A two-octet field containing additional information about invoked by the

Braden, Zhang, et al. Expiration: May 1996 [Page 86]

Internet Draft RSVP Specification November 1995

error. Its contents depend upon PATH MESSAGE ARRIVES or the Error Type.

The values for Error Code RESV
MESSAGE ARRIVES sequence, to (re-)calculate and Error Value are defined adjust the local
traffic control state in Appendix
B.

A.6 SCOPE Class

SCOPE class = 7.

This object contains a list of IP addresses, used for routing
messages accordance with wildcard scope without loops. The addresses must be
listed in ascending numerical order. the current reservation
and path state. If the result is to modify the traffic control
state, this sequence turns on the Resv_Refresh_Needed flag.

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) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+ Compute the traffic control parameters using the following
steps.

1. Consider the set of RSB's matching SESSION and OI from
the message.

- Compute the effective kernel flowspec,
TC_Flowspec, as the maximum/LUB of the FLOWSPEC
values in these RSB's.

- Compute the effective traffic control filter spec
(list) TC_Filter_Spec*, by merging the
Filter_spec_lists from these RSB's.

2. Scan all RSB's matching session and Filtss, for all
OI. Set TC_B_Police_flag on if TC_Flowspec is smaller
than, or incomparable to, any FLOWSPEC in those RSB's.

3. Locate the set of PSBs (senders) whose
SENDER_TEMPLATEs match Filter_spec_list in the active
RSB and whose OutInterface_list includes OI.

4. Set TC_E_Police_flag on if any of these PSBs have
their E_Police flag on. Set TC_M_Police_flag on if it
is a shared style and there is more than one PSB in

Braden, Zhang, et al. Expiration: May August 1996 [Page 87] 83]

Internet Draft RSVP Specification November 1995

A.7 STYLE Class

STYLE class = 8.

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

+-------------+-------------+-------------+-------------+
| Option Vector |
+-------------+-------------+-------------+-------------+

Option Vector

A February 1996

the set.

5. Compute Path_Te as the sum of the SENDER_TSPEC objects
in this set of bit fields giving values PSBs.

o Search for the reservation
options. a TCSB matching SESSION and OI; for distinct
style (FF), it must also match Filter_spec_list.

If new options are added none is found, create a new TCSB.

o If TCSB is new:

1. Store TC_Flowspec, TC_Filter_Spec*, Path_Te, and the
police flags into TCSB.

2. Turn the Resv_Refresh_Needed flag on and make the
traffic control call:

Rhandle = TC_AddFlowspec( OI, TC_Flowspec,
Path_Te, police_flags)

3. If this call succeeds, record Rhandle in the future,
corresponding fields TCSB and,
for each filter_spec F in TC_Filter_Spec*, call:

Fhandle = TC_AddFilter( OI, Rhandle, Session, F)

and record the returned Fhandle in the option vector will be assigned
from TCSB.

4. Otherwise, build and send a RERR message specifying
"Admission control failed" and with the least-significant end. InPlace flag
off.

o If a node does TCSB is 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 but the left) as
follows:

27 bits: Reserved

2 bits: Sharing control

00b: Reserved

01b: Distinct reservations

10b: Shared reservations

11b: Reserved

3 bits: Sender selection control

000b: Reserved

001b: Wildcard

010b: Explicit

011b - 111b: Reserved

The low order bits of TC_Flowspec, Path_Te, and/or
police flags just computed differ from corresponding values
in the option vector are determined by TCSB, then:

1. Turn the
style, as follows: Resv_Refresh_Needed flag on and make the
traffic control call:

TC_ModFlowspec( OI, Rhandle, TC_Flowspec,
Path_Te, police_flags )

2. If this call fails, build and send a RERR message

Braden, Zhang, et al. Expiration: May August 1996 [Page 88] 84]

Internet Draft RSVP Specification November 1995

WF 10001b
FF 01010b
SE 10010b

Braden, Zhang, et al. Expiration: May February 1996 [Page 89]

Internet Draft RSVP Specification November 1995

A.8 FLOWSPEC Class

FLOWSPEC class = 9.

o Class = 9, C-Type = 1: int-serv flowspec

The contents of this object will be specified in documents
prepared by

specifying "Admission control failed" and with the int-serv working group.
InPlace bit on. If the call succeeds, update the TCSB
with the new values.

o Class = 9, C-Type = 254: Unmerged Flowspec List

+-------------+-------------+-------------+-------------+
| |
// FLOWSPEC object 1 //
| |
+-------------+-------------+-------------+-------------+
| |
// FLOWSPEC object 2 //
| |
+-------------+-------------+-------------+-------------+
// //
// //
+-------------+-------------+-------------+-------------+
| |
// FLOWSPEC object k //
| |
+-------------+-------------+-------------+-------------+

This If the TCSB is a container C-Type, used to enclose a not new but the TC_Filter_Spec* just
computed differ from the FILTER_SPEC* in the TCSB, then:

1. Make an appropriate set of FLOWSPEC
objects that could not be merged at TC_DelFilter and
TC_AddFilter calls to transform the next hop downstream
because they include unrecognized C-Types. The node Filter_spec_list
in the TCSB into the new TC_Filter_Spec*.

o Return to the event sequence that
receives invoked this object one.

PATH REFRESH

This sequence sends a path refresh for a particular sender,
i.e., a PSB. This sequence may merge those it recognizes and
forward be entered by either the rest in another Unmerged Flowspec List object.

Braden, Zhang, et al. Expiration: May 1996 [Page 90]

Internet Draft RSVP Specification November 1995

A.9 FILTER_SPEC Class

FILTER_SPEC class = 10.

o IPv4 FILTER_SPEC object: Class = 10, C-Type = 1

+-------------+-------------+-------------+-------------+
| IPv4 SrcAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| ////// | ////// | SrcPort |
+-------------+-------------+-------------+-------------+
expiration of the path refresh timer or directly as the result
of the Path_Refresh_Needed flag being turned on during the
processing of a received PATH message.

o IP6 FILTER_SPEC object: Class = 10, C-Type = 2

o IP6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3

SrcAddress

The Compute the IP source address 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 Insert TIME_VALUES and PHOP objects into the PATH message
being built.

o Create a sender host, or zero descriptor containing the SENDER_TEMPLATE,
SENDER_TSPEC, and POLICY_DATA objects, if present in the
PSB, and pack it into the PATH message being built.

o Pass any ADSPEC and SENDER_TSPEC objects present in the PSB
to indicate the traffic control call TC_Advertise. Insert the
modified ADSPEC object that is returned 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 Send a `wildcard'. copy of the PATH message to each interface in
OutInterfact_list. Before sending each copy, insert into
its PHOP object the interface address and the LIH for the
interface.

Braden, Zhang, et al. Expiration: May August 1996 [Page 91] 85]

Internet Draft RSVP Specification November 1995

SrcPort

The UDP/TCP source port for February 1996

RESV REFRESH

This sequence sends a sender, or zero to indicate reservation refresh towards a
`wildcard' (i.e., any port).

Flow Label

A 24-bit Flow Label, defined in IP6. particular
previous hop with IP address PH. This value sequence may be used entered
by either the packet classifier to efficiently identify the packets
belonging to expiration of a particular (sender->destination) data flow.

Braden, Zhang, et al. Expiration: May 1996 [Page 92]

Internet Draft RSVP Specification November 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 reservation refresh timer or
directly as IP6/UDP FILTER_SPEC object.

A.11 SENDER_TSPEC Class

SENDER_TSPEC class = 12.

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

The contents a result of this object will be specified in documents
prepared the Resv_Refresh_Needed flag being
turned on by processing a RESV or RTEAR message.

In general, this sequence considers each of the int-serv working group.

Braden, Zhang, et al. Expiration: May 1996 [Page 93]

Internet Draft RSVP Specification November 1995

A.12 ADSPEC Class

ADSPEC class = 13. PSB's with PHOP
address PH. For a given PSB, it scans the RSBs for matching
reservations and merges the styles, FLOWSPECs and
Filter_spec_list's appropriately. It then builds a RESV message
and sends it to PH. The contents details depend upon the attributes of this object will be specified
the style(s) included in documents
prepared by the int-serv working group.

Braden, Zhang, et al. Expiration: May 1996 [Page 94]

Internet Draft RSVP Specification November 1995

A.13 POLICY_DATA Class

POLICY_DATA class = 14. reservations.

o Type 1 POLICY_DATA object: Class = 14, C-Type = 1

The contents of this Create an output message containing INTEGRITY (if
supported), SESSION, RSVP_HOP, and TIME_VALUES objects.

o Determine the style for these reservations from the first
RSB for the session, and move the STYLE object into the
proto-message. (Note that the present set of styles are for further study.
never themselves merged; if future styles can be merged,
these rules will become more complex).

o Unmerged POLICY_DATA object: Class = 14, C-Type = 254

This If style is wildcard and if there are PSB's from more than
one PHOP and if the multicast routing protocol does not use
shared trees, set the Need_Scope flag on, otherwise set it
off.

o Select each sender PSB whose PHOP has address PH.

1. Set local flag B_Merge off.

2. Select all RSB's whose Filter_spec_list's match the
SENDER_TEMPLATE object in the PSB and whose OI appears
in the OutInterface_list of the PSB.

3. If B_Merge flag is off then ignore a container for a list of POLICY_DATA objects
(none blockaded RSB, as
follows.

- Select BSB's that match this RSB; if any of which may have C-Type = 254). The contained objects
have these
BSB's has a Qb that is not yet been merged.

+-------------+-------------+-------------+-------------+
| |
// POLICY_DATA object strictly larger than
RSB Flowspec, then continue processing with the
next RSB.

However, if steps 1 //
| |
+-------------+-------------+-------------+-------------+
| |
// POLICY_DATA object and 2 //
| |
+-------------+-------------+-------------+-------------+
// //
// //
+-------------+-------------+-------------+-------------+
| |
// POLICY_DATA object k //
| |
+-------------+-------------+-------------+-------------+ result in finding that all
RSB's matching this PSB are blockaded, then:

Braden, Zhang, et al. Expiration: May August 1996 [Page 95] 86]

Internet Draft RSVP Specification November 1995

A.14 RESV_CONFIRM Class

RESV_CONFIRM class = 15.

o IPv4 RESV_CONFIRM object: Class = 15, C-Type = 1

+-------------+-------------+-------------+-------------+
| IPv4 Receiver Address (4 bytes) |
+-------------+-------------+-------------+-------------+

o IP6 RESV_CONFIRM object: Class = 15, C-Type = 2

+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 Receiver Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+

Braden, Zhang, et al. Expiration: May February 1996 [Page 96]

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

- If this Error Code, RESV REFRESH sequence was invoked from
RESV ERROR RECEIVED, then return now to the 16 bits of
latter.

- Otherwise, turn on the Error Value field are:

ussr cccc cccc cccc

where B_Merge flag and restart
with this procedure step 1. above.

4. Merge the bits are:

u = 0: RSVP rejects flowspecs, as follows:

- If B_Merge flag is off, compute the message without updating local state.

u = 1: RSVP may use message to update local state and forward LUB over the message.

ss = 00: Low order 12 bits contain
Flowspec objects of this set of RSB's.

While computing the LUB, check for a globally-defined sub-code
(values listed below).

ss = 10: Low order 12 bits contain RESV_CONFIRM
object in each RSB. If a sub-code RESV_CONFIRM object is
found:

- If the FLOWSPEC in that RSB is specific
to local organization. RSVP larger than
all other (non-blockaded) flowspecs being
compared, then save this RESV_CONFIRM object
for forwarding.

- Otherwise (the corresponding FLOWSPEC is not expected to be able to
interpret this except as
the largest) then create and send a numeric value.

ss = 11: Low order 12 bits contain a sub-code that is specific RACK
message containing the RESV_CONFIRM object
to the service. RSVP address in the RESV_CONFIRM object.
Include the RESV_CONFIRM object in the RACK
message. The RACK message should also
include an ERROR_SPEC object whose
Error_Node parameter is not expected to be able to
interpret IP address of OI
from the RSB.

- Then delete the RESV_CONFIRM object from the
RSB.

- Otherwise (B_Merge flag is on), compute the GLB
over the Flowspec objects of this except as set of RSB's.

While computing the GLB, check for a numeric value. Since RESV_CONFIRM
object in each RSB. If one is found, delete it.

5. If the
traffic control mechanism might substitute Need_Scope flag is on, compute a different
service, this encoding may include some representation new SCOPE
object as the union of the service SCOPE objects found in use.

r: Reserved bit, should be zero.

cccc cccc cccc: 12 bit code. the
RSB's.

6. Merge the F_POLICY_DATA objects from the RSB's.

7. (All matching RSB's have been processed). The following globally-defined sub-codes may appear in next
step depends upon the low-
order 12 bits when ss = 00: style attributes.

Braden, Zhang, et al. Expiration: May August 1996 [Page 97] 87]

Internet Draft RSVP Specification November 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 replacement.

- Sub-code = 13: Bad Flowspec or Tspec value

Unreasonable request. High order bit u = 0, i.e., RSVP
will reject February 1996

8. Merge 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.

The high order 4 bits matching FILTER_SPEC objects from this set
of RSB's. For explicit sender selection (FF, SE)
styles, use the Error Value field are assigned SENDER_TEMPLATE as
for Error Code = 01 (above). For Error Code = 02, the following
global sub-codes are defined:

- 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 merged
FILTER_SPEC; for this Resv

RSVP should reject the message.

o Error Code = 04: No wildcard sender information for this Resv

There selection (WF) style,
there is path information, but it does not include the sender
specified in one of no filter spec to be merged.

Distinct reservation (FF) style

Use the Filterspecs listed in Sender_Template as the Resv message.
RSVP should reject merged
FILTER_SPEC. Pack the message.

Braden, Zhang, et al. Expiration: May 1996 [Page 98]

Internet Draft RSVP Specification November 1995

o Error Code = 05: Ambiguous path

Sender port appears both zero and non-zero in same session.
RSVP should reject merged (FLOWSPEC,
FILTER_SPEC, F_POLICY_DATA) triplet into the message.

o Error Code = 06: Ambiguous filter spec

Filter spec matches more than one sender, in a style that
requires
message as a unique match. RSVP should reject the message.

o Error Code = 07: Conflicting or unknown style

Reservation style conflicts with style(s) of existing flow descriptor.

Shared wildcard reservation state, or it (WF) style

There is unknown. If the high-order bit no merged FILTER_SPEC. Merge (take the
maximum of) the merged FLOWSPECS from the RSB's,
across all PSB's for PH.

Shared distinct reservation (SE) style

Using the Sender_Template as the merged
FILTER_SPEC, form the union of
Error Value is zero, RSVP should reject the message.

o Error Code = 08: Conflicting dest port

Sessions FILTER_SPECS
obtained from the RSB's. Merge (take the maximum
of) the merged FLOWSPECS from the RSB's, across
all PSB's for same destination address and protocol have appeared
with both zero and non-zero dest port fields.

o Error Code = 09: Conflicting source port

The source port PH.

9. If the Need_Scope flag is non-zero in a filter spec or on, remove from the merged
SCOPE object all sender template addresses that do not match
the set of PSB's for a session with destination port zero.

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 PH, and all senders addresses
that are local. If the resulting set is missing. RSVP empty, no
RESV should reject be forwarded to this PHOP; return.
Otherwise (set is not empty), move the new SCOPE
object into 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 (All PSB's have been processed). If a shared reservation
style is going to reject being built, move the final merged FLOWSPEC,
F_POLICY_DATA, and FILTER_SPEC (if SE) objects into the
message.

o Error Code = 13: Unknown If a RESV_CONFIRM 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 reject was saved earlier, copy it into
the message. new RESV message and delete it from the RSB in which it
was found.

o Error Code = 14: Object error

A non-specific error indicating bad format or contents of an
object. The Error Value will Set the RSVP_HOP object in the message to contain 16-bits value (Class-Num, the

Braden, Zhang, et al. Expiration: May August 1996 [Page 99] 88]

Internet Draft RSVP Specification November 1995

C-Type) February 1996

IncInterface address through which it will be sent and the
LIH from header of bad object. RSVP should reject (one of) the
message. PSB's.

o Error Code = 21: Traffic Control error

Some system error was detected and reported by Send the traffic
control modules. message to the address PH.

PATH LOCAL REPAIR

The Error Value will contain sequence is entered when RSVP learns from routing that the
set of outgoing interfaces for some destination (G,DstPort) has
changed.

o Wait for a system-specific
value giving more information about delay time of W seconds [Section 3.5].

o For each session that exists for destination IP address G,
execute the error. PATH REFRESH event sequence above for each
sender (PSB) for that session.

5. Acknowledgments

The design of RSVP is not
expected to be able to interpret this value.

o Error Code = 22: RSVP System error

The Error Value field will provide implementation-dependent
information on based upon research performed in 1992-1993 by a
collaboration including Lixia Zhang (Xerox PARC), Deborah Estrin
(USC/ISI), Scott Shenker (Xerox PARC), Sugih Jamin (USC/Xerox PARC),
and Daniel Zappala (USC). Sugih Jamin developed the error. first prototype
implementation of RSVP is not expected to be able to
interpret this value.

Braden, Zhang, et al. Expiration: and successfully demonstrated it in May 1996 [Page 100]

Internet Draft RSVP Specification November 1995

APPENDIX C. UDP Encapsulation

An RSVP implementation will generally require the ability to perform
"raw" network I/O, i.e., to send 1993.
Shai Herzog, and receive IP datagrams using
protocol 46. However, some important classes later Steve Berson, continued development of host systems may not
support raw network I/O. To use RSVP, such hosts must encapsulate RSVP messages in UDP.

The basic UDP encapsulation scheme makes two assumptions:

1. All hosts are capable
prototypes.

Since 1993, many members of sending the Internet research community have
contributed to the design and receiving multicast
packets.

2. The first/last-hop routers are RSVP-capable.

A method development of relaxing the second assumption is given later.

Let Hu be a "UDP-only" host that requires UDP encapsulation, RSVP; these include (in
alphabetical order) Steve Berson, Bob Braden, Lee Breslau, Dave
Clark, Deborah Estrin, Shai Herzog, Craig Partridge, Scott Shenker,
John Wroclawski, and Hr Daniel Zappala. In addition, a
host that can do raw network I/O. The UDP encapsulation scheme must
allow RSVP interoperation among an arbitrary topology number of Hr hosts, Hu
hosts, host
and routers.

RESV, RERR, RTEAR, router vendors have made valuable contributions, particularly
Fred Baker (Cisco), Mark Baugher (Intel), Don Hoffman (Sun), Steve
Jakowski (NetManage), John Krawczyk (Bay Networks), and Bill Nowicki
(SGI). Ron Frederick, Bobby Minnear, Eve Schooler, and PERR messages are sent to unicast addresses
learned from the path or reservation state in the node. If the node
keeps track Garrett
Wollman did early interfacing of which previous hops multicast applications to RSVP.
Steve Deering, Bill Fenner, and which interfaces need UDP
encapsulation, these messages message can be sent using UDP
encapsulation when necessary.

On Ajit Thyagarajan helped with the other hand, PATH
interface between RSVP and PTEAR messages are send to the unicast or multicast destination address routing.

Braden, Zhang, et al. Expiration: August 1996 [Page 89]

Internet Draft RSVP Specification February 1996

APPENDIX A. Object Definitions

C-Types are defined for the session. The table in Figure
12 shows the basic rules for UDP encapsulation of such messages.
Under two Internet address families IPv4 and
IP6. To accommodate other address families, additional C-Types could
easily be defined. These definitions are contained as an Appendix,
to ease updating.

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

A.1 SESSION Class

SESSION Class = 1.

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

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

DestAddress

The IP unicast or multicast destination address of the `Send' column,
session. This field must be non-zero.

Protocol Id

The IP Protocol Identifier for the notation is `mode(destaddr, destport,
TTL)', where TTL data flow. This field
must be non-zero.

Braden, Zhang, et al. Expiration: August 1996 [Page 90]

Internet Draft RSVP Specification February 1996

Flags

0x01 = E_Police flag

The E_Police flag is used in PATH messages to determine
the IP-layer hop count. 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 `Receive' column
shows first node whose RSVP is capable
of traffic policing will do so (if appropriate to the group that
service) and turn the flag off.

0x10 = Non_RSVP flag

The Non_RSVP flag is joined and, where relevant, turned on in the UDP Listen
port. SESSION object of
a PATH message whenever the RSVP daemon detects that the
previous RSVP hop included one or more non-RSVP-capable
routers. This flag is forwarded hop-by-hop and passed
to a receiver application. If it is on, it indicates to
the application that even a successful reservation
request may not install the requested QoS at every node
along the path.

0x20 = Maybe_RSVP flag

The Maybe_RSVP flag is turned on in the SESSION object
of a PATH message whenever the RSVP daemon is unable to
ascertain whether or not the previous hop included one
or more non-RSVP-capable routers. This flag is
forwarded hop-by-hop and passed to a receiver
application. If it is on and the Non_RSVP flag is off,
the application cannot tell whether or not a successful
reservation request may not install the requested QoS at
every node along the path.

DstPort

The UDP/TCP destination port for the session. Zero may be
used to indicate `none'.

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: August 1996 [Page 91]

Internet Draft RSVP Specification February 1996

A.2 RSVP_HOP Class

RSVP_HOP class = 3.

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

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

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
3.2; it should be identically zero if there is no logical
interface handle.

Braden, Zhang, et al. Expiration: August 1996 [Page 92]

Internet Draft RSVP Specification February 1996

A.3 INTEGRITY Class

INTEGRITY class = 4.

See [Baker96].

A.4 TIME_VALUES Class

TIME_VALUES class = 5.

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

+-------------+-------------+-------------+-------------+
| Refresh Period R |
+-------------+-------------+-------------+-------------+

Refresh Period

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

Braden, Zhang, et al. Expiration: August 1996 [Page 93]

Internet Draft RSVP Specification February 1996

A.5 ERROR_SPEC Class

ERROR_SPEC class = 6.

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

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

Error Node Address

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

Flags

0x01 = InPlace

This flag is used only for an ERROR_SPEC object in a
RERR message. If it on, this flag indicates that there
was, and still is, a reservation in place at the failure
point.

0x02 = NotGuilty

This flag is used only for an ERROR_SPEC object in a
RERR message, and it is only set in the interface to the

Braden, Zhang, et al. Expiration: August 1996 [Page 94]

Internet Draft RSVP Specification February 1996

receiver application. If it on, this flag indicates
that the FLOWSPEC that failed was strictly greater than
the FLOWSPEC requested by this receiver.

Error Code

A one-octet error description.

Error Value

A two-octet field containing additional information about the
error. Its contents depend upon the Error Type.

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

Braden, Zhang, et al. Expiration: August 1996 [Page 95]

Internet Draft RSVP Specification February 1996

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

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

Braden, Zhang, et al. Expiration: August 1996 [Page 96]

Internet Draft RSVP Specification February 1996

A.7 STYLE Class

STYLE class = 8.

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

+-------------+-------------+-------------+-------------+
| Flags | Option Vector |
+-------------+-------------+-------------+-------------+

Flags: 8 bits

(None assigned yet)

Option Vector: 24 bits

A set of bit fields giving values for the reservation
options. If new options are added in the future,
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

3 bits: Sender selection control

000b: Reserved

001b: Wildcard

010b: Explicit

Braden, Zhang, et al. Expiration: August 1996 [Page 97]

Internet Draft RSVP Specification February 1996

011b - 111b: Reserved

The low order bits of the option vector are determined by the
style, as follows:

WF 10001b
FF 01010b
SE 10010b

Braden, Zhang, et al. Expiration: August 1996 [Page 98]

Internet Draft RSVP Specification February 1996

A.8 FLOWSPEC Class

FLOWSPEC class = 9.

o Class = 9, C-Type = 2: int-serv flowspec

The contents of this object will be specified in documents
prepared by the int-serv working group.

Braden, Zhang, et al. Expiration: August 1996 [Page 99]

Internet Draft RSVP Specification February 1996

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

SrcAddress

The IP source address for a sender host. Must be non-zero.

Braden, Zhang, et al. Expiration: August 1996 [Page 100]

Internet Draft RSVP Specification February 1996

SrcPort

The following symbols are also used:

o D is the DestAddress UDP/TCP source port for the particular session.

o G* is a well-known group address of sender, or zero to indicate
`none'.

Flow Label

A 24-bit Flow Label, defined in IP6. This value may be used
by the form 224.0.0.x, i.e., a
group that is limited packet classifier to efficiently identify the local connected network. [TO BE
DEFINED] packets
belonging to a particular (sender->destination) data flow.

Braden, Zhang, et al. Expiration: August 1996 [Page 101]

Internet Draft RSVP Specification February 1996

A.10 SENDER_TEMPLATE Class

SENDER_TEMPLATE class = 11.

o Pu is the well-known UDP port for UDP encapsulation of RSVP:
3455. IPv4/UDP SENDER_TEMPLATE object: Class = 11, C-Type = 1

Definition same as IPv4/UDP FILTER_SPEC object.

o Ra is the IP address 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.

o Intserv SENDER_TSPEC object: Class = 12, C-Type = 1

The contents of this object are specified in service
specification documents prepared by the router interface `a'. int-serv working
group.

Braden, Zhang, et al. Expiration: August 1996 [Page 102]

Internet Draft RSVP Specification February 1996

A.12 ADSPEC Class

ADSPEC class = 13.

o Tr is Intserv ADSPEC object: Class = 13, C-Type = 2

The contents of this object are specified in service
specification documents prepared by the TTL value int-serv working
group.

Braden, Zhang, et al. Expiration: August 1996 [Page 103]

Internet Draft RSVP Specification February 1996

A.13 POLICY_DATA Class

POLICY_DATA class = 14.

o Type 1 POLICY_DATA object: Class = 14, C-Type = 1

The contents of the specific PATH message. this object are for further study.

Braden, Zhang, et al. Expiration: May August 1996 [Page 101] 104]

Internet Draft RSVP Specification November 1995 February 1996

A.14 RESV_CONFIRM Class

RESV_CONFIRM class = 15.

o Router interface `a' is on the local network connected to Hu and
Hr, while interface `b' is connected only to another router.

RSVP IPv4 RESV_CONFIRM object: Class = 15, C-Type = 1

+-------------+-------------+-------------+-------------+
| IPv4 Receiver Address (4 bytes) |
+-------------+-------------+-------------+-------------+

o IP6 RESV_CONFIRM object: Class = 15, C-Type = 2

+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 Receiver Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+

Braden, Zhang, et al. Expiration: August 1996 [Page 105]

Internet Draft RSVP
Node Node Type Send Receive
___ __________ _____________ _______________
Hu UDP-only host UDP(G*,Pu,1) UDP(G*,Pu)
or UDP(Ra,Pu,1) and UDP(D,Pu)
[Note 1] [Note 3]

Hr Raw-mode host UDP(G*,Pu,1) UDP(G*,Pu)
and Raw(D,,Tr) and Raw()

R Router
Interface a: UDP(D,Pu,Tr) UDP(G*,Pu) [Note 2]
and Raw(D,,Tr) and UDP(Ra,Pu)
and Raw()

Interface b: Raw(D,,Tr) Raw()

Figure 12: UDP Encapsulation Rules for Path Messages

[Note 1] Hu sends a PATH message to Ra only if session destination
address D is unicast.

[Note 2] R ignores PATH messages addressed to G* if D is unicast.
(This is necessary to prevent routing and reservation anomalies).

[Note 3] The DestAddress D is the IP address of Hu in this case.

R and Hr send their PATH messages twice, once with UDP encapsulation
and once in raw mode. In two cases (Hr -> R Specification February 1996

APPENDIX B. Error Codes and Hr -> Hr), each PATH
message will be delivered twice. Values

The destination following Error Codes may take steps appear in ERROR_SPEC objects and be
passed to
ignore the duplicates, although this redundancy has no ill effect
other than overhead for processing the extra messages.

A router end systems. Except where noted, these Error Codes may determine if its interface X needs UDP encapsulation by
listening
appear only in RERR messages.

o Error Code = 00: Confirmation

This code is reserved for UDP-encapsulated PATH messages that were sent to either
G* (multicast D) or to use in the address ERROR_SPEC object of interface X (unicast D). There
is one a RACK
message. The Error Value will also be zero.

o Error Code = 01: Admission Control failure mode for

Reservation request was rejected by Admission Control due to
unavailable resources.

For this scheme: if no host on Error Code, the connected
network acts as an 16 bits of the Error Value field are:

ssur cccc cccc cccc

where the bits are:

ss = 00: Low order 12 bits contain a globally-defined sub-code
(values listed below).

ss = 10: Low order 12 bits contain a organization-specific sub-
code. RSVP sender, there will is not expected to be no PATH messages able to
trigger UDP encapsulation. In interpret this (unlikely) case, it will
except as a numeric value.

ss = 11: Low order 12 bits contain a service-specific sub-code.
RSVP is not expected to be
necessary able to explicitly configure UDP encapsulation on interpret this except as
a numeric value.

Since the local
network interface traffic control mechanism might substitute a
different service, this encoding may include some
representation of the router.

A UDP-only host Hu supporting unicast RSVP sessions must somehow know service in use.

u = 0: RSVP rejects the message without updating local
state.

u = 1: RSVP may use message to update local state and forward
the message. This means that the message is informational.

Braden, Zhang, et al. Expiration: May August 1996 [Page 102] 106]

Internet Draft RSVP Specification November 1995

the address Ra, presumably by configuration.

When a UDP-encapsulated packet is received, February 1996

r: Reserved bit, should be zero.

cccc cccc cccc: 12 bit code.

The following globally-defined sub-codes may appear in the IP TTL is low-
order 12 bits when ssur = 0000:

- Sub-code = 1: Delay bound cannot be met

- Sub-code = 2: Requested bandwidth unavailable

o Error Code = 02: Policy Control failure

Reservation has been rejected for administrative reasons, for
example, required credentials not
available to the application on most systems. The RSVP daemon that
receives submitted, insufficient quota
or balance, or administrative preemption. This Error Code may
appear in a UDP-encapsulated PATH PERR or PTEAR message should therefore
use the Send_TTL field RERR message.

Contents of the RSVP common header as the effective
receive TTL.

We have assumed that the first-hop RSVP-capable router R is on the
directly-connected network. There Error Value field are several possible approaches if to be determined in the
future.

o Error Code = 03: No path information for this Resv message.

No path state for this session. RESV message cannot be
forwarded.

o Error Code = 04: No sender information for this Resv message.

There is path state for this session, but it does not include
the case.

1. Hu can send both unicast and multicast sessions to
UDP(Ra,Pu,Ta).

Here Ta must sender matching some flow descriptor contained in the RESV
message. RESV message cannot be forwarded.

o Error Code = 05: Conflicting reservation style

Reservation style conflicts with style(s) of existing
reservation state. The Error Value field contains the TTL to exactly reach R. If Ta is too small, low-order
16 bits of the PATH message will not reach R. If Ta is too large,
multicast routing in R will forward Option Vector of the UDP packet into existing style with which
the
Internet until its hop count expires. conflict occurred. This will turn on UDP
encapsulation between routers within the Internet, causing bogus
UDP traffic. The host Hu must RESV message cannot be explicitly configured forwarded.

o Error Code = 06: Unknown reservation style

Reservation style is unknown. This RESV message cannot be
forwarded.

o Error Code = 07: Conflicting dest port

Sessions for same destination address and protocol have appeared

Braden, Zhang, et al. Expiration: August 1996 [Page 107]

Internet Draft RSVP Specification February 1996

with Ra both zero and Ta.

2. A particular host on the LAN connected to Hu could be designated
as an "RSVP relay host". A relay host would listen on (G*,Pu) non-zero dest port fields. This Error Code
may appear in a PERR or RERR message.

o Error Code = 08: Ambiguous path

Sender port appears both zero and forward any non-zero in same session in a
PATH messages directly to R, although it would
not be message. This Error Code may appear only in a PERR
message.

o Error Code = 09, 10, 11: (reserved)

o Error Code = 12: Service preempted

The service request defined by the STYLE object and the flow
descriptor has been administratively preempted.

For this Error Code, the 16 bits of the Error Value field are:

ssur cccc cccc cccc

Here the data path. high-order bits ssur are as defined under Error Code
01. The relay host would have following globally-defined sub-codes may appear in the
low-order 12 bits when ssur = 0000 are to be
configured with Ra and Ta.

APPENDIX D. Experimental and Open Issues

D.1 Reservation Compatibility

How strong is defined in the requirement for compatibility
future.

o Error Code = 13: Unknown object class

Error Value contains 16-bit value composed of reservations in
different directions? For example, see Figure 10; (Class-Num, C-
Type) of unknown object. This error 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 sent only if RSVP
is logically possible going to make reject the corresponding
reservations on message, as determined by the two different interfaces. The current
implementation does NOT allow this; instead, it prevents mixing high-order
bits of
incompatible styles in the same session on Class-Num. This Error Code may appear in a node, even if they
are on different interfaces.

D.2 Session Groups (Experimental)

Section 1.2 explained PERR or
RERR message.

o Error Code = 14: Unknown object C-Type

Error Value contains 16-bit value composed of (Class-Num, C-
Type) of object.

o Error Code = 15-19: (reserved)

o Error Code = 20: Reserved for API

Error Value field contains an API error code, for an API error
that a distinct destination address, was detected asynchronously and
therefore a distinct session, will must be used for each of the reported via an
upcall.

o Error Code = 21: Traffic Control Error

Braden, Zhang, et al. Expiration: May 1996 [Page 103]

Internet Draft RSVP Specification November 1995

subflows in a hierarchically encoded flow. However, these
separate sessions are logically related. For example it may be
necessary to pass reservations for all subflows to Admission Expiration: August 1996 [Page 108]

Internet Draft RSVP Specification February 1996

Reservation request was rejected by Traffic Control at the same time (since it would be nonsense due to admit high
frequency components but reject the baseband component of the
session data). Such a logical grouping is indicated in RSVP by
defining a "session group", an ordered set of sessions.

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

o The reference address is an agreed-upon choice from among continued attempts would be futile.

For this Error Code, the
DestAddress values 16 bits of the sessions in the group, for example
the smallest numerically.

o The session group ID is used to distinguish different groups
with Error Value field are:

ss00 cccc cccc cccc

Here the same reference address.

o high-order bits ss are as defined under Error Code 01.

The count is the number of members following globally-defined sub-codes may appear in the group.

o The rank, low
order 12 bits (cccc cccc cccc) when ssr = 000:

- Sub-code = 01: Service conflict

Trying to merge two incompatible service requests.

- Sub-code = 02: Service unsupported

Traffic control can provide neither the requested service
nor an integer between 1 acceptable replacement.

- Sub-code = 03: Bad Flowspec value

Mal-formed or unreasonable request.

- Sub-code = 04: Bad Tspec value

Mal-formed or unreasonable request.

o Error Code = 22: Traffic Control System error

A system error was detected and count, is different in
each session of reported by the session group. traffic control
modules. The SESSION_GROUP objects for all sessions in the group Error Value will contain a system-specific value
giving more information about the same values of the reference address, the session
group ID, and the count error. RSVP is not expected
to be able to interpret this value.