WDIFF

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

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

Resource ReSerVation Protocol (RSVP) --

Version 1 Functional Specification

July 7,

November 22, 1995

Status of Memo

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

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

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

Abstract

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

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

Internet Draft RSVP Specification July November 1995

Table of Contents

1. Introduction ........................................................5
1.1 Data Flows ......................................................8
1.2 Reservation Model ...............................................9
1.3 Reservation Styles ..............................................11
1.4 Examples of Styles ..............................................14
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
2.7 Policy and Security .............................................27
2.8 Automatic RSVP Tunneling ........................................28
2.9 Host Model ......................................................28
3. RSVP Functional Specification .......................................30
3.1 RSVP Message Formats ............................................30
3.2 Sending RSVP Messages ...........................................42
3.3 Avoiding RSVP Message Loops .....................................44
3.4 Local Repair ....................................................48
3.5 Time Parameters .................................................48
3.6 Traffic Policing and TTL ........................................50
3.7 Multihomed Hosts ................................................51
3.8 Future Compatibility ............................................52
3.9 RSVP Interfaces .................................................55
4. Message Processing Rules ............................................65
APPENDIX A. Object Definitions .........................................82
APPENDIX B. Error Codes and Values .....................................97
APPENDIX C. UDP Encapsulation ..........................................101
APPENDIX D. Experimental and Open Issues ...............................103

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

Internet Draft RSVP Specification November 1995

What's Changed Since Danvers IETF

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

o Added fields to common header for linear fragmentation, The role and
moved all references to semantic fragmentation to Appendix D.

o Added SE (Shared Explicit) style to all parts interpretation of the document.

o Further clarified reservation options IP Protocol Id is changed.
The Protocol Id is now a required part of the session
definition, and added table in Figure
3. Defined option vector in STYLE object.

o Renamed CREDENTIAL object class to POLICY_DATA object class, filter specs and
rewrote section 2.5 to more fully express its intended usage.

o Clarified sender templates now assume
the relationship between Protocol Id from the wildcard scope session rather than stating it
explicitly.

o A "soft" reservation option and wildcards in individual FILTER_SPEC
objects: wildcard confirmation message is as wildcard does. added.

o Added SCOPE object definition and defined the rules for its use The text states explicitly that an erroneous reservation
message is not forwarded. A mechanism to prevent looping of wildcard-scope messages.

o Added some mechanisms for handling backwards compatibility for
future protocol extensions: (1) High bit allow a receiver
more flexible control over forwarding of object class number;
(2) unmerged FLOWSPEC C-Type; (3) unmerged POLICY_DATA C-Type. its messages after
an admission control failure has not been designed and is
therefore not included in this version of the protocol.

o Rewrote Section 4.3 on preventing looping. Included rules A terminology confusion is eliminated. The term "scope" was
used both for
SCOPE object.

o Specified rules a set of senders and for local repair upon route change notification
(Section 4.4).

o Specified a set of sender hosts.
A new term "sender selection" is introduced for each error type whether or not the state
information in first,
leaving "scope" for the erroneous packet is to be stored and
forwarded. second.

o Deleted the discussion of retransmitting The FILTER_SPEC object is dropped from a Teardown message Q
times; assume Q=1 wildcard sender
selection (WF) style reservation, which now selects "all
senders" without qualification.

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

o Moved Session Groups An SE style flow descriptor is simplified to Appendix D, "Experimental and Open
Issues". Session Groups should be revisited as part of a larger
context of cross-session reservations. single
flowspec.

o Changed common header format, removing Object Count (which was
redundant) The IP Router Alert option is now required in PATH, PTEAR,
and rearranging the remaining fields. Moved the two
common header flags into objects: Entry-Police RACK messages.

o The TIME_VALUES object is now required in RESV 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 SESSION local repair.

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

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

Internet Draft RSVP Specification July November 1995

object and LUB-used into ERROR_SPEC object.

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

o A rule for state timeout (Section 4.5) and redefined
the TIME_VALUES object format. randomizing refresh timeouts is included.

o Changed the error message format: (1) removed required RSVP_HOP
object from PERR and RERR messages; (2) specified more carefully
what may appear in flow descriptor list of RERR messages.

o Revised the definitions of error codes and error values, and
moved them into a separate Appendix B.

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

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

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

o Specified The suggestion that addresses should TCP could be sorted in SCOPE object. used for carrying RSVP state
through a congested non-RSVP cloud is removed.

o Added two new upcall event types SENDER_TSPECS are now required in the API: reservation event
and policy data event. PATH| messages.

o Generalized the generic traffic control calls slightly to allow
multiple filter specs per flowspec, for SE style. This
introduced a There are new set of handles, called FHandle. Also added sections on multihomed hosts (3.7) and future
compatibility (3.8). The latter section makes clear that a
preemption upcall.

o Added route change notification to the generic interface to
routing.

o Updated the
message processing rules (Section 5). containing an object with unknown C-Type should be
rejected. Any more forgiving treatment seems too complex.

o Rewrote Appendix C on UDP encapsulation. encapsulation is completely changed.

o Removed specification of FLOWSPEC object format (but int-serv
working group has since reneged on promise to specify it). Some text was rearranged in Sections 1 and 2.

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

Internet Draft RSVP Specification July November 1995

1. Introduction

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

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

RSVP reserves requests resources for simplex data streams, i.e., it reserves requests
resources in only one direction on a link, so that direction. Therefore, a sender is logically
distinct from a receiver. However, receiver, although the same application process may
act as both a sender and receiver. RSVP operates on top of IP, 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. As shown in Figure 1, an implementation of RSVP, like Like the implementations of
routing and management protocols, an implementation of RSVP will
typically execute in the background, not in the data forwarding path. path,
as shown in Figure 1.

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

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

Internet Draft RSVP Specification July November 1995

HOST ROUTER

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

Figure 1: RSVP in Hosts and Routers

Each router that is capable of resource reservation passes incoming
data packets to through a packet classifier and then queues them as
necessary in a packet scheduler. The packet classifier determines
the route and the QoS class for each packet. The There is a scheduler allocates
for each interface, to allocate resources for transmission on the
particular link-layer medium used by each 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. There are many possible ways this might This
mapping to the link layer QoS may be
accomplished, and accomplished in a number of
possible ways; the details will be medium-dependent. The
scheduler itself allocates packet transmission capacity on On a QoS-
passive medium such as a leased line. 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 and to be consistent with IP multicast, membership, RSVP makes receivers responsible for
requesting resource reservations [RSVP93]. A QoS request, which
typically originating in originates from a receiver host application, will be is passed to
the local RSVP implementation, shown as a user daemon in Figure 1.
The RSVP protocol is then used to pass 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 program applies daemon communicates with a local decision procedure,
called "admission control", to determine if it can supply the

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

Internet Draft RSVP Specification July November 1995

module, called "admission control", to determine if the router can
supply the requested QoS. If the admission control check succeeds,
the RSVP program daemon sets parameters to in the packet classifier and
scheduler to obtain the desired QoS. If the admission control fails at any node, check
fails, the RSVP program immediately returns an error indication 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 will be constantly changing, and the RSVP design assumes that router 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, in addition routers. That is, RSVP sends periodic refresh messages to receiver-initiation.
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 application; see Appendix
A). A
for more details.

In summary, RSVP has the following attributes:

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

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

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

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

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

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

Internet Draft RSVP Specification July 1995
services. Section 2 presents an overview of the RSVP protocol
mechanisms, while
mechanisms. Section 3 gives examples of the services and
mechanism. Section 4 contains the functional specification of RSVP. RSVP,
while Section 5 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

The set of

RSVP defines a "session" as a data flows flow with the same unicast or multicast
destination constitute a session. RSVP treats each session
independently. All data packets in particular
destination and transport-layer protocol. The destination for a
particular session are
directed to is generally defined by DestAddress, the same IP
destination address DestAddress, of the data packets, and perhaps to by DstPort, a
" generalized destination port", i.e., some further demultiplexing
point defined in a higher
layer (transport the transport or application). We refer to application protocol layer. RSVP treats
each session independently, and this document often assumes the latter as a
"generalized destination port".
qualification "for the same session".

DestAddress is the a group address for multicast delivery, delivery or the
unicast address of a single receiver. A generalized destination
port 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 for greater generality, the present version uses supports
only UDP/TCP ports as generalized ports.

Figure 2 illustrates the flow of data packets in a single RSVP
session,
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
the
multicast routing protocol. 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 correspond to be running in a unique Internet host, or a
single host may contain multiple logical senders and/or receivers,
distinguished by generalized 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

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

Internet Draft RSVP Specification July 1995

Even if the destination address is unicast,

For unicast transmission, there may will be multiple
receivers, distinguished by the generalized port. There a single destination host
but there may also be multiple senders for a unicast destination, i.e., senders; RSVP can set up reservations
for multipoint-to-point 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
spec, together with the DestAddress and the generalized
destination port defining the session) defines session definition, specifies 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 the QoS occurs at the place where the
data enters the medium, i.e., at the upstream end of the link,
although the 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.

The flowspec in a reservation request will generally include a
service type class and two sets of numeric parameters: (1) an "Rspec"
(R for `reserve'), which `reserve') that defines the desired per-hop reservation, QoS, and (2) a "Tspec"
(T for `traffic'), which defines the parameters `traffic') that
may be used to police describes the data flow, i.e., to ensure it does not
exceed its promised traffic level. flow. The form 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 delivers the Tspec and Rspec, together with an
indication whether traffic policing is needed to Specification November 1995

In the admission
control and packet scheduling components most general approach [RSVP93], filter specs may select
arbitrary subsets of traffic control. A
service that requires traffic policing might for example apply it
at the edge packets in a given session. Such subsets
might be defined in terms of the network and at data merge points; RSVP knows
when these occur and must so indicate to the traffic control
mechanism. On the other hand, RSVP cannot interpret the service
embodied in the flowspec and therefore does not know whether
policing will actually be applied in a particular case.

In the general RSVP reservation model [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 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

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

Internet Draft RSVP Specification July 1995 the
interest of simplicity (and to minimize layer violation), the
present RSVP version uses a much more restricted form of filter
spec: select only on
spec, consisting of sender IP address, on UDP/TCP port number,
and perhaps on IP protocol id.

RSVP can distinguish subflows of a hierarchically-encoded signal
if they are assigned distinct multicast destination addresses, or,
for a unicast destination, distinct destination ports. Data
packets that are addressed to a particular session but do not
match any of the filter specs for that session are expected to be
sent as best-effort traffic, and under congested conditions, such
packets are likely to experience long delays, address and they may be
dropped. When a receiver does not wish to receive a particular
(sub-)flow, it can economize on network resources by explicitly
asking the network to drop unneeded the data packets; it does so
by leaving the multicast group(s) to which these packets are
addressed. Thus, determining where packets get delivered should
be a routing function; RSVP is concerned only with optionally the QoS of
those packets that are delivered by routing. UDP/TCP
port number SrcPort.

RSVP reservation request messages originate at receivers and are
passed upstream towards the sender(s). (This document defines the
directional terms "upstream" vs. "downstream", "previous hop" vs.
"next hop", and "incoming interface" vs "outgoing interface" with
respect to the data flow direction.) When an elementary a reservation request
is received at a node, the RSVP daemon takes two primary actions: general actions are taken.

1. Daemon makes Make a reservation

The flowspec and the filter spec are passed to traffic
control. Admission control determines the admissibility of
the request (if it's new); if this test fails, the
reservation is rejected and RSVP returns an error message to
the appropriate receiver(s). If admission control succeeds,
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. Daemon forwards Forward the reservation 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, received from downstream, for two
reasons. First, it is

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

Internet Draft RSVP Specification July 1995 possible (in theory) in theory for the traffic control
mechanism to modify the flowspec hop-by-hop, although none of the
currently no realtime defined services
do this. does so. Second, reservations for the
same sender, or the same set of senders, from different downstream
branches of the multicast distribution tree(s) must be are "merged" as reservations
travel upstream. Merging reservations is upstream; that is, a necessary
consequence of multicast distribution, which creates node forwards upstream only the
reservation request with the "maximum" flowspec.

When a single
stream of data packets in receiver originates a particular router from any Si,
regardless of the set of receivers downstream. The reservation
for Si on request, it can also
request a particular outgoing link L should be confirmation message to indicate that its request was
(probably) installed in the "maximum" 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) along the sink
tree to the sender(s) where there is an existing reservation level
equal or greater than that being requested. At that point, the
arriving request will be dropped in favor of the individual flowspecs from equal or larger
reservation in place; the receivers Rj node may then send a reservation
confirmation message back to the receiver. Note that are downstream
via link L. Merging the receipt
of a confirmation is discussed further only a high-probability indication, not a
guarantee that the requested service is in place all the way to
the sender(s), as explained in Section 2.2. 2.6.

The basic RSVP reservation model is "one pass": a receiver sends a
reservation request upstream, and each node in the path can only
accept either
accepts or reject rejects the request. This scheme provides no easy way
for a receiver to make
end-to-end service guarantees, since find out the QoS request must be
applied independently at each hop. resulting end-to-end service.
Therefore, RSVP also supports an optional
reservation model, enhancement to one-pass service known
as "One Pass With Advertising" (OPWA) [Shenker94]. In With OPWA,
RSVP control packets are sent downstream, following the data
paths, are used to gather information on the
end-to-end service that would result from a variety of possible
reservation requests. may be used to predict the end-
to-end QoS. The results ("advertisements") are delivered by RSVP
to the receiver host, hosts and perhaps to the receiver application. applications.
The information advertisements may then be used by the receiver to construct 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 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" among all packets of selected
senders.

Another option controls the scope selection of the request: senders: an "explicit" sender specification,
list of all selected senders, or a "wildcard" that implicitly
selects a group of senders. all the senders to the session. In an explicit-style explicit-selection
reservation, the each filter spec must match exactly one sender, while the filter spec
in a wildcard reservation must match at least one sender but may
match any number. wildcard-selection no filter spec is needed.

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

Internet Draft RSVP Specification July November 1995

Sender || Reservations:
Scope
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" reservation scope. sender selection. Thus, a WF-style reservation
creates a single reservation into which flows from all
upstream senders are mixed; this reservation may be thought
of as a shared "pipe", whose "size" is the largest of the
resource requests for that link from all receivers, independent of the
number of senders using it. A WF-style reservation has wildcard scope, i.e., the reservation is
propagated upstream towards all sender hosts. A WF-style
reservation 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" reservation scope. sender selection. Thus, an elementary FF-style
reservation request creates a distinct reservation for data
packets from a particular sender, not sharing them with other
senders' packets for the same session. It scope is
determined by an explicit list of senders.

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
necessarily be merged
to share a single reservation.

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

FF( S{Q})

where S is the selected sender and Q is the corresponding
flowspec; the pair forms a
given node.

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

Internet Draft flow descriptor. RSVP Specification July 1995

3. 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" reservation scope. sender selection. Thus, an SE-style reservation
creates a single reservation into which flows from all
upstream senders are mixed. However, like a FF reservation
the set of senders (and therefore its scope (and therefore the scope) is specified explicitly by FF style, the
SE style allows a receiver making to explicitly specify the
reservation.

WF and set of
senders.

Symbolically, we can represent an SE are both shared reservations, appropriate 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 shared reservations, appropriate for those
multicast applications whose application-specific constraints make
it unlikely that multiple data sources will transmit
simultaneously. One example is Packetized audio conferencing, where is an example of an application
suitable for shared reservations; since a limited number of people
talk at once; once, each receiver might issue a WF or SE reservation
request for twice the bandwidth required for one audio channel sender (to allow
some over-speaking). On the other hand, the FF style, which
creates independent reservations for the flows from different
senders, is appropriate for video signals.

It is not possible to merge

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. Therefore, WF and SE styles are incompatible with
FF, but reservations, since these modes are compatible with each other. Merging a WF style
reservation fundamentally
incompatible. They also disallow merging explict sender selection
with wildcard sender selection, since this might produce an SE style reservation results in
unexpected service for a WF
reservation. receiver that specified explicit
selection. As a result of these prohibitions, WF, SE, and FF
styles are all mutually incompatible.

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

2. RSVP Protocol Mechanisms

2.1 RSVP Messages

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

Each receiver host sends RSVP reservation request (RESV) messages
towards

1.4 Examples of Styles

This section presents examples of each of the senders. These reservation messages must follow in
reverse the routes styles
and show the effects of merging.

Figure 4 shows schematically a router with two incoming interfaces
through which data streams will arrive, labeled (a) and (b), and
two outgoing interfaces through which data packets will use, all the way upstream
to the sender hosts included in the scope. RESV messages must be
delivered to the sender hosts so that the hosts can set up
appropriate traffic control parameters for forwarded,
labeled (c) and (d). This topology will be assumed in the first hop.

Also note
examples that RSVP sends no positive acknowledgment messages to
indicate success (although 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 delivery two routers D and D' in
Figure 9. This illustrates the effect of a reservation request
to non-RSVP cloud or a sender could be used
broadcast LAN on interface (d).

In addition to trigger an acknowledgement at a
higher level of protocol.) 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
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: January May 1996 [Page 12] 14]

Internet Draft RSVP Specification July November 1995

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

Figure 4: RSVP Messages

Each sender transmits

For simplicity, these examples show flowspecs as one-dimensional
multiples of some base resource quantity B. The "Receive" column
shows the RSVP PATH messages forward along reservation requests received over outgoing
interfaces (c) and (d), and the uni-
/multicast routes provided by "Reserve" column shows the routing protocol(s); see Figure
4. These "Path" messages store path
resulting reservation state in for each node. Path
state is used by RSVP to route the RESV messages hop-by-hop in the
reverse direction. (In interface. The "Send"
column shows the future, some routing protocols may
supply reverse path forwarding information directly, replacing reservation requests that are sent upstream to
previous hops (a) and (b). In the
reverse-routing function of path state).

PATH messages may also carry "Reserve" column, each box
represents one reserved "pipe" on the following information:

o Sender Template

The Sender Template describes outgoing link, with the format of data packets that
corresponding flow descriptor.

Figure 5, showing the sender will originate. This template is in WF style, illustrates the form two possible
merging situations. Each of a
filter spec that could be used to select this sender's
packets from others in the same session two next hops on the same link.

Like interface (d)
results in a filter spec, separate RSVP reservation request, as shown. These
two requests are merged into the Sender Template effective flowspec 3B, which is less than fully
general at present, specifying only sender IP address,
UDP/TCP sender port, and protocol id. The port number
and/or protocol id can be wildcarded.

o Tspec

PATH message may optionally carry a Tspec that defines an
upper bound on the traffic level that the sender will
generate. This Tspec can be
used by RSVP to prevent over- make the reservation (and perhaps unnecessary Admission Control
failure) on interface (d). To forward the non-shared links starting at
reservation requests upstream, the sender.

o Adspec

The PATH message may carry a package of OPWA advertising
information, known reservations on the interfaces
(c) and (d) are merged; as an "Adspec". An Adspec received in a
PATH message result, the larger flowspec 4B is passed
forwarded upstream to each previous hop.

|
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 local traffic control routines,
which return an updated Adspec; the updated version 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: January May 1996 [Page 13] 15]

Internet Draft RSVP Specification July November 1995

forwarded downstream.

Previous Incoming Outgoing Next
Hops Interfaces Interfaces Hops

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

|
Send | <-- Resv |_____|
Path --> Reserve Receive
|
| Path --> _____
_____ ________
FF( S1{4B} ) <- (a) | ROUTER (c) | S1{4B} | (c) <- FF( S1{4B}, S2{5B} )
| |________|
| | S2{5B} |
| |________|
---------------------|---------------------------------------------
| ________
<- (b) | |--| D (d) | S1{3B} | B |--| data-->| (d) <- FF( S1{3B}, S3{B} )
FF( S2{5B}, S3{B} ) | data --> |________| <- FF( S1{B} )
| |_____|
|_____| |--------| b d |-----------|
|<-- Resv| | <-- Resv S3{B} | _____
_____
| Path-->|_____________________| Path --> |________|

Figure 6: Fixed-Filter (FF) Reservation Example

Figure 7 shows an example of Shared-Explicit (SE) style
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) | |--| D' (c) <- SE( (S1,S2){B} )
| | B' |--| {B} | |_____|
|_____|
| |________|
---------------------|---------------------------------------------
| __________
<- (b) | (d) |(S1,S2,S3)| (d) <- SE( (S1,S3){3B} )
SE( (S2,S3){3B} ) | | {3B} | <- SE( S2{2B} )
| |__________|

Figure 5: Router Using RSVP

Figure 5 illustrates RSVP's model of a router node. Each 7: Shared-Explicit (SE) Reservation Example

The three examples just shown assume that data
stream arrives packets from a previous hop through a corresponding
incoming interface S1,
S2, and departs through one or more outgoing
interface(s). The same physical interface may act in S3 are routed to both the
incoming and outgoing roles (for different data flows but the same
session).

As illustrated in interfaces. The top part
of Figure 5, there may be multiple previous hops
and/or next hops through a given physical interface. This may
result 8 shows another routing assumption: data packets from S2
and S3 are not forwarded to interface (c), e.g., because the connected
network being topology provides a shared medium or from
the existence of non-RSVP routers in the 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 next RSVP hop
(see Section 2.6). An RSVP daemon must preserve the next and
previous hop addresses in its reservation and path state,
respectively. A RESV message is sent with a unicast destination
address, the address of a previous hop. PATH messages, on the
other hand, are sent with the session destination address, unicast
or multicast.

Although multiple next hops may send reservation requests through
the same physical interface, forwarded out interface (b)
considers only the final effect should be to install
a reservation on that interface, which is defined by an effective
flowspec. This effective flowspec will be the "maximum" of the
flowspecs requested by the different next hops. In turn, a RESV interface (d).

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

Router Configuration

|
Send | Reserve Receive
|
| _______
WF( *{rB} ) <- (a) | (c) | * {B} | (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: January May 1996 [Page 14] 17]

Internet Draft RSVP Specification July November 1995

message forwarded to a particular previous hop carries

2. RSVP Protocol Mechanisms

2.1 RSVP Messages

Previous Incoming Outgoing Next
Hops Interfaces Interfaces Hops

_____ _____________________ _____
| | data --> | | data --> | |
| A |-----------| a flowspec
that is the "maximum" over the effective reservations on the
corresponding outgoing interfaces. Both cases represent merging,
which is discussed further below.

There are a number 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 ways for a syntactically valid reservation
request to fail in router node. Each data
stream arrives from a given node:

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

2. Administrative policy "previous hop" through a corresponding
"incoming interface" and departs through one or control more "outgoing
interface(s)". The same physical interface may prevent act in both the requested
reservation.

3. There may be no matching path state (i.e.,
incoming and outgoing roles for different data flows in the scope same
session. Multiple previous hops and/or next hops may be
empty), which would prevent reached
through a given physical interface, as a result of the reservation connected
network being propagated
upstream.

4. A reservation style that requires a unique sender may have a
filter spec that matches more than one sender shared medium, or the existence of non-RSVP
routers in the path
state, due to the use of wildcards.

5. The requested style may be incompatible with the style(s) of
existing reservations for the same session on the same
outgoing interface, so an effective flowspec cannot be
computed.

6. The requested style may be incompatible with the style(s) of
reservations that exist on other outgoing interfaces but will
be merged with this reservation to create a refresh message
for next RSVP hop (see Section 2.8). An
RSVP daemon preserves the next and previous hop.

In any of these cases, an error hop addresses in its
reservation and path state, respectively.

There are two fundamental RSVP message is returned to the
receiver(s) responsible for types: RESV and PATH.

Each receiver host sends RSVP reservation request (RESV) messages
upstream towards the erroneous message. An error
message does not modify state in senders. These reservation messages must
follow exactly the nodes through which it
passes. Therefore, any reservations established downstream reverse of the
node where routes the failure was detected data packets will persist until the
receiver(s) responsible cease attempting
use, upstream to all the reservation.

The erroneous message may or may not be propagated forward. In
general, if sender hosts included in the error is likely to sender
selection. RESV messages must be repeated at every node
further along the path, it is best delivered to drop the erroneous message
rather than generate a flood of error messages; this is sender hosts
themselves so that the case hosts can set up appropriate traffic
control parameters for the last four error classes listed above. The first two error
classes, admission control and administrative policy, may or may
not allow propagation of the message, depending upon the detailed
reason and perhaps on local administrative policy and/or the
particular service request. More complete rules are given in the hop.

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

Internet Draft RSVP Specification July November 1995

error definitions in Appendix B.

An erroneous FILTER_SPEC object in a RESV message will normally be
detected at the first

Each RSVP hop from the receiver application,
i.e., within sender host transmits RSVP PATH messages downstream
along the receiver host. However, an admission control
failure caused uni-/multicast routes provided by a FLOWSPEC or a POLICY_DATA object may be
detected anywhere along the path(s) to routing
protocol(s), following the sender(s).

When admission control fails for a reservation request, any
existing reservation is left paths of the data. These "Path"
messages store " path state" in place. each node along the way. This prevents a new, very
large, reservation from disrupting
path state includes at least the existing QoS by merging
with an existing reservation and then failing admission control
(this has been called unicast IP address of the "killer reservation" problem).

A node may be allowed to preempt an established reservation, in
accordance with administrative policy; this will also trigger an
error message to all affected receivers.

2.2 Merging and Packing

A
previous section explained that reservation requests in hop node, which is used to route the RESV messages are necessarily merged, to match hop-
by-hop in the multicast
distribution tree. As a result, only reverse direction. (In the essential (i.e., future, some routing
protocols may supply reverse path forwarding information directly,
replacing the
"largest") reservation requests are forwarded, once per refresh
period. reverse-routing function of path state).

A successful reservation request will propagate as far as
the closest point(s) along PATH message may carry the sink tree following information in addition to
the sender(s) where previous hop address:

o Sender Template

A PATH message is required to carry a
reservation level equal or greater than that being requested has
been made. At Sender Template, which
describes the format of data packets that point, the merging process sender will drop it
originate. This template is in
favor the form of another, equal or larger, reservation request. 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 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.

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

For protocol efficiency, RSVP also allows multiple sets of path
(or reservation)
reservation information for the same session to be "packed" into a
single PATH (or RESV) message, respectively. (For 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 message). Unlike merging, packing
preserves information.

In order to merge reservations, Specification November 1995

RSVP must be able to merge
flowspecs message.

PATH messages are sent with the same source and to merge filterspecs. Merging flowspecs requires
calculating destination
addresses as the data, so that they will be routed correctly
through non-RSVP clouds (see Section 2.8). On the "largest" of a set of flowspecs, which other hand,
RESV messages are
otherwise opaque to RSVP. Merging flowspecs is required both sent hop-by-hop; each RSVP-speaking node
forwards a RESV message to
calculate the effective flowspec to install on unicast address of a given physical
interface (see previous RSVP
hop.

2.2 Port Usage

At present an RSVP session is defined by the discussion in connection with Figure 5), and to
merge flowspecs when sending triple: (DestAddress,
ProtocolId, DstPort). Here DstPort is a refresh message upstream. Since
flowspecs are generally multi-dimensional vectors (they contain
both Tspec and Rspec components, each of which UDP/TCP destination port
field (i.e., a 16-bit quantity carried at octet offset +2 in the
transport header). DstPort may itself be
multi-dimensional), they are omitted (set to zero) if the
ProtocolId specifies a protocol that does not strictly ordered. When it cannot
take have a destination
port field in the larger format used by UDP and TCP.

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

o specifies a

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

Internet Draft RSVP Specification July 1995

third flowspec non-zero DstPort for a protocol that is at least as large as each, i.e., does not
have UDP/TCP-like ports, or

o specifies a "least
upper bound" (LUB). It is also possible zero DstPort for two flowspecs to be
incomparable, which is treated as an error. The definition a protocol that does have
UDP/TCP-like ports.

Filter specs and
implementation of the rules for comparing flowspecs are outside
RSVP proper, but they sender templates are defined as part of the service templates
[ServTempl95a]

We can now give the complete rules for calculating by the effective
flowspec (Te, Re), to be installed on an interface. Here Te is
the effective Tspec and Re 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 effective Rspec. As an example,
consider interface (d)
transport header). SrcPort may be omitted (set to zero) in Figure 5.

o Re is calculated as
certain cases. The following rules hold for the largest (using an LUB if necessary) use of the Rspecs zero
DstPort and/or SrcPort fields in RESV messages from different next hops
(e.g., D and D') but RSVP.

1. Destination ports must be consistent.

Path state and/or reservation state for the same outgoing interface (d).

o The Tspecs supplied in PATH messages from different previous
hops which may send data packets to this reservation (e.g.,
some DestAddress
and ProtocolId must have DstPort values that are all zero or
all non-zero. Violation of A, B, and B' in Figure 5) are summed; call this sum Path_Te.

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

o Te a
"Conflicting Dest Port" error.

2. Destination ports rule.

If DstPort in a session definition is the GLB (greatest lower bound) of Path_Te and Resv_Te.
For Tspecs defined by token bucket parameters, this means to
take the smaller of the bucket size and the rate parameters.

Two filter specs can zero, all SrcPort
fields used for that session must also be merged only they are identical or if one
contains the other through wild-carding. zero. The result

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

Internet Draft RSVP Specification November 1995

assumption here is that the more
general protocol does not have TCP/UDP-
like ports. Violation of the two, i.e., the one with more wildcard fields.

2.3 Soft State

To maintain reservation state, RSVP keeps "soft state" this condition in router
and a node is a
"Conflicting Src Port" error.

3. Source Ports must be consistent.

A sender host nodes. RSVP soft must not send path state is created and periodically
refreshed by PATH both with and RESV messages. The state is deleted if no
matching refresh messages arrive before the expiration of without
a
"cleanup timeout" interval. It may also be deleted as the result zero SrcPort. Violation of this condition is an explicit "teardown" message, described in the next section.
At the expiration of each "refresh timeout" period, RSVP scans its
state to build and forward PATH and RESV refresh messages to
succeeding hops.

When "Ambiguous
Path" error.

2.3 Merging Flowspecs

As noted earlier, a route changes, the single physical interface may receive multiple
reservation request from different next PATH message will initialize the
path state on hops for the new route, same session
and future RESV messages will
establish reservation state there; with the state same filter spec, but RSVP should install only one
reservation on that interface. This reservation should an
effective flowspec that is the now-unused
segment "maximum" of the route will time out. Thus, whether flowspecs
requested by the different next hops. Similarly, a RESV message is

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

Internet Draft RSVP Specification July 1995

"new" or
forwarded to a "refresh" previous hop should carry a flowspec that is determined separately at each node,
depending upon the existence of state at that node.

RSVP sends its messages as IP datagrams without reliability
enhancement. Periodic transmission
"maximum" of refresh messages the flowspecs requested by hosts
and routers is expected to replace any lost RSVP messages. To
tolerate K-1 successive packet losses, the effective cleanup
timeout must be at least K times the refresh timeout. In
addition, the traffic control mechanism in the network should be
statically configured to grant high-reliability service to RSVP
messages, to protect RSVP messages from congestion losses.

The "soft" state maintained by RSVP is dynamic; to change different next hops.
Both cases represent flowspec merging.

Merging flowspecs requires calculating the "largest" of a set of senders Si or receivers Rj or
flowspecs, which are otherwise opaque to change any QoS request, a host
simply starts sending revised PATH and/or RESV messages. The
result should be an appropriate adjustment in the RSVP state RSVP. Since flowspecs
are multi-dimensional vectors (they contain both Tspec and
immediate propagation to all nodes along the path.

In steady state, refreshing is performed hop-by-hop, Rspec
components, each of which allows
merging and packing as described may itself be multi-dimensional),
generally speaking they cannot be strictly ordered. However, in
many cases one can easily determine the previous section. If the
received state differs from "larger" of two flowspecs,
such as when both request the stored state, same bandwidth but one requests a
tighter delay, or when one of the stored state is
updated. Furthermore, if two requests both a higher
bandwidth and a tighter delay bound. When the result will be to modify "larger" of the refresh
messages to two
cannot be generated, these refresh messages determined, RSVP must be generated
and forwarded immediately. This will result in state changes
propagating end-to-end without delay. However, propagation of a
change stops when compute and if it reaches use a point where merging causes
no resulting state change. This minimizes RSVP control traffic
due to changes and third flowspec
that is essential for scaling to at least as large multicast
groups.

The RSVP state associated with a session in as each, i.e., a particular node is
divided into atomic elements that "least upper bound"
(LUB). If the two flowspecs are created, refreshed, and
timed out independently. The atomicity is determined by incomparable, their comparison
will treated as an error.

We can now give the
requirement that any sender or receiver may enter or leave complete rules for calculating the
session at any time, so its state should effective
flowspec (Te, Re) to be created and timed out
independently.

2.4 Teardown

RSVP teardown messages remove path installed on an interface. Here Te is the
effective Tspec and reservation state without
waiting for Re is the cleanup timeout period, as effective Rspec. As an optimization to
release resources quickly. It example,
consider interface (d) in Figure 9.

1. Re is not necessary to explicitly tear
down calculated as the largest (using an old reservation, although it may be desirable LUB if necessary)
of the Rspecs in many
cases.

A teardown request may be initiated either by an application RESV messages from different next hops
(e.g., D and D') but the same outgoing interface (d).

2. All Tspecs that were supplied in an
end system (sender or receiver), PATH messages from different
previous hops (e.g., some or by a router as the result all of
state timeout. Once initiated, a teardown request should be A, B, and B' in Figure 9)
are summed; call this sum Path_Te.

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

Internet Draft RSVP Specification July November 1995

forwarded hop-by-hop without delay.

Teardown

3. The maximum Tspec supplied in RESV messages (like other RSVP messages) are not delivered
reliably. However, loss of a teardown message from different
next hops (e.g., D and D') is calculated; call this Resv_Te.

4. Te is not considered a
problem because the state will time out even if it 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 not
explicitly deleted. If one or more teardown message hops actually performed by traffic control. The
definition and implementation of the rules for comparing
flowspecs, calculating LUB's, and summing Tspecs are
lost, outside the router
definition of RSVP [ServTempl95a]. Section 3.9.4 shows generic
calls that failed to receive an RSVP daemon could use for these functions.

2.4 Soft State

RSVP takes a teardown message will
time out its "soft state" approach to managing the reservation
state in routers and initiate a new teardown message beyond the
loss point. Assuming that hosts. RSVP message loss probability soft state is small,
the longest time to delete created and
periodically refreshed by PATH and RESV messages. The state will seldom exceed one is
deleted if no matching refresh
timeout period.

There are two types messages arrive before the
expiration of RSVP teardown a "cleanup timeout" interval. It may also be
deleted by an explicit "teardown" message, PTEAR and RTEAR. A
PTEAR message travels towards all receivers downstream from its
point described in the next
section. At the expiration of initiation each "refresh timeout" period and deletes path
after a state along the way. A RTEAR
message deletes reservation change, RSVP scans its state to build and travels towards all senders
upstream from its point of initiation. A PTEAR (RTEAR) message
may be conceptualized as a reversed-sense Path message (Resv
message, respectively).

A teardown message deletes the specified state in the node where
it is received. Like any other state change, this will be
propagated immediately forward
PATH and RESV refresh messages to succeeding hops.

PATH and RESV messages are idempotent. When a route changes, the
next node, but only if it represents
a net change after merging. As a result, an RTEAR PATH message will
prune initialize the reservation path state back (only) as far as possible.

2.5 Admission Policy on the new route,
and Security

RSVP-mediated QoS requests future RESV messages will result in particular user(s)
getting preferential access to network resources. To prevent
abuse, some form of back pressure establish reservation state there;
the state on users will be required. This
back pressure might take the form of administrative rules, or of
some form now-unused segment of real or virtual billing for the `cost' of route will time out.
Thus, whether a
reservation. The form and contents of such back pressure message is "new" or a
matter of administrative policy that may be "refresh" is determined
independently by
separately at each administrative domain in node, depending upon the Internet.

Therefore, admission control existing state at each node is likely to contain a
policy component as well that
node.

RSVP sends its messages as a resource reservation component. As
input IP datagrams with no reliability
enhancement. Periodic transmission of refresh messages by hosts
and routers is expected to handle the policy-based admission decision, occasional loss of RSVP messages may
carry policy data. This data may include credentials identifying
users or user classes, account numbers, limits, quotas, etc.

To protect
messages. If the integrity of effective cleanup timeout is set to K times the policy-based admission
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
mechanisms, it may mechanism be necessary statically
configured to ensure the integrity of grant some minimal bandwidth for RSVP messages against corruption or spoofing, hop to
protect them from congestion losses.

The state maintained by hop. For this
purpose, RSVP messages may carry integrity objects that can 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 be
created and verified by neighboring RSVP-capable nodes. These
an appropriate adjustment in the RSVP state in all nodes along the

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

Internet Draft RSVP Specification July November 1995

objects are expected

path.

In steady state, refreshing is performed hop-by-hop to contain an encrypted part and allow
merging. If the received state differs from the stored state, the
stored state is updated. If this update results in modification
of state to assume a
shared secret between neighbors.

User policy data be forwarded in reservation request refresh messages, these refresh
messages presents must be generated and forwarded immediately, so that
state changes can be propagated end-to-end without delay.
However, propagation of a
scaling problem. When 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 group has groups.

State that is received through a large number of
receivers, it will not particular interface I* should
never be possible or desirable to carry all the
receivers' policy data upstream to forwarded out the sender(s). The policy data
will have to same interface. Conversely, state that
is forwarded out interface I* must be administratively merged, near enough to the
receivers to avoid excessive policy data. Administrative merging
implies checking the user credentials and accounting data and then
substituting a token indicating the check has succeeded. A chain
of trust established computed using an integrity field will allow upstream
nodes to accept these tokens.

Note only state
that the merge points 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 policy data this
session. Both receivers are likely to be at making wildcard-scope reservations,
in which the
boundaries of administrative domains. It may be necessary RESV messages are forwarded to
carry accumulated and unmerged policy data upstream through
multiple nodes before reaching one all previous hops for
senders in the group, with the exception of these merge points.

2.6 Automatic RSVP Tunneling

It is impossible to deploy RSVP (or any new protocol) at the same
moment throughout next hop from
which they came. The result is independent reservations in the entire Internet. Furthermore, RSVP may
never be deployed everywhere. RSVP must therefore provide correct
protocol operation even when
two RSVP-capable routers are joined
by directions.

There is an arbitrary "cloud" additional rule governing the forwarding of non-RSVP routers. Of course, an
intermediate cloud that does not support RSVP is unable to perform
resource reservation, so service guarantees cannot be made.
However, if such a cloud has sufficient excess capacity, it may
provide acceptable and useful realtime service.

RSVP will automatically tunnel through such a non-RSVP cloud.
Both RSVP and non-RSVP routers forward PATH messages towards the
destination address using their local uni-/multicast routing
table. Therefore, the routing of PATH messages will be unaffected
by non-RSVP routers in the path. When a PATH message traverses a
non-RSVP cloud, the copies that emerge will carry as a Previous
Hop address the IP address of the last RSVP-capable router before
entering the cloud. This will effectively construct a tunnel
through the cloud for RESV messages, which will
messages: state from RESV messages received from outgoing
interface Io should be forwarded
directly to the next RSVP-capable router on the path(s) back
towards the source.

Automatic tunneling is not perfect; in some circumstances it may
distribute path information to RSVP-capable routers not included
in the data distribution paths, which may create unused
reservations at these routers. This is because incoming interface Ii only if
PATH messages
carry the IP source address of the previous hop, not of the from Ii are forwarded to Io.

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

Internet Draft RSVP Specification July November 1995

original sender, and multicast routing may depend upon the source
as well as the destination address. This can be overcome by
manual configuration of the neighboring RSVP programs, when
necessary.

2.7 Host Model

Before

________________
a session can be created, the session identification,
comprised of DestAddress and perhaps the generalized destination
port, must be assigned and communicated to all the senders and
receivers by some out-of-band mechanism. When an | | 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 session "teardown" messages remove path and reservation
state immediately. Although it is
being set up, the following events happen at the not necessary to explicitly
tear down an old reservation, we recommend that all end systems.

H1 hosts send
a teardown request as soon as an application finishes.

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

H2 way. An
RTEAR message deletes reservation state and travels towards all
senders upstream from its point of initiation. A potential sender starts sending RSVP PATH messages to the
DestAddress, using RSVP.

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

A receiver teardown request may be initiated either by an application receives in an
end system (sender or receiver), or by a PATH message.

H4 A receiver starts sending appropriate RESV messages,
specifying router as the desired flow descriptors, using RSVP.

H5 A sender application receives result of
state timeout. Once initiated, a RESV message.

H6 teardown request must be
forwarded hop-by-hop without delay. A sender starts sending data packets.

There are several synchronization considerations.

o Suppose that a new sender starts sending data (H6) but no
receivers have joined teardown message deletes
the group (H1). Then there specified state in the node where it is received. As always,
this state change will be no
multicast routes beyond the host (or beyond the first RSVP-
capable router) along the path; propagated immediately to the data next node,
but only if there will be dropped at
the first hop until receivers(s) do appear (assuming a
multicast routing protocol that "prunes off" or otherwise
avoids unnecessary paths).

o Suppose that net change after merging. As a new sender starts sending PATH messages (H2)
and immediately starts sending data (H6), and there are
receivers but no RESV messages have reached the sender yet
(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 first RESV
result, an RTEAR message
[H5]; however, receivers that will prune the reservation state back
(only) as far as possible.

Like all other RSVP messages, teardown requests are farther away may not have
reservations in place yet. delivered

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

Internet Draft RSVP Specification July November 1995

o If

reliably. The loss of a receiver starts sending RESV messages (H4) before any
PATH messages have reached it (H3), RSVP teardown request message will return error
messages to not cause a
protocol failure because 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 unused state will eventually time out
even though it is not
defined in this protocol spec, as it may be host system dependent.
However, Section 4.6.1 discusses explicitly deleted. If a teardown message
is lost, the general requirements router that failed to receive that message will time
out its state and
presents initiate a generic API.

3. Examples

We use new teardown message beyond the following notation for 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 RESV message:

1. Wildcard-Filter (WF)

WF( *{Q})

Here "*{Q}" represents
reservation confirmation message RACK.

There are a Flow Descriptor with number of ways for a "wildcard" scope
(choosing all senders) and syntactically valid reservation
request to fail at some node along the path, triggering a RERR
message:

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

2. Fixed-Filter (FF)

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

A list of (sender, flowspec) pairs, i.e., flow descriptors,
packed into a single RESV message. Administrative policy may prevent the requested reservation.

3. Shared Explicit (SE)

SE( (S1,S2,...)Q1, (S3,S4,...)Q2, ...) There may be no matching path state, so that the request
cannot be forwarded towards the sender(s).

4. A list reservation style that requires the explicit selection of shared reservations, each specified by a single
flowspec and
unique sender may have a list of senders.

For simplicity we assume here filter spec that flowspecs are one-dimensional,
defining for example is ambiguous, i.e.,
that matches more than one sender in the average throughput, and state them as a
multiple path state, due to
the use of some unspecified base resource quantity B.

Figure 6 shows schematically a router wildcard fields in the filter spec.

5. The requested style may be incompatible with two previous hops labeled
(a) and (b) and two the style(s) of
existing reservations. The incompatibility may occur among
reservations for the same session on the same outgoing interfaces labeled (c) and (d). This
topology
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 be assumed trigger a RERR message to all affected receivers. An error
message does not modify state in the examples that follow. There are
three upstream senders; packets from sender S1 (S2 and S3) arrive nodes through previous hop (a) ((b), respectively). There are also three which it
passes. Therefore, any reservations established downstream receivers; packets bound for R1 and R2 (R3) are routed via
outgoing interface (c) ((d) respectively). 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.

In this version of RSVP, detection of an error in a reservation

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

Internet Draft RSVP Specification July November 1995

In addition to the connectivity shown in 6, we must

request not only generates a RERR message, it also specify prevents the
multicast routing within this node. Assume first that data packets
(hence, PATH messages)
request from each Si shown in Figure 6 is routed to
both outgoing interfaces. Under this assumption, Figures 7, 8, and 9
illustrate Wildcard-Filter, Fixed-Filter, and Shared-Explicit
reservations, respectively.

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

Figure 6: Router Configuration

In Figure 7, being forwarded further. This may not always be the "Receive" column shows
desirable behavior; for example, a receiver may want a reservation
request to propagate all the RESV messages received
over outgoing interfaces (c) and (d) and way to the "Reserve" column shows sender despite an
admission control failure at a particular link along the resulting reservation state for each interface. The "Send"
column shows path.
However, design of the RESV messages forwarded to previous hops (a) appropriate mechanism has proved difficult,
and
(b). In therefore this version take the "Reserve" column, each box represents one simplest approach.

When admission control fails for a reservation request, any
existing reservation is left in place. This prevents a new, very
large, reservation
"channel", from disrupting the existing QoS by merging
with an existing reservation and then failing admission control
(this has been called the corresponding filter. As "killer reservation" problem).

To request a result of merging, confirmation for its reservation request, a receiver
Rj includes in the RESV message a confirmation-request object
containing its IP address. At each merge point, only the largest
flowspec and any accompanying confirmation-request object is
forwarded upstream upstream. If the reservation request from Rj is equal
to each previous hop.

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

Figure 7: Wildcard-Filter (WF) Reservation Example

Figure 8 shows Fixed-Filter (FF) style reservations. The flow
descriptors for senders S2 or smaller than the reservation in place on a node, its RESV
are not forwarded further, and S3, received if the RESV included an
confirmation-request object, a RACK message is sent back to Rj.
This mechanism has the following consequences:

o A new reservation request with a flowspec larger than any in
place for a session will normally result in either a RERR or
a RACK message back to the receiver from outgoing interfaces
(c) each sender. In
this case, the RACK message will be an end-to-end
confirmation.

o The receipt of a RACK gives no guarantees. Assume the first
two reservation requests from receivers R1 and (d), R2 arrive at
the node where they are packed into merged. R2, whose reservation was
the message forwarded second to previous hop b.
On arrive at that node, may receive a RACK from
that node while R1's request has not yet propagated all the other hand,
way to a matching sender and may still fail. In this case,
R2 will receive a RACK although there is no end-to-end
reservation in place. Furthermore, if the two different flow descriptors for sender S1 flowspecs are merged into
equal, R2 may receive a RACK followed by a RERR. However, if
its flowspec is smaller, R2 will receive only the single message FF( S1{3B} ), which RACK.

o Despite these uncertainties, receipt of a RACK indicates a
high probability that the reservation is sent to in place.

o Finally, note that RERR and/or RACK messages may be lost.

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

Internet Draft RSVP Specification July November 1995

previous hop (a). For each outgoing interface, there is a private
reservation for each source that has been requested, but this private
reservation

2.7 Policy and Security

RSVP-mediated QoS requests will result in particular user(s)
getting preferential access to network resources. To prevent
abuse, some form of back pressure on users is shared among likely to be
required. This back pressure might take the receivers that made form of
administrative rules, or of some form of real or virtual billing
for the request.

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

Figure 8: Fixed-Filter (FF) Reservation Example

Figure 9 shows "cost" of a simple example reservation. The form and contents of Shared-Explicit (SE) style
reservations. Here each outgoing interface has such
back pressure is a single reservation matter of administrative policy that is shared may be
determined independently by each administrative domain in the
Internet.

Therefore, admission control at each node is likely to contain a list
policy component in addition to a resource reservation component.
As input 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 senders.

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

Figure 9: Shared-Explicit (SE) Reservation Example

The three examples just shown assume full routing, i.e., data packets
from S1, S2, the policy-based admission control
mechanisms, it may be necessary to ensure the integrity of RSVP
messages against corruption or spoofing, hop by hop. For this
purpose, RSVP messages may carry integrity objects that can be
created and S3 verified by neighbor RSVP-capable nodes. These
objects are routed expected to both outgoing interfaces. The top

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

Internet Draft RSVP Specification July 1995 contain an encrypted part and to assume a
shared secret between neighbors.

User policy data in reservation request messages presents a
scaling problem. When a multicast group has a large number of Figure 10 shows another routing assumption:
receivers, it will be impossible or undesirable to carry all
receivers' policy data packets
from S1 are not forwarded upstream to interface (d), because the mesh topology
provides a shorter path for S1 -> R3 that does not traverse this
node. sender(s). The bottom of Figure 10 shows WF style reservations under this
assumption. Since there is no route from (a) policy data
will have to (d), the reservation
forwarded out interface (a) considers only be administratively merged at places near the reservation on
interface (c); no
receivers, to avoid excessive policy data. Administrative merging takes place in this case.

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

Router Configuration

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

Figure 10: WF Reservation Example -- Partial Routing

Finally, we note that state that is received through
implies checking the user credentials and accounting data and then
substituting a particular
interface I is never forwarded out token indicating the same interface. Conversely,
state that is forwarded out interface I must be computed check has succeeded. A chain
of trust established using only
state that arrived on interfaces an integrity field will allow upstream
nodes to accept these tokens.

In summary, different from I. A trivial example administrative domain in the Internet may
have different policies regarding their resource usage and
reservation. The role of this rule RSVP is illustrated in Figure 11, which shows a transit
router to carry policy data associated
with one sender and one receiver on each interface (and
assumes one next/previous hop per interface). Interfaces (a) and (c)
are both outgoing and incoming interfaces for this session. Both
receivers are making wildcard-scope reservations, in which reservation to the RESV
messages network as needed. Note that the
merge points for policy data are forwarded likely to all previous hops for senders in the group,
with be at the exception boundaries of the next hop from which they came. These
result in independent reservations in the two directions.

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

Internet Draft RSVP Specification July 1995

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

Figure 11: Independent Reservations
administrative domains. It may be necessary to carry accumulated
and unmerged policy data upstream through multiple nodes before
reaching one of these merge points.

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

Internet Draft RSVP Specification July November 1995

2.8 Automatic RSVP Functional Specification

4.1 Tunneling

It is impossible to deploy RSVP Message Formats

All (or any new protocol) at the same
moment throughout the entire Internet. Furthermore, RSVP messages consist of a common header followed may
never be deployed everywhere. RSVP must therefore provide correct
protocol operation even when two RSVP-capable routers are joined
by a
variable number an arbitrary "cloud" of variable-length typed "objects". The
subsections non-RSVP routers. Of course, an
intermediate cloud that follow define the formats of does not support RSVP is unable to perform
resource reservation. However, if such a cloud has sufficient
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 messages towards the common header,
destination address using their local uni-/multicast routing
table. Therefore, the object structures, and each routing of PATH messages will be unaffected
by non-RSVP routers in the RSVP message types.

For each RSVP path. When a PATH message type, there is traverses a set of rules for the
permissible ordering and choice
non-RSVP cloud, it carries to the next RSVP-capable node the IP
address of object types. These rules are
specified using Backus-Naur Form (BNF) augmented with square
brackets surrounding optional sub-sequences.

4.1.1 Common Header

The fields in the common header are as follows:

Vers: 4 bits

Protocol version number. last RSVP-capable router before entering the cloud.
This is version 1.

Flags: 4 bits

(None defined yet)

Type: 8 bits

1 = PATH

2 = effectively constructs a tunnel through the cloud for RESV

3 = PERR

4 = RERR

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

Internet Draft RSVP Specification July 1995

5 = PTEAR

6 = RTEAR

RSVP Checksum: 16 bits

A standard TCP/UDP checksum over
messages, which can then be forwarded directly to the contents of next RSVP-
capable router on the RSVP
message, with path(s) back towards the checksum field replaced by zero.

RSVP Length: 16 bits

The total length source.

Some interconnection topologies of this RSVP packet in bytes, including
the common header and non-RSVP routers can
cause RESV messages to arrive at the variable-length objects that
follow. If the MF flag is on wrong RSVP-capable node, or
to arrive at the Fragment Offset field
is non-zero, this is the length of wrong interface at the current fragment of
a larger message.

Message ID: 32 bits

A label shared by all fragments of one message from a
given next/previous RSVP hop. correct node. An RSVP implementation
assignes a unique Message ID to each
daemon must be prepared to handle either situation. When a RESV
message it sends.

MF: More Fragments Flag: 1 bit

This flag is arrives, its IP destination address should normally be the low-order bit
address of one of a byte; the seven high-
order bits are reserved. It local interfaces. If so, the reservation
should be made on the addressed interface, even if it is not the
one on for all but which the last
fragment of message arrived. If the destination address does
not match any local interface and the message is not a message.

Fragment Offset: 24 bits

This field gives PATH or
PTEAR, it should be forwarded without further processing by this
node.

2.9 Host Model

Before a session can be created, the byte offset session identification,
comprised of DestAddress and perhaps the fragment in generalized destination
port, must be assigned and communicated to all the
message.

4.1.2 Object Formats

An object consists of one or more 32-bit words with a one-word
header, in senders and
receivers by some out-of-band mechanism. When an RSVP session is
being set up, the following format:

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

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

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

Internet Draft RSVP Specification July November 1995

An object header has the following fields:

Length

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

Class-Num

Identifies the object class; values of this field PATH message.

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

H5 A sender application receives a RESV message.

H6 A sender starts sending data packets.

There are
defined several synchronization considerations.

o H1 and H2 may happen in Appendix A. Each object class has either order.

o Suppose that a name,
which new sender starts sending data (H6) but there
are no multicast routes because no receivers have joined the
group (H1). Then the data will always be capitalized in this document. An
RSVP implementation must recognize dropped at some router
node (which node depends upon the following classes:

NULL

A NULL object has routing protocol) until
receivers(s) appear.

o Suppose that a Class-Num of zero, new sender starts sending PATH messages (H2)
and data (H6) simultaneously, and there are receivers but no
RESV messages have reached the sender yet (e.g., because its C-Type
is ignored. Its length must be
PATH messages have not yet propagated to the receiver(s)).
Then the initial data may arrive at least 4, but can
be any multiple receivers without the
desired QoS. The sender could mitigate this problem by
awaiting arrival of 4. A NULL object the first RESV message (H5); however,
receivers that are farther away may appear
anywhere not have reservations in
place yet.

o If a sequence of objects, and its contents receiver starts sending RESV messages (H4) before
receiving any PATH messages (H3), RSVP will be ignored by return error
messages to the receiver.

SESSION

Contains the IP destination address (DestAddress) and
possibly a generalized destination port,

The receiver may simply choose to define a
specific session ignore such error messages,
or it may avoid them by waiting for the other objects that follow.
Required in every RSVP message.

RSVP_HOP

Carries the IP address of the RSVP-capable node PATH messages before
sending RESV messages. [LZ: should recommend that
sent this message. This document refers to a
RSVP_HOP object as a PHOP ("previous hop") object receiver
wait for
downstream at least PATH messages or as a NHOP ("next hop") object
for upstream messages.

TIME_VALUES

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

STYLE

Defines the reservation style plus style-specific
information that arrive before sending RESV
messages.]

A specific application program interface (API) for RSVP is not a FLOWSPEC or FILTER_SPEC
object,
defined in a RESV message. this protocol spec, as it may be host system dependent.
However, Section 3.9.1 discusses the general requirements and
presen

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

Internet Draft RSVP Specification July November 1995

FLOWSPEC

Defines a desired QoS, in

3. RSVP Functional Specification

3.1 RSVP Message Formats

An RSVP message consists of a RESV message.

FILTER_SPEC

Defines common header followed by a subset variable
number of session data packets variable-length, typed "objects". The subsections that should
receive
follow define the desired QoS (specified by an FLOWSPEC
object), in a RESV message.

SENDER_TEMPLATE

Contains a sender IP address formats of the common header, the object
structures, and perhaps some
additional demultiplexing information to identify a
sender, in each of the RSVP message types.

For each RSVP message type, there is a PATH message.

SENDER_TSPEC

Defines set of rules for the traffic characteristics
permissible choice and ordering of a sender's
data stream, in a PATH message.

ADSPEC

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

ERROR_SPEC

Specifies an error, object types. These rules are
specified using Backus-Naur Form (BNF) augmented with square
brackets surrounding optional sub-sequences.

3.1.1 Common Header

The fields in a PERR or RERR message.

POLICY_DATA

Carries information that will allow a local policy
module to decide whether an associated reservation the common header are as follows:

Vers: 4 bits

Protocol version number. This is
administratively permitted. May appear in a version 1.

Flags: 4 bits

(None defined yet)

Type: 8 bits

1 = PATH or
RESV message.

INTEGRITY

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

SCOPE

An explicit specification of the scope for forwarding
a

2 = RESV message.

3 = PERR

4 = RERR

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

Internet Draft RSVP Specification July November 1995

C-Type

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

The maximum object content length is 65528 bytes. The Class-
Num and C-Type fields (together

5 = PTEAR

6 = RTEAR

7 = RACK

RSVP Checksum: 16 bits

A standard TCP/UDP checksum over the contents of the RSVP
message, with the 'Optional' flag bit)
may be used together as a 16-bit number to define a unique type
for each object. checksum field replaced by zero.

RSVP Length: 16 bits

The high-order bit total length of this RSVP packet in bytes, including
the Class-Num common header and the variable-length objects that
follow. If the MF flag is used to determine what
action a node should take if it does not recognize the Class-
Num of an object. If Class-Num < 128, then the node should
ignore the object but forward it (unmerged). If Class-Num >=
128, the message should be rejected and an "Unknown Object
Class" error returned. Note that merging cannot be performed on unknown object types; as a result, unmerged objects may be
forwarded to or the first node that does know how to merge them.
The scaling limitations that Fragment Offset field
is non-zero, this imposes must be considered
when defining and deploying new object types.

4.1.3 Path Message

PATH messages carry information from senders to receivers along is the paths used by length of the data packets. current fragment of
a larger message.

Send_TTL: 8 bits

The IP destination address TTL value with which the message was sent.

Message ID: 32 bits

A label shared by all fragments of one message from a PATH
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 DestAddress for the session; the
source address is an address of the node that sent the message
(preferably the address low-order bit of a byte; the interface through which it was
sent). The PHOP (i.e., seven high-
order bits are reserved. It is on for all but the RSVP_HOP) object last
fragment of each PATH
message must contain a message.

Fragment Offset: 24 bits

This field gives the address byte offset of the interface through which fragment in the PATH message was sent.

The format
message.

3.1.2 Object Formats

Every object consists of one or more 32-bit words with a PATH message is as follows:

[ <INTEGRITY> ] [ <TIME_VALUES> ]

<sender descriptor list> ::= <empty > one-
word header, in the following format:

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

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

[ <POLICY_DATA> ] [ <ADSPEC> ]

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

Internet Draft RSVP Specification July November 1995

Each sender descriptor defines a sender, and

+-------------+-------------+-------------+-------------+
| |
// (Object contents) //
| |
+-------------+-------------+-------------+-------------+

An object header has the sender
descriptor list allows multiple sender descriptors to following fields:

Length

A 16-bit field containing the total object length in
bytes. Must always be packed
into a PATH message. For each sender in the list, multiple of 4, and at least 4.

Class-Num

Identifies the
SENDER_TEMPLATE object defines the format class; values of data packets; this field are
defined in
addition, a SENDER_TSPEC Appendix A. Each object may specify the traffic flow, class has a
POLICY_DATA name,
which is always capitalized in this document. An RSVP
implementation must recognize the following classes:

NULL

A NULL object may specify user credential and accounting
information, has a Class-Num of zero, and an ADSPEC its C-Type
is ignored. Its length must be at least 4, but can
be any multiple of 4. A NULL object may carry advertising (OPWA)
data.

Each sender host must periodically send PATH message(s)
containing appear
anywhere in a sender descriptor for each its own data stream(s).
Each sender descriptor is forwarded sequence of objects, and replicated as necessary
to follow its contents
will be ignored by the delivery path(s) for a data packet from receiver.

SESSION

Contains the same
sender, finally reaching IP destination address (DestAddress),
the applications on all receivers
(except that it is not looped back IP protocol id, and a generalized destination
port, to define a receiver included specific session for the other
objects that follow. Required in every RSVP message.

RSVP_HOP

Carries the same application process as IP address of the sender).

It is an error to send ambiguous path state, i.e., two or more
Sender Templates RSVP-capable node that are different but overlap, due
sent this message. This document refers to
wildcards. For example, if we represent a Sender Template
RSVP_HOP object as
(IP address, sender port, protocol id and use `*' to represent a wildcard, then each of the following pairs of Sender
Templates would be an error:

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

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

A PATH message received at PHOP ("previous hop") object for
downstream messages or as a node is processed to create path
state NHOP ("next hop") object
for all senders defined upstream messages.

TIME_VALUES

Contains the value for the refresh period R used by SENDER_TEMPLATE objects in
the
sender descriptor list. If present, any POLICY_DATA,
SENDER_TSPEC, creator of the message; see 3.5. Required in

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

Internet Draft RSVP Specification November 1995

every PATH and ADSPEC objects are also saved 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 path
state. If desired QoS (specified by an error is encountered while processing FLOWSPEC
object), in a PATH
message, RESV message.

SENDER_TEMPLATE

Contains a PERR message is sent sender IP address and perhaps some
additional demultiplexing information to all senders implied by the
SENDER_TEMPLATEs.

Periodically, the path state is scanned to create new identify a
sender, in a PATH
messages to be forwarded downstream. A node must independently
compute the route for each sender descriptor being forwarded.
These routes, obtained from uni-/multicast routing, generally
depend upon message.

SENDER_TSPEC

Defines the (sender host address, DestAddress) pairs and
consist traffic characteristics of a list of outgoing interfaces. The descriptors
being forwarded through the same outgoing interface may be
packed into as few sender's
data stream, in a PATH messages as possible. Note that
multicast routing of 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 based on the sender
address(es) from the sender descriptors, not
administratively permitted. May appear in a PATH or
RESV message.

INTEGRITY

Contains cryptographic data to authenticate the IP source
address; this is necessary
originating node, and perhaps to prevent routing loops; see
Section 4.3. verify the contents,

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

Internet Draft RSVP Specification July November 1995

Multicast routing may also report the expected incoming
interface (i.e., the shortest path back to the sender). If so,
any PATH message that arrives on a different interface should
be discarded immediately.

It is possible that routing will report no routes for a
(sender, DestAddress) pair; path state for

of this RSVP message.

SCOPE

An explicit list of sender should
be stored locally but not forwarded.

4.1.4 Resv Messages

RESV messages carry reservation requests hop-by-hop from
receivers hosts towards which to senders, along the reverse paths of data flow for
forward a message. May appear in a RESV, RERR, or
RTEAR message.

RESV_CONFIRM

Carries the session. The IP destination address of a receiver that requested a
confirmation. May appear in a RESV message 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 of the unicast address Class-Num is used to determine what
action a node should take if it does not recognize the Class-
Num of an object; see Section 3.8.

3.1.3 Path Message

Each sender host periodically sends a previous-hop node, obtained PATH message containing a
description of each data stream it originates. The PATH
message travels from a sender to receiver(s) along the
path state. same
path(s) used by the data packets. The IP source address of a
PATH message is an address of the node sender it describes, while
the destination address is the DestAddress for the session.
These addresses assure that sent the message. 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 NHOP (i.e., node then
forwards the RSVP_HOP) object
must contain PATH messages towards the receiver(s), replicating
it as dictated by multicast routing, while preserving the
original IP address of source address. PATH messages eventually reach the (incoming) interface through
which
applications on all receivers; however, they are not looped
back to a receiver running in the RESV message is sent. same application process as
the sender.

The RESV message format of a PATH message is as follows:

<Resv

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

Internet Draft RSVP Specification November 1995

[ <INTEGRITY> ] [ <TIME_VALUES> ]

[ <S_POLICY_DATA> <POLICY_DATA> ] [ <SCOPE> <ADSPEC> ]

<S_POLICY_DATA> ::= <POLICY DATA>

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

Here

The PHOP (i.e., the S_POLICY_DATA object is a POLICY_DATA RSVP_HOP) object that is
associated with of each PATH message
contains the session, i.e., with all address of the flows that may
be listed. There may also be flow-specific POLICY_DATA
objects, as described below. interface through which the PATH
message was most recently sent. The BNF above SENDER_TEMPLATE object
defines a flow descriptor list as simply a list the format of flow descriptors. The following style-dependent rules
specify more exactly data packets from this sender, while the composition
SENDER_TSPEC object specifies the traffic characteristics of a valid flow descriptor
list.

o WF Style:

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

Internet Draft RSVP Specification July 1995

<WF flow descriptor> ::=

<F_POLICY_DATA> ::= <POLICY_DATA>

o FF style:

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

<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
the flow. Optionally, there may be packed into the flow descriptor list of a single
RESV message. A FLOWSPEC or POLICY_DATA object can be
omitted if it
specifying user credential and accounting information and/or an
ADSPEC object carrying advertising (OPWA) data.

A PATH message received at a node is identical processed to create path
state for the most recent such object
that appeared in sender defined by the list.

o SE style:

| <flow descriptor list> <SE flow descriptor>

<SE flow descriptor> ::=

| <filter spec list> <FILTER_SPEC>

Each elementary SE style request SENDER_TEMPLATE and SESSION
objects. Any POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are
also saved in the path state. If an error is defined by encountered while
processing a single SE
descriptor, which includes PATH message, a FLOWSPEC defining PERR message is sent to the shared
reservation, possibly a POLICY_DATA object, and a list
originating sender of
FILTER_SPEC objects. Multiple elementary requests, each
representing an independent shared reservation, may be
packed into the flow descriptor list of a single RESV PATH message. A POLICY_DATA object may be omitted if it is

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

Internet Draft PATH messages must
satisfy the rules on SrcPort and DstPort in Section 2.2.

Periodically, the RSVP Specification July 1995

identical 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 most recent such object that appeared in appropriate uni-/multicast routing daemon.
The route depends upon the list. session DestAddress, and for some
routing protocols also upon the source (sender's IP) address.
The reservation scope, i.e., routing information generally includes the set list of sender hosts towards none or
more outgoing interfaces to which a particular reservation is the PATH message to be forwarded, is
determined as follows:

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

o For a style with wildcard scope, a SCOPE object, if
present, defines the scope with an explicit list of sender different IP addresses (see Section 4.3 below). If there is no
SCOPE object, the scope is determined by the relevant set
of senders in
address, the path state. A SCOPE object must be PATH messages sent
in out different interfaces
contain different PHOP addresses. In addition, any wildcard scope RESV message that is forwarded to
more than one previous hop. See Section 4.3 below.

4.1.5 Error Messages

There are two types of RSVP error messages.

o PERR messages result from 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 travel towards
senders. PERR messages are routed hop-by-hop using
MOSPF) also keep track of the
path state; at expected incoming interface for
each hop, the IP destination address source host to a multicast group. Whenever this
information is available, RSVP should check the
unicast address incoming
interface of a previous hop.

o RERR each PATH message and immediately discard those

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

Internet Draft RSVP Specification November 1995

messages result from that have arrived on the wrong interface.

3.1.4 Resv Messages

RESV messages and travel towards
the appropriate receivers. They are routed carry reservation requests hop-by-hop
using from
receivers to senders, along the reservation state; at each hop, reverse paths of data flows for
the session. The IP destination address of a RESV message is
the unicast address of a next-hop
node.

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

<PathErr message> 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:

[ <INTEGRITY> ] <ERROR_SPEC>

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

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

Internet Draft RSVP Specification July 1995

[ <INTEGRITY> <S_POLICY_DATA> ]

[ <RESV_CONFIRM> ] [ <SCOPE> ] [S_POLICY_DATA]

<ERROR_SPEC>

<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
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 objects, as described below.

The BNF above defines a flow descriptor list as simply a list
of flow descriptors. The following style-dependent rules define
specify in more detail the composition of a valid error flow
descriptor in terms list for each of sequences defined
earlier: the reservation styles.

o WF Style:

<error

<flow descriptor list> ::= <WF flow descriptor> ::=

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:

<error

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

o SE style:

<error

<First FF flow descriptor> ::= <SE

POLICY_DATA objects need be included in error messages only for
information when they are relevant (i.e., when an
administrative failure ::=

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

Each elementary FF style request is being reported).

The ERROR_SPEC object specifies the error defined by a single
(FLOWSPEC, FILTER_SPEC) pair, and includes multiple such requests
may be packed into the IP
address flow descriptor list of a single
RESV message. A FLOWSPEC object can be omitted if it is
identical to the node most recent such object that detected appeared in
the error (Error Node
Address).

When list; the first FF flow descriptor must contain a PATH or RESV message has been "packed" with multiple
sets of
FLOWSPEC.

o SE style:

<SE flow descriptor> ::=

| <filter spec list> <FILTER_SPEC>

Each elementary parameters, SE style request is defined by a single SE
descriptor, which includes a FLOWSPEC defining the RSVP implementation should
process each set independently shared
reservation, optionally a POLICY_DATA object, and return a separate error
message for each that is in error.

In general, error messages should be delivered to the
applications on all list
of FILTER_SPEC objects.

The reservation scope, i.e., the session nodes that (may have)
contributed to this error. A PERR message is forwarded to all
previous hops for all set of senders listed in the Sender Descriptor
List. A RERR message is generally forwarded towards all
receivers that may have caused the error being reported. More
specifically: which a

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

Internet Draft RSVP Specification July November 1995

o The node that detects an error in a

particular reservation request
creates and sends an RERR message is to be forwarded, is determined as
follows:

o Explicit sender selection

Match each FILTER_SPEC object against the next hop from
which the erroneous reservation came.

The message must contain the information required to
define the error and path state
created from SENDER_TEMPLATE objects to route the error message. Routing
requires at least select a
particular sender. An ambiguous match, i.e., a STYLE object and one or more
FILTER_SPEC object(s) from the erroneous RESV message.
For matching more than one SENDER_TEMPLATE (e.g.
through use of a wildcard port), is an admission control failure, for example, error. Any SCOPE
object associated with the
erroneous FLOWSPEC must reservation should be included. ignored
in this case.

o Succeeding nodes forward the RERR message using their
local reservation state, Wildcard sender selection

All senders that route to the next hops of reservations
that given outgoing interface
match the FILTER_SPEC(s) in the message. For
reservations with wildcard scope, this request. A SCOPE object, if present, contains
an explicit list of sender IP addresses. If there is an additional
limitation on forwarding RERR messages, to avoid loops;
see Section 4.3.

When no
SCOPE object, the error is an admission control failure, a node scope is
allowed (but not required) to match the FLOWSPEC as well as the
FILTER_SPEC object(s), to limit determined by the distribution relevant set
of a RERR
message to those receivers that `caused' senders in the error. Suppose
that path state. Whenever a RERR RESV message contains a FLOWSPEC Qerr that
with wildcard sender selection is being
matched against the FLOWSPEC Qlocal forwarded to more than
one previous hop, a SCOPE object must be included in the local reservation
state in node N. Qerr, which originated in a node upstream
from N, resulted from merging
message. See Section 3.3 below.

3.1.5 Error and Confirmation Messages

There are three types of flowspecs that included
Qlocal. Generally, a RERR message can be forwarded to RSVP error/confirmation messages.

o PERR messages result from PATH messages and travel towards
senders. PERR messages are routed hop-by-hop using the
receiver(s) that specified
path state; at each hop, the `biggest' flowspec. The
comparison IP destination address is the
unicast address of Qerr against a particular Qlocal to determine
whether Qlocal qualifies as (one of) previous hop.

o RERR messages result from RESV messages and travel towards
the `biggest', may be
called `de-merging'. As with merging, appropriate receivers. They are routed hop-by-hop
using the details of de-
merging depend upon reservation state; at each hop, the service and IP
destination address is the FLOWSPEC format, and unicast address of a next-hop
node.

o RACK messages are outside RSVP itself. sent to (probabilistically) acknowledge
reservation requests. A RERR RACK message that is forwarded should carry the FILTER_SPEC
from sent as the corresponding reservation state (thus `un-merging'
result of the
filter spec).

When appearance of a RERR message reaches RESV_CONFIRM object in a receiver, the STYLE object, flow
descriptor list,
RESV message, and ERROR_SPEC object (which contains the
LUB-Used flag) should be delivered a copy of that RESV_CONFIRM.
The RACK message is sent to the receiver application.
In the case unicast address of an Admission Control error, the flow descriptor
list will contain a
receiver host; the FLOWSPEC object that failed. If address is obtained from the
LUB-Used flag
RESV_CONFIRM object. A RACK message is off, this should be `equal' forwarded to (but not
necessarily identical to) the FLOWSPEC originated
receiver hop-by-hop by this
application; otherwise, they may differ. (to accommodate the hop-by-hop
integrity check mechanism).

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

Internet Draft RSVP Specification July November 1995

4.1.6 Teardown Messages

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

o A PTEAR message deletes path state (which may, in turn,
delete reservation state) and travels towards all
receivers that are downstream from

Errors encountered while processing error messages must cause
the point of
initiation. A PTEAR error message is routed like a PATH
message, and its IP destination address is DestAddress for to be discarded without creating further
error messages; however, logging of such events may be useful.

None of these messages modify the session.

o A RTEAR message deletes reservation state and travels
towards all matching senders upstream from the point of
teardown initiation. A RTEAR message is routed like a
corresponding RESV message (using the same scope rules).
Its IP destination address is any node through
which they pass; instead, they are only reported to the unicast address of a
previous hop.

<PathTear Message> end
application.

[ <INTEGRITY> ] <ERROR_SPEC>

<sender descriptor list> descriptor>

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

<ResvTear

[ <INTEGRITY> ] <ERROR_SPEC>

[S_POLICY_DATA] [ <SCOPE> ]

[ <INTEGRITY> ] <ERROR_SPEC>

<RESV_CONFIRM>

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

FLOWSPEC or POLICY_DATA objects

The RESV_CONFIRM object in the flow descriptor list of a RTEAR message will be ignored and may be omitted.

Note that the RTEAR RACK message will cease to be forwarded at the
same node where merging suppresses forwarding is a copy of the
corresponding
object from the RESV messages. The change will be propagated as
a new teardown message if that triggered the result has been to remove all
state for this session at this node; otherwise, it may result
in confirmation.

The following style-dependent rules define the immediate forwarding composition of a modified RESV refresh message.

Deletion of path state, whether as the result of a teardown
message or because of timeout, may force adjustments in related
reservation state to maintain consistency in the local node.
valid error flow descriptor:

o WF Style:

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

Internet Draft RSVP Specification July November 1995

o FF style:

o SE style:

The adjustment in reservation state depends upon ERROR_SPEC object specifies the style.
For example, suppose a PTEAR deletes error and includes the path state for 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 is being reported). In a
sender S. If RACK
message, the style specifies distinct reservations (FF), ERROR_SPEC is used only reservations for sender S should be deleted; if to carry the style
specifies shared reservations (WF or SE), delete IP address of
the
reservation if this was originating node, in the last filter spec. These
reservation changes should not trigger an immediate Error Node Address; the error
specification is a special value that indicates a confirmation.

When a RESV
refresh message, since message contains a list of flow descriptors (e.g.,
FF style), the teardown RSVP implementation should process each flow
descritor independently and return a separate RERR message will for
each that is in error.

Generally speaking, a RERR message should be forwarded towards
all receivers that may have already
made the required changes upstream. However, at caused the error being reported.
More specifically:

o The node that detects an error in
which a RTEAR reservation request
sends a RERR message stops, to the change of next hop from which the
erroneous reservation state
may trigger a RESV refresh starting at that node.

4.2 Sending RSVP Messages

RSVP messages are sent hop-by-hop between RSVP-capable routers as
"raw" IP datagrams with protocol number 46. Raw IP datagrams are
similarly intended to be used between an end system and came.

The message must contain the
first/last hop router; however, it is also possible information required to encapsulate
RSVP messages as UDP datagrams for end-system communication, as
described in Appendix C. UDP encapsulation may simplify
installation of RSVP on current end systems, particularly when
firewalls are in use.

Upon
define the arrival of an RSVP message M that changes error and to route the state, error message. Routing
requires at least a
node must forward STYLE object and one or more
FILTER_SPEC object(s) from the modified state immediatly. If this is
implemented as erroneous RESV message.
For an immediate refresh of all the state admission control failure, for example, the
session, then no refresh messages should
erroneous FLOWSPEC must be sent out included.

o Succeeding nodes forward the interface
through which M arrived. This rule is necessary to prevent packet
storms on broadcast LANs.

An RSVP RERR message must be fragmented when necessary using their
local reservation state, to fit into the
MTU next hops of reservations
that match the interface through which it will be sent. All fragments
of FILTER_SPEC(s) in the message should carry message. For
reservations with wildcard scope, there is an additional
limitation on forwarding RERR messages, to avoid loops;
see Section 3.3.

When the same unique value of error is an admission control failure, a node is
allowed (but not required) to match the Message
ID field, FLOWSPEC as well as appropriate Fragment Offset and MF bits, in
their common headers. When an RSVP message arrives, it must be
reassembled before it can be processed. The refresh period R is
appropriate as a ressembly timeout time.

Since RSVP messages are normally expected to be generated and sent
hop-by-hop, using the RSVP-level fragmentation mechanism should
result in no IP fragmentation. However, IP fragmentation may
occur through a non-RSVP cloud. For IP6, which does not support
router fragmentation, this case will require that the RSVP
implementation use Path MTU Discovery or hand configuration to
obtain an appropriate MTU.

Under overload conditions, lost RSVP control messages could cause
a failure of resource reservations. Routers should be configured

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

Internet Draft RSVP Specification July November 1995

FILTER_SPEC object(s), to give a preferred class of service to RSVP packets. RSVP should
not use significant bandwidth, but queueing delay and dropping limit the distribution of
RSVP messages needs a RERR
message to be controlled. Loss of RSVP packets
through those receivers that `caused' the error. Suppose
that a congested non-RSVP cloud may still be RERR message contains a problem. The
simplest solution FLOWSPEC Qerr that is to adopt a larger value for being
matched against the timeout
factor K (see section 4.5 below). If this does not suffice,
neighboring RSVP routers could use FLOWSPEC Qlocal in the local reservation
state in node N. Qerr, which originated in a TCP connection to pass RSVP
messages through node upstream
from N, resulted from merging of flowspecs that included
Qlocal. Generally, a non-RSVP cloud. RERR message can be forwarded to the
receiver(s) that specified the `biggest' flowspec. The current protocol contains
no automatic mechanism
comparison of Qerr against a particular Qlocal to setting up such connections; hand
configuration is assumed.

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

1. When a node N forwards a PATH message out a logical outgoing
interface L, it includes in determine
whether Qlocal qualifies as (one of) the message some encoding of `biggest', may be
called `de-merging'. As with merging, the
identity details of L. This information is carried (in the HOP
object) as a value called de-
merging depend upon the "logical interface handle" or
LIH.

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

3. When N' sends a RESV FLOWSPEC format, and
are outside RSVP itself.

A RERR message to N, it includes that is forwarded should carry the LIH value FILTER_SPEC
from the path corresponding reservation state (again, in (thus `de-merging' the HOP object).

4.
filter spec).

When the RESV a RERR or RACK message arrives at N, its LIH value provides reaches a receiver, the information necessary to attach STYLE
object, flow descriptor list, and ERROR_SPEC object (which
contains the reservation LUB-Used flag) should be delivered to the
appropriate logical interface. Note that N creates and
interprets receiver
application. In the LIH; it is case of an opaque value to N'.

4.3 Avoiding RSVP Message Loops

We must ensure Admission Control error, the
flow descriptor list will contain the FLOWSPEC object that
failed. If the rules for forwarding RSVP control messages
avoid looping. In steady state, PATH and RESV messages are
forwarded only once per refresh period on each hop. This avoids
directly looping packets, but there LUB-Used flag is still off, this should be
semantically equivalent (but not necessarily identical) to the possibility of an
" auto-refresh" loop, clocked
FLOWSPEC originated by the refresh period. The effect this application; otherwise, they may
differ.

3.1.6 Teardown Messages

There are two types of such a loop is to keep RSVP Teardown message, PTEAR and RTEAR.

o A PTEAR message deletes path state active "forever", even if the end
nodes have ceased refreshing it (but (which in turn deletes
the reservation state will be deleted
when the for that sender, if there is any)
and travels towards all receivers leave the multicast group and/or that are downstream from
the senders
stop sending point of initiation. A PTEAR message is routed like a
PATH messages). On message, and its IP destination address is
DestAddress for the other hand, error session.

o A RTEAR message deletes reservation state and travels
towards all matching senders upstream from the point of
teardown messages are forwarded immediately and are therefore initiation. A RTEAR message is routed in the
same way as a corresponding RESV message (using the same
scope rules). Its IP destination address is the unicast
address of a previous hop.

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

Internet Draft RSVP Specification July November 1995

subject to direct looping.

o PATH Messages

PATH messages are forwarded using routes determined by the
appropriate routing protocol. For routing that is source-
dependent (e.g., some multicast routing algorithms), the RSVP
daemon must route each sender descriptor separately using the
source addresses found

[ <INTEGRITY> ]

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

[ <INTEGRITY> ] [ <SCOPE> ]

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

FLOWSPEC or POLICY_DATA objects in the SENDER_TEMPLATE objects. This
should ensure that there will be no auto-refresh loops flow descriptor list of
PATH messages, even in
a topology with cycles.

Consider each RTEAR message type.

o PTEAR Messages

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

o PERR Messages

Since PATH messages don't loop, they create path state
defining a loop-free reverse path to each sender. PERR
messages are always directed to particular senders will be ignored and
therefore cannot loop.

o RESV Messages

Like PERR message, RESV messages directed to particular
senders (i.e., with explicit scope) cannot loop. However,
there may be omitted.

Note that, unless it is accidentally dropped along the way, a potential for auto-refresh of RESV messages with
wildcard scope;
PTEAR message will reach all the solution is presented below.

o RTEAR Messages receivers down stream from its
origination. On the other hand, a RTEAR messages are routed message will cease to
be forwarded at the same as RESV messages and have
an analogous looping problem for wildcard scope.

o RERR Messages

RERR messages for wildcard scope reservations have node where merging suppresses
forwarding of the same
potential for looping as corresponding RESV messages. In each node N
along the reservations themselves, and way, if the
solution presented below is required.

If RTEAR message causes the topology has no loops, then looping removal of wildcard-scoped
messages can be avoided by simply enforcing the rule given
earlier: all
state that is received through a particular interface
must never be forwarded out the same interface. However, when the

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

Internet Draft RSVP Specification July 1995

topology does have cycles then further effort is needed to prevent
auto-refresh loops in wildcard-scope RESV, RTEAR, and RERR
messages. The solution is for such messages to carry an explicit
sender address list in a SCOPE object.

When a RESV or RTEAR message with wildcard scope is to be
forwarded to a particular previous hop, this session, N will create a new SCOPE object is
computed from the SCOPE objects that were received (in messages of
the same type). If the computed SCOPE object is empty, the teardown message is not forwarded to the previous hop;
be propagated further upstream; otherwise, the RTEAR message is sent containing
may result in the new SCOPE object. The rules for
computing a new SCOPE object for immediate forwarding of a modified RESV or RTEAR message are as
follows:

1. The union is formed
refresh message.

Deletion of path state as the sets result of sender IP addresses listed
in all SCOPE objects a PTEAR message or a
timeout may force adjustments in the related reservation state, to
maintain state for consistency in the given
session.

If local node. The adjustment
in reservation state from some NHOP does not contain depends upon the style. For example,
suppose a SCOPE
object, PTEAR deletes the path state for a substitute sender list must be created and included
in S. If the union. For
style specifies explicit sender selection (FF or SE), delete
any reservation with a filter spec matching S; otherwise, the
style is wildcard scope sender selection (WF) message that arrived
on outgoing interface OI, and the substitute list reservation
should be deleted if S is the set of
senders that route last sender to OI. For the session.
These reservation changes should not trigger an explicit scope (SE) immediate RESV
refresh message, it is since the set of senders explicitly listed in PTEAR message have already made the
message.

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

3. If
required changes upstream. However, at the SCOPE object is to be sent to PHOP, remove from node in which a
RTEAR message stops, the
set any senders that did not come from PHOP.

Figure 12 shows an example change of wildcard-scoped (WF style) RESV
messages. The address lists within SCOPE objects are shown in
square brackets. Note that there reservation state may be additional connections
among the nodes, creating looping topology
trigger a RESV refresh starting at that is not shown. 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

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

Internet Draft RSVP Specification July November 1995

________________
a | | c
R4, S4<----->|

intended to 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 that cannot
do raw network I/O.

PATH, PTEAR, and RACK messages must be sent with the Router |<-----> R2, S2, S3
| |
b | |
R1, S1<----->| |
|________________|

Figure 12: SCOPE Objects Alert
IP option [Katz95] in Wildcard-Scope Reservations

SCOPE objects are not necessary if the multicast routing uses
shared trees or if the reservation style has explicit scope.
Furthermore, attaching a SCOPE object to a reservation their IP headers. This option may be
deferred to a node which has more than one previous hop upstream.

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

1. The node the fast forwarding path of a high-speed router to detect
datagrams that detected require special processing.

Upon the error initiates arrival of an RERR RSVP message
containing a copy of the SCOPE object associated with M that changes the
reservation state or message in error.

2. Suppose a wildcard-scoped RERR message arrives at a node with state, a SCOPE object containing the sender host address list L.
The
node forwards must forward the RERR modified state immediately. However, this
must not trigger sending an message using out the rules interface through
which M arrived (as could happen if the implementation simply
triggered an immediate refresh of Section
4.1.5. However, all state for the RERR session).
This rule is necessary to prevent packet storms on broadcast LANs.

An RSVP message forwarded out OI must
contain a SCOPE object derived from L by including only those
senders that route be fragmented when necessary to OI. If this SCOPE object is empty, fit into the
RERR message should not be sent out OI.

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

Internet Draft RSVP Specification July 1995

4.4 Local Repair

When a route changes,
MTU of the next PATH or RESV refresh interface through which it will establish
path or reservation state (respectively) along be sent. All fragments
of the new route. To
provide fast adaptation to routing changes without message should carry the overhead same unique value of
short refresh periods, the local routing protocol module Message
ID field, as well as appropriate Fragment Offset and MF bits, in
their common headers. When an RSVP message arrives, it must be
reassembled before it can
notify be processed. The refresh period R can
be used as an appropriate reassembly timeout time.

Since RSVP messages are normally generated and sent hop-by-hop,
using the RSVP-level fragmentation mechanism should avoid further
fragmentation at the IP level. However, IP fragmentation may
still occur when RSVP daemon messages travel through a non-RSVP cloud.
In case of route changes for particular
destinations. The IP6, which does not support IP fragmentation at
routers, an RSVP daemon should implementation must use this information Path MTU Discovery or
hand configuration to
trigger obtain an immediate appropriate MTU between adjacent
RSVP neighbors.

RSVP recovers from occasional packet losses by its periodic
refresh mechanism. Under network overload, however, substantial
losses of state for these destinations,
using the new route.

More specifically, the rules are as follows:

o When routing detects RSVP messages could cause a change failure of resource
reservations. To control the set queueing delay and dropping of outgoing
interfaces for sending PATH messages for destination G, RSVP
sends immediate PATH refreshes for all sessions G/* (i.e.,
for any session with destination G, regardless of destination
port). Such refresh messages are to
packets, routers should be sent configured to at least 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
new outgoing interfaces timeout factor K (see section 3.5 below).

Some multicast routing protocols provide for these sessions.

o "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 mapped into some

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

Internet Draft RSVP Specification November 1995

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 node N forwards a PATH message arrives with out a Previous Hop address that
differs from logical outgoing
interface L, it includes in the one stored message some encoding of the
identity of L, called the "logical interface handle" or LIH.
The LIH value is carried in the RSVP_HOP object.

2. The next hop node N' stores the LIH value in its path state, RSVP should
send immediate state.

3. When N' sends a RESV refreshes for that session.

4.5 Time Parameters

There are two time parameters relevant message to each element of RSVP N, it includes the LIH value
from the path or reservation state (again, in a node: the refresh period R between
receiving successive refreshes for RSVP_HOP object).

4. When the state, and its lifetime L.
Each RSVP RESV or PATH message may contain a TIME_VALUES object
specifying the R value that was used arrives at N, its LIH value provides
the information necessary to generate this refresh
message; this is used attach the reservation to determine the L when
appropriate logical interface. Note that N creates and
interprets the state LIH; it is
received and stored.

In more detail:

1. To avoid premature loss an opaque value to N'.

3.3 Avoiding RSVP Message Loops

Forwarding of RSVP messages must avoid looping. In steady state, we require that L >= (K +
0.5)* R, where K is a small integer. Then K-1 successive
PATH and RESV messages may be lost without state being deleted. Currently
K = 3 are forwarded only once per refresh period
on each hop. This avoids looping packets, but there is suggested.

2. Each message will generally carry a TIME_VALUES object
containing the R used to generate refreshes; still the recipient
node uses this R to determine L
possibility of an " auto-refresh" loop, clocked by the stored state.

However, refresh
period. Such auto-refresh loops keep state active "forever", even
if a default R = Rdef is used, the TIME_VALUES
object may be omitted from a message. Rdef is currently
defined to be 30 seconds.

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

Internet Draft RSVP Specification July 1995

3. This document does not specify end nodes have ceased refreshing it, until either the interval R to be used for
generating refresh messages. If
receivers leave the node does not implement
local repair of reservations disrupted by route changes, a
smaller R improves multicast group and/or the speed of adapting senders stop
sending PATH messages. On the other hand, error and teardown
messages are forwarded immediately and are therefore subject to routing changes
(but increases overhead). With local repair, a router can be
more relaxed about R since
looping.

Consider each message type.

o PATH Messages

PATH messages are forwarded in exactly the periodic refresh becomes only same way as IP
data packets. Therefore there should be no loops of PATH
messages, even in a backstop robustness mechanism. A node may therefore adjust topology with cycles.

o PTEAR Messages

PTEAR messages use the effective R dynamically same routing as PATH messages and
therefore cannot loop.

o PERR Messages

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

Internet Draft RSVP Specification November 1995

Since PATH messages do not loop, they create path state
defining a loop-free reverse path to limit the overhead due each sender. PERR
messages are always directed to
refresh messages.

4. The TIME_VALUES object could contain, in addition particular senders and
therefore cannot loop.

o RESV Messages

RESV messages directed to the
hop-by-hop R value, an end-to-end upper bound on R, called
Rmax. When Rmax is specified, a node particular senders (i.e., with
explicit sender selection) cannot set R > Rmax. loop. However, RESV
messages with wildcard sender selection (WF style) have a node is allowed to refuse an RSVP message (i.e.,
drop it and return an error) when it specifies an Rmax value
that is so small that it would create unacceptable overhead.
This refusal would look like
potential for auto-refresh looping.

o RTEAR Messages

Although RTEAR messages are routed the same as RESV messages,
during the second pass around a kind of admission control
failure.

5. However, when R is changed dynamically, loop there will be no state
so any RTEAR message will be dropped. Hence there is a limit to
how fast it may increase. Specifically, no
looping problem here.

o RERR Messages

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

o RACK Messages

RACK messages are forwarded towards a fixed unicast receiver
address and cannot loop.

If the topology has no loops, then looping of two
successive values R2/R1 must not exceed 1 + Slew.Max.

Currently, Slew.Max is 0.30. With K = 3, one packet may "wildcard" RESV and
RERR messages, i.e., messages with wildcard sender selection, can
be
lost without avoided by simply enforcing the rule given earlier: state timeout while R that
is increasing 30 percent
per refresh cycle.

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

7. A node should randomize its refresh timeouts particular interface must never be forwarded
out the same interface. However, when the topology does have
cycles, further effort is needed to avoid
synchronization and burstiness of refreshes.

8. The values prevent auto-refresh loops of Rdef, K,
wildcard RESV messages and Slew.Max used in an implementation
should be easily modifiable, as experience may lead to
different values. The possibility fast loops of dynamically changing K
and/or Slew.Max in response wildcard RERR messages.
The solution to measured loss rates this problem adopted by this protocol
specification is for
future study.

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

Internet Draft RSVP Specification July 1995

4.6 RSVP Interfaces

RSVP on such messages to carry an explicit sender
address list in a router has interfaces SCOPE object.

When a RESV message with WF style is to routing and be forwarded to traffic control.
RSVP on a host has an interface to applications (i.e, an API) and
also an interface to traffic control (if it exists on the host).

4.6.1 Application/RSVP Interface

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

o Register

Call: REGISTER( DestAddress , DestPort

[ , SESSION_object ] , SND_flag , RCV_flag

[ , Source_Address ] [ , Source_Port ]

[ , Source_ProtID ] [ , Sender_Template ]

[ , Sender_Tspec ] [ , Data_TTL ]

[ , Sender_Policy_Data ]

[ , Upcall_Proc_addr ] ) -> Session-id

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

The SESSION_object parameter new SCOPE object is included as an escape
mechanism to support some more general definition of computed from the
session ("generalized destination port"), should
SCOPE objects that be
necessary were received in matching RESV messages. If
the future. Normally SESSION_object will be
omitted; if it computed SCOPE object is supplied, it should be an
appropriately-formatted representation of a SESSION
object.

SND_flag should be set true if empty, the host will send data,
and RCV_flag should be set true if message is not forwarded
to the host will receive
data. Setting neither true previous hop; otherwise, the message is an error. sent containing the
new SCOPE object. The optional rules for computing a new SCOPE object for
a RESV message are as follows:

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

Internet Draft RSVP Specification July November 1995

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

If SND_FLAG is true, a successful REGISTER call will cause
RSVP to begin sending PATH messages for this session using
these parameters, which are interpreted as follows:

- Source_Address

This

1. The union is formed of the address sets of sender IP addresses listed
in all SCOPE objects in the interface from which reservation state for the
data will be sent. given
session.

If it is omitted, reservation state from some NHOP does not contain a default
interface will be used. This parameter is needed on SCOPE
object, a multihomed substitute sender host.

- Source_Port

This is the UDP/TCP port from which the data will list must be
sent. If it is omitted or zero, the port is "wild" created and can match any port included
in a FILTER_SPEC.

- Source_ProtID

This is the IP protocol ID for union. For a message that arrived on outgoing
interface OI, the sender data. If
it substitute list is omitted or zero, the protocol id is "wild" and
can match any protocol id in a FILTER_SPEC.

- Sender_Template

This parameter is included as an escape mechanism to
support a more general definition set of the senders that
route to OI.

2. Any local senders (i.e., any sender
("generalized source port"). Normally applications on this parameter
may be omitted; if it is supplied, it should be an
appropriately formatted representation of a
SENDER_TEMPLATE object.

- Sender_Tspec

This parameter is a Tspec describing
node) are removed from this set.

3. If the traffic flow SCOPE object is to be sent. It may be included sent to prevent over-
reservation on PHOP, remove from the initial hops.

- Data_TTL

This is the (non-default) IP Time-To-Live parameter
set any senders that is being supplied on did not come from PHOP.

Figure 11 shows an example of wildcard-scoped (WF style) RESV
messages. The address lists within SCOPE objects are shown in
square brackets. Note that there may be additional connections
among the data packets. It is
needed to ensure nodes, creating looping topology that Path messages do is not have a shown.

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

Internet Draft RSVP Specification July November 1995

scope larger than

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

Figure 11: SCOPE Objects in Wildcard-Scope Reservations

SCOPE objects are not necessary if the multicast data packets.

- Sender_Policy_Data

This optional parameter passes policy data for routing uses
shared trees or if the
sender. This data reservation style has explicit sender
selection. Furthermore, attaching a SCOPE object to a reservation
may be supplied by deferred to a system
service, node which has more than one previous hop
upstream.

The following rules are used for SCOPE objects in RERR messages
with WF style:

1. The node that detected the application treating it as opaque.

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

o Reserve

Call: RESERVE( session-id,

style, style-dependent-parms )

A receiver uses this call to make initiates an RERR message
containing a resource reservation
for copy of the session registered as `session-id'. The style
parameter indicates SCOPE object associated with the
reservation style. The rest of
the parameters depend upon state or message in error.

2. Suppose a wildcard-scoped RERR message arrives at a node with
a SCOPE object containing the style, but generally these
will include appropriate flowspecs, filter specs, and
possibly receiver policy data objects. sender host address list L.
The first RESERVE call will initiate node forwards the periodic
transmission of RESV messages. A later RESERVE call may
be given to modify RERR message using the parameters rules of Section
3.1.5. However, the earlier call (but
note that changing the reservations may result in
admission control failure, depending upon the style).

The RESERVE call returns immediately. Following RERR message forwarded out OI must
contain a RESERVE
call, an asynchronous ERROR/EVENT upcall may occur at any
time.

o Release

Call: RELEASE( session-id )

This call will terminate RSVP state for the session
specified SCOPE object derived from L by session-id. It may send appropriate teardown
messages and will cease sending refreshes for including only those
senders that route to OI. If this
session-id.

o Error/Event Upcalls

Upcall: <Upcall_Proc>( ) -> session-id, Info_type, SCOPE object is empty, the

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

Internet Draft RSVP Specification July November 1995

[ Error_code , Error_value , LUB-Used, ]

List_count, [ Flowspec_list,]

[ Filter_spec_list, ] [ Advert_list, ]

[ Policy_data ]

Here "Upcall_Proc" represents

RERR message should not be sent out OI.

3.4 Local Repair

When a route changes, the upcall procedure whose
address was supplied in the REGISTER call.

This upcall may occur asynchronously at any time after a
REGISTER call and before a RELEASE call, to indicate an
error next PATH or an event. Currently there are three upcall
types, distinguished by RESV refresh message will
establish path or reservation state (respectively) along the Info_type parameter:

1. Info_type = Path Event

A Path Event upcall indicates new
route. To provide fast adaptation to a receiver
application that there is at least one active sender.
It results from receipt routing changes without the
overhead of short refresh periods, the first PATH message for
this session.

This upcall provides synchronizing information to local routing protocol
module can notify the
receiver application, and it may also provide
parallel lists RSVP daemon 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. route changes for particular
destinations. The
Error_code, Error_value, LUB-Used flag, and
Policy_data parameters will be undefined in RSVP daemon should use this
upcall.

2. Info_type = Resv Event

A Resv Event upcall indicates information to
trigger a sender application
that a reservation quick refresh of state for this session in place along these destinations, using the entire path to at least one receiver. It is
triggered by
new route.

More specifically, the receipt rules are as follows:

o When routing detects a change of the first reservation
message or by modification set of previous reservation
state, outgoing
interfaces for this session.

`List_count' will be 1, destination G, RSVP should wait for a short
period W, and Flowspec_list will
contain one FLOWSPEC, the effective QoS that would then send PATH refreshes for 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
allow the routing protocol getting settled with the new
change(s), and the exact value for W should be
applicable 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 one stored in the path state, RSVP should
send immediate RESV refreshes for that session.

3.5 Time Parameters

There are two time parameters relevant to each element of RSVP
path or reservation state in a node: the application itself.
Filter_spec_list refresh period R between
generation of successive refreshes for the state by the neighbor
node, and Advert_list will the local state's lifetime L. Each RSVP RESV or PATH
message may contain one a TIME_VALUES object specifying the R value
that was used to generate this (refresh) message. This R value is
then used to determine the value for L when the state is received
and stored. The values for R and L may vary from hop to 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 periodic messages contend with other network

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

Internet Draft RSVP Specification July November 1995

NULL object. The Error_code, Error_value, LUB-Used
flag,

traffic for link and Policy_data parameters will be undefined in forwarding resources. Since RSVP sends
periodic refresh messages, it must avoid message
synchronization and ensure that any synchronization that may
occur is not stable.

For this upcall.

3. Info_type = Path Error

An Path Error event indicates an error in sender
information that was specified in the REGISTER call.

The Error_code parameter will define the error, and
Error_value may supply some additional (perhaps
system-specific) data about reason, the error. `List_count'
will refresh timer should be 1, and Filter_spec_list and Flowspec_list
will contain randomly set to
a value in the Sender_Template supplied 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
REGISTER call; Sender_Tspec and Advert_list will each
contain one NULL object. The Policy_data parameter
will worst
case, K-1 successive messages may be undefined in this upcall.

4. Info_type = Resv Error

An Resv Error event indicates an error in processing lost without state being
deleted. To compute a reservation message to which this application
contributed. The Error_code parameter will define lifetime L for a collection of state
with different R values R0, R1, ..., replace R by max(Ri).

Currently K = 3 is suggested as the error, and Error_value default. However, it may supply
be necessary to set a larger K value for hops with high loss
rate. K may be set either by manual configuration per
interface, or by some additional
(perhaps system-specific) data on adaptive technique that has not yet
been specified.

3. Each message that creates state (PATH or RESV message)
carries a TIME_VALUES object containing the error.

Filter_spec_list and Flowspec_list will contain R used to
generate refreshes; the
FILTER_SPEC and FLOWSPEC objects from recipient node uses this R to
determine L of the error flow
descriptor (see Section 4.1.5). List_count will
specify stored state.

4. R is chosen locally by each node. If the number node does not
implement local repair of FILTER_SPECS in
Filter_spec_list, while there will be one FLOWSPEC in
Flowspec_list. The Policy_data parameter will be
undefined in this upcall.

5. Info_type = Policy Data

A Policy Information upcall passes reservations disrupted by route
changes, a Policy_data
parameter containing policy information (accounting,
current costs, prices, quota, etc.) that arrived at smaller R speeds up adaptation to routing changes,
while increasing the receiver.

List_count will RSVP overhead. With local repair, a
router can be zero, and more relaxed about R since the Error_code,
Error_value, and LUB-Used flag parameters will be
undefined in this upcall.

Although RSVP messages indicating path events or errors periodic refresh
becomes only a backstop robustness mechanism. A node may be received periodically,
therefore adjust the API should make effective R dynamically to control the
corresponding asynchronous upcall
amount of overhead due to refresh messages.

The current suggested default for R is 30 seconds. However,
the application only default should be configurable per interface.

5. When R is changed dynamically, there is a limit to how fast
it may increase. Specifically, the ratio of two successive
values R2/R1 must not exceed 1 + Slew.Max.

Currently, Slew.Max is 0.30. With K = 3, one packet may be
lost without state timeout while R is increasing 30 percent
per refresh cycle.

6. To improve robustness, a node may temporarily send refreshes

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

Internet Draft RSVP Specification July November 1995

on the first occurrence, or when the information to be
reported changes.

4.6.2 RSVP/Traffic Control Interface

In each router and host, enhanced QoS is achieved by

more often than R after a group state change (including initial
state establishment).

7. The values of
inter-related traffic control functions: a packet classifier,
an admission control module, Rdef, K, and a packet scheduler. This
section describes a generic Slew.Max used in an implementation
should be easily modifiable per interface, as experience may
lead to different values. The possibility of dynamically
adapting K and/or Slew.Max in response to measured loss rates
is for future study.

3.6 Traffic Policing and TTL

RSVP interface is required to compute and pass several service-related flags
to traffic control.

1. Make a Reservation

Call: Rhandle = TC_AddFlowspec( Interface, Flowspec

[ , Sender_Tspec]

, E_Police_Flag , M_Police_Flag )

This call passes a Flowspec defining control: policing flags and a desired non-RSVP flag.

Some QoS to
admission control. It services may also pass Sender_Tspec, the
maximum require traffic characteristics computed over policing at some or all of
(1) the
SENDER_TSPECs edge of senders that will contribute data packets
to this reservation.

E_Police_Flag and M_Police_Flag are Boolean parameters.
E_Police_Flag is on if this is an entry node, while
M_Police is on if this node is an interior data merge the network, (2) a merging point for data from
multiple senders, and/or (3) a shared reservation style. These flags are
used branch point where traffic flow
from upstream may be greater than the downstream reservation.
RSVP knows where such points occur and must so indicate to enable the
traffic policing or shaping when
appropriate, control mechanism. On the other hand, RSVP does not
interpret the service embodied in accordance with the service. 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 call returns an error code if Flowspec flag is malformed
or if set in the requested resources are unavailable. Otherwise,
it establishes a new reservation channel corresponding to
Rhandle. It returns the opaque number Rhandle for
subsequent references to this reservation.

2. Modify Reservation

Call: TC_ModFlowspec( Rhandle, new_Flowspec

[ , Sender_Tspec] , Police_flag )

This call can modify an existing reservation. If
new_Flowspec first-hop RSVP node that implements
traffic control (and is included, 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 hop capable of traffic
control is passed to Admission
Control; if it reached. This is rejected, controlled by the E_Police flag
in SESSION objects.

o M_Police_Flag -- Merge Policing

This flag should be set on for a reservation using a 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 current flowspec is left being installed

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

Internet Draft RSVP Specification July November 1995

is smaller than, or incomparable to, a FLOWSPEC in force. The corresponding filter specs, if any, are not
affected.

3. Delete Flowspec

Call: TC_DelFlowspec( Rhandle )

This call will delete an existing reservation, including place on
any other interface, for the flowspec same FILTER_SPEC and all associated filter specs.

4. Add Filter Spec

Call: FHandle = TC_AddFilter( Rhandle, Session , FilterSpec )

This call is used SESSION.

RSVP must also detect and report to associate receivers the presence of
non-RSVP hops in the path. For this purpose, an additional filter spec
with RSVP daemon must
place into each PATH message that it sends the reservation specified by value of the given Rhandle,
following a successful TC_AddFlowspec call. This call
returns a filter handle FHandle.

5. Delete Filter Spec

Call: TC_DelFilter( FHandle )

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

6. OPWA Update

Call: TC_Advertise( interface, Adspec

[ ,Sender_TSpec ] ) -> New_Adspec

This call is used for OPWA IP TTL
with which the message was sent. The RSVP-capable node that
receives this message compares this field to compute the outgoing
advertisement New_Adspec for a specified interface.
Sender_TSpec is also passed TTL with which
the message was actually received, and if they differ it turns on
the Non_RSVP flag. This flag is available.

7. Preemption Upcall

Upcall: TC_Preempt() -> RHandle, Reason_code

In order carried forward to grant a new reservation request, receivers in
the admission
control and/or policy modules may be allowed to preempt an
existing reservation. This might be reflected ADSPEC [??].

3.7 Multihomed Hosts

Accommodating multihomed hosts requires some special rules in an

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

Internet Draft RSVP Specification July 1995

upcall to RSVP, passing
RSVP. We use the RHandle term `multihomed host' to cover both hosts (end
systems) with more than one network interface [could ref. section
3.3.4 of the preempted
reservation, RFC-1122], and some indication of the reason.

4.6.3 RSVP/Routing Interface routers that are supporting local
application programs.

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

o Promiscuous receive mode application executing on a multihomed host may explicitly
specify which interface any given flow will use for RSVP messages

Any datagram received sending and/or
for IP protocol 46 must be diverted receiving data packets, to override the RSVP program for processing, without being
forwarded. system-specified
default interface. The identity RSVP daemon must be aware of the interface on which it is
received should also be available default,
and if an application sets a specific interface, it must also pass
that information to the RSVP daemon. RSVP.

o Route Query

RSVP must be able Sending Data

A sender application uses an API call (SENDER in Section
3.9.1) to query the routing daemon for declare to RSVP the
route(s) for forwarding a specific datagram.

Ucast_Route_Query( DestAddress, Notify_flag ) -> OutInterface

Mcast_Route_Query( SrcAddress, DestAddress, Notify_flag )

-> OutInterface_list

If characteristics of the Notify_flag is True, routing data
flow it will save state
necessary to issue unsolicited route change notification
callbacks whenever the specified route changes. originate. This will
continue until routing receives a route query call with may optionally include the Notify_Flag set False.

o Route Change Notification
local IP address of the sender. If requested it is set by a route query with the Notify_flag True,
application, this parameter must be the routing interface address for
sending the data packets; otherwise, the system default
interface is implied.

The RSVP daemon may provide on the host then sends PATH messages for this
application out the specified interface (only).

o Making Reservations

A receiver application uses an asynchronous callback API call (called RESERVE in
Section 3.9.1) to
RSVP that request a specified route reservation from RSVP. This call
may optionally include the local IP address of the receiver,
i.e., the interface address for receiving data packets. In
the case of multicast sessions, this is the interface on
which the group has changed.

Ucast_Route_Change( ) -> DestAddress, OutInterface

Mcast_Route_Change( )

-> SrcAddress, DestAddress, OutInterface_list

o Outgoing Link Specification been joined. If the parameter is

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

Internet Draft RSVP Specification July November 1995

omitted, the system default interface is used.

In general, the RSVP must be able to force a (multicast) datagram to be
sent on a specific outgoing virtual link, bypassing the
normal routing mechanism. A virtual link may be a real
outgoing link or a multicast tunnel. Outgoing link
specification is necessary because RSVP may daemon should send different
versions of outgoing PATH RESV messages for
application out the same source and
destination addresses specified interface. However, when the
application is executing on different interfaces. It a router and the session is also
necessary
multicast, a more complex situation arises. Suppose in some cases this
case that a receiver application joins the group on an
interface Iapp that differs from Isp, the shortest-path
interface to avoid the sender. Then there are two possible ways
for multicast routing loops.

o Discover Interface List to deliver data packets to the
application. The RSVP daemon must be able determine which case holds
by examining the path state, to learn what real and virtual
interfaces are active, with their IP addresses.

Braden, Zhang, et al. Expiration: January 1996 [Page 54]

Internet Draft RSVP Specification July 1995

5. Message Processing Rules

This generic description decide which incoming
interface to use for sending RESV messages.

1. The multicast routing protocol may create a separate
branch of RSVP operation assumes the following data
structures. An actual implementation may use additional or different
structures multicast distribution `tree' to optimize processing.

o PSB -- Path State Block

Each PSB holds deliver
to Iapp. In this case, there will be path state for a particular (session, sender)
pair, which are defined by SESSION
both Isp and SENDER_TEMPLATE objects,
respectively. PSB contents include Iapp. The path state on Iapp should only
match a PHOP object and possibly
SENDER_TSPEC, POLICY_DATA, and/or ADSPEC objects reservation from PATH
messages.

o RSB -- Reservation State Block

Each RSB holds reservation the local application; it must
be marked "Local_only" by the RSVP daemon. If
"Local_only" path state for a particular 4-tuple:
(session, next hop, style, filterspec), which are defined in
SESSION, NHOP, STYLE, and FILTER_SPEC objects, respectively.
RSB contents also include a FLOWSPEC object and may include a
POLICY_DATA object. We assume that RSB contents include Iapp exists, the
outgoing interface OI that is implied by NHOP.

MESSAGE ARRIVES

Verify version number, checksum, and length fields of common header,
and discard RESV
message if any mismatch should be sent out Iapp.

Note that it is found.

Further processing depends upon message type.

PATH MESSAGE ARRIVES

Each sender descriptor object sequence in the message defines a
sender. Process each sender as follows, starting possible for the
Path_Refresh_Needed path state blocks for
Isp and Resv_Refresh_Needed flags off.

1. If there is a POLICY_DATA object, verify it; Iapp to have the same next hop, if it there is
unacceptable, build and send a "Administrative Rejection"
PERR message, drop the PATH message, and return. an
intervening non-RSVP cloud.

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

3. If protocol may forward data within
the message arrived on an interface different router from
EXPECTED_INTERFACE, drop it and return.

Braden, Zhang, et al. Expiration: January 1996 [Page 55]

Internet Draft RSVP Specification July 1995

4. Search for a Isp to Iapp. In this case, Iapp will
appear in the list of outgoing interfaces of the path
state block (PSB) whose (SESSION,
SENDER_TEMPLATE) pair matches the corresponding objects in for Isp, and the message.

If there is a match considering wildcards RESV message should be sent out
Isp.

3.8 Future Compatibility

We may expect that in the
SENDER_TEMPLATE objects, but the two SENDER_TEMPLATEs
differ, build and send a "Ambiguous Path" PERR message,
drop the PATH message, and return.

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

o Create a future new PSB.

o Set a cleanup timer for the PSB. If this is the first
PSB for the session, set a refresh timer object C-Types will be
defined for the
session.

o Copy the SESSION, TIME_VALUES, existing object classes, and PHOP perhaps new object
classes will be defined. It will be desirable to employ such new
objects into
the PSB. Copy into the PSB any of within the following
objects Internet using older implementations that do
not recognize them. Unfortunately, this is only possible to a
limited degree with reasonable complexity. The rules are present: POLICY_DATA, SENDER_TSPEC,
and ADSPEC.

o Store ROUTE_MASK and EXPECTED_INTERFACE in as
follows.

1. Unknown Class

There are two possible ways that an RSVP implementation can
treat an object with unknown class. This choice is
determined by the PSB.

o Turn on high-order bit of the Path_Refresh_Needed flag.

6. Otherwise (there is a matching PSB):

o Restart cleanup timer. Class-Num octet, as

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

Internet Draft RSVP Specification November 1995

follows.

o If the SENDER_TSPEC and/or ADSPEC values differ
between 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 PSB, copy the new values
into node should ignore the PSB object but
forward it, unexamined and turn on unmodified, in all messages
resulting from the Path_Refresh_Needed flag.
Note that if SEND_TSPEC has changed, reservations
matching S may also change; state contained in this may be deferred until message.

For example, suppose that a RESV refresh arrives.

o If the new ROUTE_MASK differs from message that stored is
received contains an object of unknown class. Such an
object should be saved in the
PSB, turn on reservation state without
further examination; however, only the Path_Refresh_Needed flag, and store latest object
with a 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 ROUTE_MASK into the PSB.

o If RESV
message.

Note that objects with unknown class cannot be merged;
however, unmerged objects may be forwarded until they
reach a node that knows how to merge them. Forwarding
objects with unknown class enables incremental
deployment of new objects; however, the scaling
limitations of doing so must be carefully examined
before a new EXPECTED_INTERFACE differs from object class is deployed with Class-Num <
128.

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

2. Unknown C-Type for Known Class

One might expect the known Class-Num to provide information
that stored could allow intelligent handling of such an object.
However, in practice such class-dependent handling is
complex, and in many cases it is not useful.

Generally, the PSB, turn on appearance of an object with unknown C-Type
should result in rejection of the Resv_Refres_Needed flag entire message and
store the new EXPECTED_INTERFACE value into
generation of an error message (RERR or PERR as appropriate).
The error message will include the PSB.

7. Save Class-Num and C-Type that
failed (see Appendix B); the IP TTL with which end system that originated the
failed message arrived in the PSB . may be able to use this information to retry

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

Internet Draft RSVP Specification July November 1995

8. If the Path_Refresh_Needed flag is now set, execute

the
PATH REFRESH event sequence (below); however, send no PATH
refresh messages out the interface through which the PATH
message arrived.

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

PATH TEAR MESSAGE ARRIVES

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

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

o Each sender descriptor in the PTEAR message contains a
SENDER_TEMPLATE object defining a sender S; different C-Type object, repeating this
process until it as
follows.

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

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

3. Delete the PSB.

o Drop the PTEAR message runs out of alternatives or succeeds.

Objects of certain classes (FLOWSPEC, ADSPEC, and return.

PATH ERROR MESSAGE ARRIVES

o If there
POLICY_DATA) are no existing PSB's for SESSION then drop opaque to RSVP, which simply hands them to
traffic control or policy modules. Depending upon its
internal rules, either of the
PERR message latter modules may reject a C-
Type and return.

o Look up inform the RSVP daemon; RSVP should then reject the PSB for (session, sender); sender is defined by
SENDER_TEMPLATE. If no PSB is found, drop PERR
message and
return.

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

Call: <Upcall_Proc>( session-id, Path Error,
Error_code, Error_value, 0,
1, SENDER_TEMPLATE, NULL, NULL, NULL) error, as described in the previous
paragraph.

Braden, Zhang, et al. Expiration: January May 1996 [Page 57] 54]

Internet Draft RSVP Specification July November 1995

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

o Otherwise (PHOP is not local API), forward

3.9 RSVP Interfaces

RSVP on a copy of the
PERR message router has interfaces to the PHOP node.

RESV MESSAGE ARRIVES

A RESV message arrives through outgoing interface OI.

o Check the SESSION object.

If there are no existing PSB's for SESSION then build routing and
send to traffic control.
RSVP on a RERR message (as described later) specifying "No
path information", drop the RESV message, and return.
However, do not send the RERR message if the style host has
wildcard reservation scope an interface to applications (i.e, an API) and this is not the receiver
host itself.

o Check the STYLE object.

If the style in the message conflicts with the style of any
reservation for this session in place
also an interface to traffic control (if it exists on any interface,
reject the RESV message by building and sending host).

3.9.1 Application/RSVP Interface

This section describes a RERR
message specifying "Conflicting Style", drop the RESV
message, generic interface between an
application and return.

o Check an RSVP control process. The details of a real
interface may be operating-system dependent; the POLICY_DATA object.

Verify following can
only suggest the POLICY_DATA field (if any) basic functions to check permission be performed. Some of
these calls cause information to create be returned asynchronously.

o Register Session

Call: SESSION( DestAddress , ProtocolId, DstPort ,

[ , SESSION_object ]

[ , Upcall_Proc_addr ] ) -> Session-id

This call initiates RSVP processing for a reservation. If it is unacceptable, build session, defined
by DestAddress together with ProtocolId and
send an "Administrative rejection" RERR message, drop possibly a
port number DstPort. If successful, the
RESV message, and return.

o Make reservations

Process the STYLE object and the flow descriptor list.

For FF style, execute the following steps for each b flow
descriptor, i.e., for each (FLOWSPEC, FILTER_SPEC) pair.
For SE style, execute the following steps for each
FILTER_SPEC SESSION call
returns immediately with a local session identifier
Session-id, which may be used in subsequent calls.

The Upcall_Proc_addr parameter defines the list, using the given FLOWSPEC. For WF
style, execute the following once, using address of an internal
placeholder "WILD_FILTER" for FILTERSPEC if it is omitted.

1. Find
upcall procedure to receive asynchronous error or create a reservation state block (RSB) for event
notification; see below. The SESSION_object parameter is
included as an escape mechanism to support some more
general definition of the
4-tuple: (SESSION, NHOP, style, FILTER_SPEC). session ("generalized
destination port"), should that be necessary in the
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: January May 1996 [Page 58] 55]

Internet Draft RSVP Specification July November 1995

2. Start

A sender uses this call to define, or restart to modify the cleanout timer on
definition of, the RSB. Start
a refresh timer attributes of the data stream. The
first SENDER call for this session if none was started.

3. If the RSB existed and contains state matching session registered as `Session-
id' will cause RSVP to begin sending PATH messages for
this
flow descriptor, continue with session; later calls will modify the next flow
descriptor. Otherwise (the state path
information.

The SENDER parameters are interpreted as follows:

- Source_Address

This is new or modified),
continue processing the current flow descriptor with address of the following steps.

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

-
data will be sent. If this set it is empty, build and send an error
message specifying "No omitted, a default
interface will be used. This parameter is needed on
a multihomed sender information", and
continue with the next flow descriptor. host.

- If this set contains more than one PSB and if Source_Port

This is the
style has UDP/TCP port from which the explicit option (e.g., FF data will be
sent. If it is omitted or SE),
build and send an error message specifying
"Ambiguous filter spec" and continue with the
next flow descriptor.

- Set K_E_Police_flag on if any of these PSBs have
the E_Police flag on, otherwise set
K_E_Police_flag off. Set K_M_Police_flag on if zero, the style has wildcard scope and there port is more
than one PSB "wild"
and can match any port in the scope, otherwise, set
K_M_Police_flag off. a FILTER_SPEC.

- Compute K_Tspec Sender_Template

This parameter is included as the sum an escape mechanism to
support a more general definition of the SENDER_TSPEC
objects, if any, in sender
("generalized source port"). Normally this set of PSBs.

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

- Compute the effective kernel flowspec,
K_Flowspec, as Sender_Tspec

This optional parameter describes the maximum of traffic flow to
be sent. It may be included to prevent over-
reservation on the FLOWSPEC values
in these RSB's initial hops.

- Compute Data_TTL

This is the effective kernel filter spec K_Filter
by merging (non-default) IP Time-To-Live parameter
that is being supplied on the FILTER_SPEC objects in these
RSB's.

6. If this reservation has wildcard scope and this data packets. It is
needed to ensure that Path messages do not
the first flow descriptor in the message, one of the
filter specs must have changed; delete a
scope larger than multicast data packets.

- Sender_Policy_Data

This optional parameter passes policy data for the old one and
install
sender. This data may be supplied by a system
service, with the new: application treating it as opaque.

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

Internet Draft RSVP Specification July November 1995

TC_DelFilter( old_Fhandle );

Fhandle = TC_AddFilter( Rhandle, SESSION, K_filter)

Then continue with the next flow descriptor.

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

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

o Reserve

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

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

A receiver uses this call fails, build and send to make or to modify a RERR message
specifying "Admission control failed", and continue
with resource
reservation for the next flow descriptor. Otherwise, record session registered as `session-id'.
The first RESERVE call will initiate the
kernel handle Rhandle returned by 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 in
admission control failure).

The optional `receiver_address' parameter may be used by a
receiver on a multihomed host (or router); it is the
RSB(s). Then call:

TC_AddFilter( Rhandle, SESSION, K_Filter)

to set the filter, and continue with IP
address of one of the next flow
descriptor.

However, node's interfaces. The ACK_flag
should be set on if there was a previous kernel reservation
with handle Rhandle, and ACK is desired, off
otherwise. The `style' parameter indicates the flowspec has changed,
call:

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

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

If parameters depend upon
the flowspec is unchanged style, but the generally these will include appropriate
flowspecs, filter spec has
changed, install 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 for the new:

TC_DelFilter( old_Fhandle session specified by
session-id. The node then sends appropriate teardown
messages and ceases sending refreshes for this session-id.

o Error/Event Upcalls

Upcall: <Upcall_Proc>( )
Fhandle = TC_AddFilter( Rhandle, SESSION, K_filter) -> session-id, Info_type,

[ Error_code , Error_value ,

Error_Node , LUB-Used, ]

List_count, [ Flowspec_list,]

[ Filter_spec_list, ] [ Advert_list, ]

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

Internet Draft RSVP Specification July November 1995

Then continue with

[ Policy_data ]

Here "Upcall_Proc" represents the next flow descriptor.

If processing a RESV message finds an error, upcall procedure whose
address was supplied in the SESSION call.

This upcall may occur asynchronously at any time after a RERR message is
created containing flow descriptor
SESSION call and before a RELEASE call, to indicate an ERRORS object. The
Error Node field
error or an event. Currently there are five upcall types,
distinguished by the Info_type parameter:

1. Info_type = Path Event

A Path Event upcall results from receipt of the ERRORS object (see Appendix A) first
PATH message for this session, indicating to a
receiver application that there is set at least one
active sender.

This upcall provides synchronizing information to the IP address of OI,
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 message is sent unicast to NHOP.

RESV TEAR MESSAGE ARRIVES

A RTEAR message arrives on outgoing interface OI.

o Initialize flag Tear_Needed to False.

o Execute the following steps for each flow descriptor, i.e., number in each (FLOWSPEC, FILTERSPEC) pair, list; where these objects are
missing, corresponding null objects must appear. The
Error_code, Error_value, LUB-Used flag, and
Policy_data parameters will be undefined in the flow descriptor
list:

1. Find matching RSB for the 4-tuple: (SESSION, NHOP,
style, FILTER_SPEC). If no RSB is found, continue
with next flow descriptor. this
upcall.

2. Delete the RSB.

3. If there are no more RSBs for the same (SESSION, OI,
FILTER_SPEC) triple, call Info_type = Resv Event

A Resv Event upcall is triggered by the kernel interface to
delete receipt of
the reservation:

TC_DelFlowspec( K_handle )

and set Tear_Needed to True.

4. Otherwise (there are other RSB's first reservation message or by modification of a
previous reservation state, for the same
reservation), recompute K_Flowspec this session.

`List_count' will be 1, and call Flowspec_list will
contain one FLOWSPEC, the kernel
interface module:

TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec) effective QoS that would be
applicable to update the reservation. If this kernel call fails,
return; the prior reservation application itself.
Filter_spec_list and Advert_list will remain contain one
NULL object. The Error_code, Error_value, LUB-Used
flag, and Policy_data parameters will be undefined in place.

o If Tear_Needed is False (the resulting merged state may
have changed but is still
this upcall.

3. Info_type = Path Error

An Path Error event indicates an error in place), then execute the RESV
REFRESH sequence below, drop RTEAR message, and return. sender
information that was specified in a SENDER call.

Braden, Zhang, et al. Expiration: January May 1996 [Page 61] 58]

Internet Draft RSVP Specification July November 1995

o Otherwise, need to create new RTEAR message for each PHOP,

The Error_code parameter will define the error, and perhaps
Error_value may supply some RESV refresh messages.

Set Refresh_Needed flag to False. Do additional (perhaps
system-specific) data about the following for
each sender Si (in error. The
Error_Node parameter will specify the path stat) whose ROUTE_MASK includes IP address of
the outgoing interface OI and for each PHOP:

1. Pick each flow descriptor Fj in node that detected the RTEAR message
whose FILTER_SPEC matches Si, error.

`List_count' will be 1, and do Filter_spec_list will
contain the following.

- If there is no RSB whose FILTER_SPEC matches Si,
then add Fj to Sender_Template supplied in the new RTEAR message being built.

- Otherwise (there is a matching RSB), note SENDER
call; Flow_Spec_list and Advert_list will each
contain one NULL object. The Policy_data parameter
will contain any POLICY_DATA objects in the
incoming interface of Si as PERR
message.

4. Info_type = Resv Error/Confirmation

An Resv Error/Confirmation event indicates an interface needing error
in a RESV refresh message and set the Refresh_Needed
flag True.

2. If the new RTEAR reservation message contains any flow
descriptors, forward it to PHOP.

If which this application
contributed, or the scope is wildcard, include only receipt of a single flow
descriptor in the RACK message.

o If The
Error_code parameter will define the Refresh_Needed flag is true, then execute error or
confirmation. For an error, Error_value may supply
some additional (perhaps system-specific) data. The
Error_Node parameter will specify the
RESV_REFRESH sequence below, for IP address of
the incoming interfaces node that have been noted.

RESV ERROR MESSAGE ARRIVES

o If there is no state for SESSION, then drop detected the RERR
mesasge event being reported.

Filter_spec_list and return.

o For each RSB, do Flowspec_list will contain the following. Note that an RSB implies
an outgoing interface OI
FILTER_SPEC and a next hop NHOP.

1. If OI differs FLOWSPEC objects from the incoming interface through
which the RERR message arrived, continue with the next
RSB.

2. Compare the FILTER_SPEC(s) in the error flow
descriptor with (see Section 3.1.5). List_count will
specify the FILTER_SPEC(s) number of FILTER_SPECS in
Filter_spec_list, while there will be one FLOWSPEC in
Flowspec_list. For an error, the RSB. If no
match, continue with Policy_data
parameter will contain any POLICY_DATA objects in the next RSB.

Otherwise, form a new
RERR message.

Although RSVP messages indicating path or resv events may
be received periodically, the API should make the
corresponding asynchronous upcall to the application only
on the first occurrence or when the information to be
reported changes. All error flow descriptor with and confirmation events
should be reported to the
subset application.

3.9.2 RSVP/Traffic Control Interface

In an RSVP-capable node, enhanced QoS is achieved by a group of FILTER_SPECs that matched.
inter-related traffic control functions: a packet classifier,

Braden, Zhang, et al. Expiration: January May 1996 [Page 62] 59]

Internet Draft RSVP Specification July November 1995

3. Compare the FLOWSPEC in

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

M_Police_Flag, B_Police_Flag )

The TC_Flowspec parameter defines the RERR message with desired effective
QoS to admission control; its value is computed as the
FLOWSPEC in
maximum over the RSB. If they don't match along any
coordinate (i.e., if flowspecs of different next hops (see the RSB FLOWSPEC is strictly
`smaller'), continue with
Compare_Flowspecs call below). It contains the next RSB.

If they agree on some but not all coordinates, turn on effective
reservation Tspec Resv_Te (although the LUB-used flag.

4. If NHOP in PSB is local API, deliver error RSVP daemon itself
has no means to
application via an upcall:

Call: <Upcall_Proc>( session-id, Resv Error, k,
Error_code, Error_value, LUB-Used,
Filter_Spec_List, Flowspec_List, NULL,
NULL)

and continue with the next RSB. Here k,
Filter_Spec_List, and Flowspec_List are constructed
from extract the new error flow descriptor.

5. If Tspec). The TC_Tspec
parameter defines the RESV message has wildcard scope, use its SCOPE
object SC.In to construct a SCOPE object SC.Out to be
forwarded. SC.Out should contain those effective sender
addresses Tspec Path_Te (see
Section 2.3). We assume that appeared traffic control takes the
min of Resv_Te and Path_Te (see step (4) in SC.In Section 2.3).

E_Police_Flag, M_Police_Flag, and that route to OI
[LIH?], B_Police_Flag are
Boolean parameters whose values should be set as determined by scanning the PSB's. If
SC.Out described
in Section 3.6.

The TC_AddFlowspec call returns an error code if Flowspec
is empty, continue with malformed or if the next RSB.

6. Create requested resources are
unavailable. Otherwise, it establishes a new RERR message containing the new error
flow descriptor and send reservation
channel corresponding to Rhandle. It returns the NHOP address specified
by the RSB. Include SC.Out if the scope is wildcard.

7. Continue with the next RSB. opaque
number Rhandle for subsequent references to this
reservation.

o Drop the RERR message and return.

PATH REFRESH Modify Reservation

Call: TC_ModFlowspec( Rhandle, new_Flowspec,

Sender_Tspec, E_Police_flag,

M_Police_Flag, B_Police_Flag )

This sequence may be entered by either the expiration of call can modify an existing reservation. If
new_Flowspec is included, it is passed to Admission
Control; if it is rejected, the path
refresh timer for a particular session, or immediately current flowspec is left
in force. The corresponding filter specs, if any, are not
affected. The other parameters are defined as the result
of processing a PATH message turning on the Path_Refresh_Needed flag.

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

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

Internet Draft RSVP Specification July November 1995

o Pass Delete Flowspec

Call: TC_DelFlowspec( Rhandle )

This call will delete an existing reservation, including
the ADSPEC flowspec and SENDER_TSPEC objects present in the PSB all associated filter specs.

o Add Filter Spec

Call: FHandle = TC_AddFilter( Rhandle, Session , FilterSpec )

This call is used to associate an additional filter spec
with the kernel reservation specified by the given Rhandle,
following a successful TC_AddFlowspec call. This call TC_Advertise, and get back
returns a modified ADSPEC
object. Pack this modified object into filter handle FHandle.

o Delete Filter Spec

Call: TC_DelFilter( FHandle )

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 is used for OPWA to compute the PATH message being
built. outgoing
advertisement New_Adspec for a specified interface.

o Create Preemption Upcall

Upcall: TC_Preempt() -> RHandle, Reason_code

In order to grant a sender descriptor sequence containing new reservation request, the
SENDER_TEMPLATE, SENDER_TSPEC, and POLICY_DATA objects, if
present admission
control and/or policy modules may be allowed to preempt an
existing reservation. This might be reflected in an
upcall to RSVP, passing the PSB. Pack RHandle of the sender descriptor into preempted
reservation, and some indication of the PATH
message being built.

o If reason.

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

Internet Draft RSVP Specification November 1995

3.9.3 RSVP/Routing Interface

An RSVP implementation needs the PSB has following support from the E_Police flag on
packet forwarding and if interface OI is not
capable routing mechanisms of policing, turn the E_Police flag on in the PATH
message being built. node.

o Compute the IP TTL Promiscuous Receive Mode for RSVP Messages

Any packet received for IP protocol 46 must be diverted to
the PATH message as one less than RSVP program for processing, without being forwarded.
On a router, the
maximum identity of the TTL values from the senders included in the
message. However, if the result interface, real or
virtual, on which it is zero, return without sending received must also be available to
the PATH message. RSVP daemon.

o If the maximum size of the Route Query

To forward PATH message is reached, send the
packet out interface OI and start packing a new one.

RESV REFRESH

This sequence may PTEAR messages, an RSVP daemon must be entered by either the expiration of
able to query the
reservation refresh timer routing daemon(s) for a particular session, 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 may or immediately as may
not depend upon SrcAddress, i.e., upon the result sender host IP
address, which is also the IP source address of processing a RESV or RTEAR the
message.

For each PHOP defined by Here IncInterface is the path state, scan interface through which
the RSBs, merge packet is expected to arrive; some multicast routing
protocols may not provide it.

If the
style, FLOWSPECs and FILTER_SPECs appropriately, build a new RESV
message, and send it Notify_flag is True, routing will save state
necessary to PHOP. Each message carries a NHOP object
containing issue unsolicited route change notification
callbacks (see below) whenever the local address of specified route
changes. Such callbacks will be enabled until routing
receives a route query call with the interface through which it is
sent.

The details Notify_Flag set
False.

A multicast route query may return an empty
OutInterface_list if there are no receivers downstream of building the RESV messages depend upon the
shared/distinct option
a particular router. A route query may also return a `No
such route' error, probably as a result of the style. For each PHOP, do the
following:

o Distinct style

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

1. Select all RSB's whose FILTER_SPECs match the
SENDER_TEMPLATE object for Si and whose OI matches a bit transient
inconsistency in the ROUTE_MASK of the PSB routing (since a PATH or PTEAR
message for Si.

2. Compute the maximum over the FLOWSPEC objects of requested route did arrive at this set
of RSB's, and merge their FILTER_SPEC, STYLE, and node).
In either case, the local state should be updated as

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

Internet Draft RSVP Specification July November 1995

POLICY_DATA objects.

3. Append the (FLOWSPEC, FILTER_SPEC pair) to

requested by the RESV message
being built message, although it cannot be forwarded
further. Updating local state will make path state
available immediately for destination PHOP. When the packet fills, a new local receiver, or upon completion of all PSB's it will
tear down path state immediately.

o Route Change Notification

If requested by a route query with the same PHOP, send
it.

o Shared style

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

2. For all selected RSB's for all Si corresponding routing daemon may provide an asynchronous callback to a given
PHOP:

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

- Merge
the metching FILTER_SPEC objects; this will in
general result in RSVP daemon that a list of non-overlapping
FILTER_SPECs, but where there are overlaps due specified route has changed.

Ucast_Route_Change( ) -> DestAddress, OutInterface

Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,

[ IncInterface, ] OutInterface_list

o Outgoing Link Specification

RSVP must be able to
wildcards, use the `wildest'.

- Merge the STYLE and POLICY_DATA objects.

- Place the resulting merged objects into force a RESV message
and send it (multicast) datagram to PHOP.

3. If the scope is wildcard, a forwarded RESV must contain be
sent on a
SCOPE object. The set of IP addresses in specific outgoing virtual link, bypassing the SCOPE object
sent to
normal routing mechanism. A virtual link may be a given PHOP real
outgoing link or a multicast tunnel. Outgoing link
specification is formed as follows.

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

- Intersect that set with the set necessary to send different versions of sender hosts listed
in path state for PHOP.

- If the resulting set
an outgoing PATH message on different interfaces. It is empty, no RESV should be
forwarded
also necessary in some cases to this PHOP.

Braden, Zhang, et al. Expiration: January 1996 [Page 65]

Internet Draft RSVP avoid routing loops.

o Source Address Specification July 1995

APPENDIX A. Object Definitions

C-Types are defined for

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

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

A.1 SESSION Class

SESSION Class = 1.

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

+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| ////// | Flags | DestPort |
+-------------+-------------+-------------+-------------+
used when sending PATH messages.

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

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

DestAddress

The Interface List Discovery

RSVP must be able to learn what real and virtual
interfaces are active, with their IP unicast or multicast destination address of the
session.

Flags

0x01 = E_Police flag

The E_Police flag is used addresses.

3.9.4 Service-Dependent Manipulations

Flowspecs, Tspecs, and Adspecs are opaque objects to RSVP;
their contents are defined in PATH messages service specification documents.
In order to determine manipulate these objects, RSVP daemon must have
available to it the following service-dependent routines.

o Compare Flowspecs

Braden, Zhang, et al. Expiration: January May 1996 [Page 66] 63]

Internet Draft RSVP Specification July November 1995

Compare_Flowspecs( Flowspec_1, Flowspec_2 ) -> result_code

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 the effective "edge" of
Tspecs that are contained. Although the network, RSVP daemon
cannot itself parse a flowspec to control traffic
policing. If extract the sender host is not itself capable of
traffic policing, Tspec, it will set this bit on in PATH
messages it sends. The first node whose RSVP is capable
of traffic policing will do so (if appropriate to the
service) and turn
can use the flag off.

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

DestPort 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 ) -> result_code

The UDP/TCP destination port for the session. Zero may be 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 indicate a `wildcard', i.e., any port.

Other SESSION C-Types could be defined in the future to
support other demultiplexing conventions in the transport-
layer or application layer. compute Path_Te (see Section 2.3).

Braden, Zhang, et al. Expiration: January May 1996 [Page 67] 64]

Internet Draft RSVP Specification July 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 = 2

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

4. Message Processing Rules

This object section provides the IP address a generic description of the interface through which
the last RSVP-knowledgeable hop forwarded this message. The
Logical Interface Handle rules for RSVP
operation. It is intended to outline a 32-bit number which set of algorithms that will
accomplish the needed function. An actual implementation may be used to
distinguish logical outgoing interfaces as described use
different but equivalent algorithms. This section assumes the
generic interface calls defined in Section
4.2; it should be identically zero if there is no logical
interface handle.

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

Internet Draft RSVP Specification July 1995

A.3 INTEGRITY Class

INTEGRITY class = 4.

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

A.4 TIME_VALUES Class

TIME_VALUES class = 5.

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

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

Refresh Period

The refresh timeout period R used 3.9 and the following data
structures. An actual implementation may use additional or different
data structures and interfaces.

[NOTE: This section is always the last to generate be updated when changes are
made, and it is neither correct nor complete at the present time.
Therefore, when this message; section disagrees with the rest of the text, you
should believe the rest of the text!]

o PSB -- Path State Block

Each PSB holds path state for a particular (session, sender)
pair, defined by SESSION and SENDER_TEMPLATE objects,
respectively, received in milliseconds.

Max Refresh Period a PATH message.

PSB contents include the following values from a PATH message:

- The largest R value that previous hop IP address from a node is allowed to apply to PHOP object (required)

- LIH, the
downstream state for this session. A node may refuse to
accept this requirement, Logical Interface Handle from the previous hop,
from a PHOP object (required).

- The remaining IP TTL (required)

- SENDER_TSPEC (required)

- 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 ignoring routing: OutInterface_list, the message containing list of outgoing interfaces
for this TIME_VALUES object (sender, destination), and sending IncInterface, the expected
incoming interface. For a "R too small" error
message.

If this value is zero, no limit unicast destination,
OutInterface_list contains one entry and IncInterface is set.

Braden, Zhang, et al. Expiration: January 1996 [Page 69]

Internet Draft RSVP Specification July 1995

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

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

Error Node Address

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

Flags

0x01 = LUB-Used

The use of this flag is described RSB -- Reservation State Block

Each RSB holds a reservation request that arrived in section 4.1.5.

Error Code

A one-octet error description.

Error Value

A two-octet field containing additional information about a
particular RESV message, corresponding to the triple: (session,
next hop, filter_spec_list). Here "filter_spec_list" may be a

Braden, Zhang, et al. Expiration: January May 1996 [Page 70] 65]

Internet Draft RSVP Specification July November 1995

error. Its contents depend upon

list of FILTER_SPECs (for SE style), a single FILTER_SPEC (FF
style), or empty (WF style). We use the Error Type.

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

A.6 SCOPE Class

SCOPE class = 7.

This object contains symbol "FILTER_SPEC*"
to indicate such a FILTER_SPEC list.

RSB contents include:

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

- FLOWSPEC*, list of IP addresses, used for routing
messages with wildcard scope without loops. FLOWSPEC objects (required)

- The addresses must be
listed in ascending numerical order.

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

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

o IP6 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 the reservation specifications that have been handed
to traffic control for specific outgoing interfaces. In
general, information in TCSB's is derived from RSB's for the
same outgoing interface. Each TCSB defines a single reservation
for a particular triple: (session, OI, filter_spec_list). TCSB
contents include:

- TC_Flowspec, the effective flowspec, i.e., the maximum over
the corresponding FLOWSPEC values from matching RSB's.
TC_Flowspec is passed to traffic control to make the actual
reservation. The Tspec part of TC_Flowspec is the
effective reservation Tspec Resv_Te (Section 2.3).

- TC_Tspec, equal to the effective sender Tspec Path_Te.

- Police Flags

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

- Rhandle, F_Handle_list

Handles returned by the traffic control interface,
corresponding to the reservation (flowspec) and to the list object: Class = 7, C-Type = 2

+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 Src Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
// //
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 Src Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
of filter specs.

Boolean flags Path_Refresh_Needed, Resv_Refresh_Needed, and

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

Internet Draft RSVP Specification July November 1995

A.7 STYLE Class

STYLE class = 8.

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

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

Style ID

An integer identifying

Tear_Needed will also be used in this section.

[LZ: It might be very helpful to have a short section to summarize
the style, as follows:

0 = No ID assigned; use option vector.

1 = WF

2 = FF

3 = SE

Option Vector

A set management of bit all the timers.]

MESSAGE ARRIVES

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

Reassemble a fragmented message.

Parse the reservation
options. If new options are added sequence of objects in the futre,
corresponding fields in message to verify the option vector will be assigned
from length
field of the least-significant end. If common header; discard message if there is a node mismatch.

If the message type is not PATH or PTEAR and if the IP destination
address does not recognize
a style ID, it may interpret as much match any of the option vector as
it can, ignoring new fields that may have been defined.

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

19 bits: Reserved

2 bits: Sharing control

00b: Reserved

01b: Distinct reservations

10b: Shared reservations

11b: Reserved

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

Internet Draft RSVP Specification July 1995

3 bits: Scope control

000b: Reserved

001b: Wildcard scope

010b: Explicit scope

011b - 111b: Reserved

The low order bits addresses of the option vector are determined by local interfaces,
then forward the
style id, as follows:

WF 10001b
FF 01010b
SE 10010b

Braden, Zhang, et al. Expiration: January 1996 [Page 73]

Internet Draft RSVP Specification July 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 message to IP destination address and return.

Verify the int-serv working group.

o Class = 9, C-Type = 254: Unmerged Flowspec List

+-------------+-------------+-------------+-------------+
| |
// FLOWSPEC 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 1 //
| |
+-------------+-------------+-------------+-------------+
| |
// FLOWSPEC sequence in the message as
follows. The flags Path_Refresh_Needed and Resv_Refresh_Needed
flags are initially off.

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

o If the DstPort in the SESSION object 2 //
| |
+-------------+-------------+-------------+-------------+
// //
// //
+-------------+-------------+-------------+-------------+
| |
// FLOWSPEC is zero but the
SrcPort in the SENDER_TEMPLATE object k //
| |
+-------------+-------------+-------------+-------------+

This is non-zero, build a container C-Type, used to enclose
send a set of FLOWSPEC
objects that could not be merged at "Conflicting Src Port" PERR message, drop the next hop downstream
because they include unrecognized C-Types. The node that
receives this object may merge those it recognizes PATH
message, and
forward return.

o Search for a path state block (PSB) whose (SESSION,
SENDER_TEMPLATE) pair matches the rest corresponding objects in another Unmerged Flowspec List object.
the message, considering any wildcard ports.

o If, during the PSB search, a PSB is found whose session
matches the DestAddress and Protocol Id fields of the
received SESSION object, but the DstPorts differ and one is
zero, then build and send a "Conflicting Dst Port" PERR
message, drop the PATH message, and return.

Braden, Zhang, et al. Expiration: January May 1996 [Page 74] 67]

Internet Draft RSVP Specification July 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) |
+-------------+-------------+-------------+-------------+
| Protocol Id | ////// | SrcPort |
+-------------+-------------+-------------+-------------+ 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 IP6 FILTER_SPEC object: Class = 10, C-Type = 2

+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 If there was no matching PSB, then:

1. Create a new PSB.

2. Call the appropriate Route_Query routine, using
DestAddress from SESSION and (for multicast routing)
SrcAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | ////// | SrcPort |
+-------------+-------------+-------------+-------------+ from SENDER_TEMPLATE. Store the values of
OutInterface_list and IncInterface into the PSB.
However, if the sender is from the local API, then
instead of invoking routing, set OutInterface_List to
the single interface whose address matches the sender
address; IncInterface is undefined in this case.

3. If IncInterface is defined and if a multicast message
arrived on an interface different from IncInterface,
drop the message and return.

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

5. Copy contents of the SESSION, SENDER_TEMPLATE,
SENDER_TSPEC, and PHOP (IP address and LIH) objects
into the PSB. Store the received TTL into the PSB.
Copy into the PSB either of the following objects that
are present: POLICY_DATA and ADSPEC.

6. Turn on the Path_Refresh_Needed flag.

o Otherwise (there is a matching PSB and there is no dest
port conflict):

1. If there is no route change notification in place,
call the appropriate Route_Query routine using
DestAddress from SESSION and (for multicast routing)
SrcAddress from SENDER_TEMPLATE.

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

- If 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, or SENDER_TSPEC
differs between the 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 the Path_Refresh_Needed flag.

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

However, if the PATH message being processed came from
a local application and if there is reservation state
for this session, then make 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.

o If the message arrived with a TTL different from Send_TTL
in the RSVP common header, set the Non_RSVP flag on in the
PSB.

o If 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 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} )

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

PATH TEAR MESSAGE ARRIVES

o Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair
matches the corresponding objects in the message. If no
matching PSB is found, drop the PTEAR message and return.

o Forward a copy of the PTEAR message to each outgoing

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

Internet Draft RSVP Specification November 1995

interface listed in OutInterface_list of the PSB.

o Find each RSB that matches this PSB, i.e., whose
FILTER_SPEC object matches the SENDER_TEMPLATE in the PSB
and 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.

o Delete the PSB.

o Drop the PTEAR message and return.

PATH ERROR MESSAGE ARRIVES

o Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair
matches the corresponding objects in the message. If no
matching PSB is found, drop the PERR message and return.

o If the previous hop address in the PSB 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 is ignored. [LZ: Why we don't send these objects
up to application? They might of some help to understand
the errors.] Drop the PERR message and return.

o Otherwise, send a copy of the PERR message to the PHOP IP
address, drop the PERR message, and return.

RESV MESSAGE ARRIVES

Initially, the Resv_Refresh_PHOP* list is empty and the
Resv_Refresh_Needed flag is off. These variables are used to
control immediate reservation refreshes.

o Process the NHOP object

The logical outgoing interface OI is taken from the LIH in
the NHOP object. (If the physical interface is not implied

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

Internet Draft RSVP Specification November 1995

by the LIH, it can be learned from the interface matching
the IP destination address).

o Check the SESSION object.

If there are no existing PSB's for SESSION then build and
send a RERR message (as described later) specifying "No
path information", drop the RESV message, and return.
However, do not send the RERR message if the style has
wildcard reservation scope and this is 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 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 object and 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 the following steps once, with
FILTER_SPEC* consisting of the list of FILTER_SPEC objects from
the flow descriptor.

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 is non-zero, build a send
a "Conflicting Src Port" RERR message, drop the RESV
message, and return.

o Find or create a reservation state block (RSB) for the
triple: (SESSION, NHOP, FILTER_SPEC*). Call this the
"active RSB".

o If the RSB is not new and if its style is incompatible with

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

Internet Draft RSVP Specification November 1995

the STYLE object in the message, build and send a RERR
message specifying "Conflicting Style", drop the RESV
message, and return.

o Start or restart the cleanup timer on the the active RSB.

o If the active RSB is not new, check whether FLOWSPEC or
SCOPE objects have changed. If not, continue with the next
flow descriptor in the RESV message, if any.

o If the active RSB is new, set its OI and style, and copy
any FLOWSPEC, POLICY_DATA, and/or SCOPE objects into it.

o If there is a RESV_CONFIRM in the message, turn on
Resv_Refresh_Needed and save the object in the RSB.

o The active RSB must be new or changed. Compute the traffic
control parameters, using the following steps.

1. Locate the set of PSBs (senders) whose
SENDER_TEMPLATEs match FILTER_SPEC* in the active RSB
and whose OutInterface_list includes OI.

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

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

3. Add the PHOP from 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
is a shared style and there is more than one PSB in
the set.

5. Compute Path_Te as the sum of the SENDER_TSPEC objects
in this set of PSBs.

6. Scan all RSB's matching the SESSION and
Filter_Spec_list from the message.

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

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

Internet Draft RSVP Specification November 1995

incompatible with the specifying "Conflicting
Style", drop the RESV message, delete the RSB if
it has just been created, and return.

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

7. Consider the set of RSB's for the same (SESSION, OI,
Filter_Spec_list) triple from the message.

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

- Compute the effective kernel filter spec (list),
TC_Filter*. by merging the FILTER_SPEC* object
(lists) from these RSB's.

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

1. If none is found but style is SE, search for a TCSB
matching (SESSION, OI). If find one and if TCSB's
TC_Flowspec, Path_Te, and police flags match the
computed values, then

- Make an appropriate set of TC_DelFilter and
TC_AddFilter calls to transform the
Filter_Spec_list in the TCSB into the
Filter_Spec_list from the message.

- Set Resv_Refresh_Needed on, drop the RESV
message, and return.

2. Otherwise, if none is found:

- Create a new TCSB.

- Store TC_Flowspec, Filter_Spec_list, Path_Te, and
the police flags into TCSB.

[SCOPE?]

- Set Resv_Refresh_Needed on.

- Make the traffic control call:

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

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 )

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 in Filter_Spec_list, call:

Fhandle = TC_AddFilter( Rhandle, SESSION, F)

and record the returned Fhandle in the TCSB.

- Continue with the next flow descriptor.

3. Otherwise (found existing TCSB), check whether
TC_Flowspec, Path_Te, and/or any of the police flags
has changed, and if so:

- Store TC_Flowspec, Filter_Spec_list, Path_Te, and
the police flags into it.

[SCOPE?]

- Set Resv_Refresh_Needed on.

- Make the 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 the Resv_Refresh_Needed flag is now on, execute the RESV
REFRESH sequence (below) for each PHOP in the
Resv_Refresh_PHOP* set.

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

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

Internet Draft RSVP Specification November 1995

RESV 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., 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 the 4-tuple: (SESSION, NHOP,
style, Filter_Spec_list); call this the active RSB.
If no active RSB 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 the set of RSB's matching this TCSB. If
there are none:

- Call the traffic control 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 the same TCSB),

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

Internet Draft RSVP Specification November 1995

recompute TC_Flowspec and Path_Te (see RESV MESSAGE
ARRIVES). (This also adds the appropriate PHOP
addresses to the Resv_Refresh_PHOP* list>) If either
changed, update the TCSB, set flag Resv_Refresh_Needed
on, 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 the credential to make 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 If Tear_Needed and Resv_Refresh_Needed flags are both off,
then drop the RTEAR message and return.

o If Tear_Needed is off but Resv_Refresh_Needed is on, then
execute the RESV REFRESH sequence for each PHOP in the
Resv_Refresh_PHOP* set, drop the RTEAR message, and return.

o Otherwise (Tear_Needed is on), need to forward RTEAR and/or
RESV refresh messages.

Do the following for each PSB whose OutInterface_list
includes the outgoing interface OI:

1. Pick each flow descriptor Fj in the RTEAR message
whose FILTER_SPEC matches the PSB, and do the
following.

- If there is no RSB whose FILTER_SPEC matches the
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 PSB.

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

Internet Draft RSVP Specification November 1995

o If the Resv_Refresh_Needed flag is now on, execute the RESV
REFRESH sequence (below) for each PHOP in the
Resv_Refresh_PHOP* set.

If the Refresh_Needed flag is true, then execute the RESV
REFRESH sequence for the PSB's that have been noted.

o Drop the RTEAR message and 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 return.

o Do the following with each RSB for this SESSION whose OI
does not match In_If and whose FILTER_SPEC matches that in
the RERR message.

1. Copy the error flow descriptor from the incoming RERR
message.

2. Compare the FLOWSPEC in the RERR message with the
FLOWSPEC in the RSB. If they don't match along any
coordinate (i.e., if the RSB FLOWSPEC is strictly
`smaller'), continue 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 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)

and continue with the next RSB. Here k,
Filter_Spec_List, and Flowspec_List are constructed
from the error flow descriptor.

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

Internet Draft RSVP Specification November 1995

4. If the RESV 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
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.

5. 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 sender selection is
wildcard.

6. Continue with the next RSB.

o Drop the RERR message and return.

RESV CONFIRMATION ARRIVES

If the (unicast) IP address found in its RESV_CONFIRM object
matches an interface of the node, a confirmation upcall is made
to 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, the RACK message is forwarded immediately to the
address in the IP address in its RESV_CONFIRM object.

PATH REFRESH

This sequence sends a path refresh 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 the result
of the Path_Refresh_Needed flag being turned on during the
processing of a received PATH message.

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

o 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

o Create a sender 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 the traffic control call TC_Advertise. Insert the
modified ADSPEC object that is returned into the PATH
message being built.

o IP6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3

+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 SrcAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| /////// | Flow Label (24 bits) |
+-------------+-------------+-------------+-------------+

SrcAddress

The IP source 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 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.

RESV REFRESH

This sequence sends a sender host, reservation refresh towards a particular
previous hop with IP address PH. This sequence may be entered
by either the expiration of a reservation refresh timer or zero
directly as the result of the Resv_Refresh_Needed flag being
turned on as the result of processing a RESV or RTEAR message.

In general, this sequence considers each of the 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*'s
appropriately. It then builds a RESV message and sends it to indicate
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 `wildcard'. STYLE object from the first RSB and move it into

Braden, Zhang, et al. Expiration: January May 1996 [Page 75] 79]

Internet Draft RSVP Specification July November 1995

Protocol Id

The IP protocol Identifier,

the output message. (Note that the present set of
styles are never themselves merged; if future styles
can be merged, these rules will become more complex).

3. Compute the maximum/LUB over the FLOWSPEC objects of
this set of RSB's.

4. While computing the maximum/LUB, check for a
RESV_CONFIRM object in each RSB. If a RESV_CONFIRM
object is found and if the FLOWSPEC in that RSB 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 zero smaller than the largest, or if the result of
merging was a LUB, then create and send a RACK message
to indicate the address in the RESV_CONFIRM object.

- Include the RESV_CONFIRM object in the RACK
message.

- Build a `wildcard'.

SrcPort confirmation ERROR_SPEC object and
include it in the RACK message. The UDP/TCP source port for a sender, or zero Error_Node
parameter in this object should be the IP address
of OI from the RSB.

Then delete the RESV_CONFIRM object from the RSB.

5. Merge 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 indicate merge.

6. If the Need_Scope flag is on, compute a
`wildcard' (i.e., any port).

Flow Label

A 24-bit Flow Label, defined new SCOPE
object as the union of the SCOPE objects found in IP6. This value may be used
by the packet classifier to efficiently identify
RSB's.

7. Merge the packets
belonging to a particular (sender->destination) data flow. F_POLICY_DATA objects from the RSB's.

8. (All matching RSB's have been processed). The next

Braden, Zhang, et al. Expiration: January May 1996 [Page 76] 80]

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

step depends upon the style attributes.

Distinct reservation (FF) style

Pack the merged (FLOWSPEC, FILTER_SPEC,
F_POLICY_DATA) triplet into the message as IP6/UDP FILTER_SPEC object.

A.11 SENDER_TSPEC Class

SENDER_TSPEC class = 12.

The only current a flow
descriptor.

Shared reservation (SE, WF) styles

Merge (take the maximum) across all PSB's the
merged FLOWSPECS from the RSB's.

If the sender selection is not wildcard (i.e., if
it is SE), form the union of Tspec the FILTER_SPECs
obtained from the RSB's. For Wildcard sender
selection (WF) style, there is not filter spec to
merge.

9. If the Need_Scope flag is on, remove from the merged
SCOPE object all sender addresses that do not match
the set of PSB's for PH, and all senders addresses
that are local. If the resulting set is empty, no
RESV should be forwarded to this PHOP; return;
otherwise (set is not empty), move the new SCOPE
object into the message.

o (All PSB's have been processed). If a token bucket. shared reservation
style is being built, move the final merged FLOWSPEC,
F_POLICY_DATA, and FILTER_SPEC (if SE) objects into the
message.

o If a RESV_CONFIRM object was saved earlier, copy it into
the new RESV message and delete it from the RSB in which it
was found.

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

+-----------+-----------+-----------+-----------+
| b: Token Bucket Depth (bits) |
+-----------+-----------+-----------+-----------+
| r: Average data rate (bits/sec) |
+-----------+-----------+-----------+-----------+ Set the RSVP_HOP object in the message to contain the
IncInterface address through which it will be sent and the
LIH from (one of) the PSB's.

o Send the message to the address PH.

Braden, Zhang, et al. Expiration: January May 1996 [Page 77] 81]

Internet Draft RSVP Specification July November 1995

A.12 ADSPEC Class

ADSPEC class = 13.

[TBD]

Braden, Zhang, et al. Expiration: January 1996 [Page 78]

APPENDIX A. Object Definitions

C-Types are defined for the two Internet Draft RSVP Specification July 1995

A.13 POLICY_DATA 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

POLICY_DATA class = 14. 1.

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

[TBD]

+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+

o Unmerged POLICY_DATA IP/UDP SESSION object: Class = 14, C-Type = 254

This object is a container for a list of POLICY_DATA objects
(none of which may have 1, C-Type = 254). The contained objects
have not yet been merged. 2

+-------------+-------------+-------------+-------------+
| |
// POLICY_DATA object 1 //
+ +
| |
+-------------+-------------+-------------+-------------+
+ IP6 DestAddress (16 bytes) +
| |
// POLICY_DATA object 2 //
+ +
| |
+-------------+-------------+-------------+-------------+
// //
// //
+-------------+-------------+-------------+-------------+
| Protocol Id |
// POLICY_DATA object k // Flags | DstPort |
+-------------+-------------+-------------+-------------+

DestAddress

The IP unicast or multicast destination address of the
session. This parameter must be supplied.

Protocol Id

The IP Protocol Identifier for the data flow. This parameter
must be supplied.

Braden, Zhang, et al. Expiration: January May 1996 [Page 79] 82]

Internet Draft RSVP Specification July November 1995

APPENDIX B. Error Codes and Values

The following Error Codes are defined.

o Error Code

Flags

0x01 = 01: Admission failure

Reservation rejected by admission control.

For this Error Code, E_Police flag

The E_Police flag is used in PATH messages to determine
the 16 bits effective "edge" of the Error Value field are:

ussr cccc cccc cccc

where the bits are:

u = 0: RSVP should reject the message without updating local
state.

u = 1: RSVP may use message network, to update local state and forward
it.

ss = 00: Low order 12 bits contain a globally-defined sub-code
(values listed below).

ss = 10: Low order 12 bits contain a sub-code that control traffic
policing. If the sender host is specific
to local organization. not itself capable of
traffic policing, it will set this bit on in PATH
messages it sends. The first node whose RSVP is not expected capable
of traffic policing will do so (if appropriate to be able the
service) and turn the flag off.

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

DstPort

The UDP/TCP destination port for the session. Zero may be
used to indicate a numeric value.

ss `wildcard', i.e., any port.

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

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

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

o IP6 RSVP_HOP object: Class = 11: Low order 12 bits contain a sub-code that is specific
to 3, C-Type = 2

This object provides the service. RSVP IP address of the interface through which
the last RSVP-knowledgeable hop forwarded this message. The
Logical Interface Handle is not expected to a 32-bit number which may be able used to
interpret this except
distinguish logical outgoing interfaces as a numeric value. Since the
traffic control mechanism might substitute a different
service, this encoding may include some representation of
the service described in use.

r: Reserved bit, Section
3.2; it should be zero.

cccc cccc cccc: 12 bit code.

The following globally-defined sub-codes may appear in the low-
order 12 bits when uu = 00: identically zero if there is no logical
interface handle.

Braden, Zhang, et al. Expiration: January May 1996 [Page 80] 84]

Internet Draft RSVP Specification July November 1995

- Sub-code = 1: Delay bound cannot be met

- Sub-code

A.3 INTEGRITY Class

INTEGRITY class = 2: Requested bandwidth unavailable

- Sub-code 4.

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

A.4 TIME_VALUES Class

TIME_VALUES class = 11: Service conflict

- Sub-code 5.

o TIME_VALUES Object: Class = 12: Service unsupported

Traffic control can provide neither the requested service
nor an acceptable substitute.

- Sub-code 5, C-Type = 13: Bad Flowspec or Tspec value

Unreasonable request. High order 4 bits should be 000r, so
that 1

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

Refresh Period

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

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

Internet Draft RSVP will reject the message.

- Sub-code Specification November 1995

A.5 ERROR_SPEC Class

ERROR_SPEC class = 14: Rmax value too small.

Rmax would result in excessive refresh overhead. 6.

o Error Code IPv4 ERROR_SPEC object: Class = 02: Administrative rejection

Reservation has been rejected for administrative reasons.

For this 6, C-Type = 1

+-------------+-------------+-------------+-------------+
| IP4 Error Code, the high order 4 bits of the Node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| Flags | Error Value
field are assigned as for Code | Error Value |
+-------------+-------------+-------------+-------------+

o IP6 ERROR_SPEC object: Class = 01 (above). For this case, the
following global sub-codes may be used:

- Sub-code = 1: Required credential(s) not presented.

- Sub-code = 2: Request too large

Reservation request exceeds allowed value for this user
class.

- Sub-code = 3: Insufficient quota or balance.

- Sub-code 6, C-Type = 4: Administrative preemption

o 2

+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 Error Code = 03: No path information for this Resv

RSVP should reject the message.

There is path information, but it does not include the sender
specified in any | Error Value |
+-------------+-------------+-------------+-------------+

Error Node Address

The IP address of the Filterspecs listed node in which the Resv message.
RSVP should reject error was detected.

Flags

0x01 = LUB-Used

The use of this flag is described in section 3.1.5.

Error Code

A one-octet error description.

Error Value

A two-octet field containing additional information about the message.

Braden, Zhang, et al. Expiration: January May 1996 [Page 81] 86]

Internet Draft RSVP Specification July November 1995

o Error Code = 05: Ambiguous path

Sender specification is ambiguous with existing path state.
RSVP should reject

error. Its contents depend upon the message.

o Error Code = 06: Ambiguous filter spec

Filter spec matches more than one sender, in style that requires
a unique match. RSVP should reject the message.

o Type.

The values for Error Code = 07: Conflicting or unknown style

Reservation style conflicts with style(s) of existing
reservation state, or it is unknown. If the high-order bit of and Error Value is zero, RSVP should reject the message.

o Error Code are defined in Appendix
B.

A.6 SCOPE Class

SCOPE class = 11: Missing required object

RSVP was unable to find or construct required 7.

This object data from
message. Error Value will contains a list of IP addresses, used for routing
messages with wildcard scope without loops. The addresses must be Class-Num that is missing. RSVP
should reject the message.
listed in ascending numerical order.

o Error Code IPv4 SCOPE List object: Class = 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 7, C-Type = 1

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

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

Internet Draft RSVP is going to reject the message. Specification November 1995

A.7 STYLE Class

STYLE class = 8.

o Error Code STYLE object: Class = 13: Unknown object 8, C-Type

Error Value will contain 16-bit value composed of (Class-Num,
C-Type) of object. This error should be sent only if RSVP is
going to should reject the message.

o Error Code = 14: Object error 1

+-------------+-------------+-------------+-------------+
| Option Vector |
+-------------+-------------+-------------+-------------+

Option Vector

A non-specific error indicating bad format or contents set of an
object. The Error Value bit fields giving values for the reservation
options. If new options are added in the future,
corresponding fields in the option vector will contain 16-bits value (Class-Num,
C-Type) be assigned
from header the least-significant end. If a node does not recognize
a style ID, it may interpret as much of bad object. RSVP should reject the
message.

o Error Code = 21: Traffic Control error

Some system error was detected and reported by option vector as
it can, ignoring new fields that may have been defined.

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

27 bits: Reserved

2 bits: Sharing control modules.

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 Error Value will contain a system-specific
value giving more information about low order bits of the error.

o Error Code = 22: RSVP System error option vector are determined by the
style, as follows:

Braden, Zhang, et al. Expiration: January May 1996 [Page 82] 88]

Internet Draft RSVP Specification July November 1995

The Error Value field will provide implementation- dependent
information on the error.

WF 10001b
FF 01010b
SE 10010b

Braden, Zhang, et al. Expiration: January May 1996 [Page 83] 89]

Internet Draft RSVP Specification July November 1995

APPENDIX C. UDP Encapsulation

As described earlier, RSVP control messages are intended to be
carried directly within IP datagrams as "raw packets". Implementing
RSVP in a node will require an intercept in the packet forwarding
path for protocol 46, and the necessary kernel change is incorporated
in the recent releases

A.8 FLOWSPEC Class

FLOWSPEC class = 9.

o Class = 9, C-Type = 1: int-serv flowspec

The contents of IP multicasting

There are particular circumstances where it may this object will be desirable to
encapsulate RSVP messages specified in UDP packets, as a short-term measure.

1. UDP encapsulation can be used between hosts and the last- (or
first-) hop router(s). This may ease installing RSVP on some
host systems, documents
prepared by avoiding a kernel change for the RSVP
intercept.

2. UDP encapsulation may be useful for legal penetration of
firewalls.

3. UDP encapsulation might be used on each interface of an
intermediate RSVP router whose kernel supported multicast but
which did not have the RSVP intercept.

In the following discussion, we concentrate on (1) and (2).

Figure 13 shows a typical situation for a host running RSVP. Here
two RSVP-capable hosts Hu and Hr within a corporation are connected
to the Internet through some arbitrarily complex set of networks and
routers that is labelled the "Corporate cloud". The border router R
is assumed to be RSVP-capable, but the corporate cloud is not.

_ _ _ _
______ ( ) RSVP-capable int-serv working group.

o Class = 9, C-Type = 254: Unmerged Flowspec List

+-------------+-------------+-------------+-------------+
| | ( ) router
// FLOWSPEC object 1 //
| |
+-------------+-------------+-------------+-------------+
| |
// FLOWSPEC object 2 //
| |
+-------------+-------------+-------------+-------------+
// //
// //
+-------------+-------------+-------------+-------------+
| Hu |-----( Corporate ) ______
|______| ( ) a| |b
( cloud )-----| R |---->Internet
______ ( ) |______| |
// FLOWSPEC object k //
| ( ) | Hr |------( )
|______| (_ _ _ _ _)

Figure 13: End Host Situation

We assume that Hu
+-------------+-------------+-------------+-------------+

This is a "UDP-only" host that requires UDP
encapsulation, while Hr is container C-Type, used to enclose a "raw-capable" host set of FLOWSPEC
objects that can use raw RSVP could not be merged at the next hop downstream
because they include unrecognized C-Types. The node that
receives this object may merge those it recognizes and
forward the rest in another Unmerged Flowspec List object.

Braden, Zhang, et al. Expiration: January May 1996 [Page 84] 90]

Internet Draft RSVP Specification July November 1995

packets. The UDP encapsulation scheme should allow RSVP
interoperation among an arbitrary topology of Hr hosts and Hu hosts
as well as routers R.

RESV messages are always sent unicast; once path state has been
established, the unicast destination address of each RESV message is
known. If the path state also indicates whether the next host node
needs UDP encapsulation,

A.9 FILTER_SPEC Class

FILTER_SPEC class = 10.

o IPv4 FILTER_SPEC object: Class = 10, C-Type = 1

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

o IP6 FILTER_SPEC object: Class = 10, C-Type = 2

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

o IP6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3

+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IP6 SrcAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| /////// | Flow Label (24 bits) |
+-------------+-------------+-------------+-------------+

SrcAddress

The IP source address for a RESV message can simply be sent to the
next-hop node, either in raw mode sender host, or with UDP encapsuation.

UDP encapsulation of PATH messages poses a more difficult problem.
To solve it, we define two new well-known multicast addresses G1 and
G2, and zero to indicate
a well-known UDP port Pu. Then the table in Figure 14 shows
the rules. Under the `Send' column, the notation is <mode>(destaddr,
destport, TTL), where TTL is the IP-layer hop count. `wildcard'.

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

Internet Draft RSVP Specification November 1995

SrcPort

The `Receive'
column shows the group that is joined and, where relevant, the UDP
Listen port. T1 and T2 are configured IP TTL values used UDP/TCP source port for
encapsulation, while Tr is the local TTL a sender, or zero to indicate a
`wildcard' (i.e., any port).

Flow Label

A 24-bit Flow Label, defined in IP6. This value of the specific PATH
message. Finally, D is may be used
by the DestAddress for packet classifier to efficiently identify the packets
belonging to a particular session.

Node Node Type Send Receive
___ __________ _______________ _______________
Hu UDP-only host UDP(G1,Pu,T1) UDP(G1,Pu)
and UDP(G2,Pu)

Hr Raw-mode host UDP(G1,Pu,T1) UDP(G1,Pu)
and Raw(D,,Tr) and Raw()

R Router
Interface a: UDP(G2,Pu,T2) UDP(G1,Pu)
and Raw(D,,Tr) and Raw()

Interface b: Raw(D,,Tr) Raw()

Figure 14: UDP Encapsulation Rules for Path Messages

Note that R and Hr must send their PATH messages twice, once with UDP
encapsulation and once in raw mode. In two cases (Hr -> R and Hr ->
Hr), each PATH message (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 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 of this object will be delivered twice. The router may take
steps to ignore specified in documents
prepared by the duplicates, but 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.

The contents of this redundancy actually has no
ill effect other than overhead for processing object will be specified in documents
prepared by the extra messages.

A router must keep track of which 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.

o Type 1 POLICY_DATA object: Class = 14, C-Type = 1

The contents of its interfaces are using UDP
encapsulation and which this object are not. A node can always listen for
UDP(G1,Pu) on each interface, and if it receives further study.

o Unmerged POLICY_DATA object: Class = 14, C-Type = 254

This object is a UDP-encapsulated container for a list of POLICY_DATA objects
(none of which may have C-Type = 254). The contained objects
have not yet been merged.

+-------------+-------------+-------------+-------------+
| |
// POLICY_DATA object 1 //
| |
+-------------+-------------+-------------+-------------+
| |
// POLICY_DATA object 2 //
| |
+-------------+-------------+-------------+-------------+
// //
// //
+-------------+-------------+-------------+-------------+
| |
// POLICY_DATA object k //
| |
+-------------+-------------+-------------+-------------+

Braden, Zhang, et al. Expiration: January May 1996 [Page 85] 95]

Internet Draft RSVP Specification July November 1995

PATH message, mark the corresponding path state as UDP-needed. Then
matching RESV messages will be correctly encapsulated.

Two provisions are necessary for this automatic determination of
encapsulation to work.

C1 A router must use different groups G1 and G2 for sending

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 1996 [Page 96]

Internet Draft RSVP Specification November 1995

APPENDIX B. Error Codes and
receiving, as already shown.

C2 Values

The TTL value T1 used following Error Codes are defined.

o Error Code = 01: Admission failure

Reservation rejected by a host must be exactly enough to reach
the router R.

If T1 is too small to pass through admission control.

For this Error Code, the corporate cloud, 16 bits of course
PATH messages will not be forwarded. If T1 is too large, multicast
routing in R will forward the UDP packet into Error Value field are:

ussr cccc cccc cccc

where the Internet until its
hop count expires. This will turn on UDP encapsulation between
routers within bits are:

u = 0: RSVP rejects the Internet, causing bogus UDP traffic. (Note message without updating local state.

u = 1: RSVP may use message to update local state and forward
the message.

ss = 00: Low order 12 bits contain a globally-defined sub-code
(values listed below).

ss = 10: Low order 12 bits contain a sub-code that
UDP packets addressed is specific
to G2 by a router will local organization. RSVP is not expected to be received by a
neighboring router).

However, there are possible situations where it will be impossible able to
find
interpret this except as a value of T1 that meets condition C2. Within the corporate
cloud there might be numeric value.

ss = 11: Low order 12 bits contain a multicast tunnel with an outgoing threshold
larger than the hop count through the cloud. Another possibility is
that there might be more than one border router R, with different
TTL's. There are several possible ways sub-code that C2 might be satisfied in
such cases.

1. It might be possible is specific
to configure the hosts' service. RSVP daemons with
the IP address for R; the daemons could then "unicast" PATH
messages to this address. This solution will be feasible as
long as the number of Hr and Hu hosts is small.

2. A particular host on the LAN including Hu could be designated as
an "RSVP relay host". This system would listen on (G1,Pu) and
be configured with the IP address of R. It could then forward
any (PATH) messages it received directly not expected to R, and T1 could be
set only large enough able to reach local hosts and
interpret this except as a numeric value. Since the relay.

Finally, manual configuration
traffic control mechanism might substitute a different
service, this encoding may include some representation of T1 could
the service in use.

r: Reserved bit, should be replaced by an expanding
ring search conducted by host RSVP daemons. This possibility is for
future study.

APPENDIX D. Experimental and Open Issues zero.

cccc cccc cccc: 12 bit code.

The following globally-defined sub-codes may appear in the low-
order 12 bits when ss = 00:

Braden, Zhang, et al. Expiration: January May 1996 [Page 86] 97]

Internet Draft RSVP Specification July November 1995

D.1 Reservation Compatability

How strong is

- 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 requirement 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 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 compatability administrative reasons.

The high order 4 bits of reservations in
different directions? For example, see Figure 11; should it be
possible to have incompatible reservation styles on the two
interfaces? If R1 requests a WF reservation and R2 requests a FF
reservation, it is logically possible to make Error Value field are assigned as
for Error Code = 01 (above). For Error Code = 02, the corresponding
reservations on 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 for this Resv

RSVP should reject the two different interfaces. The current
implementation does NOT allow this; instead, message.

o Error Code = 04: No sender information for this Resv

There is path information, but it prevents mixing of
incompatible styles in does not include the same session on a node, even if they
are on different interfaces.

D.2 Session Groups (Experimental)

Section 1.2 explained that a distinct destination address, and
therefore a distinct session, will be used for each sender
specified in one of the
subflows Filterspecs listed in a hierarchically encoded flow. However, these
separate sessions are logically related. For example it may be
necessary to pass reservations for all subflows to Admission
Control at the same time (since it would be nonsense to admit high
frequency components but Resv message.
RSVP should reject the baseband component of the
session data). Such a logical grouping is indicated 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 by
defining should reject the message.

o Error Code = 06: Ambiguous filter spec

Filter spec matches more than one sender, in a "session group", an ordered set of sessions.

To declare style that
requires a set unique match. RSVP should reject the message.

o Error Code = 07: Conflicting or unknown sty