draft-ietf-rsvp-spec-07.txt   draft-ietf-rsvp-spec-08.txt 
Internet Draft R. Braden, Ed. Internet Draft R. Braden, Ed.
Expiration: January 1996 ISI Expiration: May 1996 ISI
File: draft-ietf-rsvp-spec-07.txt L. Zhang File: draft-ietf-rsvp-spec-08.txt L. Zhang
PARC PARC
D. Estrin S. Berson
ISI ISI
S. Herzog S. Herzog
ISI ISI
S. Jamin J. Wroclaswki
USC MIT
Resource ReSerVation Protocol (RSVP) -- Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification Version 1 Functional Specification
July 7, 1995 November 22, 1995
Status of Memo Status of Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 5 skipping to change at page 2, line 5
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au
(Pacific Rim). (Pacific Rim).
Abstract Abstract
This memo describes version 1 of RSVP, a resource reservation setup This memo describes version 1 of RSVP, a resource reservation setup
protocol designed for an integrated services Internet. RSVP provides protocol designed for an integrated services Internet. RSVP provides
receiver-initiated setup of resource reservations for multicast or receiver-initiated setup of resource reservations for multicast or
unicast data flows, with good scaling and robustness properties. unicast data flows, with good scaling and robustness properties.
What's Changed Since Danvers IETF Table of Contents
The most important changes in this document from the rsvp-spec-05 draft
are:
o Added fields to common header for linear fragmentation, and
moved all references to semantic fragmentation to Appendix D.
o Added SE (Shared Explicit) style to all parts of the document.
o Further clarified reservation options and added table in Figure
3. Defined option vector in STYLE object.
o Renamed CREDENTIAL object class to POLICY_DATA object class, and
rewrote section 2.5 to more fully express its intended usage.
o Clarified the relationship between the wildcard scope
reservation option and wildcards in individual FILTER_SPEC
objects: wildcard is as wildcard does.
o Added SCOPE object definition and defined the rules for its use 1. Introduction ........................................................5
to prevent looping of wildcard-scope messages. 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
What's Changed
o Added some mechanisms for handling backwards compatibility for The most important changes in this document from the rsvp-spec-07 draft
future protocol extensions: (1) High bit of object class number; are:
(2) unmerged FLOWSPEC C-Type; (3) unmerged POLICY_DATA C-Type.
o Rewrote Section 4.3 on preventing looping. Included rules for o The role and interpretation of the IP Protocol Id is changed.
SCOPE object. The Protocol Id is now a required part of the session
definition, and filter specs and sender templates now assume
the Protocol Id from the session rather than stating it
explicitly.
o Specified rules for local repair upon route change notification o A "soft" reservation confirmation message is added.
(Section 4.4).
o Specified for each error type whether or not the state o The text states explicitly that an erroneous reservation
information in the erroneous packet is to be stored and message is not forwarded. A mechanism to allow a receiver
forwarded. more flexible control over forwarding of its messages after
an admission control failure has not been designed and is
therefore not included in this version of the protocol.
o Deleted the discussion of retransmitting a Teardown message Q o A terminology confusion is eliminated. The term "scope" was
times; assume Q=1 is sufficient. used both for a set of senders and for a set of sender hosts.
A new term "sender selection" is introduced for the first,
leaving "scope" for the second.
o Moved Session Groups to Appendix D, "Experimental and Open o The FILTER_SPEC object is dropped from a wildcard sender
Issues". Session Groups should be revisited as part of a larger selection (WF) style reservation, which now selects "all
context of cross-session reservations. senders" without qualification.
o Changed common header format, removing Object Count (which was o The StyleID byte is dropped from a STYLE object, as
redundant) and rearranging the remaining fields. Moved the two redundant.
common header flags into objects: Entry-Police into SESSION
object and LUB-used into ERROR_SPEC object.
o Revised the rules for state timeout (Section 4.5) and redefined o An SE style flow descriptor is simplified to a single
the TIME_VALUES object format. flowspec.
o Changed the error message format: (1) removed required RSVP_HOP o The IP Router Alert option is now required in PATH, PTEAR,
object from PERR and RERR messages; (2) specified more carefully and RACK messages.
what may appear in flow descriptor list of RERR messages.
o Revised the definitions of error codes and error values, and o The TIME_VALUES object is now required in RESV and PATH
moved them into a separate Appendix B. messages; there is no default.
o No longer require CREDENTIAL (i.e., POLICY_DATA) match for o Policing at branch points is now defined in a new section on
teardown. policing (3.6).
o Revised routing of RERR messages to use SCOPE objects to avoid o A 2-second delay is inserted into local repair.
wildcard-induced looping.
o Added LIH (logical interface handle) to RSVP_HOP object, for IP o Merging of SE with WF objects is no longer allowed.
multicast tunnels.
o Specified that addresses should be sorted in SCOPE object. o The Rmax end-to-end bound on the refresh rate R is removed,
since its utility was unclear.
o Added two new upcall event types in the API: reservation event o A rule for randomizing refresh timeouts is included.
and policy data event.
o Generalized the generic traffic control calls slightly to allow o The suggestion that TCP could be used for carrying RSVP state
multiple filter specs per flowspec, for SE style. This through a congested non-RSVP cloud is removed.
introduced a new set of handles, called FHandle. Also added a
preemption upcall.
o Added route change notification to the generic interface to o SENDER_TSPECS are now required in PATH| messages.
routing.
o Updated the message processing rules (Section 5). o There are new sections on multihomed hosts (3.7) and future
compatibility (3.8). The latter section makes clear that a
message containing an object with unknown C-Type should be
rejected. Any more forgiving treatment seems too complex.
o Rewrote Appendix C on UDP encapsulation. o Appendix C on UDP encapsulation is completely changed.
o Removed specification of FLOWSPEC object format (but int-serv o Some text was rearranged in Sections 1 and 2.
working group has since reneged on promise to specify it).
1. Introduction 1. Introduction
This document defines RSVP, a resource reservation setup protocol This document defines RSVP, a resource reservation setup protocol
designed for an integrated services Internet [RSVP93,ISInt93]. designed for an integrated services Internet [RSVP93,ISInt93].
A host uses the RSVP protocol to request a specific quality of On behalf of an application data stream, a host uses the RSVP
service (QoS) from the network, on behalf of an application data protocol to request a specific quality of service (QoS) from the
stream. RSVP is also used to deliver QoS requests to routers along network. RSVP delivers QoS requests to routers along the path(s) of
the path(s) of the data stream and to maintain router and host state the data stream and maintains router and host state to provide the
to provide the requested service. This will generally (but not requested service. RSVP requests will generally, although not
necessarily) require reserving resources along the data path. necessarily, result in resources being reserved along the data path.
RSVP reserves resources for simplex data streams, i.e., it reserves RSVP requests resources for simplex data streams, i.e., it requests
resources in only one direction on a link, so that a sender is resources in only one direction. Therefore, a sender is logically
logically distinct from a receiver. However, the same application distinct from a receiver, although the same application process may
may act as both sender and receiver. RSVP operates on top of IP, act as both a sender and a receiver at the same time. RSVP operates
occupying the place of a transport protocol in the protocol stack. on top of IP (either IPv4 or IP6), occupying the place of a transport
However, like ICMP, IGMP, and routing protocols, RSVP does not protocol in the protocol stack. However, like ICMP, IGMP, and
transport application data but is rather an Internet control routing protocols, RSVP does not transport application data but is
protocol. As shown in Figure 1, an implementation of RSVP, like the rather an Internet control protocol. Like the implementations of
implementations of routing and management protocols, will typically routing and management protocols, an implementation of RSVP will
execute in the background, not in the data forwarding path. typically execute in the background, not in the data forwarding path,
as shown in Figure 1.
RSVP is not itself a routing protocol; the RSVP daemon consults the RSVP is not itself a routing protocol; RSVP is designed to operate
local routing protocol(s) to obtain routes. Thus, a host sends IGMP with current and future unicast and multicast routing protocols. The
messages to join a multicast group, and it sends RSVP messages to RSVP daemon consults the local routing protocol(s) to obtain routes.
reserve resources along the delivery path(s) from that group. RSVP In the multicast case, for example, a host sends IGMP messages to
is designed to operate with existing and future unicast and multicast join a multicast group and then sends RSVP messages to reserve
routing protocols. resources along the delivery path(s) of that group. Routing
protocols determine where packets get forwarded; RSVP only concerns
with the QoS of those packets that are forwarded by routing.
HOST ROUTER HOST ROUTER
_________________________ RSVP ______________________ _________________________ RSVP _____________________________
| | .---------------. | | | .--------------. |
| _______ ______ | . | ________ . ______ | | _______ ______ | / | ________ . ______ |
| | | | | | . || | . | || RSVP | | | | | | / || | . | | | RSVP
| |Applic-| | RSVP <----- ||Routing | -> RSVP <------> | |Applic-| | RSVP <----/ ||Routing | -> RSVP <---------->
| | App <----->daemon| | ||Protocol| |daemon|| | | App <----->daemon| | ||Protocol| |daemon||
| | | | | | || daemon <----> || | | | | | | || daemon <----> ||
| |_______| |___.__| | ||_ ._____| |__.___|| | |_______| |___.__| | ||_ ._____| |__.__.| |
|===|===============v=====| |===v=============v====| | | | | | | | . |
| data .......... | | . ............ | |===|===============|=====| |===|=============|====.======|
| | ____v_ ____v____ | | _v__v_ _____v___ | | data .........| | | | ...........| .____ |
| | |Class-| | || data | |Class-| | || data | | ____V_ ____V____ | | _V__V_ _____V___ | Adm.||
| |=> ifier|=> Packet =============> ifier|==> Packet |======> | | |Class-| | || data | |Class-| | ||Cntrl||
| |______| |Scheduler|| | |______| |Scheduler|| | |=> ifier|=> Packet ============> ifier|==> Packet ||_____|| data
| |______| |Scheduler|| | |______| |Scheduler|===========>
| |_________|| | |_________|| | |_________|| | |_________||
|_________________________| |______________________| |_________________________| |_____________________________|
Figure 1: RSVP in Hosts and Routers Figure 1: RSVP in Hosts and Routers
Each router that is capable of resource reservation passes incoming Each router that is capable of resource reservation passes incoming
data packets to a packet classifier and then queues them as necessary data packets through a packet classifier and then queues them as
in a packet scheduler. The packet classifier determines the route necessary in a packet scheduler. The packet classifier determines
and the QoS class for each packet. The scheduler allocates resources the route and the QoS class for each packet. There is a scheduler
for transmission on the particular link-layer medium used by each for each interface, to allocate resources for transmission on the
interface. If the link-layer medium is QoS-active, i.e., if it has particular link-layer medium used by that interface. If the link-
its own QoS management capability, then the packet scheduler is layer medium is QoS-active, i.e., if it has its own QoS management
responsible for negotiation with the link layer to obtain the QoS capability, then the packet scheduler is responsible for negotiation
requested by RSVP. There are many possible ways this might be with the link layer to obtain the QoS requested by RSVP. This
accomplished, and the details will be medium-dependent. The mapping to the link layer QoS may be accomplished in a number of
scheduler itself allocates packet transmission capacity on a QoS- possible ways; the details will be medium-dependent. On a QoS-
passive medium such as a leased line. The scheduler may also passive medium such as a leased line, the scheduler itself allocates
allocate other system resources such as CPU time or buffers. 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 In order to efficiently accommodate heterogeneous receivers and
dynamic group membership and to be consistent with IP multicast, RSVP dynamic group membership, RSVP makes receivers responsible for
makes receivers responsible for requesting resource reservations requesting resource reservations [RSVP93]. A QoS request, which
[RSVP93]. A QoS request, typically originating in a receiver host typically originates from a receiver host application, is passed to
application, will be passed to the local RSVP implementation, shown the local RSVP implementation, shown as a user daemon in Figure 1.
as a user daemon in Figure 1. The RSVP protocol is then used to pass The RSVP protocol then carries the request to all the nodes (routers
the request to all the nodes (routers and hosts) along the reverse and hosts) along the reverse data path(s) to the data source(s).
data path(s) to the data source(s).
At each node, the RSVP program applies a local decision procedure, At each node, the RSVP daemon communicates with a local decision
called "admission control", to determine if it can supply the module, called "admission control", to determine if the router can
requested QoS. If admission control succeeds, the RSVP program sets supply the requested QoS. If the admission control check succeeds,
parameters to the packet classifier and scheduler to obtain the the RSVP daemon sets parameters in the packet classifier and
desired QoS. If admission control fails at any node, the RSVP scheduler to obtain the desired QoS. If the admission control check
program returns an error indication to the application that fails, the RSVP program immediately returns an error notification to
originated the request. We refer to the packet classifier, packet the application process that originated the request. We refer to the
scheduler, and admission control components as "traffic control". packet classifier, packet scheduler, and admission control components
as " traffic control".
RSVP is designed to scale well for very large multicast groups. RSVP is designed to scale well for very large multicast groups.
Since the membership of a large group will be constantly changing, Since both the membership of a large group and the topology of large
the RSVP design assumes that router state for traffic control will be multicast trees are likely to change with time, the RSVP design
built and destroyed incrementally. For this purpose, RSVP uses "soft assumes that router state for traffic control will be built and
state" in the routers, in addition to receiver-initiation. destroyed incrementally. For this purpose, RSVP uses "soft state" in
the routers. That is, RSVP sends periodic refresh messages to
maintain the state along the reserved path(s); in absence of
refreshes, the state will automatically time out and be deleted.
RSVP protocol mechanisms provide a general facility for creating and RSVP protocol mechanisms provide a general facility for creating and
maintaining distributed reservation state across a mesh of multicast maintaining distributed reservation state across a mesh of multicast
or unicast delivery paths. RSVP transfers reservation parameters as or unicast delivery paths. RSVP transfers reservation parameters as
opaque data (except for certain well-defined operations on the data), opaque data (except for certain well-defined operations on the data),
which it simply passes to traffic control for interpretation. which it simply passes to traffic control for interpretation.
Although the RSVP protocol mechanisms are largely independent of the Although the RSVP protocol mechanisms are largely independent of the
encoding of these parameters, the encodings must be defined in the encoding of these parameters, the encodings must be defined in the
reservation model that is presented to an application (see Appendix reservation model that is presented to an application; see Appendix A
A). for more details.
In summary, RSVP has the following attributes: In summary, RSVP has the following attributes:
o RSVP supports multicast or unicast data delivery and adapts to o RSVP makes resource reservations for both unicast and many-to-
changing group membership as well as changing routes. many multicast applications, adapting dynamically to changing
group membership as well as changing routes.
o RSVP is simplex. o RSVP is 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 o RSVP is receiver-oriented, i.e., the receiver of a data flow
responsible for the initiation and maintenance of the resource initiates and maintains the resource reservation used for that
reservation used for that flow. flow.
o RSVP maintains "soft state" in the routers, enabling it to o RSVP maintains "soft state" in the routers, providing graceful
gracefully support dynamic membership changes and automatically support for dynamic membership changes and automatic adaptation
adapt to routing changes. to routing changes.
o RSVP provides several reservation models or "styles" (defined o RSVP provides several reservation models or "styles" (defined
below) to fit a variety of applications. below) to fit a variety of applications.
o RSVP provides transparent operation through routers that do not o RSVP provides transparent operation through routers that do not
support it. support it.
Further discussion on the objectives and general justification for Further discussion on the objectives and general justification for
RSVP design are presented in [RSVP93,ISInt93]. RSVP design are presented in [RSVP93,ISInt93].
The remainder of this section describes the RSVP reservation The remainder of this section describes the RSVP reservation
services. Section 2 presents an overview of the RSVP protocol services. Section 2 presents an overview of the RSVP protocol
mechanisms, while Section 3 gives examples of the services and mechanisms. Section 3 contains the functional specification of RSVP,
mechanism. Section 4 contains the functional specification of RSVP. while Section 4 presents explicit message processing rules. Appendix
Section 5 presents explicit message processing rules. 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 1.1 Data Flows
The set of data flows with the same unicast or multicast RSVP defines a "session" as a data flow with a particular
destination constitute a session. RSVP treats each session destination and transport-layer protocol. The destination for a
independently. All data packets in a particular session are particular session is generally defined by DestAddress, the IP
directed to the same IP destination address DestAddress, and destination address of the data packets, and perhaps by DstPort, a
perhaps to some further demultiplexing point defined in a higher " generalized destination port", i.e., some further demultiplexing
layer (transport or application). We refer to the latter as a point in the transport or application protocol layer. RSVP treats
"generalized destination port". each session independently, and this document often assumes the
qualification "for the same session".
DestAddress is the group address for multicast delivery, or the DestAddress is a group address for multicast delivery or the
unicast address of a single receiver. A generalized destination unicast address of a single receiver. DstPort could be defined by
port could be defined by a UDP/TCP destination port field, by an a UDP/TCP destination port field, by an equivalent field in
equivalent field in another transport protocol, or by some another transport protocol, or by some application-specific
application-specific information. Although the RSVP protocol is information. Although the RSVP protocol is designed to be easily
designed to be easily extendible for greater generality, the extendible for greater generality, the present version supports
present version uses only UDP/TCP ports as generalized ports. only UDP/TCP ports as generalized ports.
Figure 2 illustrates the flow of data packets in a single RSVP Figure 2 illustrates the flow of data packets in a single RSVP
session, assuming multicast data distribution. The arrows session assuming multicast data distribution. The arrows indicate
indicate data flowing from senders S1 and S2 to receivers R1, R2, data flowing from senders S1 and S2 to receivers R1, R2, and R3,
and R3, and the cloud represents the distribution mesh created by and the cloud represents the distribution mesh created by
the multicast routing protocol. Multicast distribution forwards a multicast routing. Multicast distribution forwards a copy of each
copy of each data packet from a sender Si to every receiver Rj; a data packet from a sender Si to every receiver Rj; a unicast
unicast distribution session has a single receiver R. Each sender distribution session has a single receiver R. Each sender Si and
Si and each receiver Rj may correspond to a unique Internet host, each receiver Rj may be running in a unique Internet host, or a
or a single host may contain multiple logical senders and/or single host may contain multiple senders and/or receivers,
receivers, distinguished by generalized ports. distinguished by generalized ports.
Senders Receivers Senders Receivers
_____________________ _____________________
( ) ===> R1 ( ) ===> R1
S1 ===> ( Multicast ) S1 ===> ( Multicast )
( ) ===> R2 ( ) ===> R2
( distribution ) ( distribution )
S2 ===> ( ) S2 ===> ( )
( by Internet ) ===> R3 ( by Internet ) ===> R3
(_____________________) (_____________________)
Figure 2: Multicast Distribution Session Figure 2: Multicast Distribution Session
Even if the destination address is unicast, there may be multiple
receivers, distinguished by the generalized port. There may also For unicast transmission, there will be a single destination host
be multiple senders for a unicast destination, i.e., RSVP can set but there may be multiple senders; RSVP can set up reservations
up reservations for multipoint-to-point transmission. for multipoint-to-single-point transmission.
1.2 Reservation Model 1.2 Reservation Model
An elementary RSVP reservation request consists of a "flowspec" An elementary RSVP reservation request consists of a "flowspec"
together with a "filter spec"; this pair is called a "flow together with a "filter spec"; this pair is called a "flow
descriptor". The flowspec specifies a desired QoS. The filter descriptor". The flowspec specifies a desired QoS. The filter
spec (together with the DestAddress and the generalized spec, together with session definition, specifies the set of data
destination port defining the session) defines the set of data
packets -- the "flow" -- to receive the QoS defined by the packets -- the "flow" -- to receive the QoS defined by the
flowspec. The flowspec is used to set parameters to the node's flowspec. The flowspec is used to set parameters to the node's
packet scheduler (assuming that admission control succeeds), while packet scheduler (assuming that admission control succeeds), while
the filter spec is used to set parameters in the packet the filter spec is used to set parameters in the packet
classifier. Note that the action to control the QoS occurs at the classifier. Data packets that are addressed to a particular
place where the data enters the medium, i.e., at the upstream end session but do not match any of the filter specs for that session
of the link, although the RSVP reservation request originates from are handled as best-effort traffic.
receiver(s) downstream.
The flowspec in a reservation request will generally include a Note that the action to control QoS occurs at the place where the
service type and two sets of numeric parameters: (1) an "Rspec" (R data enters the medium, i.e., at the upstream end of the link,
for `reserve'), which defines the desired per-hop reservation, and although an RSVP reservation request originates from receiver(s)
(2) a "Tspec" (T for `traffic'), which defines the parameters that downstream. In this document, we define the directional terms
may be used to police the data flow, i.e., to ensure it does not "upstream" vs. "downstream", "previous hop" vs. "next hop", and
exceed its promised traffic level. "incoming interface" vs "outgoing interface" with respect to the
direction of data flows.
The form and contents of Tspecs and Rspecs are determined by the The flowspec in a reservation request will generally include a
integrated service model [ServTempl95a], and are generally opaque service class and two sets of numeric parameters: (1) an "Rspec"
to RSVP. RSVP delivers the Tspec and Rspec, together with an (R for `reserve') that defines the desired QoS, and (2) a "Tspec"
indication whether traffic policing is needed to the admission (T for `traffic') that describes the data flow. The formats and
control and packet scheduling components of traffic control. A contents of Tspecs and Rspecs are determined by the integrated
service that requires traffic policing might for example apply it service model [ServTempl95a], and are generally opaque to RSVP.
at the edge 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 In the most general approach [RSVP93], filter specs may select
select arbitrary subsets of the packets in a given session. Such arbitrary subsets of the packets in a given session. Such subsets
subsets might be defined in terms of senders (i.e., sender IP might be defined in terms of senders (i.e., sender IP address and
address and generalized source port), in terms of a higher-level generalized source port), in terms of a higher-level protocol, or
protocol, or generally in terms of any fields in any protocol generally in terms of any fields in any protocol headers in the
headers in the packet. For example, filter specs might be used to packet. For example, filter specs might be used to select
select different subflows in a hierarchically-encoded signal by different subflows in a hierarchically-encoded signal by selecting
selecting on fields in an application-layer header. However, in on fields in an application-layer header. However, in the
the interest of simplicity (and to minimize layer violation), the interest of simplicity (and to minimize layer violation), the
present RSVP version uses a much more restricted form of filter present RSVP version uses a much more restricted form of filter
spec: select only on sender IP address, on UDP/TCP port number, spec, consisting of sender IP address and optionally the UDP/TCP
and perhaps on IP protocol id. port number SrcPort.
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, 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 the QoS of
those packets that are delivered by routing.
RSVP reservation request messages originate at receivers and are RSVP reservation request messages originate at receivers and are
passed upstream towards the sender(s). (This document defines the passed upstream towards the sender(s). When a reservation request
directional terms "upstream" vs. "downstream", "previous hop" vs. is received at a node, two general actions are taken.
"next hop", and "incoming interface" vs "outgoing interface" with
respect to the data flow direction.) When an elementary
reservation request is received at a node, the RSVP daemon takes
two primary actions:
1. Daemon makes a reservation 1. Make a reservation
The flowspec and the filter spec are passed to traffic The flowspec and the filter spec are passed to traffic
control. Admission control determines the admissibility of control. Admission control determines the admissibility of
the request (if it's new); if this test fails, the the request (if it's new); if this test fails, the
reservation is rejected and RSVP returns an error message to reservation is rejected and RSVP returns an error message to
the appropriate receiver(s). If admission control succeeds, the appropriate receiver(s). If admission control succeeds,
the node uses the flowspec to set up the packet scheduler for the node uses the flowspec to set up the packet scheduler for
the desired QoS and the filter spec to set the packet the desired QoS and the filter spec to set the packet
classifier to select the appropriate data packets. classifier to select the appropriate data packets.
2. Daemon forwards the reservation upstream 2. Forward the request upstream
The reservation request is propagated upstream towards the The reservation request is propagated upstream towards the
appropriate senders. The set of sender hosts to which a appropriate senders. The set of sender hosts to which a
given reservation request is propagated is called the "scope" given reservation request is propagated is called the "scope"
of that request. of that request.
The reservation request that a node forwards upstream may differ The reservation request that a node forwards upstream may differ
from the request that it received, for two reasons. First, it is from the request that it received from downstream, for two
possible (in theory) for the traffic control mechanism to modify reasons. First, it is possible in theory for the traffic control
the flowspec hop-by-hop, although currently no realtime services mechanism to modify the flowspec hop-by-hop, although none of the
do this. Second, reservations from different downstream branches currently defined services does so. Second, reservations for the
of the multicast distribution tree(s) must be "merged" as same sender, or the same set of senders, from different downstream
reservations travel upstream. Merging reservations is a necessary branches of the multicast tree(s) are "merged" as reservations
consequence of multicast distribution, which creates a single travel upstream; that is, a node forwards upstream only the
stream of data packets in a particular router from any Si, reservation request with the "maximum" flowspec.
regardless of the set of receivers downstream. The reservation
for Si on a particular outgoing link L should be the "maximum" of When a receiver originates a reservation request, it can also
the individual flowspecs from the receivers Rj that are downstream request a confirmation message to indicate that its request was
via link L. Merging is discussed further in Section 2.2. (probably) installed in the network. A successful reservation
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 equal or larger
reservation in place; the node may then send a reservation
confirmation message back to the receiver. Note that the receipt
of a confirmation is only a high-probability indication, not a
guarantee that the requested service is in place all the way to
the sender(s), as explained in Section 2.6.
The basic RSVP reservation model is "one pass": a receiver sends a The basic RSVP reservation model is "one pass": a receiver sends a
reservation request upstream, and each node in the path can only reservation request upstream, and each node in the path either
accept or reject the request. This scheme provides no way to make accepts or rejects the request. This scheme provides no easy way
end-to-end service guarantees, since the QoS request must be for a receiver to find out the resulting end-to-end service.
applied independently at each hop. RSVP also supports an optional Therefore, RSVP supports an enhancement to one-pass service known
reservation model, known as "One Pass With Advertising" (OPWA) as "One Pass With Advertising" (OPWA) [Shenker94]. With OPWA,
[Shenker94]. In OPWA, RSVP control packets sent downstream, RSVP control packets are sent downstream, following the data
following the data paths, are used to gather information on the paths, to gather information that may be used to predict the end-
end-to-end service that would result from a variety of possible to-end QoS. The results ("advertisements") are delivered by RSVP
reservation requests. The results ("advertisements") are to the receiver hosts and perhaps to the receiver applications.
delivered by RSVP to the receiver host, and perhaps to the The advertisements may then be used by the receiver to construct,
receiver application. The information may then be used by the or to dynamically adjust, an appropriate reservation request.
receiver to construct an appropriate reservation request.
1.3 Reservation Styles 1.3 Reservation Styles
A reservation request includes a set of control options, which are A reservation request includes a set of control options, which are
collectively called the reservation "style". collectively called the reservation "style".
One option concerns the treatment of reservations for different One option concerns the treatment of reservations for different
senders within the same session: establish a "distinct" senders within the same session: establish a "distinct"
reservation for each upstream sender, or else make a single reservation for each upstream sender, or else make a single
reservation that is " shared" among all packets of selected reservation that is " shared" among all packets of selected
senders. Another option controls the scope of the request: an senders.
"explicit" sender specification, or a "wildcard" that implicitly
selects a group of senders. In an explicit-style reservation, the
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.
|| Reservations: Another option controls the selection of senders: an "explicit"
Scope || Distinct | Shared list of all selected senders, or a "wildcard" that implicitly
selects all the senders to the session. In an explicit-selection
reservation, each filter spec must match exactly one sender, while
in a wildcard-selection no filter spec is needed.
Sender || Reservations:
Selection || Distinct | Shared
_________||__________________|____________________ _________||__________________|____________________
|| | | || | |
Explicit || Fixed-Filter | Shared-Explicit | Explicit || Fixed-Filter | Shared-Explicit |
|| (FF) style | (SE) Style | || (FF) style | (SE) Style |
__________||__________________|____________________| __________||__________________|____________________|
|| | | || | |
Wildcard || (None defined) | Wildcard-Filter | Wildcard || (None defined) | Wildcard-Filter |
|| | (WF) Style | || | (WF) Style |
__________||__________________|____________________| __________||__________________|____________________|
Figure 3: Reservation Attributes and Styles Figure 3: Reservation Attributes and Styles
The styles currently defined are as follows (see Figure 3): The styles currently defined are as follows (see Figure 3):
1. Wildcard-Filter (WF) Style o Wildcard-Filter (WF) Style
The WF style implies the options: "shared" reservation and " The WF style implies the options: "shared" reservation and "
wildcard" reservation scope. Thus, a WF-style reservation wildcard" sender selection. Thus, a WF-style reservation
creates a single reservation into which flows from all creates a single reservation into which flows from all
upstream senders are mixed; this reservation may be thought upstream senders are mixed; this reservation may be thought
of as a shared "pipe", whose "size" is the largest of the of as a shared "pipe", whose "size" is the largest of the
resource requests for that link from all receivers, resource requests from all receivers, independent of the
independent of the number of senders using it. A WF-style number of senders using it. A WF-style reservation is
reservation has wildcard scope, i.e., the reservation is propagated upstream towards all sender hosts, and
propagated upstream towards all sender hosts. A WF-style automatically extends to new senders as they appear.
reservation automatically extends to new senders as they
appear.
2. Fixed-Filter (FF) Style 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 The FF style implies the options: "distinct" reservations and
"explicit" reservation scope. Thus, an elementary FF-style "explicit" sender selection. Thus, an elementary FF-style
reservation request creates a distinct reservation for data reservation request creates a distinct reservation for data
packets from a particular sender, not sharing them with other packets from a particular sender, not sharing them with other
senders' packets for the same session. It scope is senders' packets for the same session.
determined by an explicit list of senders.
The total reservation on a link for a given session is the The total reservation on a link for a given session is the
total of the FF reservations for all requested senders. On total of the FF reservations for all requested senders. On
the other hand, FF reservations requested by different the other hand, FF reservations requested by different
receivers Rj but selecting the same sender Si must receivers Rj but selecting the same sender Si must be merged
necessarily be merged to share a single reservation in a to share a single reservation.
given node.
3. Shared Explicit (SE) Style Symbolically, we can represent an elementary FF reservation
request by:
FF( S{Q})
where S is the selected sender and Q is the corresponding
flowspec; the pair forms a flow descriptor. RSVP allows
multiple elementary FF-style reservations to be requested at
the same time, using a list of flow descriptors:
FF( S1{Q1}, S2{Q2}, ...)
o Shared Explicit (SE) Style
The SE style implies the options: "shared" reservation and " The SE style implies the options: "shared" reservation and "
explicit" reservation scope. Thus, an SE-style reservation explicit" sender selection. Thus, an SE-style reservation
creates a single reservation into which flows from all creates a single reservation into which flows from all
upstream senders are mixed. However, like a FF reservation upstream senders are mixed. However, like the FF style, the
the set of senders (and therefore its scope (and therefore SE style allows a receiver to explicitly specify the set of
the scope) is specified explicitly by the receiver making the senders.
reservation.
WF and SE are both shared reservations, appropriate for those Symbolically, we can represent an SE reservation request by:
SE( (S1,S2,...){Q} ),
i.e., a flow descriptor composed of a flowspec Q and a list
of senders S1, S2, etc.
Both WF and SE are shared reservations, appropriate for those
multicast applications whose application-specific constraints make multicast applications whose application-specific constraints make
it unlikely that multiple data sources will transmit it unlikely that multiple data sources will transmit
simultaneously. One example is audio conferencing, where a limited simultaneously. Packetized audio is an example of an application
number of people talk at once; each receiver might issue a WF or suitable for shared reservations; since a limited number of people
SE reservation request for twice one audio channel (to allow some talk at once, each receiver might issue a WF or SE reservation
over-speaking). On the other hand, the FF style, which creates request for twice the bandwidth required for one sender (to allow
independent reservations for the flows from different senders, is some over-speaking). On the other hand, the FF style, which
appropriate for video signals. creates independent reservations for the flows from different
senders, is appropriate for video signals.
It is not possible to merge shared reservations with distinct The RSVP rules disallow merging of shared reservations with
reservations. Therefore, WF and SE styles are incompatible with distinct reservations, since these modes are fundamentally
FF, but are compatible with each other. Merging a WF style incompatible. They also disallow merging explict sender selection
reservation with an SE style reservation results in a WF with wildcard sender selection, since this might produce an
reservation. unexpected service for a 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 Other reservation options and styles may be defined in the future
(see Appendix D.4, for example). (see Appendix D.4, for example).
2. RSVP Protocol Mechanisms 1.4 Examples of Styles
2.1 RSVP Messages This section presents examples of each of the reservation styles
and show the effects of merging.
There are two fundamental RSVP message types: RESV and PATH . 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 will be forwarded,
labeled (c) and (d). This topology will be assumed in the
examples that follow. There are three upstream senders; packets
from sender S1 (S2 and S3) arrive through previous hop (a) ((b),
respectively). There are also three downstream receivers; packets
bound for R1 (R2 and R3) are routed via outgoing interface (c)
((d), respectively). We furthermore assume that R2 and R3 arrive
via different next hops, e.g., via the two routers D and D' in
Figure 9. This illustrates the effect of a non-RSVP cloud or a
broadcast LAN on interface (d).
Each receiver host sends RSVP reservation request (RESV) messages In addition to the connectivity shown in 4, we must also specify
towards the senders. These reservation messages must follow in the multicast routes within this node. Assume first that data
reverse the routes the data packets will use, all the way upstream packets from each Si shown in Figure 4 is routed to both outgoing
to the sender hosts included in the scope. RESV messages must be interfaces. Under this assumption, Figures 5, 6, and 7 illustrate
delivered to the sender hosts so that the hosts can set up Wildcard-Filter, Fixed-Filter, and Shared-Explicit reservations,
appropriate traffic control parameters for the first hop. respectively.
Also note that RSVP sends no positive acknowledgment messages to ________________
indicate success (although the delivery of a reservation request (a)| | (c)
to a sender could be used to trigger an acknowledgement at a ( S1 ) ---------->| |----------> ( R1 )
higher level of protocol.) | Router |
Sender Receiver (b)| | (d)
_____________________ ( S2,S3 ) ------->| |----------> ( R2, R3 )
Path --> ( ) |________________|
Si =======> ( Multicast ) Path -->
<-- Resv ( ) =========> Rj
( distribution ) <-- Resv
(_____________________)
Figure 4: RSVP Messages Figure 4: Router Configuration
For simplicity, these examples show flowspecs as one-dimensional
multiples of some base resource quantity B. The "Receive" column
shows the RSVP reservation requests received over outgoing
interfaces (c) and (d), and the "Reserve" column shows the
resulting reservation state for each interface. The "Send"
column shows the reservation requests that are sent upstream to
previous hops (a) and (b). In the "Reserve" column, each box
represents one reserved "pipe" on the outgoing link, with the
corresponding flow descriptor.
Each sender transmits RSVP PATH messages forward along the uni- Figure 5, showing the WF style, illustrates the two possible
/multicast routes provided by the routing protocol(s); see Figure merging situations. Each of the two next hops on interface (d)
4. These "Path" messages store path state in each node. Path results in a separate RSVP reservation request, as shown. These
state is used by RSVP to route the RESV messages hop-by-hop in the two requests are merged into the effective flowspec 3B, which is
reverse direction. (In the future, some routing protocols may used to make the reservation on interface (d). To forward the
supply reverse path forwarding information directly, replacing the reservation requests upstream, the reservations on the interfaces
reverse-routing function of path state). (c) and (d) are merged; as a result, the larger flowspec 4B is
forwarded upstream to each previous hop.
PATH messages may also carry the following information: |
Send | Reserve Receive
|
| _______
WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} )
| |_______|
|
-----------------------|----------------------------------------
| _______
WF( *{4B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} )
| |_______| <- WF( *{2B} )
o Sender Template Figure 5: Wildcard-Filter (WF) Reservation Example
The Sender Template describes the format of data packets that Figure 6 shows Fixed-Filter (FF) style reservations. The flow
the sender will originate. This template is in the form of a descriptors for senders S2 and S3, received from outgoing
filter spec that could be used to select this sender's interfaces (c) and (d), are packed into the request forwarded to
packets from others in the same session on the same link. 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.
Like a filter spec, the Sender Template is less than fully |
general at present, specifying only sender IP address, Send | Reserve Receive
UDP/TCP sender port, and protocol id. The port number |
and/or protocol id can be wildcarded. | ________
FF( S1{4B} ) <- (a) | (c) | S1{4B} | (c) <- FF( S1{4B}, S2{5B} )
| |________|
| | S2{5B} |
| |________|
---------------------|---------------------------------------------
| ________
<- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} )
FF( S2{5B}, S3{B} ) | |________| <- FF( S1{B} )
| | S3{B} |
| |________|
o Tspec Figure 6: Fixed-Filter (FF) Reservation Example
PATH message may optionally carry a Tspec that defines an Figure 7 shows an example of Shared-Explicit (SE) style
upper bound on the traffic level that the sender will reservations. When SE-style reservations are merged, the
generate. This Tspec can be used by RSVP to prevent over- resulting filter spec is the union of the original filter specs.
reservation (and perhaps unnecessary Admission Control
failure) on the non-shared links starting at the sender.
o Adspec |
Send | Reserve Receive
|
| ________
SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} )
| | {B} |
| |________|
---------------------|---------------------------------------------
| __________
<- (b) | (d) |(S1,S2,S3)| (d) <- SE( (S1,S3){3B} )
SE( (S2,S3){3B} ) | | {3B} | <- SE( S2{2B} )
| |__________|
The PATH message may carry a package of OPWA advertising Figure 7: Shared-Explicit (SE) Reservation Example
information, known as an "Adspec". An Adspec received in a
PATH message is passed to the local traffic control routines, The three examples just shown assume that data packets from S1,
which return an updated Adspec; the updated version is S2, and S3 are routed to both outgoing interfaces. The top part
forwarded downstream. of Figure 8 shows another routing assumption: data packets from S2
and S3 are not forwarded to interface (c), e.g., because the
network topology provides a shorter path for these senders towards
R1, not traversing this node. The bottom part of Figure 8 shows
WF style reservations under this assumption. Since there is no
route from (b) to (c), the reservation forwarded out interface (b)
considers only the reservation on interface (d).
_______________
(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
2. RSVP Protocol Mechanisms
2.1 RSVP Messages
Previous Incoming Outgoing Next Previous Incoming Outgoing Next
Hops Interfaces Interfaces Hops Hops Interfaces Interfaces Hops
_____ _____________________ _____ _____ _____________________ _____
| | data --> | | data --> | | | | data --> | | data --> | |
| A |-----------| a c |--------------| C | | A |-----------| a c |--------------| C |
|_____| <-- Resv | | <-- Resv |_____| |_____| Path --> | | Path --> |_____|
Path --> | | Path --> _____ <-- Resv | | <-- Resv _____
_____ | ROUTER | | | | _____ | ROUTER | | | |
| | | | | |--| D | | | | | | |--| D |
| B |--| data-->| | data --> | |_____| | B |--| data-->| | data --> | |_____|
|_____| |--------| b d |-----------| |_____| |--------| b d |-----------|
|<-- Resv| | <-- Resv | _____ | Path-->| | Path --> | _____
_____ | Path-->|_____________________| Path --> | | | _____ | <--Resv|_____________________| <-- Resv | | |
| | | |--| D' | | | | |--| D' |
| B' |--| | |_____| | B' |--| | |_____|
|_____| | | |_____| | |
Figure 5: Router Using RSVP Figure 9: Router Using RSVP
Figure 5 illustrates RSVP's model of a router node. Each data Figure 9 illustrates RSVP's model of a router node. Each data
stream arrives from a previous hop through a corresponding stream arrives from a "previous hop" through a corresponding
incoming interface and departs through one or more outgoing "incoming interface" and departs through one or more "outgoing
interface(s). The same physical interface may act in both the interface(s)". The same physical interface may act in both the
incoming and outgoing roles (for different data flows but the same incoming and outgoing roles for different data flows in the same
session). session. Multiple previous hops and/or next hops may be reached
through a given physical interface, as a result of the connected
network being a shared medium, or the existence of non-RSVP
routers in the path to the next RSVP hop (see Section 2.8). An
RSVP daemon preserves the next and previous hop addresses in its
reservation and path state, respectively.
As illustrated in Figure 5, there may be multiple previous hops There are two fundamental RSVP message types: RESV and PATH.
and/or next hops through a given physical interface. This may
result from the connected network being a shared medium or from
the existence of non-RSVP routers in the path to the next RSVP hop
(see Section 2.6). An RSVP daemon must preserve the next and
previous hop addresses in its reservation and path state,
respectively. A RESV message is sent with a unicast destination
address, the address of a previous hop. PATH messages, on the
other hand, are sent with the session destination address, unicast
or multicast.
Although multiple next hops may send reservation requests through Each receiver host sends RSVP reservation request (RESV) messages
the same physical interface, the final effect should be to install upstream towards the senders. These reservation messages must
a reservation on that interface, which is defined by an effective follow exactly the reverse of the routes the data packets will
flowspec. This effective flowspec will be the "maximum" of the use, upstream to all the sender hosts included in the sender
flowspecs requested by the different next hops. In turn, a RESV selection. RESV messages must be delivered to the sender hosts
message forwarded to a particular previous hop carries a flowspec themselves so that the hosts can set up appropriate traffic
that is the "maximum" over the effective reservations on the control parameters for the first hop.
corresponding outgoing interfaces. Both cases represent merging,
which is discussed further below.
There are a number of ways for a syntactically valid reservation Each RSVP sender host transmits RSVP PATH messages downstream
request to fail in a given node: along the uni-/multicast routes provided by the routing
protocol(s), following the paths of the data. These "Path"
messages store " path state" in each node along the way. This
path state includes at least the unicast IP address of the
previous hop node, which is used to route the RESV messages hop-
by-hop in the reverse direction. (In the future, some routing
protocols may supply reverse path forwarding information directly,
replacing the reverse-routing function of path state).
1. The effective flowspec, computed using the new request, may A PATH message may carry the following information in addition to
fail admission control. the previous hop address:
2. Administrative policy or control may prevent the requested o Sender Template
reservation.
3. There may be no matching path state (i.e., the scope may be A PATH message is required to carry a Sender Template, which
empty), which would prevent the reservation being propagated describes the format of data packets that the sender will
upstream. originate. This template is in the form of a filter spec
that could be used to select this sender's packets from
others in the same session on the same link.
4. A reservation style that requires a unique sender may have a Like a filter spec, the Sender Template is less than fully
filter spec that matches more than one sender in the path general at present, specifying only the sender IP address and
state, due to the use of wildcards. optionally the UDP/TCP sender port. It assumes the protocol
Id for the session.
5. The requested style may be incompatible with the style(s) of o Sender Tspec
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 A PATH message is required to carry a Sender Tspec, which
reservations that exist on other outgoing interfaces but will defines the traffic characteristics of the data stream that
be merged with this reservation to create a refresh message the sender will generate. This Tspec is used by traffic
for the previous hop. 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.
In any of these cases, an error message is returned to the o Adspec
receiver(s) responsible for the erroneous message. An error
message does not modify state in the nodes through which it
passes. Therefore, any reservations established downstream of the
node where the failure was detected will persist until the
receiver(s) responsible cease attempting the reservation.
The erroneous message may or may not be propagated forward. In A PATH message may optionally carry a package of OPWA
general, if the error is likely to be repeated at every node advertising information, known as an "Adspec". An Adspec
further along the path, it is best to drop the erroneous message received in a PATH message is passed to the local traffic
rather than generate a flood of error messages; this is the case control, which returns an updated Adspec; the updated version
for the last four error classes listed above. The first two error is then forwarded downstream.
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
error definitions in Appendix B.
An erroneous FILTER_SPEC object in a RESV message will normally be For protocol efficiency, RSVP also allows multiple sets of
detected at the first RSVP hop from the receiver application, reservation information for the same session to be "packed" into a
i.e., within the receiver host. However, an admission control single RESV message. Unlike merging, packing preserves
failure caused by a FLOWSPEC or a POLICY_DATA object may be information. For simplicity, however, the protocol currently
detected anywhere along the path(s) to the sender(s). prohibits packing reservations of different sessions into the same
RSVP message.
When admission control fails for a reservation request, any PATH messages are sent with the same source and destination
existing reservation is left in place. This prevents a new, very addresses as the data, so that they will be routed correctly
large, reservation from disrupting the existing QoS by merging through non-RSVP clouds (see Section 2.8). On the other hand,
with an existing reservation and then failing admission control RESV messages are sent hop-by-hop; each RSVP-speaking node
(this has been called the "killer reservation" problem). forwards a RESV message to the unicast address of a previous RSVP
hop.
A node may be allowed to preempt an established reservation, in 2.2 Port Usage
accordance with administrative policy; this will also trigger an
error message to all affected receivers.
2.2 Merging and Packing At present an RSVP session is defined by the triple: (DestAddress,
ProtocolId, DstPort). Here DstPort is a UDP/TCP destination port
field (i.e., a 16-bit quantity carried at octet offset +2 in the
transport header). DstPort may be omitted (set to zero) if the
ProtocolId specifies a protocol that does not have a destination
port field in the format used by UDP and TCP.
A previous section explained that reservation requests in RESV RSVP allows any value for ProtocolId. However, end-system
messages are necessarily merged, to match the multicast implementations of RSVP may know about certain values for this
distribution tree. As a result, only the essential (i.e., the field, and in particular must know about the values for UDP and
"largest") reservation requests are forwarded, once per refresh TCP (17 and 6, respectively). An end system should give an error
period. A successful reservation request will propagate as far as to an application that either:
the closest point(s) along the sink tree to the sender(s) where a
reservation level equal or greater than that being requested has
been made. At that point, the merging process will drop it in
favor of another, equal or larger, reservation request.
For protocol efficiency, RSVP also allows multiple sets of path o specifies a non-zero DstPort for a protocol that does not
(or reservation) information for the same session to be "packed" have UDP/TCP-like ports, or
into a single PATH (or RESV) message, respectively. (For
simplicity, the protocol currently prohibits packing different
sessions into the same RSVP message). Unlike merging, packing
preserves information.
In order to merge reservations, RSVP must be able to merge o specifies a zero DstPort for a protocol that does have
flowspecs and to merge filterspecs. Merging flowspecs requires UDP/TCP-like ports.
calculating the the "largest" of a set of flowspecs, which are
otherwise opaque to RSVP. Merging flowspecs is required both to Filter specs and sender templates are defined by the pair:
calculate the effective flowspec to install on a given physical (SrcAddress, SrcPort), where SrcPort is a UDP/TCP source port
interface (see the discussion in connection with Figure 5), and to field (i.e., a 16-bit quantity carried at octet offset +0 in the
merge flowspecs when sending a refresh message upstream. Since transport header). SrcPort may be omitted (set to zero) in
flowspecs are generally multi-dimensional vectors (they contain certain cases. The following rules hold for the use of zero
both Tspec and Rspec components, each of which may itself be DstPort and/or SrcPort fields in RSVP.
multi-dimensional), they are not strictly ordered. When it cannot
take the larger of two flowspecs, RSVP must compute and use a 1. Destination ports must be consistent.
third flowspec that is at least as large as each, i.e., a "least
upper bound" (LUB). It is also possible for two flowspecs to be Path state and/or reservation state for the same DestAddress
incomparable, which is treated as an error. The definition and and ProtocolId must have DstPort values that are all zero or
implementation of the rules for comparing flowspecs are outside all non-zero. Violation of this condition in a node is a
RSVP proper, but they are defined as part of the service templates "Conflicting Dest Port" error.
[ServTempl95a]
2. Destination ports rule.
If DstPort in a session definition is zero, all SrcPort
fields used for that session must also be zero. The
assumption here is that the protocol does not have TCP/UDP-
like ports. Violation of this condition in a node is a
"Conflicting Src Port" error.
3. Source Ports must be consistent.
A sender host must not send path state both with and without
a zero SrcPort. Violation of this condition is an "Ambiguous
Path" error.
2.3 Merging Flowspecs
As noted earlier, a single physical interface may receive multiple
reservation request from different next hops for the same session
and with the same filter spec, but RSVP should install only one
reservation on that interface. This reservation should an
effective flowspec that is the "maximum" of the flowspecs
requested by the different next hops. Similarly, a RESV message
forwarded to a previous hop should carry a flowspec that is the
"maximum" of the flowspecs requested by the different next hops.
Both cases represent flowspec merging.
Merging flowspecs requires calculating the "largest" of a set of
flowspecs, which are otherwise opaque to RSVP. Since flowspecs
are multi-dimensional vectors (they contain both Tspec and Rspec
components, each of which may itself be multi-dimensional),
generally speaking they cannot be strictly ordered. However, in
many cases one can easily determine the "larger" of two flowspecs,
such as when both request the same bandwidth but one requests a
tighter delay, or when one of the two requests both a higher
bandwidth and a tighter delay bound. When the "larger" of the two
cannot be determined, RSVP must compute and use a third flowspec
that is at least as large as each, i.e., a "least upper bound"
(LUB). If the two flowspecs are incomparable, their comparison
will treated as an error.
We can now give the complete rules for calculating the effective We can now give the complete rules for calculating the effective
flowspec (Te, Re), to be installed on an interface. Here Te is flowspec (Te, Re) to be installed on an interface. Here Te is the
the effective Tspec and Re is the effective Rspec. As an example, effective Tspec and Re is the effective Rspec. As an example,
consider interface (d) in Figure 5. consider interface (d) in Figure 9.
o Re is calculated as the largest (using an LUB if necessary) 1. Re is calculated as the largest (using an LUB if necessary)
of the Rspecs in RESV messages from different next hops of the Rspecs in RESV messages from different next hops
(e.g., D and D') but the same outgoing interface (d). (e.g., D and D') but the same outgoing interface (d).
o The Tspecs supplied in PATH messages from different previous 2. All Tspecs that were supplied in PATH messages from different
hops which may send data packets to this reservation (e.g., previous hops (e.g., some or all of A, B, and B' in Figure 9)
some or all of A, B, and B' in Figure 5) are summed; call are summed; call this sum Path_Te.
this sum Path_Te.
o The maximum Tspec supplied in RESV messages from different 3. The maximum Tspec supplied in RESV messages from different
next hops (e.g., D and D') is calculated; call this Resv_Te. next hops (e.g., D and D') is calculated; call this Resv_Te.
o Te is the GLB (greatest lower bound) of Path_Te and Resv_Te. 4. Te is the GLB (greatest lower bound) of Path_Te and Resv_Te.
For Tspecs defined by token bucket parameters, this means to For Tspecs defined by token bucket parameters, this means to
take the smaller of the bucket size and the rate parameters. take the smaller of the bucket size and the rate parameters.
Two filter specs can be merged only they are identical or if one Flowspecs, Tspecs, and Adspecs are opaque to RSVP. Therefore, the
contains the other through wild-carding. The result is the more last of these steps is actually performed by traffic control. The
general of the two, i.e., the one with more wildcard fields. definition and implementation of the rules for comparing
flowspecs, calculating LUB's, and summing Tspecs are outside the
definition of RSVP [ServTempl95a]. Section 3.9.4 shows generic
calls that an RSVP daemon could use for these functions.
2.3 Soft State 2.4 Soft State
To maintain reservation state, RSVP keeps "soft state" in router RSVP takes a "soft state" approach to managing the reservation
and host nodes. RSVP soft state is created and periodically state in routers and hosts. RSVP soft state is created and
refreshed by PATH and RESV messages. The state is deleted if no periodically refreshed by PATH and RESV messages. The state is
matching refresh messages arrive before the expiration of a deleted if no matching refresh messages arrive before the
"cleanup timeout" interval. It may also be deleted as the result expiration of a "cleanup timeout" interval. It may also be
of an explicit "teardown" message, described in the next section. deleted by an explicit "teardown" message, described in the next
At the expiration of each "refresh timeout" period, RSVP scans its section. At the expiration of each "refresh timeout" period and
state to build and forward PATH and RESV refresh messages to after a state change, RSVP scans its state to build and forward
succeeding hops. PATH and RESV refresh messages to succeeding hops.
When a route changes, the next PATH message will initialize the PATH and RESV messages are idempotent. When a route changes, the
path state on the new route, and future RESV messages will next PATH message will initialize the path state on the new route,
establish reservation state there; the state on the now-unused and future RESV messages will establish reservation state there;
segment of the route will time out. Thus, whether a message is the state on the now-unused segment of the route will time out.
"new" or a "refresh" is determined separately at each node, Thus, whether a message is "new" or a "refresh" is determined
depending upon the existence of state at that node. separately at each node, depending upon the existing state at that
node.
RSVP sends its messages as IP datagrams without reliability RSVP sends its messages as IP datagrams with no reliability
enhancement. Periodic transmission of refresh messages by hosts enhancement. Periodic transmission of refresh messages by hosts
and routers is expected to replace any lost RSVP messages. To and routers is expected to handle the occasional loss of RSVP
tolerate K-1 successive packet losses, the effective cleanup messages. If the effective cleanup timeout is set to K times the
timeout must be at least K times the refresh timeout. In refresh timeout period, then RSVP can tolerate K-1 successive RSVP
addition, the traffic control mechanism in the network should be packet losses without falsely erasing a reservation. We recommend
statically configured to grant high-reliability service to RSVP that the network traffic control mechanism be statically
messages, to protect RSVP messages from congestion losses. configured to grant some minimal bandwidth for RSVP messages to
protect them from congestion losses.
The "soft" state maintained by RSVP is dynamic; to change the set The state maintained by RSVP is dynamic; to change the set of
of senders Si or receivers Rj or to change any QoS request, a host senders Si or to change any QoS request, a host simply starts
simply starts sending revised PATH and/or RESV messages. The sending revised PATH and/or RESV messages. The result should be
result should be an appropriate adjustment in the RSVP state and an appropriate adjustment in the RSVP state in all nodes along the
immediate propagation to all nodes along the path. path.
In steady state, refreshing is performed hop-by-hop, which allows In steady state, refreshing is performed hop-by-hop to allow
merging and packing as described in the previous section. If the merging. If the received state differs from the stored state, the
received state differs from the stored state, the stored state is stored state is updated. If this update results in modification
updated. Furthermore, if the result will be to modify the refresh of state to be forwarded in refresh messages, these refresh
messages to be generated, these refresh messages must be generated messages must be generated and forwarded immediately, so that
and forwarded immediately. This will result in state changes state changes can be propagated end-to-end without delay.
propagating end-to-end without delay. However, propagation of a However, propagation of a change stops when and if it reaches a
change stops when and if it reaches a point where merging causes point where merging causes no resulting state change. This
no resulting state change. This minimizes RSVP control traffic minimizes RSVP control traffic due to changes and is essential for
due to changes and is essential for scaling to large multicast scaling to large multicast groups.
groups.
The RSVP state associated with a session in a particular node is State that is received through a particular interface I* should
divided into atomic elements that are created, refreshed, and never be forwarded out the same interface. Conversely, state that
timed out independently. The atomicity is determined by the is forwarded out interface I* must be computed using only state
requirement that any sender or receiver may enter or leave the that arrived on interfaces different from I*. A trivial example
session at any time, so its state should be created and timed out of this rule is illustrated in Figure 10, which shows a transit
independently. router with one sender and one receiver on each interface (and
assumes one next/previous hop per interface). Interfaces (a) and
(c) serve as both outgoing and incoming interfaces for this
session. Both receivers are making wildcard-scope reservations,
in which the RESV messages are forwarded to all previous hops for
senders in the group, with the exception of the next hop from
which they came. The result is independent reservations in the
two directions.
2.4 Teardown There is an additional rule governing the forwarding of RESV
messages: state from RESV messages received from outgoing
interface Io should be forwarded to incoming interface Ii only if
PATH messages from Ii are forwarded to Io.
RSVP teardown messages remove path and reservation state without ________________
waiting for the cleanup timeout period, as an optimization to a | | c
release resources quickly. It is not necessary to explicitly tear ( R1, S1 ) <----->| Router |<-----> ( R2, S2 )
down an old reservation, although it may be desirable in many |________________|
cases.
Send | Receive
|
WF( *{3B}) <-- (a) | (c) <-- WF( *{3B})
|
Receive | Send
|
WF( *{4B}) --> (a) | (c) --> WF( *{4B})
|
Reserve on (a) | Reserve on (c)
__________ | __________
| * {4B} | | | * {3B} |
|__________| | |__________|
|
Figure 10: Independent Reservations
2.5 Teardown
Upon arrival, RSVP "teardown" messages remove path and reservation
state immediately. Although it is not necessary to explicitly
tear down an old reservation, we recommend that all end hosts send
a teardown request as soon as an application finishes.
There are two types of RSVP teardown message, PTEAR and RTEAR. A
PTEAR message travels towards all receivers downstream from its
point of initiation and deletes path state along the way. An
RTEAR message deletes reservation state and travels towards all
senders upstream from its point of initiation. A PTEAR (RTEAR)
message may be conceptualized as a reversed-sense Path message
(Resv message, respectively).
A teardown request may be initiated either by an application in an A teardown request may be initiated either by an application in an
end system (sender or receiver), or by a router as the result of end system (sender or receiver), or by a router as the result of
state timeout. Once initiated, a teardown request should be state timeout. Once initiated, a teardown request must be
forwarded hop-by-hop without delay. forwarded hop-by-hop without delay. A teardown message deletes
the specified state in the node where it is received. As always,
this state change will be propagated immediately to the next node,
but only if there will be a net change after merging. As a
result, an RTEAR message will prune the reservation state back
(only) as far as possible.
Teardown messages (like other RSVP messages) are not delivered Like all other RSVP messages, teardown requests are not delivered
reliably. However, loss of a teardown message is not considered a reliably. The loss of a teardown request message will not cause a
problem because the state will time out even if it is not protocol failure because the unused state will eventually time out
explicitly deleted. If one or more teardown message hops are even though it is not explicitly deleted. If a teardown message
lost, the router that failed to receive a teardown message will is lost, the router that failed to receive that message will time
time out its state and initiate a new teardown message beyond the out its state and initiate a new teardown message beyond the loss
loss point. Assuming that RSVP message loss probability is small, point. Assuming that RSVP message loss probability is small, the
the longest time to delete state will seldom exceed one refresh longest time to delete state will seldom exceed one refresh
timeout period. timeout period.
There are two types of RSVP teardown message, PTEAR and RTEAR. A 2.6 Errors and Acknowledgments
PTEAR message travels towards all receivers downstream from its
point of initiation and deletes path state along the way. A RTEAR
message deletes reservation state and travels towards all senders
upstream from its point of initiation. A PTEAR (RTEAR) message
may be conceptualized as a reversed-sense Path message (Resv
message, respectively).
A teardown message deletes the specified state in the node where There are two RSVP error messages, RERR and PERR, and a
it is received. Like any other state change, this will be reservation confirmation message RACK.
propagated immediately to the next node, but only if it represents
a net change after merging. As a result, an RTEAR message will
prune the reservation state back (only) as far as possible.
2.5 Admission Policy and Security There are a number of ways for a syntactically valid reservation
request to fail at some node along the path, triggering a RERR
message:
1. The effective flowspec that is computed using the new request
may fail admission control.
2. Administrative policy may prevent the requested reservation.
3. There may be no matching path state, so that the request
cannot be forwarded towards the sender(s).
4. A reservation style that requires the explicit selection of a
unique sender may have a filter spec that is ambiguous, i.e.,
that matches more than one sender in the path state, due to
the use of wildcard fields in the filter spec.
5. The requested style may be incompatible with the style(s) of
existing reservations. The incompatibility may occur among
reservations for the same session on the same outgoing
interface, or among effective reservations on different
outgoing interfaces.
In any of these cases, a RERR message is returned to the
receiver(s) responsible for the erroneous request. A node may
also decide to preempt an established reservation. A preemption
will trigger a RERR message to all affected receivers. An error
message does not modify state in the nodes through which it
passes. Therefore, any reservations established downstream of the
node where the failure occurred will persist until the responsible
receiver(s) explicitly tear down the state or allow it to time
out.
In this version of RSVP, detection of an error in a reservation
request not only generates a RERR message, it also prevents the
request from being forwarded further. This may not always be the
desirable behavior; for example, a receiver may want a reservation
request to propagate all the way to the sender despite an
admission control failure at a particular link along the path.
However, design of the appropriate mechanism has proved difficult,
and therefore this version take the simplest approach.
When admission control fails for a reservation request, any
existing reservation is left in place. This prevents a new, very
large, reservation from disrupting the existing QoS by merging
with an existing reservation and then failing admission control
(this has been called the "killer reservation" problem).
To request a 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. If the reservation request from Rj is equal
to or smaller than the reservation in place on a node, its RESV
are not forwarded further, and 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 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 R2 arrive at
the node where they are merged. R2, whose reservation was
the second to arrive at that node, may receive a RACK from
that node while R1's request has not yet propagated all the
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 flowspecs are
equal, R2 may receive a RACK followed by a RERR. However, if
its flowspec is smaller, R2 will receive only the RACK.
o Despite these uncertainties, receipt of a RACK indicates a
high probability that the reservation is in place.
o Finally, note that RERR and/or RACK messages may be lost.
2.7 Policy and Security
RSVP-mediated QoS requests will result in particular user(s) RSVP-mediated QoS requests will result in particular user(s)
getting preferential access to network resources. To prevent getting preferential access to network resources. To prevent
abuse, some form of back pressure on users will be required. This abuse, some form of back pressure on users is likely to be
back pressure might take the form of administrative rules, or of required. This back pressure might take the form of
some form of real or virtual billing for the `cost' of a administrative rules, or of some form of real or virtual billing
reservation. The form and contents of such back pressure is a for the "cost" of a reservation. The form and contents of such
matter of administrative policy that may be determined back pressure is a matter of administrative policy that may be
independently by each administrative domain in the Internet. determined independently by each administrative domain in the
Internet.
Therefore, admission control at each node is likely to contain a Therefore, admission control at each node is likely to contain a
policy component as well as a resource reservation component. As policy component in addition to a resource reservation component.
input to the policy-based admission decision, RSVP messages may As input to the policy-based admission decision, RSVP messages may
carry policy data. This data may include credentials identifying carry policy data. This data may include credentials identifying
users or user classes, account numbers, limits, quotas, etc. users or user classes, account numbers, limits, quotas, etc.
To protect the integrity of the policy-based admission control To protect the integrity of the policy-based admission control
mechanisms, it may be necessary to ensure the integrity of RSVP mechanisms, it may be necessary to ensure the integrity of RSVP
messages against corruption or spoofing, hop by hop. For this messages against corruption or spoofing, hop by hop. For this
purpose, RSVP messages may carry integrity objects that can be purpose, RSVP messages may carry integrity objects that can be
created and verified by neighboring RSVP-capable nodes. These created and verified by neighbor RSVP-capable nodes. These
objects are expected to contain an encrypted part and to assume a objects are expected to contain an encrypted part and to assume a
shared secret between neighbors. shared secret between neighbors.
User policy data in reservation request messages presents a User policy data in reservation request messages presents a
scaling problem. When a multicast group has a large number of scaling problem. When a multicast group has a large number of
receivers, it will not be possible or desirable to carry all the receivers, it will be impossible or undesirable to carry all
receivers' policy data upstream to the sender(s). The policy data receivers' policy data upstream to the sender(s). The policy data
will have to be administratively merged, near enough to the will have to be administratively merged at places near the
receivers to avoid excessive policy data. Administrative merging receivers, to avoid excessive policy data. Administrative merging
implies checking the user credentials and accounting data and then implies checking the user credentials and accounting data and then
substituting a token indicating the check has succeeded. A chain substituting a token indicating the check has succeeded. A chain
of trust established using an integrity field will allow upstream of trust established using an integrity field will allow upstream
nodes to accept these tokens. nodes to accept these tokens.
Note that the merge points for policy data are likely to be at the In summary, different administrative domain in the Internet may
boundaries of administrative domains. It may be necessary to have different policies regarding their resource usage and
carry accumulated and unmerged policy data upstream through reservation. The role of RSVP is to carry policy data associated
multiple nodes before reaching one of these merge points. with each reservation to the network as needed. Note that the
merge points for policy data are likely to be at the boundaries of
administrative domains. It may be necessary to carry accumulated
and unmerged policy data upstream through multiple nodes before
reaching one of these merge points.
2.6 Automatic RSVP Tunneling 2.8 Automatic RSVP Tunneling
It is impossible to deploy RSVP (or any new protocol) at the same It is impossible to deploy RSVP (or any new protocol) at the same
moment throughout the entire Internet. Furthermore, RSVP may moment throughout the entire Internet. Furthermore, RSVP may
never be deployed everywhere. RSVP must therefore provide correct never be deployed everywhere. RSVP must therefore provide correct
protocol operation even when two RSVP-capable routers are joined protocol operation even when two RSVP-capable routers are joined
by an arbitrary "cloud" of non-RSVP routers. Of course, an by an arbitrary "cloud" of non-RSVP routers. Of course, an
intermediate cloud that does not support RSVP is unable to perform intermediate cloud that does not support RSVP is unable to perform
resource reservation, so service guarantees cannot be made. resource reservation. However, if such a cloud has sufficient
However, if such a cloud has sufficient excess capacity, it may capacity, it may still provide acceptable realtime service.
provide acceptable and useful realtime service.
RSVP will automatically tunnel through such a non-RSVP cloud. RSVP automatically tunnels through such a non-RSVP cloud. Both
Both RSVP and non-RSVP routers forward PATH messages towards the RSVP and non-RSVP routers forward PATH messages towards the
destination address using their local uni-/multicast routing destination address using their local uni-/multicast routing
table. Therefore, the routing of PATH messages will be unaffected table. Therefore, the routing of PATH messages will be unaffected
by non-RSVP routers in the path. When a PATH message traverses a 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 non-RSVP cloud, it carries to the next RSVP-capable node the IP
Hop address the IP address of the last RSVP-capable router before address of the last RSVP-capable router before entering the cloud.
entering the cloud. This will effectively construct a tunnel This effectively constructs a tunnel through the cloud for RESV
through the cloud for RESV messages, which will be forwarded messages, which can then be forwarded directly to the next RSVP-
directly to the next RSVP-capable router on the path(s) back capable router on the path(s) back towards the source.
towards the source.
Automatic tunneling is not perfect; in some circumstances it may Some interconnection topologies of RSVP and non-RSVP routers can
distribute path information to RSVP-capable routers not included cause RESV messages to arrive at the wrong RSVP-capable node, or
in the data distribution paths, which may create unused to arrive at the wrong interface at the correct node. An RSVP
reservations at these routers. This is because PATH messages daemon must be prepared to handle either situation. When a RESV
carry the IP source address of the previous hop, not of the message arrives, its IP destination address should normally be the
original sender, and multicast routing may depend upon the source address of one of the local interfaces. If so, the reservation
as well as the destination address. This can be overcome by should be made on the addressed interface, even if it is not the
manual configuration of the neighboring RSVP programs, when one on which the message arrived. If the destination address does
necessary. not match any local interface and the message is not a PATH or
PTEAR, it should be forwarded without further processing by this
node.
2.7 Host Model 2.9 Host Model
Before a session can be created, the session identification, Before a session can be created, the session identification,
comprised of DestAddress and perhaps the generalized destination comprised of DestAddress and perhaps the generalized destination
port, must be assigned and communicated to all the senders and port, must be assigned and communicated to all the senders and
receivers by some out-of-band mechanism. When an RSVP session is receivers by some out-of-band mechanism. When an RSVP session is
being set up, the following events happen at the end systems. being set up, the following events happen at the end systems.
H1 A receiver joins the multicast group specified by H1 A receiver joins the multicast group specified by
DestAddress, using IGMP. DestAddress, using IGMP.
H2 A potential sender starts sending RSVP PATH messages to the H2 A potential sender starts sending RSVP PATH messages to the
DestAddress, using RSVP. DestAddress.
H3 A receiver application receives a PATH message. H3 A receiver application receives a PATH message.
H4 A receiver starts sending appropriate RESV messages, H4 A receiver starts sending appropriate RESV messages,
specifying the desired flow descriptors, using RSVP. specifying the desired flow descriptors.
H5 A sender application receives a RESV message. H5 A sender application receives a RESV message.
H6 A sender starts sending data packets. H6 A sender starts sending data packets.
There are several synchronization considerations. There are several synchronization considerations.
o Suppose that a new sender starts sending data (H6) but no o H1 and H2 may happen in either order.
receivers have joined the group (H1). Then there will be no
multicast routes beyond the host (or beyond the first RSVP- o Suppose that a new sender starts sending data (H6) but there
capable router) along the path; the data will be dropped at are no multicast routes because no receivers have joined the
the first hop until receivers(s) do appear (assuming a group (H1). Then the data will be dropped at some router
multicast routing protocol that "prunes off" or otherwise node (which node depends upon the routing protocol) until
avoids unnecessary paths). receivers(s) appear.
o Suppose that a new sender starts sending PATH messages (H2) o Suppose that a new sender starts sending PATH messages (H2)
and immediately starts sending data (H6), and there are and data (H6) simultaneously, and there are receivers but no
receivers but no RESV messages have reached the sender yet RESV messages have reached the sender yet (e.g., because its
(e.g., because its PATH messages have not yet propagated to PATH messages have not yet propagated to the receiver(s)).
the receiver(s)). Then the initial data may arrive at Then the initial data may arrive at receivers without the
receivers without the desired QoS. The sender could mitigate desired QoS. The sender could mitigate this problem by
this problem by awaiting arrival of the first RESV message awaiting arrival of the first RESV message (H5); however,
[H5]; however, receivers that are farther away may not have receivers that are farther away may not have reservations in
reservations in place yet. place yet.
o If a receiver starts sending RESV messages (H4) before any o If a receiver starts sending RESV messages (H4) before
PATH messages have reached it (H3), RSVP will return error receiving any PATH messages (H3), RSVP will return error
messages to the receiver. The receiver may simply choose to messages to the receiver.
ignore such error messages, or it may avoid them by waiting
for PATH messages before sending RESV messages. The receiver may simply choose to ignore such error messages,
or it may avoid them by waiting for PATH messages before
sending RESV messages. [LZ: should recommend that a receiver
wait for at least PATH messages to arrive before sending RESV
messages.]
A specific application program interface (API) for RSVP is not A specific application program interface (API) for RSVP is not
defined in this protocol spec, as it may be host system dependent. defined in this protocol spec, as it may be host system dependent.
However, Section 4.6.1 discusses the general requirements and However, Section 3.9.1 discusses the general requirements and
presents a generic API. presen
3. Examples
We use the following notation for a RESV message:
1. Wildcard-Filter (WF)
WF( *{Q})
Here "*{Q}" represents a Flow Descriptor with a "wildcard" scope
(choosing all senders) and a flowspec of quantity Q.
2. Fixed-Filter (FF)
FF( S1{Q1}, S2{Q2}, ...)
A list of (sender, flowspec) pairs, i.e., flow descriptors,
packed into a single RESV message.
3. Shared Explicit (SE)
SE( (S1,S2,...)Q1, (S3,S4,...)Q2, ...)
A list of shared reservations, each specified by a single
flowspec and a list of senders.
For simplicity we assume here that flowspecs are one-dimensional,
defining for example the average throughput, and state them as a
multiple of some unspecified base resource quantity B.
Figure 6 shows schematically a router with two previous hops labeled
(a) and (b) and two outgoing interfaces labeled (c) and (d). This
topology will be assumed in the examples that follow. There are
three upstream senders; packets from sender S1 (S2 and S3) arrive
through previous hop (a) ((b), respectively). There are also three
downstream receivers; packets bound for R1 and R2 (R3) are routed via
outgoing interface (c) ((d) respectively).
In addition to the connectivity shown in 6, we must also specify the
multicast routing within this node. Assume first that data packets
(hence, PATH messages) 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, the "Receive" column shows the RESV messages received
over outgoing interfaces (c) and (d) and the "Reserve" column shows
the resulting reservation state for each interface. The "Send"
column shows the RESV messages forwarded to previous hops (a) and
(b). In the "Reserve" column, each box represents one reservation
"channel", with the corresponding filter. As a result of merging,
only the largest flowspec is forwarded upstream to each previous hop.
|
Send | Reserve Receive
|
| _______
WF( *{3B} ) <- (a) | (c) | * {B} | (c) <- WF( *{B} )
| |_______|
|
-----------------------|----------------------------------------
| _______
WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} )
| |_______|
Figure 7: Wildcard-Filter (WF) Reservation Example
Figure 8 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 message forwarded to previous hop b.
On the other hand, the two different flow descriptors for sender S1
are merged into the single message FF( S1{3B} ), which is sent to
previous hop (a). For each outgoing interface, there is a private
reservation for each source that has been requested, but this private
reservation is shared among the receivers that made the request.
|
Send | Reserve Receive
|
| ________
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 a simple example of Shared-Explicit (SE) style
reservations. Here each outgoing interface has a single reservation
that is shared by a list 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, and S3 are routed to both outgoing interfaces. The top
part of Figure 10 shows another routing assumption: data packets
from S1 are not forwarded to interface (d), because the mesh topology
provides a shorter path for S1 -> R3 that does not traverse this
node. The bottom of Figure 10 shows WF style reservations under this
assumption. Since there is no route from (a) to (d), the reservation
forwarded out interface (a) considers only the reservation on
interface (c); no 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 a particular
interface I is never forwarded out the same interface. Conversely,
state that is forwarded out interface I must be computed using only
state that arrived on interfaces different from I. A trivial example
of this rule is illustrated in Figure 11, which shows a transit
router with one sender and one receiver on each interface (and
assumes one next/previous hop per interface). Interfaces (a) and (c)
are both outgoing and incoming interfaces for this session. Both
receivers are making wildcard-scope reservations, in which the RESV
messages are forwarded to all previous hops for senders in the group,
with the exception of the next hop from which they came. These
result in independent reservations in the two directions.
________________
a | | c
( R1, S1 ) <----->| Router |<-----> ( R2, S2 )
|________________|
Send | Receive
|
WF( *{3B}) <-- (a) | (c) <-- WF( *{3B})
|
Receive | Send
|
WF( *{4B}) --> (a) | (c) --> WF( *{4B})
|
Reserve on (a) | Reserve on (c)
__________ | __________
| * {4B} | | | * {3B} |
|__________| | |__________|
|
Figure 11: Independent Reservations
4. RSVP Functional Specification 3. RSVP Functional Specification
4.1 RSVP Message Formats 3.1 RSVP Message Formats
All RSVP messages consist of a common header followed by a An RSVP message consists of a common header followed by a variable
variable number of variable-length typed "objects". The number of variable-length, typed "objects". The subsections that
subsections that follow define the formats of the common header, follow define the formats of the common header, the object
the object structures, and each of the RSVP message types. structures, and each of the RSVP message types.
For each RSVP message type, there is a set of rules for the For each RSVP message type, there is a set of rules for the
permissible ordering and choice of object types. These rules are permissible choice and ordering of object types. These rules are
specified using Backus-Naur Form (BNF) augmented with square specified using Backus-Naur Form (BNF) augmented with square
brackets surrounding optional sub-sequences. brackets surrounding optional sub-sequences.
4.1.1 Common Header 3.1.1 Common Header
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Vers | Flags| Type | RSVP Checksum | | Vers | Flags| Type | RSVP Checksum |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| RSVP Length | (Reserved) | | RSVP Length | (Reserved) | Send_TTL |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Message ID | | Message ID |
+----------+--+-------------+-------------+-------------+ +----------+--+-------------+-------------+-------------+
|(Reserved)|MF| Fragment offset | |(Reserved)|MF| Fragment offset |
+----------+--+-------------+-------------+-------------+ +----------+--+-------------+-------------+-------------+
The fields in the common header are as follows: The fields in the common header are as follows:
Vers: 4 bits Vers: 4 bits
skipping to change at page 28, line 8 skipping to change at page 31, line 8
2 = RESV 2 = RESV
3 = PERR 3 = PERR
4 = RERR 4 = RERR
5 = PTEAR 5 = PTEAR
6 = RTEAR 6 = RTEAR
7 = RACK
RSVP Checksum: 16 bits RSVP Checksum: 16 bits
A standard TCP/UDP checksum over the contents of the RSVP A standard TCP/UDP checksum over the contents of the RSVP
message, with the checksum field replaced by zero. message, with the checksum field replaced by zero.
RSVP Length: 16 bits RSVP Length: 16 bits
The total length of this RSVP packet in bytes, including The total length of this RSVP packet in bytes, including
the common header and the variable-length objects that the common header and the variable-length objects that
follow. If the MF flag is on or the Fragment Offset field follow. If the MF flag is on or the Fragment Offset field
is non-zero, this is the length of the current fragment of is non-zero, this is the length of the current fragment of
a larger message. a larger message.
Send_TTL: 8 bits
The IP TTL value with which the message was sent.
Message ID: 32 bits Message ID: 32 bits
A label shared by all fragments of one message from a A label shared by all fragments of one message from a
given next/previous RSVP hop. An RSVP implementation given next/previous RSVP hop. An RSVP implementation
assignes a unique Message ID to each message it sends. assigns a unique Message ID to each message it sends.
MF: More Fragments Flag: 1 bit MF: More Fragments Flag: 1 bit
This flag is the low-order bit of a byte; the seven high- This flag is the low-order bit of a byte; the seven high-
order bits are reserved. It is on for all but the last order bits are reserved. It is on for all but the last
fragment of a message. fragment of a message.
Fragment Offset: 24 bits Fragment Offset: 24 bits
This field gives the byte offset of the fragment in the This field gives the byte offset of the fragment in the
message. message.
4.1.2 Object Formats 3.1.2 Object Formats
An object consists of one or more 32-bit words with a one-word Every object consists of one or more 32-bit words with a one-
header, in the following format: word header, in the following format:
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type | | Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
// (Object contents) // // (Object contents) //
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
An object header has the following fields: An object header has the following fields:
Length Length
A 16-bit field containing the total object length in A 16-bit field containing the total object length in
bytes. Must always be a multiple of 4, and at least 4. bytes. Must always be a multiple of 4, and at least 4.
Class-Num Class-Num
Identifies the object class; values of this field are Identifies the object class; values of this field are
skipping to change at page 29, line 15 skipping to change at page 32, line 21
Length Length
A 16-bit field containing the total object length in A 16-bit field containing the total object length in
bytes. Must always be a multiple of 4, and at least 4. bytes. Must always be a multiple of 4, and at least 4.
Class-Num Class-Num
Identifies the object class; values of this field are Identifies the object class; values of this field are
defined in Appendix A. Each object class has a name, defined in Appendix A. Each object class has a name,
which will always be capitalized in this document. An which is always capitalized in this document. An RSVP
RSVP implementation must recognize the following classes: implementation must recognize the following classes:
NULL NULL
A NULL object has a Class-Num of zero, and its C-Type A NULL object has a Class-Num of zero, and its C-Type
is ignored. Its length must be at least 4, but can is ignored. Its length must be at least 4, but can
be any multiple of 4. A NULL object may appear be any multiple of 4. A NULL object may appear
anywhere in a sequence of objects, and its contents anywhere in a sequence of objects, and its contents
will be ignored by the receiver. will be ignored by the receiver.
SESSION SESSION
Contains the IP destination address (DestAddress) and Contains the IP destination address (DestAddress),
possibly a generalized destination port, to define a the IP protocol id, and a generalized destination
specific session for the other objects that follow. port, to define a specific session for the other
Required in every RSVP message. objects that follow. Required in every RSVP message.
RSVP_HOP RSVP_HOP
Carries the IP address of the RSVP-capable node that Carries the IP address of the RSVP-capable node that
sent this message. This document refers to a sent this message. This document refers to a
RSVP_HOP object as a PHOP ("previous hop") object for RSVP_HOP object as a PHOP ("previous hop") object for
downstream messages or as a NHOP ("next hop") object downstream messages or as a NHOP ("next hop") object
for upstream messages. for upstream messages.
TIME_VALUES TIME_VALUES
If present, contains values for the refresh period R Contains the value for the refresh period R used by
and the state time-to-live T (see section 4.5), to the creator of the message; see 3.5. Required in
override the default values of R and T. every PATH and RESV message.
STYLE STYLE
Defines the reservation style plus style-specific Defines the reservation style plus style-specific
information that is not a FLOWSPEC or FILTER_SPEC information that is not in FLOWSPEC or FILTER_SPEC
object, in a RESV message. objects. Required in every RESV message.
FLOWSPEC FLOWSPEC
Defines a desired QoS, in a RESV message. Defines a desired QoS, in a RESV message.
FILTER_SPEC FILTER_SPEC
Defines a subset of session data packets that should Defines a subset of session data packets that should
receive the desired QoS (specified by an FLOWSPEC receive the desired QoS (specified by an FLOWSPEC
object), in a RESV message. object), in a RESV message.
skipping to change at page 30, line 28 skipping to change at page 33, line 35
additional demultiplexing information to identify a additional demultiplexing information to identify a
sender, in a PATH message. sender, in a PATH message.
SENDER_TSPEC SENDER_TSPEC
Defines the traffic characteristics of a sender's Defines the traffic characteristics of a sender's
data stream, in a PATH message. data stream, in a PATH message.
ADSPEC ADSPEC
Carries an Adspec containing OPWA data, in a PATH Carries OPWA data, in a PATH message.
message.
ERROR_SPEC ERROR_SPEC
Specifies an error, in a PERR or RERR message. Specifies an error, in a PERR or RERR message.
POLICY_DATA POLICY_DATA
Carries information that will allow a local policy Carries information that will allow a local policy
module to decide whether an associated reservation is module to decide whether an associated reservation is
administratively permitted. May appear in a PATH or administratively permitted. May appear in a PATH or
RESV message. RESV message.
INTEGRITY INTEGRITY
Contains cryptographic data to authenticate the Contains cryptographic data to authenticate the
originating node, and perhaps to verify the contents, originating node, and perhaps to verify the contents,
of this RSVP message. of this RSVP message.
SCOPE SCOPE
An explicit specification of the scope for forwarding An explicit list of sender hosts towards which to
a RESV message. forward a message. May appear in a RESV, RERR, or
RTEAR message.
RESV_CONFIRM
Carries the IP address of a receiver that requested a
confirmation. May appear in a RESV or RACK message.
C-Type C-Type
Object type, unique within Class-Num. Values are defined Object type, unique within Class-Num. Values are defined
in Appendix A. in Appendix A.
The maximum object content length is 65528 bytes. The Class- The maximum object content length is 65528 bytes. The Class-
Num and C-Type fields (together with the 'Optional' flag bit) Num and C-Type fields may be used together as a 16-bit number
may be used together as a 16-bit number to define a unique type to define a unique type for each object.
for each object.
The high-order bit of the Class-Num is used to determine what The high-order bit of the Class-Num is used to determine what
action a node should take if it does not recognize the Class- action a node should take if it does not recognize the Class-
Num of an object. If Class-Num < 128, then the node should Num of an object; see Section 3.8.
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 the first node that does know how to merge them.
The scaling limitations that this imposes must be considered
when defining and deploying new object types.
4.1.3 Path Message 3.1.3 Path Message
PATH messages carry information from senders to receivers along Each sender host periodically sends a PATH message containing a
the paths used by the data packets. The IP destination address description of each data stream it originates. The PATH
of a PATH message is the DestAddress for the session; the message travels from a sender to receiver(s) along the same
source address is an address of the node that sent the message path(s) used by the data packets. The IP source address of a
(preferably the address of the interface through which it was PATH message is an address of the sender it describes, while
sent). The PHOP (i.e., the RSVP_HOP) object of each PATH the destination address is the DestAddress for the session.
message must contain the address of the interface through which These addresses assure that the message will be correctly
the PATH message was sent. routed through a non-RSVP cloud.
Each RSVP-capable node along the path(s) captures PATH messages
and processes them to build local path state. The node then
forwards the PATH messages towards the receiver(s), replicating
it as dictated by multicast routing, while preserving the
original IP source address. PATH messages eventually reach the
applications on all receivers; however, they are not looped
back to a receiver running in the same application process as
the sender.
The format of a PATH message is as follows: The format of a PATH message is as follows:
<Path Message> ::= <Common Header> <SESSION> <RSVP_HOP> <Path Message> ::= <Common Header> <SESSION> <RSVP_HOP>
[ <INTEGRITY> ] [ <TIME_VALUES> ] [ <INTEGRITY> ] <TIME_VALUES>
<sender descriptor list>
<sender descriptor list> ::= <empty > |
<sender descriptor list> <sender descriptor> <sender descriptor>
<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ] <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <POLICY_DATA> ] [ <ADSPEC> ] [ <POLICY_DATA> ] [ <ADSPEC> ]
Each sender descriptor defines a sender, and the sender
descriptor list allows multiple sender descriptors to be packed
into a PATH message. For each sender in the list, the
SENDER_TEMPLATE object defines the format of data packets; in
addition, a SENDER_TSPEC object may specify the traffic flow, a
POLICY_DATA object may specify user credential and accounting
information, and an ADSPEC object may carry advertising (OPWA)
data.
Each sender host must periodically send PATH message(s)
containing a sender descriptor for each its own data stream(s).
Each sender descriptor is forwarded and replicated as necessary
to follow the delivery path(s) for a data packet from the same
sender, finally reaching the applications on all receivers
(except that it is not looped back to a receiver included in
the same application process as the sender).
It is an error to send ambiguous path state, i.e., two or more
Sender Templates that are different but overlap, due to
wildcards. For example, if we represent a Sender Template 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) The PHOP (i.e., the RSVP_HOP) object of each PATH message
contains the address of the interface through which the PATH
message was most recently sent. The SENDER_TEMPLATE object
defines the format of data packets from this sender, while the
SENDER_TSPEC object specifies the traffic characteristics of
the flow. Optionally, there may be a POLICY_DATA object
specifying user credential and accounting information and/or an
ADSPEC object carrying advertising (OPWA) data.
A PATH message received at a node is processed to create path A PATH message received at a node is processed to create path
state for all senders defined by SENDER_TEMPLATE objects in the state for the sender defined by the SENDER_TEMPLATE and SESSION
sender descriptor list. If present, any POLICY_DATA, objects. Any POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are
SENDER_TSPEC, and ADSPEC objects are also saved in the path also saved in the path state. If an error is encountered while
state. If an error is encountered while processing a PATH processing a PATH message, a PERR message is sent to the
message, a PERR message is sent to all senders implied by the originating sender of the PATH message. PATH messages must
SENDER_TEMPLATEs. satisfy the rules on SrcPort and DstPort in Section 2.2.
Periodically, the path state is scanned to create new 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 the (sender host address, DestAddress) pairs and
consist of a list of outgoing interfaces. The descriptors
being forwarded through the same outgoing interface may be
packed into as few PATH messages as possible. Note that
multicast routing of path information is based on the sender
address(es) from the sender descriptors, not the IP source
address; this is necessary to prevent routing loops; see
Section 4.3.
Multicast routing may also report the expected incoming Periodically, the RSVP daemon at a node scans the path state to
interface (i.e., the shortest path back to the sender). If so, create new PATH messages to forward downstream. Each message
any PATH message that arrives on a different interface should contains a sender descriptor defining one sender. The RSVP
be discarded immediately. daemon forwards these messages using routing information it
obtains from the appropriate uni-/multicast routing daemon.
The route depends upon the session DestAddress, and for some
routing protocols also upon the source (sender's IP) address.
The routing information generally includes the list of none or
more outgoing interfaces to which the PATH message to be
forwarded. Because each outgoing interface has a different IP
address, the PATH messages sent out different interfaces
contain different PHOP addresses. In addition, any ADSPEC or
POLICY_DATA objects carried in PATH messages will also
generally differ for different outgoing interfaces.
It is possible that routing will report no routes for a Some IP multicast routing protocols (e.g., DVMRP, PIM, and
(sender, DestAddress) pair; path state for this sender should MOSPF) also keep track of the expected incoming interface for
be stored locally but not forwarded. each source host to a multicast group. Whenever this
information is available, RSVP should check the incoming
interface of each PATH message and immediately discard those
messages that have arrived on the wrong interface.
4.1.4 Resv Messages 3.1.4 Resv Messages
RESV messages carry reservation requests hop-by-hop from RESV messages carry reservation requests hop-by-hop from
receivers to senders, along the reverse paths of data flow for receivers to senders, along the reverse paths of data flows for
the session. The IP destination address of a RESV message is the session. The IP destination address of a RESV message is
the unicast address of a previous-hop node, obtained from the the unicast address of a previous-hop node, obtained from the
path state. The IP source address is an address of the node path state. The IP source address is an address of the node
that sent the message. The NHOP (i.e., the RSVP_HOP) object that sent the message.
must contain the IP address of the (incoming) interface through
which the RESV message is sent.
The RESV message format is as follows: The RESV message format is as follows:
<Resv Message> ::= <Common Header> <SESSION> <RSVP_HOP> <Resv Message> ::= <Common Header> <SESSION> <RSVP_HOP>
[ <INTEGRITY> ] [ <TIME_VALUES> ] [ <INTEGRITY> ] <TIME_VALUES>
[ <S_POLICY_DATA> ] [ <SCOPE> ] [ <S_POLICY_DATA> ]
[ <RESV_CONFIRM> ] [ <SCOPE> ]
<STYLE> <flow descriptor list> <STYLE> <flow descriptor list>
<S_POLICY_DATA> ::= <POLICY DATA> <S_POLICY_DATA> ::= <POLICY_DATA>
<flow descriptor list> ::= <flow descriptor> | <flow descriptor list> ::= <flow descriptor> |
<flow descriptor list> <flow descriptor> <flow descriptor list> <flow descriptor>
Here the S_POLICY_DATA object is a POLICY_DATA object that is The NHOP (i.e., the RSVP_HOP) object contains the IP address of
associated with the session, i.e., with all the flows that may the (incoming) interface through which the RESV message is
be listed. There may also be flow-specific POLICY_DATA sent. The appearance of a RESV_CONFIRM object signals a
objects, as described below. 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 The BNF above defines a flow descriptor list as simply a list
of flow descriptors. The following style-dependent rules of flow descriptors. The following style-dependent rules
specify more exactly the composition of a valid flow descriptor specify in more detail the composition of a valid flow
list. descriptor list for each of the reservation styles.
o WF Style: o WF Style:
<flow descriptor list> ::= <WF flow descriptor> <flow descriptor list> ::= <WF flow descriptor>
<WF flow descriptor> ::= <FLOWSPEC> [ <F_POLICY_DATA> ]
<WF flow descriptor> ::=
<FLOWSPEC> [ <F_POLICY_DATA> ] <FILTER_SPEC>
<F_POLICY_DATA> ::= <POLICY_DATA> <F_POLICY_DATA> ::= <POLICY_DATA>
o FF style: o FF style:
<flow descriptor list> ::= <FF flow descriptor> | <flow descriptor list> ::= <First FF flow descriptor> |
<flow descriptor list> <FF flow descriptor> <flow descriptor list> <FF flow descriptor>
<First FF flow descriptor> ::=
<FLOWSPEC> [ <F_POLICY_DATA> ] <FILTER_SPEC>
<FF flow descriptor> ::= <FF flow descriptor> ::=
[ <FLOWSPEC> ] [ <F_POLICY_DATA> ] <FILTER_SPEC> [ <FLOWSPEC> ] [ <F_POLICY_DATA> ] <FILTER_SPEC>
Each elementary FF style request is defined by a single Each elementary FF style request is defined by a single
(FLOWSPEC, FILTER_SPEC) pair, and multiple such requests (FLOWSPEC, FILTER_SPEC) pair, and multiple such requests
may be packed into the flow descriptor list of a single may be packed into the flow descriptor list of a single
RESV message. A FLOWSPEC or POLICY_DATA object can be RESV message. A FLOWSPEC object can be omitted if it is
omitted if it is identical to the most recent such object identical to the most recent such object that appeared in
that appeared in the list. the list; the first FF flow descriptor must contain a
FLOWSPEC.
o SE style: o SE style:
<flow descriptor list> ::= <SE descriptor> <flow descriptor list> ::= <SE flow descriptor>
| <flow descriptor list> <SE flow descriptor>
<SE flow descriptor> ::= <SE flow descriptor> ::=
<FLOWSPEC> [ <F_POLICY_DATA> ] <filter spec list> <FLOWSPEC> [ <F_POLICY_DATA> ] <filter spec list>
<filter spec list> ::= <FILTER_SPEC> <filter spec list> ::= <FILTER_SPEC>
| <filter spec list> <FILTER_SPEC> | <filter spec list> <FILTER_SPEC>
Each elementary SE style request is defined by a single SE Each elementary SE style request is defined by a single SE
descriptor, which includes a FLOWSPEC defining the shared descriptor, which includes a FLOWSPEC defining the shared
reservation, possibly a POLICY_DATA object, and a list of reservation, optionally a POLICY_DATA object, and a list
FILTER_SPEC objects. Multiple elementary requests, each of FILTER_SPEC objects.
representing an independent shared reservation, may be
packed into the flow descriptor list of a single RESV
message. A POLICY_DATA object may be omitted if it is
identical to the most recent such object that appeared in
the list.
The reservation scope, i.e., the set of sender hosts towards The reservation scope, i.e., the set of senders towards which a
which a particular reservation is to be forwarded, is particular reservation is to be forwarded, is determined as
determined as follows: follows:
o For a style with explicit scope, match each FILTER_SPEC o Explicit sender selection
object against the path state created from SENDER_TEMPLATE
objects to select a particular sender. It is an error if
a FILTER_SPEC matches more than one SENDER_TEMPLATE, due
to wildcarding. A SCOPE object, if present, should be
ignored.
o For a style with wildcard scope, a SCOPE object, if Match each FILTER_SPEC object against the path state
present, defines the scope with an explicit list of sender created from SENDER_TEMPLATE objects to select a
IP addresses (see Section 4.3 below). If there is no particular sender. An ambiguous match, i.e., a
FILTER_SPEC matching more than one SENDER_TEMPLATE (e.g.
through use of a wildcard port), is an error. Any SCOPE
object associated with the reservation should be ignored
in this case.
o Wildcard sender selection
All senders that route to the given outgoing interface
match this request. A SCOPE object, if present, contains
an explicit list of sender IP addresses. If there is no
SCOPE object, the scope is determined by the relevant set SCOPE object, the scope is determined by the relevant set
of senders in the path state. A SCOPE object must be sent of senders in the path state. Whenever a RESV message
in any wildcard scope RESV message that is forwarded to with wildcard sender selection is forwarded to more than
more than one previous hop. See Section 4.3 below. one previous hop, a SCOPE object must be included in the
message. See Section 3.3 below.
4.1.5 Error Messages 3.1.5 Error and Confirmation Messages
There are two types of RSVP error messages. There are three types of RSVP error/confirmation messages.
o PERR messages result from PATH messages and travel towards o PERR messages result from PATH messages and travel towards
senders. PERR messages are routed hop-by-hop using the senders. PERR messages are routed hop-by-hop using the
path state; at each hop, the IP destination address is the path state; at each hop, the IP destination address is the
unicast address of a previous hop. unicast address of a previous hop.
o RERR messages result from RESV messages and travel towards o RERR messages result from RESV messages and travel towards
the appropriate receivers. They are routed hop-by-hop the appropriate receivers. They are routed hop-by-hop
using the reservation state; at each hop, the IP using the reservation state; at each hop, the IP
destination address is the unicast address of a next-hop destination address is the unicast address of a next-hop
node. node.
Errors encountered while processing error messages must not o RACK messages are sent to (probabilistically) acknowledge
create further error messages. reservation requests. A RACK message is sent as the
result of the appearance of a RESV_CONFIRM object in a
RESV message, and contains a copy of that RESV_CONFIRM.
The RACK message is sent to the unicast address of a
receiver host; the address is obtained from the
RESV_CONFIRM object. A RACK message is forwarded to the
receiver hop-by-hop by (to accommodate the hop-by-hop
integrity check mechanism).
Errors encountered while processing error messages must cause
the error message to be discarded without creating further
error messages; however, logging of such events may be useful.
None of these messages modify the state of any node through
which they pass; instead, they are only reported to the end
application.
<PathErr message> ::= <Common Header> <SESSION> <PathErr message> ::= <Common Header> <SESSION>
[ <INTEGRITY> ] <ERROR_SPEC> [ <INTEGRITY> ] <ERROR_SPEC>
<sender descriptor> <sender descriptor>
<sender descriptor> ::= (see earlier definition) <sender descriptor> ::= (see earlier definition)
<ResvErr Message> ::= <Common Header> <SESSION> <ResvErr Message> ::= <Common Header> <SESSION>
[ <INTEGRITY> ] [S_POLICY_DATA] [ <INTEGRITY> ] <ERROR_SPEC>
<ERROR_SPEC> [S_POLICY_DATA] [ <SCOPE> ]
<STYLE> <error flow descriptor> <STYLE> <error flow descriptor>
<ResvConf Message> ::= <Common Header> <SESSION>
[ <INTEGRITY> ] <ERROR_SPEC>
<RESV_CONFIRM>
<STYLE> <flow descriptor list>
<flow descriptor list> ::= (see earlier definition)
The RESV_CONFIRM object in a RACK message is a copy of the
object from the RESV message that triggered the confirmation.
The following style-dependent rules define the composition of a The following style-dependent rules define the composition of a
valid error flow descriptor in terms of sequences defined valid error flow descriptor:
earlier:
o WF Style: o WF Style:
<error flow descriptor> ::= <WF flow descriptor> <error flow descriptor> ::= <WF flow descriptor>
o FF style: o FF style:
<error flow descriptor> ::= <FF flow descriptor> <error flow descriptor> ::= <FF flow descriptor>
o SE style: o SE style:
<error flow descriptor> ::= <SE flow descriptor> <error flow descriptor> ::= <SE flow descriptor>
POLICY_DATA objects need be included in error messages only for
information when they are relevant (i.e., when an
administrative failure is being reported).
The ERROR_SPEC object specifies the error and includes the IP The ERROR_SPEC object specifies the error and includes the IP
address of the node that detected the error (Error Node address of the node that detected the error (Error Node
Address). 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 RACK
message, the ERROR_SPEC is used only to carry the IP address of
the originating node, in the Error Node Address; the error
specification is a special value that indicates a confirmation.
When a PATH or RESV message has been "packed" with multiple When a RESV message contains a list of flow descriptors (e.g.,
sets of elementary parameters, the RSVP implementation should FF style), the RSVP implementation should process each flow
process each set independently and return a separate error descritor independently and return a separate RERR message for
message for each that is in error. each that is in error.
In general, error messages should be delivered to the Generally speaking, a RERR message should be forwarded towards
applications on all the session nodes that (may have) all receivers that may have caused the error being reported.
contributed to this error. A PERR message is forwarded to all More specifically:
previous hops for all 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:
o The node that detects an error in a reservation request o The node that detects an error in a reservation request
creates and sends an RERR message to the next hop from sends a RERR message to the next hop from which the
which the erroneous reservation came. erroneous reservation came.
The message must contain the information required to The message must contain the information required to
define the error and to route the error message. Routing define the error and to route the error message. Routing
requires at least a STYLE object and one or more requires at least a STYLE object and one or more
FILTER_SPEC object(s) from the erroneous RESV message. FILTER_SPEC object(s) from the erroneous RESV message.
For an admission control failure, for example, the For an admission control failure, for example, the
erroneous FLOWSPEC must be included. erroneous FLOWSPEC must be included.
o Succeeding nodes forward the RERR message using their o Succeeding nodes forward the RERR message using their
local reservation state, to the next hops of reservations local reservation state, to the next hops of reservations
that match the FILTER_SPEC(s) in the message. For that match the FILTER_SPEC(s) in the message. For
reservations with wildcard scope, there is an additional reservations with wildcard scope, there is an additional
limitation on forwarding RERR messages, to avoid loops; limitation on forwarding RERR messages, to avoid loops;
see Section 4.3. see Section 3.3.
When the error is an admission control failure, a node is When the error is an admission control failure, a node is
allowed (but not required) to match the FLOWSPEC as well as the allowed (but not required) to match the FLOWSPEC as well as the
FILTER_SPEC object(s), to limit the distribution of a RERR FILTER_SPEC object(s), to limit the distribution of a RERR
message to those receivers that `caused' the error. Suppose message to those receivers that `caused' the error. Suppose
that a RERR message contains a FLOWSPEC Qerr that is being that a RERR message contains a FLOWSPEC Qerr that is being
matched against the FLOWSPEC Qlocal in the local reservation matched against the FLOWSPEC Qlocal in the local reservation
state in node N. Qerr, which originated in a node upstream state in node N. Qerr, which originated in a node upstream
from N, resulted from merging of flowspecs that included from N, resulted from merging of flowspecs that included
Qlocal. Generally, a RERR message can be forwarded to the Qlocal. Generally, a RERR message can be forwarded to the
receiver(s) that specified the `biggest' flowspec. The receiver(s) that specified the `biggest' flowspec. The
comparison of Qerr against a particular Qlocal to determine comparison of Qerr against a particular Qlocal to determine
whether Qlocal qualifies as (one of) the `biggest', may be whether Qlocal qualifies as (one of) the `biggest', may be
called `de-merging'. As with merging, the details of de- called `de-merging'. As with merging, the details of de-
merging depend upon the service and the FLOWSPEC format, and merging depend upon the service and the FLOWSPEC format, and
are outside RSVP itself. are outside RSVP itself.
A RERR message that is forwarded should carry the FILTER_SPEC A RERR message that is forwarded should carry the FILTER_SPEC
from the corresponding reservation state (thus `un-merging' the from the corresponding reservation state (thus `de-merging' the
filter spec). filter spec).
When a RERR message reaches a receiver, the STYLE object, flow When a RERR or RACK message reaches a receiver, the STYLE
descriptor list, and ERROR_SPEC object (which contains the object, flow descriptor list, and ERROR_SPEC object (which
LUB-Used flag) should be delivered to the receiver application. contains the LUB-Used flag) should be delivered to the receiver
In the case of an Admission Control error, the flow descriptor application. In the case of an Admission Control error, the
list will contain the FLOWSPEC object that failed. If the flow descriptor list will contain the FLOWSPEC object that
LUB-Used flag is off, this should be `equal' to (but not failed. If the LUB-Used flag is off, this should be
necessarily identical to) the FLOWSPEC originated by this semantically equivalent (but not necessarily identical) to the
application; otherwise, they may differ. FLOWSPEC originated by this application; otherwise, they may
differ.
4.1.6 Teardown Messages 3.1.6 Teardown Messages
There are two types of RSVP Teardown message, PTEAR and RTEAR. There are two types of RSVP Teardown message, PTEAR and RTEAR.
o A PTEAR message deletes path state (which may, in turn, o A PTEAR message deletes path state (which in turn deletes
delete reservation state) and travels towards all the reservation state for that sender, if there is any)
receivers that are downstream from the point of and travels towards all receivers that are downstream from
initiation. A PTEAR message is routed like a PATH the point of initiation. A PTEAR message is routed like a
message, and its IP destination address is DestAddress for PATH message, and its IP destination address is
the session. DestAddress for the session.
o A RTEAR message deletes reservation state and travels o A RTEAR message deletes reservation state and travels
towards all matching senders upstream from the point of towards all matching senders upstream from the point of
teardown initiation. A RTEAR message is routed like a teardown initiation. A RTEAR message is routed in the
corresponding RESV message (using the same scope rules). same way as a corresponding RESV message (using the same
Its IP destination address is the unicast address of a scope rules). Its IP destination address is the unicast
previous hop. address of a previous hop.
<PathTear Message> ::= <Common Header> <SESSION> <RSVP_HOP> <PathTear Message> ::= <Common Header> <SESSION> <RSVP_HOP>
[ <INTEGRITY> ] [ <INTEGRITY> ]
<sender descriptor list> <sender descriptor>
<sender descriptor list> ::= (see earlier definition) <sender descriptor> ::= (see earlier definition)
<ResvTear Message> ::= <Common Header> <SESSION> <RSVP_HOP> <ResvTear Message> ::= <Common Header> <SESSION> <RSVP_HOP>
[ <INTEGRITY> ] [ <SCOPE> ] [ <INTEGRITY> ] [ <SCOPE> ]
<STYLE> <flow descriptor list> <STYLE> <flow descriptor list>
<flow descriptor list> ::= (see earlier definition) <flow descriptor list> ::= (see earlier definition)
FLOWSPEC or POLICY_DATA objects in the flow descriptor list of FLOWSPEC or POLICY_DATA objects in the flow descriptor list of
a RTEAR message will be ignored and may be omitted. a RTEAR message will be ignored and may be omitted.
Note that the RTEAR message will cease to be forwarded at the Note that, unless it is accidentally dropped along the way, a
same node where merging suppresses forwarding of the PTEAR message will reach all the receivers down stream from its
corresponding RESV messages. The change will be propagated as origination. On the other hand, a RTEAR message will cease to
a new teardown message if the result has been to remove all be forwarded at the same node where merging suppresses
state for this session at this node; otherwise, it may result forwarding of the corresponding RESV messages. In each node N
in the immediate forwarding of a modified RESV refresh message. along the way, if the RTEAR message causes the removal of all
state for this session, N will create a new teardown message to
Deletion of path state, whether as the result of a teardown be propagated further upstream; otherwise, the RTEAR message
message or because of timeout, may force adjustments in related may result in the immediate forwarding of a modified RESV
reservation state to maintain consistency in the local node. refresh message.
The adjustment in reservation state depends upon the style. Deletion of path state as the result of a PTEAR message or a
For example, suppose a PTEAR deletes the path state for a timeout may force adjustments in related reservation state, to
sender S. If the style specifies distinct reservations (FF), maintain state consistency in the local node. The adjustment
only reservations for sender S should be deleted; if the style in reservation state depends upon the style. For example,
specifies shared reservations (WF or SE), delete the suppose a PTEAR deletes the path state for a sender S. If the
reservation if this was the last filter spec. These style specifies explicit sender selection (FF or SE), delete
reservation changes should not trigger an immediate RESV any reservation with a filter spec matching S; otherwise, the
refresh message, since the teardown message will have already style is wildcard sender selection (WF) and the reservation
made the required changes upstream. However, at the node in should be deleted if S is the last sender to the session.
which a RTEAR message stops, the change of reservation state These reservation changes should not trigger an immediate RESV
may trigger a RESV refresh starting at that node. refresh message, since the PTEAR message have already made the
required changes upstream. However, at the node in which a
RTEAR message stops, the change of reservation state may
trigger a RESV refresh starting at that node.
4.2 Sending RSVP Messages 3.2 Sending RSVP Messages
RSVP messages are sent hop-by-hop between RSVP-capable routers as RSVP messages are sent hop-by-hop between RSVP-capable routers as
"raw" IP datagrams with protocol number 46. Raw IP datagrams are "raw" IP packets with protocol number 46. Raw IP packets are
similarly intended to be used between an end system and the intended to be used between an end system and the first/last hop
first/last hop router; however, it is also possible to encapsulate router, although it is also possible to encapsulate RSVP messages
RSVP messages as UDP datagrams for end-system communication, as as UDP datagrams for end-system communication, as described in
described in Appendix C. UDP encapsulation may simplify Appendix C. UDP encapsulation is needed for systems that cannot
installation of RSVP on current end systems, particularly when do raw network I/O.
firewalls are in use.
PATH, PTEAR, and RACK messages must be sent with the Router Alert
IP option [Katz95] in their IP headers. This option may be used
by in the fast forwarding path of a high-speed router to detect
datagrams that require special processing.
Upon the arrival of an RSVP message M that changes the state, a Upon the arrival of an RSVP message M that changes the state, a
node must forward the modified state immediatly. If this is node must forward the modified state immediately. However, this
implemented as an immediate refresh of all the state for the must not trigger sending an message out the interface through
session, then no refresh messages should be sent out the interface which M arrived (as could happen if the implementation simply
through which M arrived. This rule is necessary to prevent packet triggered an immediate refresh of all state for the session).
storms on broadcast LANs. This rule is necessary to prevent packet storms on broadcast LANs.
An RSVP message must be fragmented when necessary to fit into the An RSVP message must be fragmented when necessary to fit into the
MTU of the interface through which it will be sent. All fragments MTU of the interface through which it will be sent. All fragments
of the message should carry the same unique value of the Message of the message should carry the same unique value of the Message
ID field, as well as appropriate Fragment Offset and MF bits, in ID field, as well as appropriate Fragment Offset and MF bits, in
their common headers. When an RSVP message arrives, it must be their common headers. When an RSVP message arrives, it must be
reassembled before it can be processed. The refresh period R is reassembled before it can be processed. The refresh period R can
appropriate as a ressembly timeout time. be used as an appropriate reassembly timeout time.
Since RSVP messages are normally expected to be generated and sent Since RSVP messages are normally generated and sent hop-by-hop,
hop-by-hop, using the RSVP-level fragmentation mechanism should using the RSVP-level fragmentation mechanism should avoid further
result in no IP fragmentation. However, IP fragmentation may fragmentation at the IP level. However, IP fragmentation may
occur through a non-RSVP cloud. For IP6, which does not support still occur when RSVP messages travel through a non-RSVP cloud.
router fragmentation, this case will require that the RSVP In case of IP6, which does not support IP fragmentation at
implementation use Path MTU Discovery or hand configuration to routers, an RSVP implementation must use Path MTU Discovery or
obtain an appropriate MTU. hand configuration to obtain an appropriate MTU between adjacent
RSVP neighbors.
Under overload conditions, lost RSVP control messages could cause RSVP recovers from occasional packet losses by its periodic
a failure of resource reservations. Routers should be configured refresh mechanism. Under network overload, however, substantial
to give a preferred class of service to RSVP packets. RSVP should losses of RSVP messages could cause a failure of resource
not use significant bandwidth, but queueing delay and dropping of reservations. To control the queueing delay and dropping of RSVP
RSVP messages needs to be controlled. Loss of RSVP packets packets, routers should be configured to offer them a preferred
through a congested non-RSVP cloud may still be a problem. The class of service. If RSVP packets experience noticeable losses
simplest solution is to adopt a larger value for the timeout when crossing a congested non-RSVP cloud, a larger value can be
factor K (see section 4.5 below). If this does not suffice, used for the timeout factor K (see section 3.5 below).
neighboring RSVP routers could use a TCP connection to pass RSVP
messages through a non-RSVP cloud. The current protocol contains
no automatic mechanism to setting up such connections; hand
configuration is assumed.
Some multicast routing protocols provide for "multicast tunnels", Some multicast routing protocols provide for "multicast tunnels",
which encapsulate multicast packets for transmission through which encapsulate multicast packets for transmission through
routers that do not have multicast capability. A multicast tunnel routers that do not have multicast capability. A multicast tunnel
looks like a logical outgoing interface that is mapped into some looks like a logical outgoing interface that is mapped into some
physical interface. A multicast routing protocol that supports physical interface. A multicast routing protocol that supports
tunnels will describe a route using a list of logical rather than tunnels will describe a route using a list of logical rather than
physical interfaces. RSVP can support multicast tunnels in the physical interfaces. RSVP can run through multicast tunnels in
following manner: the following manner:
1. When a node N forwards a PATH message out a logical outgoing 1. When a node N forwards a PATH message out a logical outgoing
interface L, it includes in the message some encoding of the interface L, it includes in the message some encoding of the
identity of L. This information is carried (in the HOP identity of L, called the "logical interface handle" or LIH.
object) as a value called the "logical interface handle" or The LIH value is carried in the RSVP_HOP object.
LIH.
2. The next hop node N' stores the LIH value in its path state. 2. The next hop node N' stores the LIH value in its path state.
3. When N' sends a RESV message to N, it includes the LIH value 3. When N' sends a RESV message to N, it includes the LIH value
from the path state (again, in the HOP object). from the path state (again, in the RSVP_HOP object).
4. When the RESV message arrives at N, its LIH value provides 4. When the RESV message arrives at N, its LIH value provides
the information necessary to attach the reservation to the the information necessary to attach the reservation to the
appropriate logical interface. Note that N creates and appropriate logical interface. Note that N creates and
interprets the LIH; it is an opaque value to N'. interprets the LIH; it is an opaque value to N'.
4.3 Avoiding RSVP Message Loops 3.3 Avoiding RSVP Message Loops
We must ensure that the rules for forwarding RSVP control messages Forwarding of RSVP messages must avoid looping. In steady state,
avoid looping. In steady state, PATH and RESV messages are PATH and RESV messages are forwarded only once per refresh period
forwarded only once per refresh period on each hop. This avoids on each hop. This avoids looping packets, but there is still the
directly looping packets, but there is still the possibility of an possibility of an " auto-refresh" loop, clocked by the refresh
" auto-refresh" loop, clocked by the refresh period. The effect period. Such auto-refresh loops keep state active "forever", even
of such a loop is to keep state active "forever", even if the end if the end nodes have ceased refreshing it, until either the
nodes have ceased refreshing it (but the state will be deleted receivers leave the multicast group and/or the senders stop
when the receivers leave the multicast group and/or the senders sending PATH messages. On the other hand, error and teardown
stop sending PATH messages). On the other hand, error and messages are forwarded immediately and are therefore subject to
teardown messages are forwarded immediately and are therefore looping.
subject to direct looping.
o PATH Messages Consider each message type.
PATH messages are forwarded using routes determined by the o PATH Messages
appropriate routing protocol. For routing that is source-
dependent (e.g., some multicast routing algorithms), the RSVP
daemon must route each sender descriptor separately using the
source addresses found in the SENDER_TEMPLATE objects. This
should ensure that there will be no auto-refresh loops of
PATH messages, even in a topology with cycles.
Consider each message type. PATH messages are forwarded in exactly the same way as IP
data packets. Therefore there should be no loops of PATH
messages, even in a topology with cycles.
o PTEAR Messages o PTEAR Messages
PTEAR messages use the same routing as PATH messages and PTEAR messages use the same routing as PATH messages and
therefore cannot loop. therefore cannot loop.
o PERR Messages o PERR Messages
Since PATH messages do not loop, they create path state
Since PATH messages don't loop, they create path state
defining a loop-free reverse path to each sender. PERR defining a loop-free reverse path to each sender. PERR
messages are always directed to particular senders and messages are always directed to particular senders and
therefore cannot loop. therefore cannot loop.
o RESV Messages o RESV Messages
Like PERR message, RESV messages directed to particular RESV messages directed to particular senders (i.e., with
senders (i.e., with explicit scope) cannot loop. However, explicit sender selection) cannot loop. However, RESV
there is a potential for auto-refresh of RESV messages with messages with wildcard sender selection (WF style) have a
wildcard scope; the solution is presented below. potential for auto-refresh looping.
o RTEAR Messages o RTEAR Messages
RTEAR messages are routed the same as RESV messages and have Although RTEAR messages are routed the same as RESV messages,
an analogous looping problem for wildcard scope. during the second pass around a loop there will be no state
so any RTEAR message will be dropped. Hence there is no
looping problem here.
o RERR Messages o RERR Messages
RERR messages for wildcard scope reservations have the same RERR messages for WF style reservations may loop for
potential for looping as the reservations themselves, and the essentially the same reasons that RESV messages loop.
solution presented below is required.
If the topology has no loops, then looping of wildcard-scoped o RACK Messages
messages can be avoided by simply enforcing the rule given
earlier: state that is received through a particular interface
must never be forwarded out the same interface. However, when the
topology does have cycles then further effort is needed to prevent
auto-refresh loops in wildcard-scope RESV, RTEAR, and RERR
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 RACK messages are forwarded towards a fixed unicast receiver
forwarded to a particular previous hop, a new SCOPE object is address and cannot loop.
computed from the SCOPE objects that were received (in messages of
the same type). If the computed SCOPE object is empty, the If the topology has no loops, then looping of "wildcard" RESV and
message is not forwarded to the previous hop; otherwise, the RERR messages, i.e., messages with wildcard sender selection, can
message is sent containing the new SCOPE object. The rules for be avoided by simply enforcing the rule given earlier: state that
computing a new SCOPE object for a RESV or RTEAR message are as is received through a particular interface must never be forwarded
follows: out the same interface. However, when the topology does have
cycles, further effort is needed to prevent auto-refresh loops of
wildcard RESV messages and fast loops of wildcard RERR messages.
The solution to this problem adopted by this protocol
specification is for such messages to carry an explicit sender
address list in a SCOPE object.
When a RESV message with WF style is to be forwarded to a
particular previous hop, a new SCOPE object is computed from the
SCOPE objects that were received in matching RESV messages. If
the computed SCOPE object is empty, the message is not forwarded
to the previous hop; otherwise, the message is sent containing the
new SCOPE object. The rules for computing a new SCOPE object for
a RESV message are as follows:
1. The union is formed of the sets of sender IP addresses listed 1. The union is formed of the sets of sender IP addresses listed
in all SCOPE objects in the reservation state for the given in all SCOPE objects in the reservation state for the given
session. session.
If reservation state from some NHOP does not contain a SCOPE If reservation state from some NHOP does not contain a SCOPE
object, a substitute sender list must be created and included object, a substitute sender list must be created and included
in the union. For a wildcard scope (WF) message that arrived in the union. For a message that arrived on outgoing
on outgoing interface OI, the substitute list is the set of interface OI, the substitute list is the set of senders that
senders that route to OI. For an explicit scope (SE) route to OI.
message, it is the set of senders explicitly listed in the
message.
2. Any local senders (i.e., any sender applications on this 2. Any local senders (i.e., any sender applications on this
node) are removed from this set. node) are removed from this set.
3. If the SCOPE object is to be sent to PHOP, remove from the 3. If the SCOPE object is to be sent to PHOP, remove from the
set any senders that did not come from PHOP. set any senders that did not come from PHOP.
Figure 12 shows an example of wildcard-scoped (WF style) RESV Figure 11 shows an example of wildcard-scoped (WF style) RESV
messages. The address lists within SCOPE objects are shown in messages. The address lists within SCOPE objects are shown in
square brackets. Note that there may be additional connections square brackets. Note that there may be additional connections
among the nodes, creating looping topology that is not shown. among the nodes, creating looping topology that is not shown.
________________ ________________
a | | c a | | c
R4, S4<----->| Router |<-----> R2, S2, S3 R4, S4<----->| Router |<-----> R2, S2, S3
| | | |
b | | b | |
R1, S1<----->| | R1, S1<----->| |
skipping to change at page 43, line 30 skipping to change at page 47, line 30
| |
Receive on (a): | Send on (c): Receive on (a): | Send on (c):
| |
WF( [S1,S2,S3]) --> | WF( [S2, S3]) --> WF( [S1,S2,S3]) --> | WF( [S2, S3]) -->
| |
Receive on (b): | Receive on (b): |
| |
WF( [S2,S3,S4]) --> | WF( [S2,S3,S4]) --> |
| |
Figure 12: SCOPE Objects in Wildcard-Scope Reservations Figure 11: SCOPE Objects in Wildcard-Scope Reservations
SCOPE objects are not necessary if the multicast routing uses SCOPE objects are not necessary if the multicast routing uses
shared trees or if the reservation style has explicit scope. shared trees or if the reservation style has explicit sender
Furthermore, attaching a SCOPE object to a reservation may be selection. Furthermore, attaching a SCOPE object to a reservation
deferred to a node which has more than one previous hop upstream. may be deferred to a node which has more than one previous hop
upstream.
The following rules are used for SCOPE objects in wildcard-scoped The following rules are used for SCOPE objects in RERR messages
RERR messages: with WF style:
1. The node that detected the error initiates an RERR message 1. The node that detected the error initiates an RERR message
containing a copy of the SCOPE object associated with the containing a copy of the SCOPE object associated with the
reservation state or message in error. reservation state or message in error.
2. Suppose a wildcard-scoped RERR message arrives at a node with 2. Suppose a wildcard-scoped RERR message arrives at a node with
a SCOPE object containing the sender host address list L. a SCOPE object containing the sender host address list L.
The node forwards the RERR message using the rules of Section The node forwards the RERR message using the rules of Section
4.1.5. However, the RERR message forwarded out OI must 3.1.5. However, the RERR message forwarded out OI must
contain a SCOPE object derived from L by including only those contain a SCOPE object derived from L by including only those
senders that route to OI. If this SCOPE object is empty, the senders that route to OI. If this SCOPE object is empty, the
RERR message should not be sent out OI. RERR message should not be sent out OI.
4.4 Local Repair 3.4 Local Repair
When a route changes, the next PATH or RESV refresh will establish When a route changes, the next PATH or RESV refresh message will
path or reservation state (respectively) along the new route. To establish path or reservation state (respectively) along the new
provide fast adaptation to routing changes without the overhead of route. To provide fast adaptation to routing changes without the
short refresh periods, the local routing protocol module can overhead of short refresh periods, the local routing protocol
notify the RSVP daemon of route changes for particular module can notify the RSVP daemon of route changes for particular
destinations. The RSVP daemon should use this information to destinations. The RSVP daemon should use this information to
trigger an immediate refresh of state for these destinations, trigger a quick refresh of state for these destinations, using the
using the new route. new route.
More specifically, the rules are as follows: More specifically, the rules are as follows:
o When routing detects a change of the set of outgoing o When routing detects a change of the set of outgoing
interfaces for sending PATH messages for destination G, RSVP interfaces for destination G, RSVP should wait for a short
sends immediate PATH refreshes for all sessions G/* (i.e., period W, and then send PATH refreshes for all sessions G/*
for any session with destination G, regardless of destination (i.e., for any session with destination G, regardless of
port). Such refresh messages are to be sent to at least the destination port).
new outgoing interfaces for these sessions.
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 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 o When a PATH message arrives with a Previous Hop address that
differs from the one stored in the path state, RSVP should differs from the one stored in the path state, RSVP should
send immediate RESV refreshes for that session. send immediate RESV refreshes for that session.
4.5 Time Parameters 3.5 Time Parameters
There are two time parameters relevant to each element of RSVP There are two time parameters relevant to each element of RSVP
path or reservation state in a node: the refresh period R between path or reservation state in a node: the refresh period R between
receiving successive refreshes for the state, and its lifetime L. generation of successive refreshes for the state by the neighbor
Each RSVP RESV or PATH message may contain a TIME_VALUES object node, and the local state's lifetime L. Each RSVP RESV or PATH
specifying the R value that was used to generate this refresh message may contain a TIME_VALUES object specifying the R value
message; this is used to determine the L when the state is that was used to generate this (refresh) message. This R value is
received and stored. 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: In more detail:
1. To avoid premature loss of state, we require that L >= (K + 1. Floyd and Jacobson [FJ94] have shown that periodic messages
0.5)* R, where K is a small integer. Then K-1 successive generated by independent network nodes can become
messages may be lost without state being deleted. Currently synchronized. This can lead to disruption in network
K = 3 is suggested. services as the periodic messages contend with other network
traffic for link and forwarding resources. Since RSVP sends
periodic refresh messages, it must avoid message
synchronization and ensure that any synchronization that may
occur is not stable.
2. Each message will generally carry a TIME_VALUES object For this reason, the refresh timer should be randomly set to
containing the R used to generate refreshes; the recipient a value in the range [0.5R, 1.5R].
node uses this R to determine L of the stored state.
However, if a default R = Rdef is used, the TIME_VALUES 2. To avoid premature loss of state, L must satisfy L >= (K +
object may be omitted from a message. Rdef is currently 0.5)*1.5*R, where K is a small integer. Then in the worst
defined to be 30 seconds. case, K-1 successive messages may be lost without state being
deleted. To compute a lifetime L for a collection of state
with different R values R0, R1, ..., replace R by max(Ri).
3. This document does not specify the interval R to be used for Currently K = 3 is suggested as the default. However, it may
generating refresh messages. If the node does not implement be necessary to set a larger K value for hops with high loss
local repair of reservations disrupted by route changes, a rate. K may be set either by manual configuration per
smaller R improves the speed of adapting to routing changes interface, or by some adaptive technique that has not yet
(but increases overhead). With local repair, a router can be been specified.
more relaxed about R since the periodic refresh becomes only
a backstop robustness mechanism. A node may therefore adjust
the effective R dynamically to limit the overhead due to
refresh messages.
4. The TIME_VALUES object could contain, in addition to the 3. Each message that creates state (PATH or RESV message)
hop-by-hop R value, an end-to-end upper bound on R, called carries a TIME_VALUES object containing the R used to
Rmax. When Rmax is specified, a node cannot set R > Rmax. generate refreshes; the recipient node uses this R to
However, a node is allowed to refuse an RSVP message (i.e., determine L of the stored state.
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 a kind of admission control
failure.
5. However, when R is changed dynamically, there is a limit to 4. R is chosen locally by each node. If the node does not
how fast it may increase. Specifically, the ratio of two implement local repair of reservations disrupted by route
successive values R2/R1 must not exceed 1 + Slew.Max. changes, a smaller R speeds up adaptation to routing changes,
while increasing the RSVP overhead. With local repair, a
router can be more relaxed about R since the periodic refresh
becomes only a backstop robustness mechanism. A node may
therefore adjust the effective R dynamically to control the
amount of overhead due to refresh messages.
The current suggested default for R is 30 seconds. However,
the 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 Currently, Slew.Max is 0.30. With K = 3, one packet may be
lost without state timeout while R is increasing 30 percent lost without state timeout while R is increasing 30 percent
per refresh cycle. per refresh cycle.
6. To improve robustness, a node may temporarily send refreshes 6. To improve robustness, a node may temporarily send refreshes
more often than R after a state change (including initial more often than R after a state change (including initial
state establishment). state establishment).
7. A node should randomize its refresh timeouts to avoid 7. The values of Rdef, K, and Slew.Max used in an implementation
synchronization and burstiness of refreshes. 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.
8. The values of Rdef, K, and Slew.Max used in an implementation 3.6 Traffic Policing and TTL
should be easily modifiable, as experience may lead to
different values. The possibility of dynamically changing K
and/or Slew.Max in response to measured loss rates is for
future study.
4.6 RSVP Interfaces RSVP is required to compute and pass several service-related flags
to traffic control: policing flags and a non-RSVP flag.
Some QoS services may require traffic policing at some or all of
(1) the edge of the network, (2) a merging point for data from
multiple senders, and/or (3) a branch point where traffic flow
from upstream may be greater than the downstream reservation.
RSVP knows where such points occur and must so indicate to the
traffic control mechanism. On the other hand, RSVP does not
interpret the service embodied in the flowspec and therefore does
not know whether policing will actually be applied in any
particular case.
The RSVP daemon passes to traffic control a separate policing flag
for each of these three situations.
o E_Police_Flag -- Entry Policing
This flag is set in the first-hop RSVP node that implements
traffic control (and is therefore capable of policing).
For example, sender hosts must implement RSVP but currently
many of them do not implement traffic control. In this case,
the E_Police_Flag should be off in the sender host, and it
should only be set on when the first hop capable of traffic
control is reached. This is controlled by the E_Police flag
in SESSION objects.
o M_Police_Flag -- Merge Policing
This flag should be set on for a 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 flowspec being installed
is smaller than, or incomparable to, a FLOWSPEC in place on
any other interface, for the same FILTER_SPEC and SESSION.
RSVP must also detect and report to receivers the presence of
non-RSVP hops in the path. For this purpose, an RSVP daemon must
place into each PATH message that it sends the value of the IP TTL
with which the message was sent. The RSVP-capable node that
receives this message compares this field to the TTL with which
the message was actually received, and if they differ it turns on
the Non_RSVP flag. This flag is carried forward to receivers in
the ADSPEC [??].
3.7 Multihomed Hosts
Accommodating multihomed hosts requires some special rules in
RSVP. We use the term `multihomed host' to cover both hosts (end
systems) with more than one network interface [could ref. section
3.3.4 of RFC-1122], and routers that are supporting local
application programs.
An application executing on a multihomed host may explicitly
specify which interface any given flow will use for sending and/or
for receiving data packets, to override the system-specified
default interface. The RSVP daemon must be aware of the default,
and if an application sets a specific interface, it must also pass
that information to RSVP.
o Sending Data
A sender application uses an API call (SENDER in Section
3.9.1) to declare to RSVP the characteristics of the data
flow it will originate. This call may optionally include the
local IP address of the sender. If it is set by the
application, this parameter must be the interface address for
sending the data packets; otherwise, the system default
interface is implied.
The RSVP daemon on the host then sends PATH messages for this
application out the specified interface (only).
o Making Reservations
A receiver application uses an API call (called RESERVE in
Section 3.9.1) to request a 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 been joined. If the parameter is
omitted, the system default interface is used.
In general, the RSVP daemon should send RESV messages for
application out the specified interface. However, when the
application is executing on a router and the session is
multicast, a more complex situation arises. Suppose in this
case that a receiver application joins the group on an
interface Iapp that differs from Isp, the shortest-path
interface to the sender. Then there are two possible ways
for multicast routing to deliver data packets to the
application. The RSVP daemon must determine which case holds
by examining the path state, to decide which incoming
interface to use for sending RESV messages.
1. The multicast routing protocol may create a separate
branch of the multicast distribution `tree' to deliver
to Iapp. In this case, there will be path state for
both Isp and Iapp. The path state on Iapp should only
match a reservation from the local application; it must
be marked "Local_only" by the RSVP daemon. If
"Local_only" path state for Iapp exists, the RESV
message should be sent out Iapp.
Note that it is possible for the path state blocks for
Isp and Iapp to have the same next hop, if there is an
intervening non-RSVP cloud.
2. The multicast routing protocol may forward data within
the router from Isp to Iapp. In this case, Iapp will
appear in the list of outgoing interfaces of the path
state for Isp, and the RESV message should be sent out
Isp.
3.8 Future Compatibility
We may expect that in the future new object C-Types will be
defined for existing object classes, and perhaps new object
classes will be defined. It will be desirable to employ such new
objects within the Internet using older implementations that do
not recognize them. Unfortunately, this is only possible to a
limited degree with reasonable complexity. The rules are as
follows.
1. Unknown Class
There are two possible ways that an RSVP implementation can
treat an object with unknown class. This choice is
determined by the high-order bit of the Class-Num octet, as
follows.
o Class-Num >= 128
In this case, the entire message should be rejected and
an "Unknown Object Class" error returned.
o Class-Num < 128
In this case, the node should ignore the object but
forward it, unexamined and unmodified, in all messages
resulting from the state contained in this message.
For example, suppose that a RESV message that is
received contains an object of unknown class. Such an
object should be saved in the reservation state without
further examination; however, only the 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 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 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 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 appearance of an object with unknown C-Type
should result in rejection of the entire message and
generation of an error message (RERR or PERR as appropriate).
The error message will include the Class-Num and C-Type that
failed (see Appendix B); the end system that originated the
failed message may be able to use this information to retry
the request using a different C-Type object, repeating this
process until it runs out of alternatives or succeeds.
Objects of certain classes (FLOWSPEC, ADSPEC, and
POLICY_DATA) are opaque to RSVP, which simply hands them to
traffic control or policy modules. Depending upon its
internal rules, either of the latter modules may reject a C-
Type and inform the RSVP daemon; RSVP should then reject the
message and send an error, as described in the previous
paragraph.
3.9 RSVP Interfaces
RSVP on a router has interfaces to routing and to traffic control. RSVP on a router has interfaces to routing and to traffic control.
RSVP on a host has an interface to applications (i.e, an API) and 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). also an interface to traffic control (if it exists on the host).
4.6.1 Application/RSVP Interface 3.9.1 Application/RSVP Interface
This section describes a generic interface between an This section describes a generic interface between an
application and an RSVP control process. The details of a real application and an RSVP control process. The details of a real
interface may be operating-system dependent; the following can interface may be operating-system dependent; the following can
only suggest the basic functions to be performed. Some of only suggest the basic functions to be performed. Some of
these calls cause information to be returned asynchronously. these calls cause information to be returned asynchronously.
o Register o Register Session
Call: REGISTER( DestAddress , DestPort Call: SESSION( DestAddress , ProtocolId, DstPort ,
[ , SESSION_object ] , SND_flag , RCV_flag [ , SESSION_object ]
[ , Source_Address ] [ , Source_Port ] [ , Upcall_Proc_addr ] ) -> Session-id
[ , Source_ProtID ] [ , Sender_Template ] This call initiates RSVP processing for a session, defined
by DestAddress together with ProtocolId and possibly a
port number DstPort. If successful, the SESSION call
returns immediately with a local session identifier
Session-id, which may be used in subsequent calls.
[ , Sender_Tspec ] [ , Data_TTL ] The Upcall_Proc_addr parameter defines the address of an
upcall procedure to receive asynchronous error or event
notification; see below. The SESSION_object parameter is
included as an escape mechanism to support some more
general definition of the session ("generalized
destination port"), should that be necessary in the
future. Normally SESSION_object will be omitted.
[ , Sender_Policy_Data ] o Define Sender
[ , Upcall_Proc_addr ] ) -> Session-id Call: SENDER( Session-id,
This call initiates RSVP processing for a session, defined [ , Source_Address ] [ , Source_Port ]
by DestAddress together with the TCP/UDP port number
DestPort. If successful, the REGISTER call returns
immediately with a local session identifier Session-id,
which may be used in subsequent calls.
The SESSION_object parameter is included as an escape [ , Sender_Template ]
mechanism to support some more general definition of the
session ("generalized destination port"), should that be
necessary in the future. Normally SESSION_object will be
omitted; if it is supplied, it should be an
appropriately-formatted representation of a SESSION
object.
SND_flag should be set true if the host will send data, [ , Sender_Tspec ] [ , Data_TTL ]
and RCV_flag should be set true if the host will receive
data. Setting neither true is an error. The optional
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 [ , Sender_Policy_Data ] )
RSVP to begin sending PATH messages for this session using A sender uses this call to define, or to modify the
these parameters, which are interpreted as follows: definition of, the attributes of the data stream. The
first SENDER call for the session registered as `Session-
id' will cause RSVP to begin sending PATH messages for
this session; later calls will modify the path
information.
The SENDER parameters are interpreted as follows:
- Source_Address - Source_Address
This is the address of the interface from which the This is the address of the interface from which the
data will be sent. If it is omitted, a default data will be sent. If it is omitted, a default
interface will be used. This parameter is needed on interface will be used. This parameter is needed on
a multihomed sender host. a multihomed sender host.
- Source_Port - Source_Port
This is the UDP/TCP port from which the data will be This is the UDP/TCP port from which the data will be
sent. If it is omitted or zero, the port is "wild" sent. If it is omitted or zero, the port is "wild"
and can match any port in a FILTER_SPEC. and can match any port in a FILTER_SPEC.
- Source_ProtID
This is the IP protocol ID for the sender data. If
it is omitted or zero, the protocol id is "wild" and
can match any protocol id in a FILTER_SPEC.
- Sender_Template - Sender_Template
This parameter is included as an escape mechanism to This parameter is included as an escape mechanism to
support a more general definition of the sender support a more general definition of the sender
("generalized source port"). Normally this parameter ("generalized source port"). Normally this parameter
may be omitted; if it is supplied, it should be an may be omitted.
appropriately formatted representation of a
SENDER_TEMPLATE object.
- Sender_Tspec - Sender_Tspec
This parameter is a Tspec describing the traffic flow This optional parameter describes the traffic flow to
to be sent. It may be included to prevent over- be sent. It may be included to prevent over-
reservation on the initial hops. reservation on the initial hops.
- Data_TTL - Data_TTL
This is the (non-default) IP Time-To-Live parameter This is the (non-default) IP Time-To-Live parameter
that is being supplied on the data packets. It is that is being supplied on the data packets. It is
needed to ensure that Path messages do not have a needed to ensure that Path messages do not have a
scope larger than multicast data packets. scope larger than multicast data packets.
- Sender_Policy_Data - Sender_Policy_Data
This optional parameter passes policy data for the This optional parameter passes policy data for the
sender. This data may be supplied by a system sender. This data may be supplied by a system
service, with the application treating it as opaque. service, with 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 o Reserve
Call: RESERVE( session-id, Call: RESERVE( session-id, [ receiver_address , ]
style, style-dependent-parms )
A receiver uses this call to make a resource reservation [ ACK_flag, ] style, style-dependent-parms )
for the session registered as `session-id'. The style
parameter indicates the reservation style. The rest of
the parameters depend upon the style, but generally these
will include appropriate flowspecs, filter specs, and
possibly receiver policy data objects.
A receiver uses this call to make or to modify a resource
reservation for the session registered as `session-id'.
The first RESERVE call will initiate the periodic The first RESERVE call will initiate the periodic
transmission of RESV messages. A later RESERVE call may transmission of RESV messages. A later RESERVE call may
be given to modify the parameters of the earlier call (but be given to modify the parameters of the earlier call (but
note that changing the reservations may result in note that changing existing reservations may result in
admission control failure, depending upon the style). admission control failure).
The optional `receiver_address' parameter may be used by a
receiver on a multihomed host (or router); it is the IP
address of one of the node's interfaces. The ACK_flag
should be set on if a reservation ACK is desired, off
otherwise. The `style' parameter indicates the
reservation style. The rest of the parameters depend upon
the style, but generally these will include appropriate
flowspecs, filter specs, and possibly receiver policy data
objects.
The RESERVE call returns immediately. Following a RESERVE The RESERVE call returns immediately. Following a RESERVE
call, an asynchronous ERROR/EVENT upcall may occur at any call, an asynchronous ERROR/EVENT upcall may occur at any
time. time.
o Release o Release
Call: RELEASE( session-id ) Call: RELEASE( session-id )
This call will terminate RSVP state for the session This call removes RSVP state for the session specified by
specified by session-id. It may send appropriate teardown session-id. The node then sends appropriate teardown
messages and will cease sending refreshes for this messages and ceases sending refreshes for this session-id.
session-id.
o Error/Event Upcalls o Error/Event Upcalls
Upcall: <Upcall_Proc>( ) -> session-id, Info_type, Upcall: <Upcall_Proc>( ) -> session-id, Info_type,
[ Error_code , Error_value , LUB-Used, ]
[ Error_code , Error_value ,
Error_Node , LUB-Used, ]
List_count, [ Flowspec_list,] List_count, [ Flowspec_list,]
[ Filter_spec_list, ] [ Advert_list, ] [ Filter_spec_list, ] [ Advert_list, ]
[ Policy_data ] [ Policy_data ]
Here "Upcall_Proc" represents the upcall procedure whose Here "Upcall_Proc" represents the upcall procedure whose
address was supplied in the REGISTER call. address was supplied in the SESSION call.
This upcall may occur asynchronously at any time after a This upcall may occur asynchronously at any time after a
REGISTER call and before a RELEASE call, to indicate an SESSION call and before a RELEASE call, to indicate an
error or an event. Currently there are three upcall error or an event. Currently there are five upcall types,
types, distinguished by the Info_type parameter: distinguished by the Info_type parameter:
1. Info_type = Path Event 1. Info_type = Path Event
A Path Event upcall indicates to a receiver A Path Event upcall results from receipt of the first
application that there is at least one active sender. PATH message for this session, indicating to a
It results from receipt of the first PATH message for receiver application that there is at least one
this session. active sender.
This upcall provides synchronizing information to the This upcall provides synchronizing information to the
receiver application, and it may also provide receiver application, and it may also provide
parallel lists of senders (in Filter_spec_list), parallel lists of senders (in Filter_spec_list),
traffic descriptions (in Flowspec_list), and service traffic descriptions (in Flowspec_list), and service
advertisements (in Advert_list). `List_count'will be advertisements (in Advert_list). `List_count' will
the number in each list; where these objects are be the number in each list; where these objects are
missing, corresponding null objects must appear. The missing, corresponding null objects must appear. The
Error_code, Error_value, LUB-Used flag, and Error_code, Error_value, LUB-Used flag, and
Policy_data parameters will be undefined in this Policy_data parameters will be undefined in this
upcall. upcall.
2. Info_type = Resv Event 2. Info_type = Resv Event
A Resv Event upcall indicates to a sender application A Resv Event upcall is triggered by the receipt of
that a reservation for this session in place along the first reservation message or by modification of a
the entire path to at least one receiver. It is previous reservation state, for this session.
triggered by the receipt of the first reservation
message or by modification of previous reservation
state, for this session.
`List_count' will be 1, and Flowspec_list will `List_count' will be 1, and Flowspec_list will
contain one FLOWSPEC, the effective QoS that would be contain one FLOWSPEC, the effective QoS that would be
applicable to the application itself. applicable to the application itself.
Filter_spec_list and Advert_list will contain one Filter_spec_list and Advert_list will contain one
NULL object. The Error_code, Error_value, LUB-Used NULL object. The Error_code, Error_value, LUB-Used
flag, and Policy_data parameters will be undefined in flag, and Policy_data parameters will be undefined in
this upcall. this upcall.
3. Info_type = Path Error 3. Info_type = Path Error
An Path Error event indicates an error in sender An Path Error event indicates an error in sender
information that was specified in the REGISTER call. information that was specified in a SENDER call.
The Error_code parameter will define the error, and The Error_code parameter will define the error, and
Error_value may supply some additional (perhaps Error_value may supply some additional (perhaps
system-specific) data about the error. `List_count' system-specific) data about the error. The
will be 1, and Filter_spec_list and Flowspec_list Error_Node parameter will specify the IP address of
will contain the Sender_Template supplied in the the node that detected the error.
REGISTER call; Sender_Tspec and Advert_list will each
`List_count' will be 1, and Filter_spec_list will
contain the Sender_Template supplied in the SENDER
call; Flow_Spec_list and Advert_list will each
contain one NULL object. The Policy_data parameter contain one NULL object. The Policy_data parameter
will be undefined in this upcall. will contain any POLICY_DATA objects in the PERR
message.
4. Info_type = Resv Error 4. Info_type = Resv Error/Confirmation
An Resv Error event indicates an error in processing An Resv Error/Confirmation event indicates an error
a reservation message to which this application in a reservation message to which this application
contributed. The Error_code parameter will define contributed, or the receipt of a RACK message. The
the error, and Error_value may supply some additional Error_code parameter will define the error or
(perhaps system-specific) data on the error. confirmation. For an error, Error_value may supply
some additional (perhaps system-specific) data. The
Error_Node parameter will specify the IP address of
the node that detected the event being reported.
Filter_spec_list and Flowspec_list will contain the Filter_spec_list and Flowspec_list will contain the
FILTER_SPEC and FLOWSPEC objects from the error flow FILTER_SPEC and FLOWSPEC objects from the error flow
descriptor (see Section 4.1.5). List_count will descriptor (see Section 3.1.5). List_count will
specify the number of FILTER_SPECS in specify the number of FILTER_SPECS in
Filter_spec_list, while there will be one FLOWSPEC in Filter_spec_list, while there will be one FLOWSPEC in
Flowspec_list. The Policy_data parameter will be Flowspec_list. For an error, the Policy_data
undefined in this upcall. parameter will contain any POLICY_DATA objects in the
RERR message.
5. Info_type = Policy Data
A Policy Information upcall passes a Policy_data
parameter containing policy information (accounting,
current costs, prices, quota, etc.) that arrived at
the receiver.
List_count will be zero, and the Error_code,
Error_value, and LUB-Used flag parameters will be
undefined in this upcall.
Although RSVP messages indicating path events or errors Although RSVP messages indicating path or resv events may
may be received periodically, the API should make the be received periodically, the API should make the
corresponding asynchronous upcall to the application only corresponding asynchronous upcall to the application only
on the first occurrence, or when the information to be on the first occurrence or when the information to be
reported changes. reported changes. All error and confirmation events
should be reported to the application.
4.6.2 RSVP/Traffic Control Interface 3.9.2 RSVP/Traffic Control Interface
In each router and host, enhanced QoS is achieved by a group of In an RSVP-capable node, enhanced QoS is achieved by a group of
inter-related traffic control functions: a packet classifier, inter-related traffic control functions: a packet classifier,
an admission control module, and a packet scheduler. This an admission control module, and a packet scheduler. This
section describes a generic RSVP interface to traffic control. section describes a generic RSVP interface to traffic control.
1. Make a Reservation o Make a Reservation
Call: Rhandle = TC_AddFlowspec( Interface, Flowspec Call: Rhandle = TC_AddFlowspec( Interface, TC_Flowspec,
[ , Sender_Tspec] TC_Tspec, E_Police_Flag,
, E_Police_Flag , M_Police_Flag ) M_Police_Flag, B_Police_Flag )
This call passes a Flowspec defining a desired QoS to The TC_Flowspec parameter defines the desired effective
admission control. It may also pass Sender_Tspec, the QoS to admission control; its value is computed as the
maximum traffic characteristics computed over the maximum over the flowspecs of different next hops (see the
SENDER_TSPECs of senders that will contribute data packets Compare_Flowspecs call below). It contains the effective
to this reservation. reservation Tspec Resv_Te (although the RSVP daemon itself
has no means to extract the Tspec). The TC_Tspec
parameter defines the effective sender Tspec Path_Te (see
Section 2.3). We assume that traffic control takes the
min of Resv_Te and Path_Te (see step (4) in Section 2.3).
E_Police_Flag and M_Police_Flag are Boolean parameters. E_Police_Flag, M_Police_Flag, and B_Police_Flag are
E_Police_Flag is on if this is an entry node, while Boolean parameters whose values should be set as described
M_Police is on if this node is an interior data merge in Section 3.6.
point for a shared reservation style. These flags are
used to enable traffic policing or shaping when
appropriate, in accordance with the service.
This call returns an error code if Flowspec is malformed The TC_AddFlowspec call returns an error code if Flowspec
or if the requested resources are unavailable. Otherwise, is malformed or if the requested resources are
it establishes a new reservation channel corresponding to unavailable. Otherwise, it establishes a new reservation
Rhandle. It returns the opaque number Rhandle for channel corresponding to Rhandle. It returns the opaque
subsequent references to this reservation. number Rhandle for subsequent references to this
reservation.
2. Modify Reservation o Modify Reservation
Call: TC_ModFlowspec( Rhandle, new_Flowspec Call: TC_ModFlowspec( Rhandle, new_Flowspec,
[ , Sender_Tspec] , Police_flag ) Sender_Tspec, E_Police_flag,
M_Police_Flag, B_Police_Flag )
This call can modify an existing reservation. If This call can modify an existing reservation. If
new_Flowspec is included, it is passed to Admission new_Flowspec is included, it is passed to Admission
Control; if it is rejected, the current flowspec is left Control; if it is rejected, the current flowspec is left
in force. The corresponding filter specs, if any, are not in force. The corresponding filter specs, if any, are not
affected. affected. The other parameters are defined as in
TC_AddFlowspec.
3. Delete Flowspec o Delete Flowspec
Call: TC_DelFlowspec( Rhandle ) Call: TC_DelFlowspec( Rhandle )
This call will delete an existing reservation, including This call will delete an existing reservation, including
the flowspec and all associated filter specs. the flowspec and all associated filter specs.
4. Add Filter Spec o Add Filter Spec
Call: FHandle = TC_AddFilter( Rhandle, Session , FilterSpec ) Call: FHandle = TC_AddFilter( Rhandle, Session , FilterSpec )
This call is used to associate an additional filter spec This call is used to associate an additional filter spec
with the reservation specified by the given Rhandle, with the reservation specified by the given Rhandle,
following a successful TC_AddFlowspec call. This call following a successful TC_AddFlowspec call. This call
returns a filter handle FHandle. returns a filter handle FHandle.
5. Delete Filter Spec o Delete Filter Spec
Call: TC_DelFilter( FHandle ) Call: TC_DelFilter( FHandle )
This call is used to remove a specific filter, specified This call is used to remove a specific filter, specified
by FHandle. by FHandle.
6. OPWA Update o OPWA Update
Call: TC_Advertise( interface, Adspec Call: TC_Advertise( interface, Adspec,
[ ,Sender_TSpec ] ) -> New_Adspec [ , Non_RSVP_flag ] ) -> New_Adspec
This call is used for OPWA to compute the outgoing This call is used for OPWA to compute the outgoing
advertisement New_Adspec for a specified interface. advertisement New_Adspec for a specified interface.
Sender_TSpec is also passed if it is available.
7. Preemption Upcall o Preemption Upcall
Upcall: TC_Preempt() -> RHandle, Reason_code Upcall: TC_Preempt() -> RHandle, Reason_code
In order to grant a new reservation request, the admission In order to grant a new reservation request, the admission
control and/or policy modules may be allowed to preempt an control and/or policy modules may be allowed to preempt an
existing reservation. This might be reflected in an existing reservation. This might be reflected in an
upcall to RSVP, passing the RHandle of the preempted upcall to RSVP, passing the RHandle of the preempted
reservation, and some indication of the reason. reservation, and some indication of the reason.
4.6.3 RSVP/Routing Interface 3.9.3 RSVP/Routing Interface
An RSVP implementation needs the following support from the An RSVP implementation needs the following support from the
packet forwarding and routing mechanisms of the node. packet forwarding and routing mechanisms of the node.
o Promiscuous receive mode for RSVP messages o Promiscuous Receive Mode for RSVP Messages
Any datagram received for IP protocol 46 must be diverted Any packet received for IP protocol 46 must be diverted to
to the RSVP program for processing, without being the RSVP program for processing, without being forwarded.
forwarded. The identity of the interface on which it is On a router, the identity of the interface, real or
received should also be available to the RSVP daemon. virtual, on which it is received must also be available to
the RSVP daemon.
o Route Query o Route Query
RSVP must be able to query the routing daemon for the To forward PATH and PTEAR messages, an RSVP daemon must be
route(s) for forwarding a specific datagram. able to query the routing daemon(s) for routes.
Ucast_Route_Query( DestAddress, Notify_flag ) -> OutInterface Ucast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag )
Mcast_Route_Query( SrcAddress, DestAddress, Notify_flag ) -> OutInterface
-> OutInterface_list Mcast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag )
-> [ IncInterface, ] OutInterface_list
Depending upon the routing protocol, the query may or may
not depend upon SrcAddress, i.e., upon the sender host IP
address, which is also the IP source address of the
message. Here IncInterface is the interface through which
the packet is expected to arrive; some multicast routing
protocols may not provide it.
If the Notify_flag is True, routing will save state If the Notify_flag is True, routing will save state
necessary to issue unsolicited route change notification necessary to issue unsolicited route change notification
callbacks whenever the specified route changes. This will callbacks (see below) whenever the specified route
continue until routing receives a route query call with changes. Such callbacks will be enabled until routing
the Notify_Flag set False. receives a route query call with the Notify_Flag set
False.
A multicast route query may return an empty
OutInterface_list if there are no receivers downstream of
a particular router. A route query may also return a `No
such route' error, probably as a result of a transient
inconsistency in the routing (since a PATH or PTEAR
message for the requested route did arrive at this node).
In either case, the local state should be updated as
requested by the message, although it cannot be forwarded
further. Updating local state will make path state
available immediately for a new local receiver, or it will
tear down path state immediately.
o Route Change Notification o Route Change Notification
If requested by a route query with the Notify_flag True, If requested by a route query with the Notify_flag True,
the routing daemon may provide an asynchronous callback to the routing daemon may provide an asynchronous callback to
RSVP that a specified route has changed. the RSVP daemon that a specified route has changed.
Ucast_Route_Change( ) -> DestAddress, OutInterface Ucast_Route_Change( ) -> DestAddress, OutInterface
Mcast_Route_Change( ) Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
-> SrcAddress, DestAddress, OutInterface_list [ IncInterface, ] OutInterface_list
o Outgoing Link Specification o Outgoing Link Specification
RSVP must be able to force a (multicast) datagram to be RSVP must be able to force a (multicast) datagram to be
sent on a specific outgoing virtual link, bypassing the sent on a specific outgoing virtual link, bypassing the
normal routing mechanism. A virtual link may be a real normal routing mechanism. A virtual link may be a real
outgoing link or a multicast tunnel. Outgoing link outgoing link or a multicast tunnel. Outgoing link
specification is necessary because RSVP may send different specification is necessary to send different versions of
versions of outgoing PATH messages for the same source and an outgoing PATH message on different interfaces. It is
destination addresses on different interfaces. It is also also necessary in some cases to avoid routing loops.
necessary in some cases to avoid routing loops.
o Discover Interface List o Source Address Specification
RSVP must be able to specify the IP source address to be
used when sending PATH messages.
o Interface List Discovery
RSVP must be able to learn what real and virtual RSVP must be able to learn what real and virtual
interfaces are active, with their IP addresses. interfaces are active, with their IP addresses.
5. Message Processing Rules 3.9.4 Service-Dependent Manipulations
This generic description of RSVP operation assumes the following data Flowspecs, Tspecs, and Adspecs are opaque objects to RSVP;
their contents are defined in service specification documents.
In order to manipulate these objects, RSVP daemon must have
available to it the following service-dependent routines.
o Compare Flowspecs
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
Tspecs that are contained. Although the RSVP daemon
cannot itself parse a flowspec to extract the Tspec, it
can use the Compare_Flowspecs call to implicitly calculate
Resv_Te (see Section 2.3).
o Compute LUB of Flowspecs
LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
Flowspec_LUB
o Compare Tspecs
Compare_Tspecs( Tspec_1, Tspec_2 ) -> result_code
The possible result_codes indicate: Tspecs are equal, or
Tspecs are unequal.
o Sum Tspecs
Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum
This call is used to compute Path_Te (see Section 2.3).
4. Message Processing Rules
This section provides a generic description of the rules for RSVP
operation. It is intended to outline a set of algorithms that will
accomplish the needed function. An actual implementation may use
different but equivalent algorithms. This section assumes the
generic interface calls defined in Section 3.9 and the following data
structures. An actual implementation may use additional or different structures. An actual implementation may use additional or different
structures to optimize processing. data structures and interfaces.
[NOTE: This section is always the last to be updated when changes are
made, and it is neither correct nor complete at the present time.
Therefore, when this section disagrees with the rest of the text, you
should believe the rest of the text!]
o PSB -- Path State Block o PSB -- Path State Block
Each PSB holds path state for a particular (session, sender) Each PSB holds path state for a particular (session, sender)
pair, which are defined by SESSION and SENDER_TEMPLATE objects, pair, defined by SESSION and SENDER_TEMPLATE objects,
respectively. PSB contents include a PHOP object and possibly respectively, received in a PATH message.
SENDER_TSPEC, POLICY_DATA, and/or ADSPEC objects from PATH
messages. PSB contents include the following values from a PATH message:
- The previous hop IP address from a PHOP object (required)
- LIH, the 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 routing: OutInterface_list, the list of outgoing interfaces
for this (sender, destination), and IncInterface, the expected
incoming interface. For a unicast destination,
OutInterface_list contains one entry and IncInterface is
undefined.
o RSB -- Reservation State Block o RSB -- Reservation State Block
Each RSB holds reservation state for a particular 4-tuple: Each RSB holds a reservation request that arrived in a
(session, next hop, style, filterspec), which are defined in particular RESV message, corresponding to the triple: (session,
SESSION, NHOP, STYLE, and FILTER_SPEC objects, respectively. next hop, filter_spec_list). Here "filter_spec_list" may be a
RSB contents also include a FLOWSPEC object and may include a list of FILTER_SPECs (for SE style), a single FILTER_SPEC (FF
POLICY_DATA object. We assume that RSB contents include the style), or empty (WF style). We use the symbol "FILTER_SPEC*"
outgoing interface OI that is implied by NHOP. 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 FLOWSPEC objects (required)
- The style (required)
- A POLICY_DATA object (optional)
- A SCOPE object (optional, depending on style)
- A RESV_CONFIRM object (optional)
o TCSB -- Traffic Control State Block
TCSB's hold 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
of filter specs.
Boolean flags Path_Refresh_Needed, Resv_Refresh_Needed, and
Tear_Needed will also be used in this section.
[LZ: It might be very helpful to have a short section to summarize
the management of all the timers.]
MESSAGE ARRIVES MESSAGE ARRIVES
Verify version number, checksum, and length fields of common header, Verify version number and checksum fields of common header, and
and discard message if any mismatch is found. discard message if any mismatch is found.
Reassemble a fragmented message.
Parse the sequence of objects in the message to verify the length
field of the common header; discard message if there is a mismatch.
If the message type is not PATH or PTEAR and if the IP destination
address does not match any of the addresses of the local interfaces,
then forward the message to IP destination address and return.
Verify the INTEGRITY object, if any. If the check fails, discard the
message and return.
Further processing depends upon message type. Further processing depends upon message type.
PATH MESSAGE ARRIVES PATH MESSAGE ARRIVES
Each sender descriptor object sequence in the message defines a Process the sender descriptor object sequence in the message as
sender. Process each sender as follows, starting the follows. The flags Path_Refresh_Needed and Resv_Refresh_Needed
Path_Refresh_Needed and Resv_Refresh_Needed flags off. flags are initially off.
1. If there is a POLICY_DATA object, verify it; if it is o If there is a POLICY_DATA object, verify it; if it is
unacceptable, build and send a "Administrative Rejection" unacceptable, build and send a "Administrative Rejection"
PERR message, drop the PATH message, and return. PERR message, drop the PATH message, and return.
2. Call the appropriate Route_Query routine, using DestAddress o If the DstPort in the SESSION object is zero but the
from SESSION and (for multicast routing) SrcAddress from SrcPort in the SENDER_TEMPLATE object is non-zero, build a
SENDER_TEMPLATE. This provides a routing bit mask send a "Conflicting Src Port" PERR message, drop the PATH
ROUTE_MASK and (for a multicast destination) an message, and return.
EXPECTED_INTERFACE.
3. If the message arrived on an interface different from
EXPECTED_INTERFACE, drop it and return.
4. Search for a path state block (PSB) whose (SESSION, o Search for a path state block (PSB) whose (SESSION,
SENDER_TEMPLATE) pair matches the corresponding objects in SENDER_TEMPLATE) pair matches the corresponding objects in
the message. the message, considering any wildcard ports.
If there is a match considering wildcards in the o If, during the PSB search, a PSB is found whose session
SENDER_TEMPLATE objects, but the two SENDER_TEMPLATEs matches the DestAddress and Protocol Id fields of the
differ, build and send a "Ambiguous Path" PERR message, received SESSION object, but the DstPorts differ and one is
drop the PATH message, and return. zero, then build and send a "Conflicting Dst Port" PERR
message, drop the PATH message, and return.
5. If there is no matching PSB for the (SESSION, o If, during the PSB search, a PSB is found with a matching
SENDER_TEMPLATE) pair then: 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 Create a new PSB. o If there was no matching PSB, then:
o Set a cleanup timer for the PSB. If this is the first 1. Create a new PSB.
2. Call the appropriate Route_Query routine, using
DestAddress from SESSION and (for multicast routing)
SrcAddress 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 PSB for the session, set a refresh timer for the
session. session.
o Copy the SESSION, TIME_VALUES, and PHOP objects into 5. Copy contents of the SESSION, SENDER_TEMPLATE,
the PSB. Copy into the PSB any of the following SENDER_TSPEC, and PHOP (IP address and LIH) objects
objects that are present: POLICY_DATA, SENDER_TSPEC, into the PSB. Store the received TTL into the PSB.
and ADSPEC. Copy into the PSB either of the following objects that
are present: POLICY_DATA and ADSPEC.
o Store ROUTE_MASK and EXPECTED_INTERFACE in the PSB. 6. Turn on the Path_Refresh_Needed flag.
o Turn on the Path_Refresh_Needed flag. o Otherwise (there is a matching PSB and there is no dest
port conflict):
6. Otherwise (there is a matching PSB): 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.
o Restart cleanup timer. - If the OutInterface_list that is returned differs
from that in the PSB, execute the PATH LOCAL
REPAIR event sequence below.
o If the SENDER_TSPEC and/or ADSPEC values differ - If a multicast message arrived on an interface
between the message and the PSB, copy the new values different from IncInterface, drop the message and
into the PSB and turn on the Path_Refresh_Needed flag. return.
Note that if SEND_TSPEC has changed, reservations
matching S may also change; this may be deferred until
a RESV refresh arrives.
o If the new ROUTE_MASK differs from that stored in the 2. If the PHOP IP address, the LIH, or SENDER_TSPEC
PSB, turn on the Path_Refresh_Needed flag, and store differs between the message and the PSB, copy the new
the new ROUTE_MASK into the PSB. 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.
o If the new EXPECTED_INTERFACE differs from that stored [LZ: [When] should ADSPEC change trigger a refresh?]
in the PSB, turn on the Resv_Refres_Needed flag and
store the new EXPECTED_INTERFACE value into the PSB.
7. Save the IP TTL with which the message arrived in the PSB . 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.
8. If the Path_Refresh_Needed flag is now set, execute the Call: <Upcall_Proc>( session-id, Resv Event, 1,
PATH REFRESH event sequence (below); however, send no PATH {Flowspec}, NULL, NULL, NULL )
refresh messages out the interface through which the PATH
message arrived.
9. If the Resv_Needed flag is now set, execute the RESV 3. Restart the cleanup timer.
REFRESH event sequence (below).
PATH TEAR MESSAGE ARRIVES 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 there is no path state for this destination, drop the o If the Path_Refresh_Needed flag is now set then:
message and return.
o Forward a copy of the PTEAR message using the same rules as 1. If this PATH message came from a network interface and
for a PATH message (see PATH REFRESH). not from a local application, make a Path Event upcall
for each local application for this session:
o Each sender descriptor in the PTEAR message contains a Call: <Upcall_Proc>( session-id, Path Event, 1,
SENDER_TEMPLATE object defining a sender S; process it as {SENDER_TSPEC}, {SENDER_TEMPLATE},
follows. {ADSPEC}, {POLICY_DATA} )
1. Locate the PSB for the pair: (session, S). If none 2. Execute the PATH REFRESH event sequence (below) for
exists, continue with next sender descriptor. the sender defined by the PSB.
2. Examine the RSB's for this session and delete PATH TEAR MESSAGE ARRIVES
reservation state that is associated with sender S and
no other sender.
3. Delete the PSB. 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
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. o Drop the PTEAR message and return.
PATH ERROR MESSAGE ARRIVES PATH ERROR MESSAGE ARRIVES
o If there are no existing PSB's for SESSION then drop the o Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair
PERR message and return. matches the corresponding objects in the message. If no
matching PSB is found, drop the PERR message and return.
o Look up the PSB for (session, sender); sender is defined by
SENDER_TEMPLATE. If no PSB is found, drop PERR message and
return.
o If PHOP in PSB is local API, deliver error to application o If the previous hop address in the PSB is the local API,
via an upcall: make an error upcall to the application:
Call: <Upcall_Proc>( session-id, Path Error, Call: <Upcall_Proc>( session-id, Path Error,
Error_code, Error_value, 0, Error_code, Error_value, Node_Addr,
1, SENDER_TEMPLATE, NULL, NULL, NULL) 0, 1, NULL, SENDER_TEMPLATE,
NULL, Policy_Data)
Any POLICY_DATA, SENDER_TSPEC, or ADSPEC object in the Any POLICY_DATA, SENDER_TSPEC, or ADSPEC object in the
message is ignored. 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 (PHOP is not local API), forward a copy of the o Otherwise, send a copy of the PERR message to the PHOP IP
PERR message to the PHOP node. address, drop the PERR message, and return.
RESV MESSAGE ARRIVES RESV MESSAGE ARRIVES
A RESV message arrives through outgoing interface OI. 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
by the LIH, it can be learned from the interface matching
the IP destination address).
o Check the SESSION object. o Check the SESSION object.
If there are no existing PSB's for SESSION then build and If there are no existing PSB's for SESSION then build and
send a RERR message (as described later) specifying "No send a RERR message (as described later) specifying "No
path information", drop the RESV message, and return. path information", drop the RESV message, and return.
However, do not send the RERR message if the style has However, do not send the RERR message if the style has
wildcard reservation scope and this is not the receiver wildcard reservation scope and this is the receiver host
host itself. itself.
o Check the STYLE object. [LZ: Explain this?]
If the style in the message conflicts with the style of any o Check the S_POLICY_DATA object.
reservation for this session in place on any interface,
reject the RESV message by building and sending a RERR 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
the STYLE object in the message, build and send a RERR
message specifying "Conflicting Style", drop the RESV message specifying "Conflicting Style", drop the RESV
message, and return. message, and return.
o Check the POLICY_DATA object. o Start or restart the cleanup timer on the the active RSB.
Verify the POLICY_DATA field (if any) to check permission o If the active RSB is not new, check whether FLOWSPEC or
to create a reservation. If it is unacceptable, build and SCOPE objects have changed. If not, continue with the next
send an "Administrative rejection" RERR message, drop the flow descriptor in the RESV message, if any.
RESV message, and return.
o Make reservations o If the active RSB is new, set its OI and style, and copy
any FLOWSPEC, POLICY_DATA, and/or SCOPE objects into it.
Process the STYLE object and the flow descriptor list. o If there is a RESV_CONFIRM in the message, turn on
Resv_Refresh_Needed and save the object in the RSB.
For FF style, execute the following steps for each b flow o The active RSB must be new or changed. Compute the traffic
descriptor, i.e., for each (FLOWSPEC, FILTER_SPEC) pair. control parameters, using the following steps.
For SE style, execute the following steps for each
FILTER_SPEC in the list, using the given FLOWSPEC. For WF
style, execute the following once, using an internal
placeholder "WILD_FILTER" for FILTERSPEC if it is omitted.
1. Find or create a reservation state block (RSB) for the 1. Locate the set of PSBs (senders) whose
4-tuple: (SESSION, NHOP, style, FILTER_SPEC). SENDER_TEMPLATEs match FILTER_SPEC* in the active RSB
and whose OutInterface_list includes OI.
2. Start or restart the cleanout timer on the RSB. Start If this set is empty, build and send an error message
a refresh timer for this session if none was started. specifying "No sender information", and continue with
the next flow descriptor in the RESV message.
3. If the RSB existed and contains state matching this 2. If this set contains more than one PSB and if the
flow descriptor, continue with the next flow style has explicit sender selection (e.g., FF or SE),
descriptor. Otherwise (the state is new or modified), build and send an error message specifying "Ambiguous
continue processing the current flow descriptor with filter spec" and continue with the next flow
the following steps. descriptor.
4. Scan the set of PSBs (senders) whose SENDER_TSPECs 3. Add the PHOP from the PSB to the Resv_Refresh_PHOP*
match FILTER_SPEC. list, if the PHOP is not already on the list.
- If this set is empty, build and send an error 4. Set TC_E_Police_flag on if any of these PSBs have
message specifying "No sender information", and their E_Police flag on. Set TC_M_Police_flag on if it
continue with the next flow descriptor. is a shared style and there is more than one PSB in
the set.
- If this set contains more than one PSB and if the 5. Compute Path_Te as the sum of the SENDER_TSPEC objects
style has the explicit option (e.g., FF or SE), in this set of PSBs.
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 6. Scan all RSB's matching the SESSION and
the E_Police flag on, otherwise set Filter_Spec_list from the message.
K_E_Police_flag off. Set K_M_Police_flag on if
the style has wildcard scope and there is more
than one PSB in the scope, otherwise, set
K_M_Police_flag off.
- Compute K_Tspec as the sum of the SENDER_TSPEC - If any of these RSB's has a style that is
objects, if any, in this set of PSBs. incompatible with the specifying "Conflicting
Style", drop the RESV message, delete the RSB if
it has just been created, and return.
5. Compute the parameters for the effective reservation, - Set TC_B_Police_flag on if TC_Flowspec is smaller
by considering all RSB's for the same (SESSION, OI, than, or incomparable to, any FLOWSPEC in those
FILTERSPEC) triple. 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, - Compute the effective kernel flowspec,
K_Flowspec, as the maximum of the FLOWSPEC values TC_Flowspec, as the maximum of the FLOWSPEC
in these RSB's values in these RSB's.
- Compute the effective kernel filter spec K_Filter - Compute the effective kernel filter spec (list),
by merging the FILTER_SPEC objects in these TC_Filter*. by merging the FILTER_SPEC* object
RSB's. (lists) from these RSB's.
6. If this reservation has wildcard scope and this is not o Search for a TCSB matching the triple (SESSION, OI,
the first flow descriptor in the message, one of the FILTER_SPEC*), taken from the RSB.
filter specs must have changed; delete the old one and
install the new:
TC_DelFilter( old_Fhandle ); 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
Fhandle = TC_AddFilter( Rhandle, SESSION, K_filter) - 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.
Then continue with the next flow descriptor. - Set Resv_Refresh_Needed on, drop the RESV
message, and return.
7. Otherwise, if there was no previous kernel reservation 2. Otherwise, if none is found:
in place for (SESSION, OI, FILTERSPEC), call the
kernel interface module:
Rhandle = TC_AddFlowspec( OI, K_flowspec, K_Tspec, - Create a new TCSB.
K_E_Police_flag, K_M_Police_flag )
If this call fails, build and send a RERR message - Store TC_Flowspec, Filter_Spec_list, Path_Te, and
specifying "Admission control failed", and continue the police flags into TCSB.
with the next flow descriptor. Otherwise, record the
kernel handle Rhandle returned by the call in the
RSB(s). Then call:
TC_AddFilter( Rhandle, SESSION, K_Filter) [SCOPE?]
to set the filter, and continue with the next flow - Set Resv_Refresh_Needed on.
descriptor.
However, if there was a previous kernel reservation - Make the traffic control call:
with handle Rhandle, and the flowspec has changed,
call:
TC_ModFlowspec( Rhandle, K_Flowspec, K_Tspec, Rhandle = TC_AddFlowspec( OI, TC_flowspec, Path_Te,
K_E_Police_flag, K_M_Police_flag ) TC_E_Police_flag, TC_M_Police_flag,
TC_B_Police_flag )
If this call fails, build and send a RERR message If this call fails, build and send a RERR message
specifying "Admission control failed". In any case, specifying "Admission control failed", and
drop the RESV message and return. continue with the next flow descriptor.
Otherwise, record Rhandle in the TCSB.
If the flowspec is unchanged but the filter spec has - For each filter_spec F in Filter_Spec_list, call:
changed, install the new:
TC_DelFilter( old_Fhandle ) Fhandle = TC_AddFilter( Rhandle, SESSION, F)
Fhandle = TC_AddFilter( Rhandle, SESSION, K_filter)
Then continue with the next flow descriptor. 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 If processing a RESV message finds an error, a RERR message is
created containing flow descriptor and an ERRORS object. The created containing flow descriptor and an ERRORS object. The
Error Node field of the ERRORS object (see Appendix A) is set to 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. the IP address of OI, and the message is sent unicast to NHOP.
RESV TEAR MESSAGE ARRIVES RESV TEAR MESSAGE ARRIVES
A RTEAR message arrives on outgoing interface OI. 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 Initialize flag Tear_Needed to False. o Process the STYLE object and the flow descriptor list in
the RTEAR message to tear down local reservation state, as
follows.
o Execute the following steps for each flow descriptor, i.e., For FF style, execute the following steps for each b flow
each (FLOWSPEC, FILTERSPEC) pair, in the flow descriptor descriptor, i.e., for each (FLOWSPEC, FILTER_SPEC) pair
list: 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, 1. Find matching RSB for the 4-tuple: (SESSION, NHOP,
style, FILTER_SPEC). If no RSB is found, continue style, Filter_Spec_list); call this the active RSB.
with next flow descriptor. If no active RSB is found, continue with next flow
descriptor.
2. Delete the RSB. 2. Delete the active RSB.
3. If there are no more RSBs for the same (SESSION, OI, 3. Find TCSB for the triple: (SESSION, OI,
FILTER_SPEC) triple, call the kernel interface to Filter_Spec_list).
delete the reservation:
TC_DelFlowspec( K_handle ) 4. Consider the set of RSB's matching this TCSB. If
there are none:
and set Tear_Needed to True. - Call the traffic control interface routine:
4. Otherwise (there are other RSB's for the same TC_DelFlowspec( Rhandle )
reservation), recompute K_Flowspec and call the kernel
interface module:
TC_ModFlowspec( K_handle, K_Flowspec, Sender_Tspec) - Delete the TCSB and set Tear_Needed flag on.
to update the reservation. If this kernel call fails, - Continue with the next flow descriptor.
return; the prior reservation will remain in place.
o If Tear_Needed is False (the resulting merged state may 5. Otherwise (there are other RSB's for the same TCSB),
have changed but is still in place), then execute the RESV recompute TC_Flowspec and Path_Te (see RESV MESSAGE
REFRESH sequence below, drop RTEAR message, and return. 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:
o Otherwise, need to create new RTEAR message for each PHOP, TC_ModFlowspec( Rhandle, TC_Flowspec, Path_Te)
and perhaps some RESV refresh messages. TC_E_Police_flag, TC_M_Police_flag,
TC_B_Police_flag )
Set Refresh_Needed flag to False. Do the following for This kernel call should not fail, since the
each sender Si (in the path stat) whose ROUTE_MASK includes reservation can only be reduced.
the outgoing interface OI and for each PHOP:
[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 1. Pick each flow descriptor Fj in the RTEAR message
whose FILTER_SPEC matches Si, and do the following. whose FILTER_SPEC matches the PSB, and do the
following.
- If there is no RSB whose FILTER_SPEC matches Si, - If there is no RSB whose FILTER_SPEC matches the
then add Fj to the new RTEAR message being built. PSB, then add Fj to the new RTEAR message being
built.
- Otherwise (there is a matching RSB), note the - Otherwise (there is a matching RSB), note the PSB
incoming interface of Si as an interface needing as needing a RESV refresh message and set the
a RESV refresh message and set the Refresh_Needed Resv_Refresh_Needed flag True.
flag True.
2. If the new RTEAR message contains any flow 2. If the new RTEAR message contains any flow
descriptors, forward it to PHOP. descriptors, send it to PHOP in the PSB.
If the scope is wildcard, include only a single flow o If the Resv_Refresh_Needed flag is now on, execute the RESV
descriptor in the message. REFRESH sequence (below) for each PHOP in the
Resv_Refresh_PHOP* set.
o If the Refresh_Needed flag is true, then execute the If the Refresh_Needed flag is true, then execute the RESV
RESV_REFRESH sequence below, for the incoming interfaces REFRESH sequence for the PSB's that have been noted.
that have been noted.
RESV ERROR MESSAGE ARRIVES o Drop the RTEAR message and return.
o If there is no state for SESSION, then drop the RERR RESV ERROR MESSAGE ARRIVES
mesasge and return.
o For each RSB, do the following. Note that an RSB implies A RERR message arrives through the (real) incoming interface
an outgoing interface OI and a next hop NHOP. In_If.
1. If OI differs from the incoming interface through o If there is no path state for SESSION, drop the RERR
which the RERR message arrived, continue with the next message and return.
RSB.
2. Compare the FILTER_SPEC(s) in the error flow o Do the following with each RSB for this SESSION whose OI
descriptor with the FILTER_SPEC(s) in the RSB. If no does not match In_If and whose FILTER_SPEC matches that in
match, continue with the next RSB. the RERR message.
Otherwise, form a new error flow descriptor with the 1. Copy the error flow descriptor from the incoming RERR
subset of FILTER_SPECs that matched. message.
3. Compare the FLOWSPEC in the RERR message with the 2. Compare the FLOWSPEC in the RERR message with the
FLOWSPEC in the RSB. If they don't match along any FLOWSPEC in the RSB. If they don't match along any
coordinate (i.e., if the RSB FLOWSPEC is strictly coordinate (i.e., if the RSB FLOWSPEC is strictly
`smaller'), continue with the next RSB. `smaller'), continue with the next RSB.
If they agree on some but not all coordinates, turn on If they agree on some but not all coordinates, turn on
the LUB-used flag. the LUB-used flag.
4. If NHOP in PSB is local API, deliver error to 3. If NHOP in RSB is the local API, deliver an error
application via an upcall: upcall to application:
Call: <Upcall_Proc>( session-id, Resv Error, k, Call: <Upcall_Proc>( session-id, Resv Error,
Error_code, Error_value, LUB-Used, Error_code, Error_value, Node_Addr,
Filter_Spec_List, Flowspec_List, NULL, LUB-Used,
NULL) Flowspec, Filter_Spec_List,
NULL, NULL)
and continue with the next RSB. Here k, and continue with the next RSB. Here k,
Filter_Spec_List, and Flowspec_List are constructed Filter_Spec_List, and Flowspec_List are constructed
from the new error flow descriptor. from the error flow descriptor.
5. If the RESV message has wildcard scope, use its SCOPE 4. If the RESV message has wildcard sender selection, use
object SC.In to construct a SCOPE object SC.Out to be its SCOPE object SC.In to construct a SCOPE object
forwarded. SC.Out should contain those sender SC.Out to be forwarded. SC.Out should contain those
addresses that appeared in SC.In and that route to OI sender addresses that appeared in SC.In and that route
[LIH?], as determined by scanning the PSB's. If to OI [LIH?], as determined by scanning the PSB's. If
SC.Out is empty, continue with the next RSB. SC.Out is empty, continue with the next RSB.
6. Create a new RERR message containing the new error 5. Create a new RERR message containing the error flow
flow descriptor and send to the NHOP address specified descriptor and send to the NHOP address specified by
by the RSB. Include SC.Out if the scope is wildcard. the RSB. Include SC.Out if the sender selection is
wildcard.
7. Continue with the next RSB. 6. Continue with the next RSB.
o Drop the RERR message and return. 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 PATH REFRESH
This sequence may be entered by either the expiration of the path This sequence sends a path refresh for a particular sender,
refresh timer for a particular session, or immediately as the result i.e., a PSB. This sequence may be entered by either the
of processing a PATH message turning on the Path_Refresh_Needed flag. 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.
For each outgoing interface OI, build a PATH message and send it to o Compute the IP TTL for the PATH message as one less than
OI. To build the message, consider each PSB whose ROUTE_MASK the maximum of the TTL values from the senders included in
includes OI, and do the following: the message. However, if the result is zero, return
without sending the PATH message.
o Pass the ADSPEC and SENDER_TSPEC objects present in the PSB to o Insert TIME_VALUES and PHOP objects into the PATH message
the kernel call TC_Advertise, and get back a modified ADSPEC being built.
object. Pack this modified object into the PATH message being
built.
o Create a sender descriptor sequence containing the o Create a sender descriptor containing the SENDER_TEMPLATE,
SENDER_TEMPLATE, SENDER_TSPEC, and POLICY_DATA objects, if SENDER_TSPEC, and POLICY_DATA objects, if present in the
present in the PSB. Pack the sender descriptor into the PATH PSB, and pack it into the PATH message being built.
message being built.
o If the PSB has the E_Police flag on and if interface OI is not o Pass any ADSPEC and SENDER_TSPEC objects present in the PSB
capable of policing, turn the E_Police flag on in the PATH to the traffic control call TC_Advertise. Insert the
modified ADSPEC object that is returned into the PATH
message being built. message being built.
o Compute the IP TTL for the PATH message as one less than the o If the PSB has the E_Police flag on and if interface OI is
maximum of the TTL values from the senders included in the not capable of policing, turn the E_Police flag on in the
message. However, if the result is zero, return without sending PATH message being built.
the PATH message.
o If the maximum size of the PATH message is reached, send the o Send a copy of the PATH message to each interface in
packet out interface OI and start packing a new one. OutInterfact_list. Before sending each copy, insert into
its PHOP object the interface address and the LIH for the
interface.
RESV REFRESH RESV REFRESH
This sequence may be entered by either the expiration of the This sequence sends a reservation refresh towards a particular
reservation refresh timer for a particular session, or immediately as previous hop with IP address PH. This sequence may be entered
the result of processing a RESV or RTEAR message. by either the expiration of a reservation refresh timer or
directly as the result of the Resv_Refresh_Needed flag being
turned on as the result of processing a RESV or RTEAR message.
For each PHOP defined by the path state, scan the RSBs, merge the In general, this sequence considers each of the PSB's with PHOP
style, FLOWSPECs and FILTER_SPECs appropriately, build a new RESV address PH. For a given PSB, it scans the RSBs for matching
message, and send it to PHOP. Each message carries a NHOP object reservations and merges the styles, FLOWSPECs and FILTER_SPEC*'s
containing the local address of the interface through which it is appropriately. It then builds a RESV message and sends it to
sent. PH. The details depend upon the attributes of the style(s)
included in the reservations.
The details of building the RESV messages depend upon the o If there are PSB's from more than one PHOP and if the
shared/distinct option of the style. For each PHOP, do the multicast routing protocol does not use shared trees, set
following: the Need_Scope flag on, otherwise set it off.
o Distinct style o Create an output message containing SESSION, RSVP_HOP,
INTEGRITY, and TIME_VALUES objects.
Select each sender Si (PSB) for PHOP, and do the following: o Select each sender PSB whose PHOP has address PH.
1. Select all RSB's whose FILTER_SPECs match the 1. Select all RSB's whose FILTER_SPEC*'s match the
SENDER_TEMPLATE object for Si and whose OI matches a bit in SENDER_TEMPLATE object in the PSB and whose OI appears
the ROUTE_MASK of the PSB for Si. in the OutInterface_list of the PSB.
2. Compute the maximum over the FLOWSPEC objects of this set 2. Get a STYLE object from the first RSB and move it into
of RSB's, and merge their FILTER_SPEC, STYLE, and the output message. (Note that the present set of
POLICY_DATA objects. styles are never themselves merged; if future styles
can be merged, these rules will become more complex).
3. Append the (FLOWSPEC, FILTER_SPEC pair) to the RESV message 3. Compute the maximum/LUB over the FLOWSPEC objects of
being built for destination PHOP. When the packet fills, this set of RSB's.
or upon completion of all PSB's with the same PHOP, send
it.
o Shared style 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 smaller than the largest, or if the result of
merging was a LUB, then create and send a RACK message
to the address in the RESV_CONFIRM object.
1. Select each sender Si (PSB) for PHOP, and select all RSB's - Include the RESV_CONFIRM object in the RACK
that: (a) have an OI matching a bit in the ROUTE_MASK for message.
Si, and (b) contain at least one FILTER_SPEC that matches
the SENDER_TEMPLATE object for Si.
2. For all selected RSB's for all Si corresponding to a given - Build a confirmation ERROR_SPEC object and
PHOP: include it in the RACK message. The Error_Node
parameter in this object should be the IP address
of OI from the RSB.
- Compute the maximum over the FLOWSPEC objects of this Then delete the RESV_CONFIRM object from the RSB.
set of RSB's.
- Merge the metching FILTER_SPEC objects; this will in 5. Merge the matching FILTER_SPEC objects from this set
general result in a list of non-overlapping of RSB's. The merging rule depend upon the style:
FILTER_SPECs, but where there are overlaps due to
wildcards, use the `wildest'.
- Merge the STYLE and POLICY_DATA objects. Explicit sender selection (FF, SE) styles:
- Place the resulting merged objects into a RESV message Use the SENDER_TEMPLATE as the merged
and send it to PHOP. FILTER_SPEC.
3. If the scope is wildcard, a forwarded RESV must contain a Wildcard sender selection (WF) style:
SCOPE object. The set of IP addresses in the SCOPE object
sent to a given PHOP is formed as follows.
- Take the union of the senders listed in SCOPE objects There is no filter spec to merge.
in all RSB's.
</