draft-ietf-rsvp-spec-08.txt   draft-ietf-rsvp-spec-09.txt 
Internet Draft R. Braden, Ed. Internet Draft R. Braden, Ed.
Expiration: May 1996 ISI Expiration: August 1996 ISI
File: draft-ietf-rsvp-spec-08.txt L. Zhang File: draft-ietf-rsvp-spec-09.txt L. Zhang
PARC PARC
S. Berson S. Berson
ISI ISI
S. Herzog S. Herzog
ISI ISI
J. Wroclaswki S. Jamin
MIT USC
Resource ReSerVation Protocol (RSVP) -- Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification Version 1 Functional Specification
November 22, 1995 February 12, 1996
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 7 skipping to change at page 2, line 7
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.
Table of Contents Table of Contents
1. Introduction ........................................................5 1. Introduction ........................................................4
1.1 Data Flows ......................................................8 1.1 Data Flows ......................................................7
1.2 Reservation Model ...............................................9 1.2 Reservation Model ...............................................8
1.3 Reservation Styles ..............................................11 1.3 Reservation Styles ..............................................10
1.4 Examples of Styles ..............................................14 1.4 Examples of Styles ..............................................13
2. RSVP Protocol Mechanisms ............................................18 2. RSVP Protocol Mechanisms ............................................18
2.1 RSVP Messages ...................................................18 2.1 RSVP Messages ...................................................18
2.2 Port Usage ......................................................20 2.2 Port Usage ......................................................20
2.3 Merging Flowspecs ...............................................21 2.3 Merging Flowspecs ...............................................21
2.4 Soft State ......................................................22 2.4 Soft State ......................................................22
2.5 Teardown ........................................................24 2.5 Teardown ........................................................24
2.6 Errors and Acknowledgments ......................................25 2.6 Errors ..........................................................25
2.7 Policy and Security .............................................27 2.7 Confirmation ....................................................27
2.8 Automatic RSVP Tunneling ........................................28 2.8 Policy and Security .............................................27
2.9 Host Model ......................................................28 2.9 Automatic RSVP Tunneling ........................................28
3. RSVP Functional Specification .......................................30 2.10 Host Model .....................................................29
3.1 RSVP Message Formats ............................................30 3. RSVP Functional Specification .......................................31
3.2 Sending RSVP Messages ...........................................42 3.1 RSVP Message Formats ............................................31
3.3 Avoiding RSVP Message Loops .....................................44 3.2 Sending RSVP Messages ...........................................44
3.4 Local Repair ....................................................48 3.3 Avoiding RSVP Message Loops .....................................45
3.5 Time Parameters .................................................48 3.4 Blockade State ..................................................49
3.6 Traffic Policing and TTL ........................................50 3.5 Local Repair ....................................................51
3.7 Multihomed Hosts ................................................51 3.6 Time Parameters .................................................52
3.8 Future Compatibility ............................................52 3.7 Traffic Policing and Non-Integrated Service Hops ................53
3.9 RSVP Interfaces .................................................55 3.8 Multihomed Hosts ................................................54
4. Message Processing Rules ............................................65 3.9 Future Compatibility ............................................56
APPENDIX A. Object Definitions .........................................82 3.10 RSVP Interfaces ................................................58
APPENDIX B. Error Codes and Values .....................................97 4. Message Processing Rules ............................................70
APPENDIX C. UDP Encapsulation ..........................................101 5. Acknowledgments .....................................................89
APPENDIX D. Experimental and Open Issues ...............................103 APPENDIX A. Object Definitions .........................................90
APPENDIX B. Error Codes and Values .....................................106
APPENDIX C. UDP Encapsulation ..........................................111
What's Changed What's Changed
The most important changes in this document from the rsvp-spec-07 draft The most important changes in this document from the rsvp-spec-08 draft
are: are:
o The role and interpretation of the IP Protocol Id is changed. o The handling of reservation errors has been fundamentally
The Protocol Id is now a required part of the session changed, to prevent the "second killer reservation problem".
definition, and filter specs and sender templates now assume A new kind of state has been introduced into a node,
the Protocol Id from the session rather than stating it "blockade state", which is created by a RERR message with
explicitly. Error Code = 01, and which controls the merging process for
generating reservation refresh messages [Sections 2.6 and
o A "soft" reservation confirmation message is added. 3.4].
o The text states explicitly that an erroneous reservation
message is not forwarded. A mechanism to allow a receiver
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 A terminology confusion is eliminated. The term "scope" was
used both for a set of senders and for a set of sender hosts.
A new term "sender selection" is introduced for the first,
leaving "scope" for the second.
o The FILTER_SPEC object is dropped from a wildcard sender
selection (WF) style reservation, which now selects "all
senders" without qualification.
o The StyleID byte is dropped from a STYLE object, as
redundant.
o An SE style flow descriptor is simplified to a single
flowspec.
o The IP Router Alert option is now required in PATH, PTEAR,
and RACK messages.
o The TIME_VALUES object is now required in RESV and PATH
messages; there is no default.
o Policing at branch points is now defined in a new section on
policing (3.6).
o A 2-second delay is inserted into local repair.
o Merging of SE with WF objects is no longer allowed. o RSVP now carries two flag bits in the SESSION object to
indicate to a receiver whether there are non-RSVP-capable
nodes along the path to a given sender [Sections 2.9 and
3.7].
o The Rmax end-to-end bound on the refresh rate R is removed, o The optional INTEGRITY object is now specified to immediately
since its utility was unclear. follow the common header and to appear in every fragment
[Section 3.1].
o A rule for randomizing refresh timeouts is included. o There are now two flag bits in an ERROR_SPEC object: InPlace
and NotGuilty [Section 3.10].
o The suggestion that TCP could be used for carrying RSVP state o The text now states that implementations should be as
through a congested non-RSVP cloud is removed. permissive as possible in accepting objects in any order
within a message (and required ordering is specified), but
they should follow the BNF-implied order in creating a
message.
o SENDER_TSPECS are now required in PATH| messages. o The text now states that IP fragmentation of data packets is
generally not possible when RSVP is in use, since the TCP/UDP
port fields may be required for classification [Section 1.2].
o There are new sections on multihomed hosts (3.7) and future o The rules for handling an unrecognized object class are
compatibility (3.8). The latter section makes clear that a changed to include a third possibility: ignore and do not
message containing an object with unknown C-Type should be forward the object [Section 3.9].
rejected. Any more forgiving treatment seems too complex.
o Appendix C on UDP encapsulation is completely changed. o All generic Traffic Control calls are modified to include an
interface specification, allowing the Thandle to be
interface-specific [Section 3.10.2].
o Some text was rearranged in Sections 1 and 2. o Disabling an interface for RSVP is allowed [Section 3.10.3].
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].
On behalf of an application data stream, a host uses the RSVP The RSVP protocol is used by a host, on behalf of an application data
protocol to request a specific quality of service (QoS) from the stream, to request a specific quality of service (QoS) from the
network. RSVP delivers QoS requests to routers along the path(s) of network. The RSVP protocol is also used by routers to deliver QoS
the data stream and maintains router and host state to provide the requests to all nodes along the path(s) of the data stream and to
requested service. RSVP requests will generally, although not establish and maintain state to provide the requested service. RSVP
necessarily, result in resources being reserved along the data path. requests will generally, although not necessarily, result in
resources being reserved along the data path.
RSVP requests resources for simplex data streams, i.e., it requests RSVP requests resources for simplex data streams, i.e., it requests
resources in only one direction. Therefore, a sender is logically resources in only one direction. Therefore, RSVP treats a sender as
distinct from a receiver, although the same application process may logically distinct from a receiver, although the same application
act as both a sender and a receiver at the same time. RSVP operates process may act as both a sender and a receiver at the same time.
on top of IP (either IPv4 or IP6), occupying the place of a transport RSVP operates on top of IP (either IPv4 or IP6), occupying the place
protocol in the protocol stack. However, like ICMP, IGMP, and of a transport protocol in the protocol stack. However, RSVP does
routing protocols, RSVP does not transport application data but is not transport application data but is rather an Internet control
rather an Internet control protocol. Like the implementations of protocol, like ICMP, IGMP, or routing protocols. Like the
routing and management protocols, an implementation of RSVP will implementations of routing and management protocols, an
typically execute in the background, not in the data forwarding path, implementation of RSVP will typically execute in the background, not
as shown in Figure 1. in the data forwarding path, as shown in Figure 1.
RSVP is not itself a routing protocol; RSVP is designed to operate RSVP is not itself a routing protocol; RSVP is designed to operate
with current and future unicast and multicast routing protocols. The with current and future unicast and multicast routing protocols. An
RSVP daemon consults the local routing protocol(s) to obtain routes. RSVP daemon consults the local routing database(s) to obtain routes.
In the multicast case, for example, a host sends IGMP messages to In the multicast case, for example, a host sends IGMP messages to
join a multicast group and then sends RSVP messages to reserve join a multicast group and then sends RSVP messages to reserve
resources along the delivery path(s) of that group. Routing resources along the delivery path(s) of that group. Routing
protocols determine where packets get forwarded; RSVP only concerns protocols determine where packets get forwarded; RSVP is only
with the QoS of those packets that are forwarded by routing. concerned with the QoS of those packets that are forwarded in
accordance with 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 <----> >|Polcy||
| |_______| |___.__| | ||_ ._____| |__.__.| | | |_______| |___.__| | ||_ ._____| |__.__.||Cntrl||
| | | | | | | . | | | | | | | | .|_____||
|===|===============|=====| |===|=============|====.======| |===|===============|=====| |===|=============|====.======|
| data .........| | | | ...........| .____ | | data .........| | | | ...........| .____ |
| | ____V_ ____V____ | | _V__V_ _____V___ | Adm.|| | | ____V_ ____V____ | | _V__V_ _____V___ |Admis||
| | |Class-| | || data | |Class-| | ||Cntrl|| | | |Class-| | || data | |Class-| | ||Cntrl||
| |=> ifier|=> Packet ============> ifier|==> Packet ||_____|| data | |=> ifier|=> Packet ============> ifier|==> Packet ||_____|| data
| |______| |Scheduler|| | |______| |Scheduler|===========> | |______| |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 node that is capable of resource reservation passes incoming
data packets through a packet classifier and then queues them as data packets through a "packet classifier", which determines the
necessary in a packet scheduler. The packet classifier determines route and the QoS class for each packet. For each outgoing
the route and the QoS class for each packet. There is a scheduler interface, a " packet scheduler" then makes forwarding decisions for
for each interface, to allocate resources for transmission on the each packet to achieve the promised QoS on the particular link-layer
particular link-layer medium used by that interface. If the link- medium used by that interface.
layer medium is QoS-active, i.e., if it has its own QoS management
capability, then the packet scheduler is responsible for negotiation If the link-layer medium is QoS-active, i.e., if it has its own QoS
with the link layer to obtain the QoS requested by RSVP. This management capability, then the packet scheduler is responsible for
mapping to the link layer QoS may be accomplished in a number of negotiation with the link layer to obtain the QoS requested by RSVP.
This mapping to the link layer QoS may be accomplished in a number of
possible ways; the details will be medium-dependent. On a QoS- possible ways; the details will be medium-dependent. On a QoS-
passive medium such as a leased line, the scheduler itself allocates passive medium such as a leased line, the scheduler itself allocates
packet transmission capacity. The scheduler may also allocate other packet transmission capacity. The scheduler may also allocate other
system resources such as CPU time or buffers. 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, RSVP makes receivers responsible for dynamic group membership, RSVP makes receivers responsible for
requesting resource reservations [RSVP93]. A QoS request, which requesting QoS [RSVP93]. A QoS request, which typically originates
typically originates from a receiver host application, is passed to from a receiver host application, is passed to the local RSVP
the local RSVP implementation, shown as a user daemon in Figure 1. implementation, shown as a daemon process in Figure 1. The RSVP
The RSVP protocol then carries the request to all the nodes (routers protocol then carries the request to all the nodes (routers and
and hosts) along the reverse data path(s) to the data source(s). hosts) along the reverse data path(s) to the data source(s).
At each node, the RSVP daemon communicates with a local decision At each node, the RSVP daemon communicates with two local decision
module, called "admission control", to determine if the router can modules, "admission control" and "policy control". Admission control
supply the requested QoS. If the admission control check succeeds, determines whether the node has sufficient available resources to
the RSVP daemon sets parameters in the packet classifier and supply the requested QoS. Policy control determines whether the user
scheduler to obtain the desired QoS. If the admission control check has administrative permission to make the reservation. If both
fails, the RSVP program immediately returns an error notification to checks succeeds, the RSVP daemon sets parameters in the packet
the application process that originated the request. We refer to the classifier and scheduler to obtain the desired QoS. If either check
fails, the RSVP program returns an error notification to the
application process that originated the request. We refer to the
packet classifier, packet scheduler, and admission control components packet classifier, packet scheduler, and admission control components
as " traffic control". 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 both the membership of a large group and the topology of large Since both the membership of a large group and the topology of large
multicast trees are likely to change with time, the RSVP design multicast trees are likely to change with time, the RSVP design
assumes that router state for traffic control will be built and assumes that router state for traffic control will be built and
destroyed incrementally. For this purpose, RSVP uses "soft state" in destroyed incrementally. For this purpose, RSVP uses "soft state" in
the routers. That is, RSVP sends periodic refresh messages to the routers. That is, RSVP sends periodic refresh messages to
maintain the state along the reserved path(s); in absence of maintain the state along the reserved path(s); in absence of
skipping to change at page 7, line 38 skipping to change at page 6, line 42
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 A reservation model that is presented to an application; see Appendix A
for more details. for more details.
In summary, RSVP has the following attributes: In summary, RSVP has the following attributes:
o RSVP makes resource reservations for both unicast and many-to- o RSVP makes resource reservations for both unicast and many-to-
many multicast applications, adapting dynamically to changing many multicast applications, adapting dynamically to changing
group membership as well as changing routes. group membership as well as changing routes.
o RSVP is simplex, i.e., it reserves for data flow in one o RSVP is simplex, i.e., it reserves for a data flow in one
direction only. direction only.
o RSVP is receiver-oriented, i.e., the receiver of a data flow o RSVP is receiver-oriented, i.e., the receiver of a data flow
initiates and maintains the resource reservation used for that initiates and maintains the resource reservation used for that
flow. flow.
o RSVP maintains "soft state" in the routers, providing graceful o RSVP maintains "soft state" in the routers, providing graceful
support for dynamic membership changes and automatic adaptation support for dynamic membership changes and automatic adaptation
to routing changes. to routing changes.
skipping to change at page 8, line 24 skipping to change at page 7, line 27
while Section 4 presents explicit message processing rules. Appendix while Section 4 presents explicit message processing rules. Appendix
A defines the variable-length typed data objects used in the RSVP A defines the variable-length typed data objects used in the RSVP
protocol. Appendix B defines error codes and values. Appendix C protocol. Appendix B defines error codes and values. Appendix C
defines an extension for UDP encapsulation of RSVP messages. defines an extension for UDP encapsulation of RSVP messages.
Finally, some experimental RSVP features are documented in Appendix D Finally, some experimental RSVP features are documented in Appendix D
for future reference. for future reference.
1.1 Data Flows 1.1 Data Flows
RSVP defines a "session" as a data flow with a particular RSVP defines a "session" as a data flow with a particular
destination and transport-layer protocol. The destination for a destination and transport-layer protocol. The destination of a
particular session is generally defined by DestAddress, the IP session is generally defined by DestAddress, the IP destination
destination address of the data packets, and perhaps by DstPort, a address of the data packets, and perhaps by DstPort, a
" generalized destination port", i.e., some further demultiplexing " generalized destination port", i.e., some further demultiplexing
point in the transport or application protocol layer. RSVP treats point in the transport or application protocol layer. RSVP treats
each session independently, and this document often assumes the each session independently, and this document often assumes the
qualification "for the same session". qualification "for the same session".
DestAddress is a group address for multicast delivery or the DestAddress is a group address for multicast delivery or the
unicast address of a single receiver. DstPort could be defined by unicast address of a single receiver. DstPort could be defined by
a UDP/TCP destination port field, by an equivalent field in a UDP/TCP destination port field, by an equivalent field in
another transport protocol, or by some application-specific another transport protocol, or by some application-specific
information. Although the RSVP protocol is designed to be easily information. Although the RSVP protocol is designed to be easily
extendible for greater generality, the present version supports extensible for greater generality, the present version supports
only UDP/TCP ports as generalized ports. only UDP/TCP ports as generalized ports.
Note that it is not strictly necessary to include ports in the
session definition when DestAddress is multicast, since different
sessions can always have different multicast addresses. However,
destination ports are necessary to allow more than one unicast
session to the same receiver host.
Figure 2 illustrates the flow of data packets in a single RSVP Figure 2 illustrates the flow of data packets in a single RSVP
session assuming multicast data distribution. The arrows indicate session, assuming multicast data distribution. The arrows
data flowing from senders S1 and S2 to receivers R1, R2, and R3, indicate data flowing from senders S1 and S2 to receivers R1, R2,
and the cloud represents the distribution mesh created by and R3, and the cloud represents the distribution mesh created by
multicast routing. Multicast distribution forwards a copy of each multicast routing. Multicast distribution forwards a copy of each
data packet from a sender Si to every receiver Rj; a unicast data packet from a sender Si to every receiver Rj; a unicast
distribution session has a single receiver R. Each sender Si and distribution session has a single receiver R. Each sender Si may
each receiver Rj may be running in a unique Internet host, or a be running in a unique Internet host, or a single host may contain
single host may contain multiple senders and/or receivers, multiple senders, distinguished by generalized source 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
(_____________________) (_____________________)
skipping to change at page 9, line 26 skipping to change at page 8, line 31
For unicast transmission, there will be a single destination host For unicast transmission, there will be a single destination host
but there may be multiple senders; RSVP can set up reservations but there may be multiple senders; RSVP can set up reservations
for multipoint-to-single-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 session definition, specifies the set of data spec, together with a session specification, defines the set of
packets -- the "flow" -- to receive the QoS defined by the data 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. Data packets that are addressed to a particular classifier. Data packets that are addressed to a particular
session but do not match any of the filter specs for that session session but do not match any of the filter specs for that session
are handled as best-effort traffic. are handled as best-effort traffic.
Note that the action to control QoS occurs at the place where the Note that the action to control QoS occurs at the place where the
data enters the medium, i.e., at the upstream end of the link, data enters the medium, i.e., at the upstream end of the link,
although an RSVP reservation request originates from receiver(s) although an RSVP reservation request originates from receiver(s)
downstream. In this document, we define the directional terms downstream. In this document, we define the directional terms
"upstream" vs. "downstream", "previous hop" vs. "next hop", and "upstream" vs. "downstream", "previous hop" vs. "next hop", and
"incoming interface" vs "outgoing interface" with respect to the "incoming interface" vs "outgoing interface" with respect to the
direction of data flows. direction of data flow.
The flowspec in a reservation request will generally include a The flowspec in a reservation request will generally include a
service class and two sets of numeric parameters: (1) an "Rspec" service class and two sets of numeric parameters: (1) an "Rspec"
(R for `reserve') that defines the desired QoS, and (2) a "Tspec" (R for `reserve') that defines the desired QoS, and (2) a "Tspec"
(T for `traffic') that describes the data flow. The formats and (T for `traffic') that describes the data flow. The formats and
contents of Tspecs and Rspecs are determined by the integrated contents of Tspecs and Rspecs are determined by the integrated
service model [ServTempl95a], and are generally opaque to RSVP. service model [ServTempl95a], and are generally opaque to RSVP.
In the most general approach [RSVP93], filter specs may select In the most general approach [RSVP93], filter specs may select
arbitrary subsets of the packets in a given session. Such subsets arbitrary subsets of the packets in a given session. Such subsets
might be defined in terms of senders (i.e., sender IP address and might be defined in terms of senders (i.e., sender IP address and
generalized source port), in terms of a higher-level protocol, or generalized source port), in terms of a higher-level protocol, or
generally in terms of any fields in any protocol headers in the generally in terms of any fields in any protocol headers in the
packet. For example, filter specs might be used to select packet. For example, filter specs might be used to select
different subflows in a hierarchically-encoded signal by selecting different subflows in a hierarchically-encoded signal by selecting
on fields in an application-layer header. However, in the on fields in an application-layer header. In the interest of
interest of simplicity (and to minimize layer violation), the simplicity (and to minimize layer violation), the present RSVP
present RSVP version uses a much more restricted form of filter version uses a much more restricted form of filter spec,
spec, consisting of sender IP address and optionally the UDP/TCP consisting of sender IP address and optionally the UDP/TCP port
port number SrcPort. number SrcPort.
Because the UDP/TCP port numbers are used for packet
classification, each router must be able to examine these fields.
As a result, it is generally necessary to avoid IP fragmentation
of a data stream for which a resource reservation is desired.
RSVP reservation request messages originate at receivers and are RSVP reservation request messages originate at receivers and are
passed upstream towards the sender(s). When a reservation request passed upstream towards the sender(s). At each intermediate node,
is received at a node, two general actions are taken. two general actions are taken on the request.
1. Make a reservation 1. Make a reservation
The flowspec and the filter spec are passed to traffic The request is passed to admission control and policy
control. Admission control determines the admissibility of control. If either test fails, the reservation is rejected
the request (if it's new); if this test fails, the and RSVP returns an error message to the appropriate
reservation is rejected and RSVP returns an error message to receiver(s). If both succeed, the node uses the flowspec to
the appropriate receiver(s). If admission control succeeds, set up the packet scheduler for the desired QoS and the
the node uses the flowspec to set up the packet scheduler for filter spec to set the packet classifier to select the
the desired QoS and the filter spec to set the packet appropriate data packets.
classifier to select the appropriate data packets.
2. Forward the request 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 from downstream, for two from the request that it received from downstream, for two
reasons. First, it is possible in theory for the traffic control reasons. First, it is possible in theory for the traffic control
mechanism to modify the flowspec hop-by-hop, although none of the mechanism to modify the flowspec hop-by-hop, although none of the
currently defined services does so. Second, reservations for the currently defined services does so. Second, reservations for the
same sender, or the same set of senders, from different downstream same sender, or the same set of senders, from different downstream
branches of the multicast tree(s) are "merged" as reservations branches of the multicast tree(s) are "merged" as reservations
travel upstream; that is, a node forwards upstream only the travel upstream; a node forwards upstream only the reservation
reservation request with the "maximum" flowspec. request with the "maximum" flowspec.
When a receiver originates a reservation request, it can also When a receiver originates a reservation request, it can also
request a confirmation message to indicate that its request was request a confirmation message to indicate that its request was
(probably) installed in the network. A successful reservation (probably) installed in the network. A successful reservation
request propagates as far as the closest point(s) along the sink request propagates upstream along the multicast tree until it
tree to the sender(s) where there is an existing reservation level reaches a point where an existing reservation is equal or greater
equal or greater than that being requested. At that point, the than that being requested. At that point, the arriving request is
arriving request will be dropped in favor of the equal or larger merged with the reservation in place, and need not be forwarded
reservation in place; the node may then send a reservation further, and the node may then send a reservation confirmation
confirmation message back to the receiver. Note that the receipt message back to the receiver. Note that the receipt of a
of a confirmation is only a high-probability indication, not a confirmation is only a high-probability indication, not a
guarantee that the requested service is in place all the way to guarantee, that the requested service is in place all the way to
the sender(s), as explained in Section 2.6. the sender(s), as explained in Section 2.7.
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 either reservation request upstream, and each node in the path either
accepts or rejects the request. This scheme provides no easy way accepts or rejects the request. This scheme provides no easy way
for a receiver to find out the resulting end-to-end service. for a receiver to find out the resulting end-to-end service.
Therefore, RSVP supports an enhancement to one-pass service known Therefore, RSVP supports an enhancement to one-pass service known
as "One Pass With Advertising" (OPWA) [Shenker94]. With OPWA, as "One Pass With Advertising" (OPWA) [Shenker94]. With OPWA,
RSVP control packets are sent downstream, following the data RSVP control packets are sent downstream, following the data
paths, to gather information that may be used to predict the end- paths, to gather information that may be used to predict the end-
to-end QoS. The results ("advertisements") are delivered by RSVP to-end QoS. The results ("advertisements") are delivered by RSVP
to the receiver hosts and perhaps to the receiver applications. to the receiver hosts and perhaps to the receiver applications.
The advertisements may then be used by the receiver to construct, The advertisements may then be used by the receiver to construct,
or to dynamically adjust, an appropriate reservation request. or to dynamically adjust, 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 options, which are
collectively called the reservation "style". collectively called the reservation "style".
One option concerns the treatment of reservations for different One reservation option concerns the treatment of reservations for
senders within the same session: establish a "distinct" different 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. senders.
Another option controls the selection of senders: an "explicit" Another reservation option controls the selection of senders: an "
list of all selected senders, or a "wildcard" that implicitly explicit" list of all selected senders, or a "wildcard" that
selects all the senders to the session. In an explicit-selection implicitly selects all the senders to the session. In an explicit
reservation, each filter spec must match exactly one sender, while sender-selection reservation, each filter spec must match exactly
in a wildcard-selection no filter spec is needed. one sender, while in a wildcard sender-selection no filter spec is
needed.
Sender || Reservations: Sender || Reservations:
Selection || Distinct | Shared 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 |
skipping to change at page 12, line 26 skipping to change at page 11, line 28
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):
o 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" sender selection. 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 from all receivers, independent of the resource requests from all receivers, independent of the
number of senders using it. A WF-style reservation is number of senders using it. A WF-style reservation is
propagated upstream towards all sender hosts, and propagated upstream towards all sender hosts, and
automatically extends to new senders as they appear. automatically extends to new senders as they appear.
Symbolically, we can represent a WF-style reservation request Symbolically, we can represent a WF-style reservation request
by: by:
WF( * {Q}) WF( * {Q})
skipping to change at page 13, line 39 skipping to change at page 12, line 42
SE style allows a receiver to explicitly specify the set of SE style allows a receiver to explicitly specify the set of
senders. senders.
Symbolically, we can represent an SE reservation request by: Symbolically, we can represent an SE reservation request by:
SE( (S1,S2,...){Q} ), SE( (S1,S2,...){Q} ),
i.e., a flow descriptor composed of a flowspec Q and a list i.e., a flow descriptor composed of a flowspec Q and a list
of senders S1, S2, etc. of senders S1, S2, etc.
Both WF and SE are shared reservations, appropriate for those Both WF and SE styles create shared reservations, appropriate for
multicast applications whose application-specific constraints make those multicast applications whose properties make it unlikely
it unlikely that multiple data sources will transmit that multiple data sources will transmit simultaneously.
simultaneously. Packetized audio is an example of an application Packetized audio is an example of an application suitable for
suitable for shared reservations; since a limited number of people shared reservations; since a limited number of people talk at
talk at once, each receiver might issue a WF or SE reservation once, each receiver might issue a WF or SE reservation request for
request for twice the bandwidth required for one sender (to allow twice the bandwidth required for one sender (to allow some over-
some over-speaking). On the other hand, the FF style, which speaking). On the other hand, the FF style, which creates
creates independent reservations for the flows from different independent reservations for the flows from different senders, is
senders, is appropriate for video signals. appropriate for video signals.
The RSVP rules disallow merging of shared reservations with The RSVP rules disallow merging of shared reservations with
distinct reservations, since these modes are fundamentally distinct reservations, since these modes are fundamentally
incompatible. They also disallow merging explict sender selection incompatible. They also disallow merging explicit sender
with wildcard sender selection, since this might produce an selection with wildcard sender selection, since this might produce
unexpected service for a receiver that specified explicit an unexpected service for a receiver that specified explicit
selection. As a result of these prohibitions, WF, SE, and FF selection. As a result of these prohibitions, WF, SE, and FF
styles are all mutually incompatible. styles are all mutually incompatible.
Other reservation options and styles may be defined in the future It would seem possible to simulate the effect of a WF reservation
(see Appendix D.4, for example). using the SE style. When an application asked for WF, the RSVP
daemon on the receiver host could use local path state to create
an equivalent SE reservation that explicitly listed all senders.
However, an SE reservation forces the packet classifier in each
node to explicitly select each sender in the list, while a WF
allows the packet classifier to simply "wild card" the sender
address and port. When there is a large list of senders, a WF
style reservation can therefore result in considerably less
overhead than an equivalent SE style reservation. For this
reason, both SE and WF are included in the protocol.
Other reservation options and styles may be defined in the future.
1.4 Examples of Styles 1.4 Examples of Styles
This section presents examples of each of the reservation styles This section presents examples of each of the reservation styles
and show the effects of merging. and shows the effects of merging.
Figure 4 shows schematically a router with two incoming interfaces Figure 4 illustrates a router with two incoming interfaces through
through which data streams will arrive, labeled (a) and (b), and which data streams will arrive, labeled (a) and (b), and two
two outgoing interfaces through which data will be forwarded, outgoing interfaces through which data will be forwarded, labeled
labeled (c) and (d). This topology will be assumed in the (c) and (d). This topology will be assumed in the examples that
examples that follow. There are three upstream senders; packets follow. There are three upstream senders; packets from sender S1
from sender S1 (S2 and S3) arrive through previous hop (a) ((b), (S2 and S3) arrive through previous hop (a) ((b), respectively).
respectively). There are also three downstream receivers; packets There are also three downstream receivers; packets bound for R1
bound for R1 (R2 and R3) are routed via outgoing interface (c) (R2 and R3) are routed via outgoing interface (c) ((d),
((d), respectively). We furthermore assume that R2 and R3 arrive respectively). We furthermore assume that R2 and R3 arrive via
via different next hops, e.g., via the two routers D and D' in different next hops, e.g., via the two routers D and D' in Figure
Figure 9. This illustrates the effect of a non-RSVP cloud or a 9. This illustrates the effect of a non-RSVP cloud or a broadcast
broadcast LAN on interface (d). LAN on interface (d).
In addition to the connectivity shown in 4, we must also specify In addition to the connectivity shown in 4, we must also specify
the multicast routes within this node. Assume first that data the multicast routes within this node. Assume first that data
packets from each Si shown in Figure 4 is routed to both outgoing packets from each Si shown in Figure 4 is routed to both outgoing
interfaces. Under this assumption, Figures 5, 6, and 7 illustrate interfaces. Under this assumption, Figures 5, 6, and 7 illustrate
Wildcard-Filter, Fixed-Filter, and Shared-Explicit reservations, Wildcard-Filter, Fixed-Filter, and Shared-Explicit reservations,
respectively. respectively.
________________ ________________
(a)| | (c) (a)| | (c)
skipping to change at page 17, line 23 skipping to change at page 17, line 20
(b)| - | (d) (b)| - | (d)
( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 ) ( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 )
|_______________| |_______________|
Router Configuration Router Configuration
| |
Send | Reserve Receive Send | Reserve Receive
| |
| _______ | _______
WF( *{rB} ) <- (a) | (c) | * {B} | (c) <- WF( *{4B} ) WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} )
| |_______| | |_______|
| |
-----------------------|---------------------------------------- -----------------------|----------------------------------------
| _______ | _______
WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} ) WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} )
| |_______| <- WF( * {2B} | |_______| <- WF( * {2B}
Figure 8: WF Reservation Example -- Partial Routing Figure 8: WF Reservation Example -- Partial Routing
2. RSVP Protocol Mechanisms 2. RSVP Protocol Mechanisms
skipping to change at page 18, line 32 skipping to change at page 18, line 32
_____ | <--Resv|_____________________| <-- Resv | | | _____ | <--Resv|_____________________| <-- Resv | | |
| | | |--| D' | | | | |--| D' |
| B' |--| | |_____| | B' |--| | |_____|
|_____| | | |_____| | |
Figure 9: Router Using RSVP Figure 9: Router Using RSVP
Figure 9 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 in the same incoming and outgoing roles for different data flows in the same
session. Multiple previous hops and/or next hops may be reached session. Multiple previous hops and/or next hops may be reached
through a given physical interface, as a result of the connected through a given physical interface, as a result of the connected
network being a shared medium, or the existence of non-RSVP 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 routers in the path to the next RSVP hop (see Section 2.9). An
RSVP daemon preserves the next and previous hop addresses in its RSVP daemon preserves the next and previous hop addresses in its
reservation and path state, respectively. reservation and path state, respectively.
There are two fundamental RSVP message types: RESV and PATH. There are two fundamental RSVP message types: RESV and PATH.
Each receiver host sends RSVP reservation request (RESV) messages Each receiver host sends RSVP reservation request (RESV) messages
upstream towards the senders. These reservation messages must upstream towards the senders. These reservation messages must
follow exactly the reverse of the routes the data packets will follow exactly the reverse of the routes the data packets will
use, upstream to all the sender hosts included in the sender use, upstream to all the sender hosts included in the sender
selection. RESV messages must be delivered to the sender hosts selection. RESV messages are delivered to the sender hosts
themselves so that the hosts can set up appropriate traffic themselves so that the hosts can set up appropriate traffic
control parameters for the first hop. control parameters for the first hop.
Each RSVP sender host transmits RSVP PATH messages downstream Each RSVP sender host transmits RSVP PATH messages downstream
along the uni-/multicast routes provided by the routing along the uni-/multicast routes provided by the routing
protocol(s), following the paths of the data. These "Path" protocol(s), following the paths of the data. These "Path"
messages store " path state" in each node along the way. This messages store "path state" in each node along the way. This path
path state includes at least the unicast IP address of the state includes at least the unicast IP address of the previous hop
previous hop node, which is used to route the RESV messages hop- node, which is used to route the RESV messages hop-by-hop in the
by-hop in the reverse direction. (In the future, some routing reverse direction. (In the future, some routing protocols may
protocols may supply reverse path forwarding information directly, supply reverse path forwarding information directly, replacing the
replacing the reverse-routing function of path state). reverse-routing function of path state).
A PATH message may carry the following information in addition to A PATH message may carry the following information in addition to
the previous hop address: the previous hop address:
o Sender Template o Sender Template
A PATH message is required to carry a Sender Template, which A PATH message is required to carry a Sender Template, which
describes the format of data packets that the sender will describes the format of data packets that the sender will
originate. This template is in the form of a filter spec originate. This template is in the form of a filter spec
that could be used to select this sender's packets from that could be used to select this sender's packets from
others in the same session on the same link. others in the same session on the same link.
Like a filter spec, the Sender Template is less than fully Like a filter spec, the Sender Template is less than fully
general at present, specifying only the sender IP address and general at present, specifying only the sender IP address and
optionally the UDP/TCP sender port. It assumes the protocol optionally the UDP/TCP sender port. It assumes the protocol
Id for the session. Id specified for the session.
o Sender Tspec o Sender Tspec
A PATH message is required to carry a Sender Tspec, which A PATH message is required to carry a Sender Tspec, which
defines the traffic characteristics of the data stream that defines the traffic characteristics of the data stream that
the sender will generate. This Tspec is used by traffic the sender will generate. This Tspec is used by traffic
control to prevent over-reservation (and perhaps unnecessary control to prevent over-reservation (and perhaps unnecessary
Admission Control failure) on all links on which the named Admission Control failure) on upstream links.
sender is the only source sending to the session.
o Adspec o Adspec
A PATH message may optionally carry a package of OPWA A PATH message may optionally carry a package of OPWA
advertising information, known as an "Adspec". An Adspec advertising information, known as an "Adspec". An Adspec
received in a PATH message is passed to the local traffic received in a PATH message is passed to the local traffic
control, which returns an updated Adspec; the updated version control, which returns an updated Adspec; the updated version
is then forwarded downstream. is then forwarded in PATH messages sent downstream.
For protocol efficiency, RSVP also allows multiple sets of
reservation information for the same session to be "packed" into a
single RESV message. Unlike merging, packing preserves
information. For simplicity, however, the protocol currently
prohibits packing reservations of different sessions into the same
RSVP message.
PATH messages are sent with the same source and destination PATH messages are sent with the same source and destination
addresses as the data, so that they will be routed correctly addresses as the data, so that they will be routed correctly
through non-RSVP clouds (see Section 2.8). On the other hand, through non-RSVP clouds (see Section 2.9). On the other hand,
RESV messages are sent hop-by-hop; each RSVP-speaking node RESV messages are sent hop-by-hop; each RSVP-speaking node
forwards a RESV message to the unicast address of a previous RSVP forwards a RESV message to the unicast address of a previous RSVP
hop. hop.
2.2 Port Usage 2.2 Port Usage
At present an RSVP session is defined by the triple: (DestAddress, At present an RSVP session is defined by the triple: (DestAddress,
ProtocolId, DstPort). Here DstPort is a UDP/TCP destination port ProtocolId, DstPort). Here DstPort is a UDP/TCP destination port
field (i.e., a 16-bit quantity carried at octet offset +2 in the 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 transport header). DstPort may be omitted (set to zero) if the
skipping to change at page 20, line 34 skipping to change at page 20, line 26
field, and in particular must know about the values for UDP and field, and in particular must know about the values for UDP and
TCP (17 and 6, respectively). An end system should give an error TCP (17 and 6, respectively). An end system should give an error
to an application that either: to an application that either:
o specifies a non-zero DstPort for a protocol that does not o specifies a non-zero DstPort for a protocol that does not
have UDP/TCP-like ports, or have UDP/TCP-like ports, or
o specifies a zero DstPort for a protocol that does have o specifies a zero DstPort for a protocol that does have
UDP/TCP-like ports. UDP/TCP-like ports.
Filter specs and sender templates are defined by the pair: Filter specs and sender templates specify the pair: (SrcAddress,
(SrcAddress, SrcPort), where SrcPort is a UDP/TCP source port SrcPort), where SrcPort is a UDP/TCP source port field (i.e., a
field (i.e., a 16-bit quantity carried at octet offset +0 in the 16-bit quantity carried at octet offset +0 in the transport
transport header). SrcPort may be omitted (set to zero) in header). SrcPort may be omitted (set to zero) in certain cases.
certain cases. The following rules hold for the use of zero
DstPort and/or SrcPort fields in RSVP. The following rules hold for the use of zero DstPort and/or
SrcPort fields in RSVP.
1. Destination ports must be consistent. 1. Destination ports must be consistent.
Path state and/or reservation state for the same DestAddress Path state and/or reservation state for the same DestAddress
and ProtocolId must have DstPort values that are all zero or and ProtocolId must have DstPort values that are all zero or
all non-zero. Violation of this condition in a node is a all non-zero. Violation of this condition in a node is a
"Conflicting Dest Port" error. "Conflicting Dest Port" error.
2. Destination ports rule. 2. Destination ports rule.
If DstPort in a session definition is zero, all SrcPort If DstPort in a session definition is zero, all SrcPort
fields used for that session must also be zero. The fields used for that session must also be zero. The
assumption here is that the protocol does not have TCP/UDP- assumption here is that the protocol does not have UDP/TCP-
like ports. Violation of this condition in a node is a like ports. Violation of this condition in a node is a
"Conflicting Src Port" error. "Conflicting Src Port" error.
3. Source Ports must be consistent. 3. Source Ports must be consistent.
A sender host must not send path state both with and without A sender host must not send path state both with and without
a zero SrcPort. Violation of this condition is an "Ambiguous a zero SrcPort. Violation of this condition is an "Ambiguous
Path" error. Path" error.
2.3 Merging Flowspecs 2.3 Merging Flowspecs
As noted earlier, a single physical interface may receive multiple As noted earlier, a single physical interface may receive multiple
reservation request from different next hops for the same session reservation requests from different next hops for the same session
and with the same filter spec, but RSVP should install only one and with the same filter spec, but RSVP should install only one
reservation on that interface. This reservation should an reservation on that interface. The installed reservation should
effective flowspec that is the "maximum" of the flowspecs have an effective flowspec that is the "largest" of the flowspecs
requested by the different next hops. Similarly, a RESV message requested by the different next hops. Similarly, a RESV message
forwarded to a previous hop should carry a flowspec that is the forwarded to a previous hop should carry a flowspec that is the
"maximum" of the flowspecs requested by the different next hops. "largest" of the flowspecs requested by the different next hops
Both cases represent flowspec merging. (however, in certain cases the "smallest" is taken rather than the
largest, see Section 3.4). These cases all represent flowspec
merging.
Merging flowspecs requires calculating the "largest" of a set of Flowspec merging requires calculation of the "largest" of a set of
flowspecs, which are otherwise opaque to RSVP. Since flowspecs flowspecs. However, since flowspecs are generally multi-
are multi-dimensional vectors (they contain both Tspec and Rspec dimensional vectors (they may contain both Tspec and Rspec
components, each of which may itself be multi-dimensional), components, each of which may itself be multi-dimensional), it may
generally speaking they cannot be strictly ordered. However, in not be possible to strictly order two flowspecs. For example, if
many cases one can easily determine the "larger" of two flowspecs, one request calls for a higher bandwidth and another calls for a
such as when both request the same bandwidth but one requests a tighter delay bound, one is not "larger" than the other. In such
tighter delay, or when one of the two requests both a higher a case, instead of taking the larger, RSVP must compute and use a
bandwidth and a tighter delay bound. When the "larger" of the two third flowspec that is at least as large as each. Mathematically,
cannot be determined, RSVP must compute and use a third flowspec RSVP merges flowspecs using the " least upper bound" (LUB) instead
that is at least as large as each, i.e., a "least upper bound" of the maximum. Typically, the LUB is calculated by creating a
(LUB). If the two flowspecs are incomparable, their comparison new flowspec whose components are individually either the max or
will treated as an error. the min of corresponding components of the flowspecs being merged.
For example, the LUB of Tspecs defined by token bucket parameters
is computed by taking the maximums of the bucket size and the rate
parameters. In several cases, the GLB (Greatest Lower Bound) is
used instead of the LUB; this simply interchanges max and min
operations.
We can now give the complete rules for calculating the effective We can now give the complete rules for calculating the effective
flowspec (Te, Re) to be installed on an interface. Here Te is the flowspec (Te, Re) to be installed on an interface. Here Te is 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 9. consider interface (d) in Figure 9.
1. 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).
2. All Tspecs that were supplied in PATH messages from different 2. All Tspecs that were supplied in PATH messages from different
previous hops (e.g., some or all of A, B, and B' in Figure 9) previous hops (e.g., some or all of A, B, and B' in Figure 9)
are summed; call this sum Path_Te. are summed; call this sum Path_Te.
3. 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.
4. 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
take the smaller of the bucket size and the rate parameters.
Flowspecs, Tspecs, and Adspecs are opaque to RSVP. Therefore, the Flowspecs, Tspecs, and Adspecs are opaque to RSVP. Therefore, the
last of these steps is actually performed by traffic control. The last of these steps is actually performed by traffic control. The
definition and implementation of the rules for comparing definition and implementation of the rules for comparing
flowspecs, calculating LUB's, and summing Tspecs are outside the flowspecs, calculating LUBs and GLBs, and summing Tspecs are
definition of RSVP [ServTempl95a]. Section 3.9.4 shows generic outside the definition of RSVP [ServTempl95a]. Section 3.10.4
calls that an RSVP daemon could use for these functions. shows generic calls that an RSVP daemon could use for these
functions.
2.4 Soft State 2.4 Soft State
RSVP takes a "soft state" approach to managing the reservation RSVP takes a "soft state" approach to managing the reservation
state in routers and hosts. RSVP soft state is created and state in routers and hosts. RSVP soft state is created and
periodically refreshed by PATH and RESV messages. The state is periodically refreshed by PATH and RESV messages. The state is
deleted if no matching refresh messages arrive before the deleted if no matching refresh messages arrive before the
expiration of a "cleanup timeout" interval. It may also be expiration of a "cleanup timeout" interval. State may also be
deleted by an explicit "teardown" message, described in the next deleted by an explicit "teardown" message, described in the next
section. At the expiration of each "refresh timeout" period and section. At the expiration of each "refresh timeout" period and
after a state change, RSVP scans its state to build and forward after a state change, RSVP scans its state to build and forward
PATH and RESV refresh messages to succeeding hops. PATH and RESV refresh messages to succeeding hops.
PATH and RESV messages are idempotent. When a route changes, the PATH and RESV messages are idempotent. When a route changes, the
next PATH message will initialize the path state on the new route, next PATH message will initialize the path state on the new route,
and future RESV messages will establish reservation state there; and future RESV messages will establish reservation state there;
the state on the now-unused segment of the route will time out. the state on the now-unused segment of the route will time out.
Thus, whether a message is "new" or a "refresh" is determined Thus, whether a message is "new" or a "refresh" is determined
separately at each node, depending upon the existing state at that separately at each node, depending upon the existing state at that
node. node.
RSVP sends its messages as IP datagrams with no 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 handle the occasional loss of RSVP and routers is expected to handle the occasional loss of an RSVP
messages. If the effective cleanup timeout is set to K times the message. If the effective cleanup timeout is set to K times the
refresh timeout period, then RSVP can tolerate K-1 successive RSVP refresh timeout period, then RSVP can tolerate K-1 successive RSVP
packet losses without falsely erasing a reservation. We recommend packet losses without falsely erasing a reservation. We recommend
that the network traffic control mechanism be statically that the network traffic control mechanism be statically
configured to grant some minimal bandwidth for RSVP messages to configured to grant some minimal bandwidth for RSVP messages to
protect them from congestion losses. protect them from congestion losses.
The state maintained by RSVP is dynamic; to change the set of The state maintained by RSVP is dynamic; to change the set of
senders Si or to change any QoS request, a host simply starts senders Si or to change any QoS request, a host simply starts
sending revised PATH and/or RESV messages. The result should be sending revised PATH and/or RESV messages. The result will be an
an appropriate adjustment in the RSVP state in all nodes along the appropriate adjustment in the RSVP state in all nodes along the
path. path.
In steady state, refreshing is performed hop-by-hop to allow In steady state, refreshing is performed hop-by-hop, to allow
merging. If the received state differs from the stored state, the merging. When the received state differs from the stored state,
stored state is updated. If this update results in modification the stored state is updated. If this update results in
of state to be forwarded in refresh messages, these refresh modification of state to be forwarded in refresh messages, these
messages must be generated and forwarded immediately, so that refresh messages must be generated and forwarded immediately, so
state changes can be propagated end-to-end without delay. that state changes can be propagated end-to-end without delay.
However, propagation of a change stops when and if it reaches a However, propagation of a change stops when and if it reaches a
point where merging causes no resulting state change. This point where merging causes no resulting state change. This
minimizes RSVP control traffic due to changes and is essential for minimizes RSVP control traffic due to changes and is essential for
scaling to large multicast groups. scaling to large multicast groups.
State that is received through a particular interface I* should State that is received through a particular interface I* should
never be forwarded out the same interface. Conversely, state that never be forwarded out the same interface. Conversely, state that
is forwarded out interface I* must be computed using only state is forwarded out interface I* must be computed using only state
that arrived on interfaces different from I*. A trivial example that arrived on interfaces different from I*. A trivial example
of this rule is illustrated in Figure 10, which shows a transit of this rule is illustrated in Figure 10, which shows a transit
skipping to change at page 24, line 35 skipping to change at page 24, line 35
2.5 Teardown 2.5 Teardown
Upon arrival, RSVP "teardown" messages remove path and reservation Upon arrival, RSVP "teardown" messages remove path and reservation
state immediately. Although it is not necessary to explicitly state immediately. Although it is not necessary to explicitly
tear down an old reservation, we recommend that all end hosts send tear down an old reservation, we recommend that all end hosts send
a teardown request as soon as an application finishes. a teardown request as soon as an application finishes.
There are two types of RSVP teardown message, PTEAR and RTEAR. A There are two types of RSVP teardown message, PTEAR and RTEAR. A
PTEAR message travels towards all receivers downstream from its PTEAR message travels towards all receivers downstream from its
point of initiation and deletes path state along the way. An point of initiation and deletes path state, as well as all
RTEAR message deletes reservation state and travels towards all dependent reservation state, along the way. An RTEAR message
senders upstream from its point of initiation. A PTEAR (RTEAR) deletes reservation state and travels towards all senders upstream
message may be conceptualized as a reversed-sense Path message from its point of initiation. A PTEAR (RTEAR) message may be
(Resv message, respectively). 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 must be state timeout. Once initiated, a teardown request must be
forwarded hop-by-hop without delay. A teardown message deletes forwarded hop-by-hop without delay. A teardown message deletes
the specified state in the node where it is received. As always, the specified state in the node where it is received. As always,
this state change will be propagated immediately to the next node, this state change will be propagated immediately to the next node,
but only if there will be a net change after merging. As a but only if there will be a net change after merging. As a
result, an RTEAR message will prune the reservation state back result, an RTEAR message will prune the reservation state back
(only) as far as possible. (only) as far as possible.
skipping to change at page 25, line 13 skipping to change at page 25, line 15
Like all other RSVP messages, teardown requests are not delivered Like all other RSVP messages, teardown requests are not delivered
reliably. The loss of a teardown request message will not cause a reliably. The loss of a teardown request message will not cause a
protocol failure because the unused state will eventually time out protocol failure because the unused state will eventually time out
even though it is not explicitly deleted. If a teardown message even though it is not explicitly deleted. If a teardown message
is lost, the router that failed to receive that message will time is lost, the router that failed to receive that message will time
out its state and initiate a new teardown message beyond the loss out its state and initiate a new teardown message beyond the loss
point. Assuming that RSVP message loss probability is small, the point. Assuming that RSVP message loss probability is small, 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.
2.6 Errors and Acknowledgments 2.6 Errors
There are two RSVP error messages, RERR and PERR, and a There are two RSVP error messages, RERR and PERR. PERR messages
reservation confirmation message RACK. are very simple. They are simply sent upstream to the sender that
created the error, and they do not change path state in the nodes
though which they pass. There are only a few possible causes of
path errors.
There are a number of ways for a syntactically valid reservation However, there are a number of ways for a syntactically valid
request to fail at some node along the path, triggering a RERR reservation request to fail at some node along the path, for
message: example:
1. The effective flowspec that is computed using the new request 1. The effective flowspec that is computed using the new request
may fail admission control. may fail admission control.
2. Administrative policy may prevent the requested reservation. 2. Administrative policy may prevent the requested reservation.
3. There may be no matching path state, so that the request 3. There may be no matching path state, so that the request
cannot be forwarded towards the sender(s). cannot be forwarded towards the sender(s).
4. A reservation style that requires the explicit selection of a 4. A reservation style that requires the explicit selection of a
unique sender may have a filter spec that is ambiguous, i.e., unique sender may have a filter spec that is ambiguous, i.e.,
that matches more than one sender in the path state, due to that matches more than one sender in the path state, due to
the use of wildcard fields in the filter spec. the use of wildcard fields in the filter spec.
5. The requested style may be incompatible with the style(s) of 5. The requested style may be incompatible with the style(s) of
existing reservations. The incompatibility may occur among existing reservations. The incompatibility may occur among
reservations for the same session on the same outgoing reservations for the same session on the same outgoing
interface, or among effective reservations on different interface, or among effective reservations on different
outgoing interfaces. outgoing interfaces.
In any of these cases, a RERR message is returned to the A node may also decide to preempt an established reservation.
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 The handling of RERR messages is somewhat complex (Section 3.4).
request not only generates a RERR message, it also prevents the Since a request that fails may be the result of merging a number
request from being forwarded further. This may not always be the of requests, a reservation error must be reported to all of the
desirable behavior; for example, a receiver may want a reservation responsible receivers. In addition, merging heterogeneous
request to propagate all the way to the sender despite an requests creates a potential difficulty known as the "killer
admission control failure at a particular link along the path. reservation" problem, in which one request could deny service to
However, design of the appropriate mechanism has proved difficult, another. There are actually two killer-reservation problems.
and therefore this version take the simplest approach.
When admission control fails for a reservation request, any 1. The first killer reservation problem (KR-I) arises when there
existing reservation is left in place. This prevents a new, very is already a reservation Q0 in place. If another receiver
large, reservation from disrupting the existing QoS by merging now makes a larger reservation Q1 > Q0, the result of merging
with an existing reservation and then failing admission control Q0 and Q1 may be rejected by admission control in some
(this has been called the "killer reservation" problem). upstream node. This must not deny service to Q0.
The solution to this problem is simple: when admission
control fails for a reservation request, any existing
reservation is left in place.
2. The second killer reservation problem (KR-II) is the
converse: the receiver making a reservation Q1 is persistent
even though Admission Control is failing for Q1 in some node.
This must not prevent a different receiver from now
establishing a smaller reservation Q0 that will succeed.
To solve this problem, a RERR message establishes additional
state, called "blockade state", in each node through which it
passes. Blockade state in a node modifies the merging
procedure to omit the offending flowspec (Q1 in the example)
from the merge, allowing a smaller request to be forwarded
and established. The Q1 reservation state is said to be
"blockaded". Detailed rules are presented in Section 3.4.
A reservation request that fails Admission Control creates
blockade state but is left in place in nodes downstream of the
failure point. It has been suggested that these reservations
downstream from the failure represent "wasted" reservations and
should be timed out if not actively deleted. However, in general
the downstream reservations will not be "wasted".
o There are two possible reasons for a receiver persisting in a
failed reservation: (1) it is polling for resource
availability along the entire path, or (2) it wants to obtain
the desired QoS along as much of the path as possible.
Certainly in the second case, and perhaps in the first case,
the receiver will want to hold onto the reservations it has
made downstream from the failure.
o If these downstream reservations were not retained, the
responsiveness of RSVP to certain transient failures would be
impaired. For example, suppose a route "flaps" to an
alternate route that is congested, so an existing reservation
suddenly fails, then quickly recovers to the original route.
The blockade state in each downstream router must not remove
the state or prevent its immediate refresh.
o If we did not refresh the downstream reservations, they might
time out, to be restored every Td seconds. Such on/off
behavior might be very distressing for users.
2.7 Confirmation
To request a confirmation for its reservation request, a receiver To request a confirmation for its reservation request, a receiver
Rj includes in the RESV message a confirmation-request object Rj includes in the RESV message a confirmation-request object
containing its IP address. At each merge point, only the largest containing Rj's IP address. At each merge point, only the largest
flowspec and any accompanying confirmation-request object is flowspec and any accompanying confirmation-request object is
forwarded upstream. If the reservation request from Rj is equal forwarded upstream. If the reservation request from Rj is equal
to or smaller than the reservation in place on a node, its RESV to or smaller than the reservation in place on a node, its RESV
are not forwarded further, and if the RESV included an are not forwarded further, and if the RESV included a
confirmation-request object, a RACK message is sent back to Rj. confirmation-request object, a RACK message is sent back to Rj.
This mechanism has the following consequences: This mechanism has the following consequences:
o A new reservation request with a flowspec larger than any in o A new reservation request with a flowspec larger than any in
place for a session will normally result in either a RERR or place for a session will normally result in either a RERR or
a RACK message back to the receiver from each sender. In a RACK message back to the receiver from each sender. In
this case, the RACK message will be an end-to-end this case, the RACK message will be an end-to-end
confirmation. confirmation.
o The receipt of a RACK gives no guarantees. Assume the first o The receipt of a RACK gives no guarantees. Assume the first
two reservation requests from receivers R1 and R2 arrive at two reservation requests from receivers R1 and R2 arrive at
the node where they are merged. R2, whose reservation was the node where they are merged. R2, whose reservation was
the second to arrive at that node, may receive a RACK from the second to arrive at that node, may receive a RACK from
that node while R1's request has not yet propagated all the that node while R1's request has not yet propagated all the
way to a matching sender and may still fail. In this case, way to a matching sender and may still fail. Thus, R2 may
R2 will receive a RACK although there is no end-to-end receive a RACK although there is no end-to-end reservation in
reservation in place. Furthermore, if the two flowspecs are place; furthermore, R2 may receive a RACK followed by a RERR.
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 2.8 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 is likely to be abuse, some form of back pressure on users is likely to be
required. This back pressure might take the form of required. This back pressure might take the form of
administrative rules, or of some form of real or virtual billing administrative rules, or of some form of real or virtual billing
for the "cost" of a reservation. The form and contents of such for the "cost" of a reservation. The form and contents of such
back pressure is a matter of administrative policy that may be back pressure is a matter of administrative policy that may be
determined independently by each administrative domain in the determined independently by each administrative domain in the
Internet. Internet.
Therefore, admission control at each node is likely to contain a Therefore, there will be policy control as well as admission
policy component in addition to a resource reservation component. control over the establishment of reservations. As input to
As input to the policy-based admission decision, RSVP messages may policy control, RSVP messages may carry policy data. Policy data
carry policy data. This data may include credentials identifying may include credentials identifying users or user classes, account
users or user classes, account numbers, limits, quotas, etc. numbers, limits, quotas, etc. Like flowspecs, policy data will be
opaque to RSVP, which will simply pass it to a "Local Policy
Module" (LPM) for a decision.
To protect the integrity of the policy-based admission control To protect the integrity of the policy control mechanisms, it may
mechanisms, it may be necessary to ensure the integrity of RSVP be necessary to ensure the integrity of RSVP messages against
messages against corruption or spoofing, hop by hop. For this corruption or spoofing, hop by hop. For this purpose, RSVP
purpose, RSVP messages may carry integrity objects that can be messages may carry integrity objects that can be created and
created and verified by neighbor RSVP-capable nodes. These verified by neighbor RSVP-capable nodes. These objects use a
objects are expected to contain an encrypted part and to assume a keyed cryptographic digest technique and assume that RSVP
shared secret between neighbors. neighbors share a secret [Baker96].
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 be impossible or undesirable to carry all 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 at places near 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 integrity fields will allow upstream
nodes to accept these tokens. nodes to accept these tokens.
In summary, different administrative domain in the Internet may In summary, different administrative domains in the Internet may
have different policies regarding their resource usage and have different policies regarding their resource usage and
reservation. The role of RSVP is to carry policy data associated reservation. The role of RSVP is to carry policy data associated
with each reservation to the network as needed. Note that the with each reservation to the network as needed. Note that the
merge points for policy data are likely to be at the boundaries of merge points for policy data are likely to be at the boundaries of
administrative domains. It may be necessary to carry accumulated administrative domains. It may be necessary to carry accumulated
and unmerged policy data upstream through multiple nodes before and unmerged policy data upstream through multiple nodes before
reaching one of these merge points. reaching one of these merge points.
2.8 Automatic RSVP Tunneling This document does not specify the contents of policy data, the
structure of an LPM, or any generic policy models. These will be
defined in the future.
2.9 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. However, if such a cloud has sufficient resource reservation. However, if such a cloud has sufficient
capacity, it may still provide acceptable realtime service. capacity, it may still provide acceptable realtime service.
skipping to change at page 28, line 27 skipping to change at page 29, line 17
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, it carries to the next RSVP-capable node the IP non-RSVP cloud, it carries to the next RSVP-capable node the IP
address of the last RSVP-capable router before entering the cloud. address of the last RSVP-capable router before entering the cloud.
This effectively constructs a tunnel through the cloud for RESV This effectively constructs a tunnel through the cloud for RESV
messages, which can then be forwarded directly to the next RSVP- messages, which can then be forwarded directly to the next RSVP-
capable router on the path(s) back towards the source. capable router on the path(s) back towards the source.
Some interconnection topologies of RSVP and non-RSVP routers can Even though RSVP operates correctly through a non-RSVP cloud, the
cause RESV messages to arrive at the wrong RSVP-capable node, or non-RSVP-capable nodes will in general perturb the QoS provided to
to arrive at the wrong interface at the correct node. An RSVP a receiver. Therefore, RSVP tries to inform the receiver when
daemon must be prepared to handle either situation. When a RESV there are non-RSVP-capable hops in the path to a given sender, by
message arrives, its IP destination address should normally be the means of two flag bits in the SESSION object of a PATH message;
address of one of the local interfaces. If so, the reservation see Section 3.7 and Appendix A.
should be made on the addressed interface, even if it is not the
one on which the message arrived. If the destination address does
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.9 Host Model Some topologies of RSVP routers and non-RSVP routers can cause
RESV messages to arrive at the wrong RSVP-capable node, or to
arrive at the wrong interface of the correct node. An RSVP daemon
must be prepared to handle either situation. If the destination
address does not match any local interface and the message is not
a PATH or PTEAR, the message must be forwarded without further
processing by this node. When a RESV message does arrive at the
addessed node, the IP destination address (or the LIH, defined
later) must be used to determine the interface to receive the
reservation.
2.10 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.
skipping to change at page 29, line 40 skipping to change at page 30, line 36
awaiting arrival of the first RESV message (H5); however, awaiting arrival of the first RESV message (H5); however,
receivers that are farther away may not have reservations in receivers that are farther away may not have reservations in
place yet. place yet.
o If a receiver starts sending RESV messages (H4) before o If a receiver starts sending RESV messages (H4) before
receiving any PATH messages (H3), RSVP will return error receiving any PATH messages (H3), RSVP will return error
messages to the receiver. messages to the receiver.
The receiver may simply choose to ignore such error messages, The receiver may simply choose to ignore such error messages,
or it may avoid them by waiting for PATH messages before or it may avoid them by waiting for PATH messages before
sending RESV messages. [LZ: should recommend that a receiver sending RESV messages.
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 3.9.1 discusses the general requirements and However, Section 3.10.1 discusses the general requirements and
presen outlines a generic interface.
3. RSVP Functional Specification 3. RSVP Functional Specification
3.1 RSVP Message Formats 3.1 RSVP Message Formats
An RSVP message consists of a common header followed by a variable An RSVP message or message fragment consists of a common header,
number of variable-length, typed "objects". The subsections that an optional integrity-check data structure, and a body consisting
follow define the formats of the common header, the object of a variable number of variable-length, typed "objects". The
structures, and each of the RSVP message types. integrity-check data structure is itself an object, of class
INTEGRITY [Baker96]. In a fragmented message, INTEGRITY objects
must occur either in every fragment or else in no fragment.
Fragmentation of a message allows division of an object across two
(or more) successive fragments.
For each RSVP message type, there is a set of rules for the The following subsections define the formats of the common header,
permissible choice and ordering of object types. These rules are the object structures, and each of the RSVP message types. For
specified using Backus-Naur Form (BNF) augmented with square each RSVP message type, there is a set of rules for the
brackets surrounding optional sub-sequences. permissible choice of object types. These rules are specified
using Backus-Naur Form (BNF) augmented with square brackets
surrounding optional sub-sequences. The BNF implies an order for
the objects in a message. However, in many (but not all) cases,
object order makes no logical difference. An implementation
should create messages with the objects in the order shown here,
but accept the objects in any order except where the order is
logically required (as noted in the following).
3.1.1 Common Header 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) | Send_TTL | | RSVP Length | (Reserved) | Send_TTL |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Message ID | | Message ID |
skipping to change at page 30, line 39 skipping to change at page 32, line 4
|(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
Protocol version number. This is version 1. Protocol version number. This is version 1.
Flags: 4 bits Flags: 4 bits
0x01 = INTEGRITY object present
(None defined yet) This flag indicates that an INTEGRITY object follows
immediately after the common header. The use of the
INTEGRITY object is described in [Baker96].
0x02 = UDP': UDP encapsulation marker flag
This flag is reserved for use by UDP encapsulation
[Appendix C].
Type: 8 bits Type: 8 bits
1 = PATH 1 = PATH
2 = RESV 2 = RESV
3 = PERR 3 = PERR
4 = RERR 4 = RERR
skipping to change at page 31, line 4 skipping to change at page 32, line 24
Type: 8 bits Type: 8 bits
1 = PATH 1 = PATH
2 = RESV 2 = RESV
3 = PERR 3 = PERR
4 = RERR 4 = RERR
5 = PTEAR 5 = PTEAR
6 = RTEAR 6 = RTEAR
7 = RACK 7 = RACK
RSVP Checksum: 16 bits RSVP Checksum: 16 bits
A standard TCP/UDP checksum over the contents of the RSVP The one's complement of the one's complement sum of the
message, with the checksum field replaced by zero. message (fragment), with the checksum field replaced by
zero for the purpose of computing the checksum. An all-
zero value means that no checksum was transmitted.
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 Send_TTL: 8 bits
skipping to change at page 31, line 41 skipping to change at page 33, line 16
assigns 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 current fragment
message. in the complete message.
3.1.2 Object Formats 3.1.2 Object Formats
Every object consists of one or more 32-bit words with a one- Every object consists of one or more 32-bit words with a one-
word 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 |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 32, line 50 skipping to change at page 34, line 26
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
Contains the value for the refresh period R used by Contains the value for the refresh period R used by
the creator of the message; see 3.5. Required in the creator of the message; see 3.6. Required in
every PATH and RESV message. 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 in FLOWSPEC or FILTER_SPEC information that is not in FLOWSPEC or FILTER_SPEC
objects. Required in every RESV message. objects. Required in every RESV message.
FLOWSPEC FLOWSPEC
skipping to change at page 33, line 51 skipping to change at page 35, line 25
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 to verify the contents of this
of this RSVP message. RSVP message. See [Baker96].
SCOPE SCOPE
An explicit list of sender hosts towards which to An explicit list of sender hosts towards which to
forward a message. May appear in a RESV, RERR, or forward a message. May appear in a RESV, RERR, or
RTEAR message. RTEAR message.
RESV_CONFIRM RESV_CONFIRM
Carries the IP address of a receiver that requested a Carries the IP address of a receiver that requested a
skipping to change at page 34, line 26 skipping to change at page 35, line 48
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 may be used together as a 16-bit number Num and C-Type fields may be used together as a 16-bit number
to define a unique type for each object. to define a unique type for each object.
The high-order bit of the Class-Num is used to determine what The high-order two bits of the Class-Num is used to determine
action a node should take if it does not recognize the Class- what action a node should take if it does not recognize the
Num of an object; see Section 3.8. Class-Num of an object; see Section 3.9.
3.1.3 Path Message 3.1.3 Path Messages
Each sender host periodically sends a PATH message containing a Each sender host periodically sends a PATH message containing a
description of each data stream it originates. The PATH description of each data stream it originates. The PATH
message travels from a sender to receiver(s) along the same message travels from a sender to receiver(s) along the same
path(s) used by the data packets. The IP source address of a path(s) used by the data packets. The IP source address of a
PATH message is an address of the sender it describes, while PATH message is an address of the sender it describes, while
the destination address is the DestAddress for the session. the destination address is the DestAddress for the session.
These addresses assure that the message will be correctly These addresses assure that the message will be correctly
routed through a non-RSVP cloud. routed through a non-RSVP cloud.
skipping to change at page 35, line 5 skipping to change at page 36, line 27
and processes them to build local path state. The node then and processes them to build local path state. The node then
forwards the PATH messages towards the receiver(s), replicating forwards the PATH messages towards the receiver(s), replicating
it as dictated by multicast routing, while preserving the it as dictated by multicast routing, while preserving the
original IP source address. PATH messages eventually reach the original IP source address. PATH messages eventually reach the
applications on all receivers; however, they are not looped applications on all receivers; however, they are not looped
back to a receiver running in the same application process as back to a receiver running in the same application process as
the sender. 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> [ <INTEGRITY> ]
[ <INTEGRITY> ] <TIME_VALUES> <SESSION> <RSVP_HOP>
<TIME_VALUES>
<sender descriptor> <sender descriptor>
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <POLICY_DATA> ] [ <ADSPEC> ] [ <POLICY_DATA> ] [ <ADSPEC> ]
If the INTEGRITY object is present, there must be an INTEGRITY
object immediately following the common header in every
fragment of the message, in this and all other messages. The
objects included in the sender descriptor must occur after all
other objects in the message.
The PHOP (i.e., the RSVP_HOP) object of each PATH message The PHOP (i.e., the RSVP_HOP) object of each PATH message
contains the address of the interface through which the PATH contains the address of the interface through which the PATH
message was most recently sent. The SENDER_TEMPLATE object message was most recently sent. The SENDER_TEMPLATE object
defines the format of data packets from this sender, while the defines the format of data packets from this sender, while the
SENDER_TSPEC object specifies the traffic characteristics of SENDER_TSPEC object specifies the traffic characteristics of
the flow. Optionally, there may be a POLICY_DATA object the flow. Optionally, there may be a POLICY_DATA object
specifying user credential and accounting information and/or an specifying user credential and accounting information and/or an
ADSPEC object carrying advertising (OPWA) data. 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
skipping to change at page 36, line 17 skipping to change at page 37, line 47
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 flows 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. that sent the message.
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> [ <INTEGRITY> ]
[ <INTEGRITY> ] <TIME_VALUES>
[ <S_POLICY_DATA> ] <SESSION> <RSVP_HOP>
<TIME_VALUES> [ <S_POLICY_DATA> ]
[ <RESV_CONFIRM> ] [ <SCOPE> ] [ <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>
The NHOP (i.e., the RSVP_HOP) object contains the IP address of The NHOP (i.e., the RSVP_HOP) object contains the IP address of
the (incoming) interface through which the RESV message is the interface through which the RESV message was sent. The
sent. The appearance of a RESV_CONFIRM object signals a appearance of a RESV_CONFIRM object signals a request for a
request for a reservation confirmation and carries the IP reservation confirmation and carries the IP address of the
address of the receiver to which the RACK should be sent. The receiver to which the RACK should be sent. The S_POLICY_DATA
S_POLICY_DATA object is a POLICY_DATA object that is associated object is a POLICY_DATA object that is associated with the
with the entire session. There may also be flow-specific entire session. There may also be flow-specific F_POLICY_DATA
POLICY_DATA objects, as described below. objects, as described below.
The STYLE object followed by the flow descriptor list must
occur at the end of the message.
The BNF above defines a flow descriptor list as simply a list 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 in more detail the composition of a valid flow specify in more detail the composition of a valid flow
descriptor list for each of the reservation styles. descriptor list for each of the reservation styles; the order
shown must be used.
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> ]
<F_POLICY_DATA> ::= <POLICY_DATA> <F_POLICY_DATA> ::= <POLICY_DATA>
o FF style: o FF style:
<flow descriptor list> ::= <First FF flow descriptor> | <flow descriptor list> ::= <First FF flow descriptor> |
<flow descriptor list> <FF flow descriptor> <flow descriptor list> <FF flow descriptor>
skipping to change at page 37, line 30 skipping to change at page 39, line 16
[ <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 object can be omitted if it is RESV message. A FLOWSPEC object can be omitted if it is
identical to the most recent such object that appeared in identical to the most recent such object that appeared in
the list; the first FF flow descriptor must contain a the list; the first FF flow descriptor must contain a
FLOWSPEC. FLOWSPEC.
Each flow descriptor in the list must be processed
independently, and a separate RERR message must be
generated for each one that is in error.
o SE style: o SE style:
<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
descriptor, which includes a FLOWSPEC defining the shared
reservation, optionally a POLICY_DATA object, and a list
of FILTER_SPEC objects.
The reservation scope, i.e., the set of senders towards which a The reservation scope, i.e., the set of senders towards which a
particular reservation is to be forwarded, is determined as particular reservation is to be forwarded, is determined as
follows: follows:
o Explicit sender selection o Explicit sender selection
Match each FILTER_SPEC object against the path state Select a particular sender by matching each FILTER_SPEC
created from SENDER_TEMPLATE objects to select a object against the path state created from SENDER_TEMPLATE
particular sender. An ambiguous match, i.e., a objects. An ambiguous match, i.e., a FILTER_SPEC matching
FILTER_SPEC matching more than one SENDER_TEMPLATE (e.g. more than one SENDER_TEMPLATE (e.g. through use of a
through use of a wildcard port), is an error. Any SCOPE wildcard port), is an error.
object associated with the reservation should be ignored
in this case.
o Wildcard sender selection o Wildcard sender selection
All senders that route to the given outgoing interface All senders that route to the given outgoing interface
match this request. A SCOPE object, if present, contains match this request. A SCOPE object, if present, contains
an explicit list of sender IP addresses. If there is no 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. Whenever a RESV message of senders in the path state.
with wildcard sender selection is forwarded to more than
one previous hop, a SCOPE object must be included in the
message. See Section 3.3 below.
3.1.5 Error and Confirmation Messages
There are three types of RSVP error/confirmation messages.
o PERR messages result from PATH messages and travel towards Whenever a RESV message with wildcard sender selection is
senders. PERR messages are routed hop-by-hop using the forwarded to more than one previous hop, a SCOPE object
path state; at each hop, the IP destination address is the must be included in the message. See Section 3.3 below.
unicast address of a previous hop.
o RERR messages result from RESV messages and travel towards 3.1.5 Teardown Messages
the appropriate receivers. They are routed hop-by-hop
using the reservation state; at each hop, the IP
destination address is the unicast address of a next-hop
node.
o RACK messages are sent to (probabilistically) acknowledge There are two types of RSVP Teardown message, PTEAR and RTEAR.
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 o A PTEAR message deletes path state (which in turn deletes
the error message to be discarded without creating further any reservation state for that sender) and travels towards
error messages; however, logging of such events may be useful. all receivers that are downstream from the initiating
node. A PTEAR message is routed like a PATH message, and
its IP destination address is DestAddress for the session.
None of these messages modify the state of any node through o A RTEAR message deletes reservation state and travels
which they pass; instead, they are only reported to the end towards all matching senders upstream from the initiating
application. node. A RTEAR message is routed in the same way as a
corresponding RESV message, and its IP destination address
is the unicast address of a previous hop.
<PathErr message> ::= <Common Header> <SESSION> <PathTear Message> ::= <Common Header> [<INTEGRITY>]
[ <INTEGRITY> ] <ERROR_SPEC> <SESSION> <RSVP_HOP>
<sender descriptor> <sender descriptor>
<sender descriptor> ::= (see earlier definition) <sender descriptor> ::= (see earlier definition)
<ResvErr Message> ::= <Common Header> <SESSION> <ResvTear Message> ::= <Common Header> [<INTEGRITY>]
[ <INTEGRITY> ] <ERROR_SPEC> <SESSION> <RSVP_HOP>
[S_POLICY_DATA] [ <SCOPE> ] [ <SCOPE> ] <STYLE>
<STYLE> <error flow descriptor> <flow descriptor list>
<ResvConf Message> ::= <Common Header> <SESSION> <flow descriptor list> ::= (see earlier definition)
[ <INTEGRITY> ] <ERROR_SPEC> FLOWSPEC or POLICY_DATA objects in the flow descriptor list of
a RTEAR message will be ignored and may be omitted. The order
requirements for sender descriptor, STYLE object, and flow
descriptor list are as given earlier for PATH and RESV
messages.
<RESV_CONFIRM> Note that, unless it is accidentally dropped along the way, a
PTEAR message will reach all receivers down stream from its
origination. On the other hand, a RTEAR message will cease to
be forwarded at the same node where merging suppresses
forwarding of the corresponding RESV messages. In each node N
along the way, if the RTEAR message causes the removal of all
state for this session, N will create a new teardown message to
be propagated further upstream; otherwise, the RTEAR message
may result in the immediate forwarding of a modified RESV
refresh message.
<STYLE> <flow descriptor list> Deletion of path state as the result of a PTEAR message or a
timeout must cause any adjustments in related reservation state
required to maintain consistency in the local node. The
adjustment in reservation state depends upon the style. For
example, suppose a PTEAR deletes the path state for a sender S.
If the style specifies explicit sender selection (FF or SE),
any reservation with a filter spec matching S should be
deleted; if the style has wildcard sender selection (WF), the
reservation should be deleted if S is the last sender to the
session. These reservation changes should not trigger an
immediate RESV refresh message, since the PTEAR message have
already made the required changes upstream. However, at the
node in which a RTEAR message stops, the change of reservation
state may trigger a RESV refresh starting at that node.
<flow descriptor list> ::= (see earlier definition) 3.1.6 Error Messages
The RESV_CONFIRM object in a RACK message is a copy of the There are two types of RSVP error messages.
object from the RESV message that triggered the confirmation.
o PERR messages result from PATH messages and travel
upstream towards the senders. PERR messages are routed
hop-by-hop using the path state; at each hop, the IP
destination address is the unicast address of a previous
hop. PERR messages do not modify the state of any node
through which they pass; instead, they are only reported
to the sender application.
o RERR messages result from RESV messages and travel
downstream towards the appropriate receivers. They are
routed hop-by-hop using the reservation state; at each
hop, the IP destination address is the unicast address of
a next-hop node.
An error encountered while processing an error message must
cause the error message to be discarded without creating
further error messages; however, logging of such events may be
useful.
<PathErr message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC>
<sender descriptor>
<sender descriptor> ::= (see earlier definition)
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC>
[S_POLICY_DATA] [ <SCOPE> ]
<STYLE> <error flow descriptor>
The ERROR_SPEC object specifies the error and includes the IP
address of the node that detected the error (Error Node
Address). POLICY_DATA objects are included in error messages
in cases where they may provide relevant information (i.e.,
when an administrative failure is being reported). The STYLE
object is copied from the RESV message in error. The use of
the SCOPE object in a RERR message is defined below in Section
3.3.
The following style-dependent rules define the composition of a The following style-dependent rules define the composition of a
valid error flow descriptor: valid error flow descriptor; the object order requirements are
as given earlier for a RESV message.
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>
The ERROR_SPEC object specifies the error and includes the IP Note that a RERR message contains only one flow descriptor.
address of the node that detected the error (Error Node Therefore, a RESV message that contains N > 1 flow descriptors
Address). POLICY_DATA objects are included in error messages (FF style) may create up to N separate RERR 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 RESV message contains a list of flow descriptors (e.g.,
FF style), the RSVP implementation should process each flow
descritor independently and return a separate RERR message for
each that is in error.
Generally speaking, a RERR message should be forwarded towards Generally speaking, a RERR message should be forwarded towards
all receivers that may have caused the error being reported. all receivers that may have caused the error being reported.
More specifically: More specifically:
o The node that detects an error in a reservation request o The node that detects an error in a reservation request
sends a RERR message to the next hop from which the sends a RERR message to the next hop from which the
erroneous reservation came. erroneous reservation came.
The message must contain the information required to This 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 in later
requires at least a STYLE object and one or more hops. It therefore includes an ERROR_SPEC object, a copy
FILTER_SPEC object(s) from the erroneous RESV message. of the STYLE object, and the appropriate error flow
For an admission control failure, for example, the descriptor. If the error is an admission control failure,
erroneous FLOWSPEC must be included. any reservation already in place will be left in place,
and the InPlace flag bit must be on in the ERROR_SPEC of
o Succeeding nodes forward the RERR message using their the RERR message.
local reservation state, to the next hops of reservations
that match the FILTER_SPEC(s) in the message. For
reservations with wildcard scope, there is an additional
limitation on forwarding RERR messages, to avoid loops;
see Section 3.3.
When the error is an admission control failure, a node is
allowed (but not required) to match the FLOWSPEC as well as the
FILTER_SPEC object(s), to limit the distribution of a RERR
message to those receivers that `caused' the error. Suppose
that a RERR message contains a FLOWSPEC Qerr that is being
matched against the FLOWSPEC Qlocal in the local reservation
state in node N. Qerr, which originated in a node upstream
from N, resulted from merging of flowspecs that included
Qlocal. Generally, a RERR message can be forwarded to the
receiver(s) that specified the `biggest' flowspec. The
comparison of Qerr against a particular Qlocal to determine
whether Qlocal qualifies as (one of) the `biggest', may be
called `de-merging'. As with merging, the details of de-
merging depend upon the service and the FLOWSPEC format, and
are outside RSVP itself.
A RERR message that is forwarded should carry the FILTER_SPEC
from the corresponding reservation state (thus `de-merging' the
filter spec).
When a RERR or RACK message reaches a receiver, the STYLE
object, flow descriptor list, and ERROR_SPEC object (which
contains the LUB-Used flag) should be delivered to the receiver
application. In the case of an Admission Control error, the
flow descriptor list will contain the FLOWSPEC object that
failed. If the LUB-Used flag is off, this should be
semantically equivalent (but not necessarily identical) to the
FLOWSPEC originated by this application; otherwise, they may
differ.
3.1.6 Teardown Messages
There are two types of RSVP Teardown message, PTEAR and RTEAR. o Succeeding nodes forward the RERR message to next hops
that have local reservation state. For reservations with
wildcard scope, there is an additional limitation on
forwarding RERR messages, to avoid loops; see Section 3.3.
There is also a rule restricting the forwarding of RESV
messages for Admission Control failures; see Section 3.4.
o A PTEAR message deletes path state (which in turn deletes A RERR message that is forwarded should carry the
the reservation state for that sender, if there is any) FILTER_SPEC from the corresponding reservation state.
and travels towards all receivers that are downstream from
the point of initiation. A PTEAR message is routed like a
PATH message, and its IP destination address is
DestAddress for the session.
o A RTEAR message deletes reservation state and travels o When a RERR message reaches a receiver, the STYLE object,
towards all matching senders upstream from the point of flow descriptor list, and ERROR_SPEC object (including its
teardown initiation. A RTEAR message is routed in the flags) should be delivered to the receiver application.
same way as a corresponding RESV message (using the same
scope rules). Its IP destination address is the unicast
address of a previous hop.
<PathTear Message> ::= <Common Header> <SESSION> <RSVP_HOP> 3.1.7 Confirmation Messages
[ <INTEGRITY> ]
<sender descriptor> RACK messages are sent to (probabilistically) acknowledge
reservation requests. A RACK message is sent as the result of
the appearance of a RESV_CONFIRM object in a RESV message.
<sender descriptor> ::= (see earlier definition) A RACK message is sent to the unicast address of a receiver
host; the address is obtained from the RESV_CONFIRM object.
However, a RACK message is forwarded to the receiver hop-by-
hop, to accommodate the hop-by-hop integrity check mechanism.
<ResvTear Message> ::= <Common Header> <SESSION> <RSVP_HOP> <ResvConf Message> ::= <Common Header> <SESSION>
[ <INTEGRITY> ] [ <SCOPE> ] <ERROR_SPEC>
<RESV_CONFIRM>
<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 The RESV_CONFIRM object is a copy of that object in the RESV
a RTEAR message will be ignored and may be omitted. message that triggered the confirmation. The ERROR_SPEC is
used only to carry the IP address of the originating node, in
Note that, unless it is accidentally dropped along the way, a the Error Node Address; the Error Code and Value are zero to
PTEAR message will reach all the receivers down stream from its indicate a confirmation. The object order requirements within
origination. On the other hand, a RTEAR message will cease to the flow descriptor list are the same as those given earlier
be forwarded at the same node where merging suppresses for a RESV message.
forwarding of the corresponding RESV messages. In each node N
along the way, if the RTEAR message causes the removal of all
state for this session, N will create a new teardown message to
be propagated further upstream; otherwise, the RTEAR message
may result in the immediate forwarding of a modified RESV
refresh message.
Deletion of path state as the result of a PTEAR message or a
timeout may force adjustments in related reservation state, to
maintain state consistency in the local node. The adjustment
in reservation state depends upon the style. For example,
suppose a PTEAR deletes the path state for a sender S. If the
style specifies explicit sender selection (FF or SE), delete
any reservation with a filter spec matching S; otherwise, the
style is wildcard sender selection (WF) and the reservation
should be deleted if S is the last sender to the session.
These reservation changes should not trigger an immediate RESV
refresh message, since the PTEAR message have already made the
required changes upstream. However, at the node in which a
RTEAR message stops, the change of reservation state may
trigger a RESV refresh starting at that node.
3.2 Sending RSVP Messages 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 packets with protocol number 46. Raw IP packets are "raw" IP packets with protocol number 46. Raw IP packets are
intended to be used between an end system and the first/last hop intended to be used between an end system and the first/last hop
router, although it is also possible to encapsulate RSVP messages router, although it is also possible to encapsulate RSVP messages
as UDP datagrams for end-system communication, as described in as UDP datagrams for end-system communication, as described in
Appendix C. UDP encapsulation is needed for systems that cannot Appendix C. UDP encapsulation is needed for systems that cannot
do raw network I/O. do raw network I/O.
PATH, PTEAR, and RACK messages must be sent with the Router Alert PATH, PTEAR, and RACK messages must be sent with the Router Alert
IP option [Katz95] in their IP headers. This option may be used 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 in the fast forwarding path of a high-speed router to detect
datagrams that require special processing. 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 immediately. However, this node must forward the modified state immediately. However, this
must not trigger sending an message out the interface through must not trigger sending an message out the interface through
which M arrived (as could happen if the implementation simply which M arrived (as could happen if the implementation simply
triggered an immediate refresh of all state for the session). triggered an immediate refresh of all state for the session).
This rule is necessary to prevent packet 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 can reassembled before it can be processed. The refresh period R can
be used as an appropriate reassembly timeout time. be used as an appropriate reassembly timeout time.
Since RSVP messages are normally generated and sent hop-by-hop, Between adjacent RSVP-capable routers, RSVP-level fragmentation
using the RSVP-level fragmentation mechanism should avoid further mechanism should normally be used in lieu of fragmentation at the
fragmentation at the IP level. However, IP fragmentation may IP level. However, IP-level fragmentation may still occur when
still occur when RSVP messages travel through a non-RSVP cloud. RSVP messages travel through a non-RSVP cloud. In case of IP6,
In case of IP6, which does not support IP fragmentation at which does not support IP fragmentation at routers, an RSVP
routers, an RSVP implementation must use Path MTU Discovery or implementation must use Path MTU Discovery or hand configuration
hand configuration to obtain an appropriate MTU between adjacent to obtain an appropriate MTU between adjacent RSVP neighbors.
RSVP neighbors.
RSVP recovers from occasional packet losses by its periodic RSVP uses its periodic refresh mechanisms to recover from
refresh mechanism. Under network overload, however, substantial occasional packet losses. Under network overload, however,
losses of RSVP messages could cause a failure of resource substantial losses of RSVP messages could cause a failure of
reservations. To control the queueing delay and dropping of RSVP resource reservations. To control the queueing delay and dropping
packets, routers should be configured to offer them a preferred of RSVP packets, routers should be configured to offer them a
class of service. If RSVP packets experience noticeable losses preferred class of service. If RSVP packets experience noticeable
when crossing a congested non-RSVP cloud, a larger value can be losses when crossing a congested non-RSVP cloud, a larger value
used for the timeout factor K (see section 3.5 below). can be used for the timeout factor K (see section 3.6 below).
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 run through multicast tunnels in physical interfaces. RSVP can run through multicast tunnels in
the following manner: the following manner:
skipping to change at page 45, line 33 skipping to change at page 46, line 51
o RERR Messages o RERR Messages
RERR messages for WF style reservations may loop for RERR messages for WF style reservations may loop for
essentially the same reasons that RESV messages loop. essentially the same reasons that RESV messages loop.
o RACK Messages o RACK Messages
RACK messages are forwarded towards a fixed unicast receiver RACK messages are forwarded towards a fixed unicast receiver
address and cannot loop. address and cannot loop.
If the topology has no loops, then looping of "wildcard" RESV and If the topology has no loops, then looping of RESV and RERR
RERR messages, i.e., messages with wildcard sender selection, can messages with wildcard sender selection can be avoided by simply
be avoided by simply enforcing the rule given earlier: state that enforcing the rule given earlier: state that is received through a
is received through a particular interface must never be forwarded particular interface must never be forwarded out the same
out the same interface. However, when the topology does have interface. However, when the topology does have cycles, further
cycles, further effort is needed to prevent auto-refresh loops of effort is needed to prevent auto-refresh loops of wildcard RESV
wildcard RESV messages and fast loops of wildcard RERR messages. messages and fast loops of wildcard RERR messages. The solution
The solution to this problem adopted by this protocol to this problem adopted by this protocol specification is for such
specification is for such messages to carry an explicit sender messages to carry an explicit sender address list in a SCOPE
address list in a SCOPE object. object.
When a RESV message with WF style is to be forwarded to a When a RESV message with WF style is to be forwarded to a
particular previous hop, a new SCOPE object is computed from the particular previous hop, a new SCOPE object is computed from the
SCOPE objects that were received in matching RESV messages. If SCOPE objects that were received in matching RESV messages. If
the computed SCOPE object is empty, the message is not forwarded the computed SCOPE object is empty, the message is not forwarded
to the previous hop; otherwise, the message is sent containing the to the previous hop; otherwise, the message is sent containing the
new SCOPE object. The rules for computing a new SCOPE object for new SCOPE object. The rules for computing a new SCOPE object for
a RESV message are as follows: 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
skipping to change at page 47, line 48 skipping to change at page 48, line 48
The following rules are used for SCOPE objects in RERR messages The following rules are used for SCOPE objects in RERR messages
with WF style: 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
3.1.5. However, the RERR message forwarded out OI must 3.1.6. 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.
3.4 Local Repair 3.4 Blockade State
The basic rule for creating a RESV refresh message is to merge the
flowspecs of the reservation requests in place in the node, by
computing their LUB. However, this rule is modified by the
existence of "blockade state" resulting from RERR messages, to
solve the KR-II problem (Section 2.6). The blockade state also
enters into the routing of RERR messages for Admission Control
failure.
When a RERR message for an Admission Control failure is received,
its flowspec Qe is used to create or refresh an element of local
blockade state. Each element of blockade state consists of a
blockade flowspec Qb taken from the flowspec of the last RERR, and
an associated blockade timer Tb. When the blockade timer expires,
the blockade state is deleted.
The granularity of blockade state depends upon the style of the
RERR message that created it. For an explicit style, there may be
a blockade state element (Qb(S),Tb(S)) for each sender S. For a
wildcard style, blockade state is per previous hop P.
An element of blockade state with flowspec Qb is said to
"blockade" a reservation with flowspec Qi if Qb is not (strictly)
greater than Qi. For example, suppose that the LUB of two
flowspecs is computed by taking the max of each of their
corresponding components. Then Qb blockades Qi if for some
component j, Qb[j] <= Qi[j].
Suppose that a node receives a RERR message from previous hop P
(or, if style is explicit, sender S) as the result of an Admission
Control failure upstream. Then:
1. An element of blockade state is created for P (or S) if it
did not exist.
2. Qb(P) (or Qb(S)) is set equal to the flowspec Qe from the
RERR message.
3. A corresponding blockade timer Tb(P) (or Tb(S)) is started or
restarted for a time Kb*R. Here Kb is a fixed multiplier and
R is the refresh interval for reservation state. Kb should
be configurable.
4. If there is some local reservation state that is not
blockaded (see below), an immediate reservation refresh for P
(or S) is generated.
5. The RERR message is forwarded to next hops in the following
way. If the InPlace bit is off, the RERR message is
forwarded to all next hops for which there is reservation
state. If the InPlace bit is on, the RERR message is
forwarded only to the next hops whose Qi is blockaded by Qb.
Finally, we present the modified rule for merging flowspecs to
create a reservation refresh message.
o If there are any local reservation requests Qi that are not
blockaded, these are merged by computing their LUB. The
blockaded reservations are ignored; this allows forwarding of
a smaller reservation that has not failed and may perhaps
succeed, after a larger reservation fails.
o Otherwise (all local requests Qi are blockaded), they are
merged by taking the GLB (Greatest Lower Bound) of the Qi's.
This refresh merging algorithm is applied separately to each flow
(each sender or PHOP) contributing to a shared reservation (WF or
SE style).
Figure 12 shows an example of the the application of blockade
state for a shared reservation (WF style). There are two previous
hops labelled (a) and (b), and two next hops labelled (c) and (d).
The larger reservation 4B arrived from (c) first, but it failed
somewhere upstream via PHOP (a), but not via PHOP (b). The
figures show the final "steady state" after the smaller
reservation 2B subsequently arrived from (d). This steady state
is perturbed roughly every Kb*R seconds, when the blockade state
times out. The next refresh then sends 4B to previous hop (a);
presumably this will fail, sending a RERR message that will re-
establish the blockade state, returning to the situation shown in
the figure. At the same time, the RERR message will be forwarded
to next hop (c) and to all receivers downstream responsible for
the 4B reservations.
Send Blockade| Reserve Receive
State|
|
| ________
(a) <- WF(*{2B}) {4B} | | * {4B} | WF(*{4B}) <- (c)
| |________|
|
---------------------------|-------------------------------
|
| ________
(b) <- WF(*{4B}) (none)| | * {2B} | WF(*{2B}) <- (d)
| |________|
Figure 12: Blockading with Shared Style
3.5 Local Repair
When a route changes, the next PATH or RESV refresh message will When a route changes, the next PATH or RESV refresh message will
establish path or reservation state (respectively) along the new establish path or reservation state (respectively) along the new
route. To provide fast adaptation to routing changes without the route. To provide fast adaptation to routing changes without the
overhead of short refresh periods, the local routing protocol overhead of short refresh periods, the local routing protocol
module can 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 a quick refresh of state for these destinations, using the trigger a quick refresh of state for these destinations, using the
new route. new route.
More specifically, the rules are as follows: The specific 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 destination G, RSVP should wait for a short interfaces for destination G, RSVP should wait for a short
period W, and then send PATH refreshes for all sessions G/* period W, and then send PATH refreshes for all sessions G/*
(i.e., for any session with destination G, regardless of (i.e., for any session with destination G, regardless of
destination port). destination port).
The short wait period before sending PATH refreshes is to The short wait period before sending PATH refreshes is to
allow the routing protocol getting settled with the new allow the routing protocol getting settled with the new
change(s), and the exact value for W should be chosen change(s), and the exact value for W should be chosen
accordingly. Currently W = 2 sec is suggested; however, this accordingly. Currently W = 2 sec is suggested; however, this
value should be configurable per interface. 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.
3.5 Time Parameters 3.6 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
generation of successive refreshes for the state by the neighbor generation of successive refreshes for the state by the neighbor
node, and the local state's lifetime L. Each RSVP RESV or PATH node, and the local state's lifetime L. Each RSVP RESV or PATH
message may contain a TIME_VALUES object specifying the R value message may contain a TIME_VALUES object specifying the R value
that was used to generate this (refresh) message. This R value is that was used to generate this (refresh) message. This R value is
then used to determine the value for L when the state is received 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. and stored. The values for R and L may vary from hop to hop.
skipping to change at page 49, line 41 skipping to change at page 53, line 10
changes, a smaller R speeds up adaptation to routing changes, changes, a smaller R speeds up adaptation to routing changes,
while increasing the RSVP overhead. With local repair, a while increasing the RSVP overhead. With local repair, a
router can be more relaxed about R since the periodic refresh router can be more relaxed about R since the periodic refresh
becomes only a backstop robustness mechanism. A node may becomes only a backstop robustness mechanism. A node may
therefore adjust the effective R dynamically to control the therefore adjust the effective R dynamically to control the
amount of overhead due to refresh messages. amount of overhead due to refresh messages.
The current suggested default for R is 30 seconds. However, The current suggested default for R is 30 seconds. However,
the default should be configurable per interface. the default should be configurable per interface.
5. When R is changed dynamically, there is a limit to how fast 5. When R is changed dynamically, there is a limit on how fast
it may increase. Specifically, the ratio of two successive it may increase. Specifically, the ratio of two successive
values R2/R1 must not exceed 1 + Slew.Max. 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. The values of Rdef, K, and Slew.Max used in an implementation 7. The values of Rdef, K, and Slew.Max used in an implementation
should be easily modifiable per interface, as experience may should be easily modifiable per interface, as experience may
lead to different values. The possibility of dynamically lead to different values. The possibility of dynamically
adapting K and/or Slew.Max in response to measured loss rates adapting K and/or Slew.Max in response to measured loss rates
is for future study. is for future study.
3.6 Traffic Policing and TTL 3.7 Traffic Policing and Non-Integrated Service Hops
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 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 (1) the edge of the network, (2) a merging point for data from
multiple senders, and/or (3) a branch point where traffic flow multiple senders, and/or (3) a branch point where traffic flow
from upstream may be greater than the downstream reservation. from upstream may be greater than the downstream reservation being
RSVP knows where such points occur and must so indicate to the requested. RSVP knows where such points occur and must so
traffic control mechanism. On the other hand, RSVP does not indicate to the traffic control mechanism. On the other hand,
interpret the service embodied in the flowspec and therefore does RSVP does not interpret the service embodied in the flowspec and
not know whether policing will actually be applied in any therefore does not know whether policing will actually be applied
particular case. in any particular case.
The RSVP daemon passes to traffic control a separate policing flag The RSVP daemon passes to traffic control a separate policing flag
for each of these three situations. for each of these three situations.
o E_Police_Flag -- Entry Policing o E_Police_Flag -- Entry Policing
This flag is set in the first-hop RSVP node that implements This flag is set in the first-hop RSVP node that implements
traffic control (and is therefore capable of policing). traffic control (and is therefore capable of policing).
For example, sender hosts must implement RSVP but currently For example, sender hosts must implement RSVP but currently
many of them do not implement traffic control. In this case, many of them do not implement traffic control. In this case,
the E_Police_Flag should be off in the sender host, and it 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 should only be set on when the first node capable of traffic
control is reached. This is controlled by the E_Police flag control is reached. This is controlled by the E_Police flag
in SESSION objects. in SESSION objects.
o M_Police_Flag -- Merge Policing o M_Police_Flag -- Merge Policing
This flag should be set on for a reservation using a shared This flag should be set on for a reservation using a shared
style (WF or SE) when flows from more than one sender are style (WF or SE) when flows from more than one sender are
being merged. being merged.
o B_Police_Flag -- Branch Policing o B_Police_Flag -- Branch Policing
This flag should be set on when the flowspec being installed This flag should be set on when the flowspec being installed
is smaller than, or incomparable to, a FLOWSPEC in place on is smaller than, or incomparable to, a FLOWSPEC in place on
any other interface, for the same FILTER_SPEC and SESSION. any other interface, for the same FILTER_SPEC and SESSION.
RSVP must also detect and report to receivers the presence of RSVP must also detect and report to receivers the presence of
non-RSVP hops in the path. For this purpose, an RSVP daemon must non-RSVP (which implies non-integrated-service compliant) hops in
place into each PATH message that it sends the value of the IP TTL the path. For this purpose, an RSVP daemon sets the Non_RSVP flag
with which the message was sent. The RSVP-capable node that bit in SESSION object of PATH messages. With normal IP
receives this message compares this field to the TTL with which forwarding, RSVP can detect a non-RSVP hop by comparing the IP TTL
the message was actually received, and if they differ it turns on with which a PATH message is sent to the TTL with which it is
the Non_RSVP flag. This flag is carried forward to receivers in received, and set the Non_RSVP bit on. For this purpose, the
the ADSPEC [??]. transmission TTL is placed in the common header.
3.7 Multihomed Hosts However, the TTL is not always a reliable indicator of non-RSVP
hops, and other means must be used. For example, if the routing
protocol uses IP encapsulating tunnels, then the routing protocol
must inform RSVP when non-RSVP hops are included. If no automatic
mechanism will work, manual configuration will be required.
Finally, there may still be cases where an RSVP cannot reliably
determine whether or not a non-RSVP hop was used. To report this
to the receiver, the SESSION object carries another flag bit,
Maybe_RSVP.
3.8 Multihomed Hosts
Accommodating multihomed hosts requires some special rules in Accommodating multihomed hosts requires some special rules in
RSVP. We use the term `multihomed host' to cover both hosts (end RSVP. We use the term `multihomed host' to cover both hosts (end
systems) with more than one network interface [could ref. section systems) with more than one network interface [could ref. section
3.3.4 of RFC-1122], and routers that are supporting local 3.3.4 of RFC-1122], and routers that are supporting local
application programs. application programs.
An application executing on a multihomed host may explicitly An application executing on a multihomed host may explicitly
specify which interface any given flow will use for sending and/or specify which interface any given flow will use for sending and/or
for receiving data packets, to override the system-specified for receiving data packets, to override the system-specified
default interface. The RSVP daemon must be aware of the default, default interface. The RSVP daemon must be aware of the default,
and if an application sets a specific interface, it must also pass and if an application sets a specific interface, it must also pass
that information to RSVP. that information to RSVP.
o Sending Data o Sending Data
A sender application uses an API call (SENDER in Section A sender application uses an API call (SENDER in Section
3.9.1) to declare to RSVP the characteristics of the data 3.10.1) to declare to RSVP the characteristics of the data
flow it will originate. This call may optionally include the flow it will originate. This call may optionally include the
local IP address of the sender. If it is set by the local IP address of the sender. If it is set by the
application, this parameter must be the interface address for application, this parameter must be the interface address for
sending the data packets; otherwise, the system default sending the data packets; otherwise, the system default
interface is implied. interface is implied.
The RSVP daemon on the host then sends PATH messages for this The RSVP daemon on the host then sends PATH messages for this
application out the specified interface (only). application out the specified interface (only).
o Making Reservations o Making Reservations
A receiver application uses an API call (called RESERVE in A receiver application uses an API call (RESERVE in Section
Section 3.9.1) to request a reservation from RSVP. This call 3.10.1) to request a reservation from RSVP. This call may
may optionally include the local IP address of the receiver, optionally include the local IP address of the receiver,
i.e., the interface address for receiving data packets. In i.e., the interface address for receiving data packets. In
the case of multicast sessions, this is the interface on the case of multicast sessions, this is the interface on
which the group has been joined. If the parameter is which the group has been joined. If the parameter is
omitted, the system default interface is used. omitted, the system default interface is used.
In general, the RSVP daemon should send RESV messages for In general, the RSVP daemon should send RESV messages for an
application out the specified interface. However, when the application out the specified interface. However, when the
application is executing on a router and the session is application is executing on a router and the session is
multicast, a more complex situation arises. Suppose in this multicast, a more complex situation arises. Suppose in this
case that a receiver application joins the group on an case that a receiver application joins the group on an
interface Iapp that differs from Isp, the shortest-path interface Iapp that differs from Isp, the shortest-path
interface to the sender. Then there are two possible ways interface to the sender. Then there are two possible ways
for multicast routing to deliver data packets to the for multicast routing to deliver data packets to the
application. The RSVP daemon must determine which case holds application. The RSVP daemon must determine which case holds
by examining the path state, to decide which incoming by examining the path state, to decide which incoming
interface to use for sending RESV messages. interface to use for sending RESV messages.
skipping to change at page 52, line 37 skipping to change at page 56, line 11
Note that it is possible for the path state blocks for Note that it is possible for the path state blocks for
Isp and Iapp to have the same next hop, if there is an Isp and Iapp to have the same next hop, if there is an
intervening non-RSVP cloud. intervening non-RSVP cloud.
2. The multicast routing protocol may forward data within 2. The multicast routing protocol may forward data within
the router from Isp to Iapp. In this case, Iapp will the router from Isp to Iapp. In this case, Iapp will
appear in the list of outgoing interfaces of the path appear in the list of outgoing interfaces of the path
state for Isp, and the RESV message should be sent out state for Isp, and the RESV message should be sent out
Isp. Isp.
3.8 Future Compatibility 3.9 Future Compatibility
We may expect that in the future new object C-Types will be We may expect that in the future new object C-Types will be
defined for existing object classes, and perhaps new object defined for existing object classes, and perhaps new object
classes will be defined. It will be desirable to employ such new classes will be defined. It will be desirable to employ such new
objects within the Internet using older implementations that do objects within the Internet using older implementations that do
not recognize them. Unfortunately, this is only possible to a not recognize them. Unfortunately, this is only possible to a
limited degree with reasonable complexity. The rules are as limited degree with reasonable complexity. The rules are as
follows. follows (`b' represents a bit).
1. Unknown Class 1. Unknown Class
There are two possible ways that an RSVP implementation can There are three possible ways that an RSVP implementation can
treat an object with unknown class. This choice is treat an object with unknown class. This choice is
determined by the high-order bit of the Class-Num octet, as determined by the two high-order bits of the Class-Num octet,
follows. as follows.
o Class-Num >= 128 o Class-Num = 0bbbbbbb
In this case, the entire message should be rejected and The entire message should be rejected and an "Unknown
an "Unknown Object Class" error returned. Object Class" error returned.
o Class-Num < 128 o Class-Num = 10bbbbbb
In this case, the node should ignore the object but The node should ignore the object, neither forwarding it
forward it, unexamined and unmodified, in all messages nor sending an error message.
resulting from the state contained in this message.
For example, suppose that a RESV message that is o Class-Num = 11bbbbbb
received contains an object of unknown class. Such an
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 number 11bbbbbb. Such an
object should be saved in the reservation state without object should be saved in the reservation state without
further examination; however, only the latest object further examination; however, only the latest object with a
with a given (unknown class, C-Type) pair should be given (unknown class, C-Type) pair should be saved. When a
saved. When a RESV message is forwarded, it should RESV message is forwarded, it should include copies of such
include copies of such saved unknown-class objects from saved unknown-class objects from all reservations that are
all reservations that are merged to form the new RESV merged to form the new RESV message.
message.
Note that objects with unknown class cannot be merged; Note that objects with unknown class cannot be merged;
however, unmerged objects may be forwarded until they however, unmerged objects may be forwarded until they reach a
reach a node that knows how to merge them. Forwarding node that knows how to merge them. Forwarding objects with
objects with unknown class enables incremental unknown class enables incremental deployment of new objects;
deployment of new objects; however, the scaling however, the scaling limitations of doing so must be
limitations of doing so must be carefully examined carefully examined before a new object class is deployed with
before a new object class is deployed with Class-Num < both high bits on.
128.
These rules should be considered when any new Class-Num is These rules should be considered when any new Class-Num is
defined. defined.
2. Unknown C-Type for Known Class 2. Unknown C-Type for Known Class
One might expect the known Class-Num to provide information One might expect the known Class-Num to provide information
that could allow intelligent handling of such an object. that could allow intelligent handling of such an object.
However, in practice such class-dependent handling is However, in practice such class-dependent handling is
complex, and in many cases it is not useful. complex, and in many cases it is not useful.
skipping to change at page 55, line 5 skipping to change at page 58, line 5
process until it runs out of alternatives or succeeds. process until it runs out of alternatives or succeeds.
Objects of certain classes (FLOWSPEC, ADSPEC, and Objects of certain classes (FLOWSPEC, ADSPEC, and
POLICY_DATA) are opaque to RSVP, which simply hands them to POLICY_DATA) are opaque to RSVP, which simply hands them to
traffic control or policy modules. Depending upon its traffic control or policy modules. Depending upon its
internal rules, either of the latter modules may reject a C- internal rules, either of the latter modules may reject a C-
Type and inform the RSVP daemon; RSVP should then reject the Type and inform the RSVP daemon; RSVP should then reject the
message and send an error, as described in the previous message and send an error, as described in the previous
paragraph. paragraph.
3.9 RSVP Interfaces 3.10 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).
3.9.1 Application/RSVP Interface 3.10.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 Session o Register Session
Call: SESSION( DestAddress , ProtocolId, DstPort , Call: SESSION( DestAddress , ProtocolId, DstPort ,
skipping to change at page 57, line 9 skipping to change at page 60, line 9
- 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.
o Reserve o Reserve
Call: RESERVE( session-id, [ receiver_address , ] Call: RESERVE( session-id, [ receiver_address , ]
[ ACK_flag, ] style, style-dependent-parms ) [ CONF_flag, ] style, style-dependent-parms )
A receiver uses this call to make or to modify a resource A receiver uses this call to make or to modify a resource
reservation for the session registered as `session-id'. 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 existing reservations may result in note that changing existing reservations may result in
admission control failure). admission control failures).
The optional `receiver_address' parameter may be used by a The optional `receiver_address' parameter may be used by a
receiver on a multihomed host (or router); it is the IP receiver on a multihomed host (or router); it is the IP
address of one of the node's interfaces. The ACK_flag address of one of the node's interfaces. The CONF_flag
should be set on if a reservation ACK is desired, off should be set on if a reservation confirmation is desired,
otherwise. The `style' parameter indicates the off otherwise. The `style' parameter indicates the
reservation style. The rest of the parameters depend upon reservation style. The rest of the parameters depend upon
the style, but generally these will include appropriate the style; generally these will include appropriate
flowspecs, filter specs, and possibly receiver policy data flowspecs, filter specs, and possibly receiver policy data
objects. 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 removes RSVP state for the session specified by This call removes RSVP state for the session specified by
session-id. The node then sends appropriate teardown session-id. The node then sends appropriate teardown
messages and ceases sending refreshes for this session-id. messages and ceases sending refreshes for this session-id.
o Error/Event Upcalls o Error/Event Upcalls
Upcall: <Upcall_Proc>( ) -> session-id, Info_type, The general form of a upcall is as follows:
[ Error_code , Error_value ,
Error_Node , LUB-Used, ]
List_count, [ Flowspec_list,] Upcall: <Upcall_Proc>( ) -> session-id, Info_type,
[ Filter_spec_list, ] [ Advert_list, ] information_parameters
[ Policy_data ]
Here "Upcall_Proc" represents the upcall procedure whose Here "Upcall_Proc" represents the upcall procedure whose
address was supplied in the SESSION call. address was supplied in the SESSION call. This upcall may
occur asynchronously at any time after a SESSION call and
before a RELEASE call, to indicate an error or an event.
This upcall may occur asynchronously at any time after a Currently there are five upcall types, distinguished by
SESSION call and before a RELEASE call, to indicate an the Info_type parameter. The selection of information
error or an event. Currently there are five upcall types, parameters depends upon the type.
distinguished by the Info_type parameter:
1. Info_type = Path Event 1. Info_type = PATH_EVENT
A Path Event upcall results from receipt of the first A Path Event upcall results from receipt of the first
PATH message for this session, indicating to a PATH message for this session, indicating to a
receiver application that there is at least one receiver application that there is at least one
active sender. active sender.
This upcall provides synchronizing information to the Upcall: <Upcall_Proc>( ) -> session-id,
receiver application, and it may also provide
parallel lists of senders (in Filter_spec_list),
traffic descriptions (in Flowspec_list), and service
advertisements (in Advert_list). `List_count' will
be the number in each list; where these objects are
missing, corresponding null objects must appear. The
Error_code, Error_value, LUB-Used flag, and
Policy_data parameters will be undefined in this
upcall.
2. Info_type = Resv Event Info_type=PATH_EVENT,
flags,
Sender_Tspec, Sender_Template,
[ , Advert ] [ , Policy_data ]
This upcall presents the Sender_Tspec and the
Sender_Template from a PATH message; it also passes
the advertisement and policy data if they are
present. The possible flags correspond to Non_RSVP
and Maybe_RSVP flags of the SESSION object.
2. Info_type = RESV_EVENT
A Resv Event upcall is triggered by the receipt of A Resv Event upcall is triggered by the receipt of
the first reservation message or by modification of a the first RESV message, or by modification of a
previous reservation state, for this session. previous reservation state, for this session.
`List_count' will be 1, and Flowspec_list will Upcall: <Upcall_Proc>( ) -> session-id,
contain one FLOWSPEC, the effective QoS that would be
applicable to the application itself.
Filter_spec_list and Advert_list will contain one
NULL object. The Error_code, Error_value, LUB-Used
flag, and Policy_data parameters will be undefined in
this upcall.
3. Info_type = Path Error Info_type=RESV_EVENT,
Style, Flowspec, Filter_Spec_list,
[ , Policy_data ]
Here `Flowspec' will be the effective QoS that has
been received. Note that an FF-style RESV message
may result in multiple RESV_EVENT upcalls, one for
each flow descriptor.
3. Info_type = PATH_ERROR
An Path Error event indicates an error in sender An Path Error event indicates an error in sender
information that was specified in a SENDER call. information that was specified in a SENDER call.
Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=PATH_ERROR,
Error_code , Error_value ,
Error_Node , Sender_Template,
[ Policy_data ]
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. The system-specific) data about the error. The
Error_Node parameter will specify the IP address of Error_Node parameter will specify the IP address of
the node that detected the error. the node that detected the error. The Policy_data
parameter, if present, will contain the POLICY_DATA
object from the failed PATH message.
`List_count' will be 1, and Filter_spec_list will 4. Info_type = RESV_ERR
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
will contain any POLICY_DATA objects in the PERR
message.
4. Info_type = Resv Error/Confirmation An Resv Error event indicates an error in a
reservation message to which this application
contributed.
An Resv Error/Confirmation event indicates an error Upcall: <Upcall_Proc>( ) -> session-id,
in a reservation message to which this application
contributed, or the receipt of a RACK message. The
Error_code parameter will define the error or
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 Info_type=RESV_ERROR,
FILTER_SPEC and FLOWSPEC objects from the error flow
descriptor (see Section 3.1.5). List_count will Error_code , Error_value ,
specify the number of FILTER_SPECS in
Filter_spec_list, while there will be one FLOWSPEC in Error_Node , Error_flags ,
Flowspec_list. For an error, the Policy_data
parameter will contain any POLICY_DATA objects in the Flowspec, Filter_spec_list,
RERR message.
[ Policy_data ]
The Error_code parameter will define the error and
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.
There are two Error_flags:
- InPlace
This flag may be on for an Admission Control
failure, to indicate that there was, and is, a
reservation in place at the failure node. This
flag is set at the failure point and forwarded
in RERR messages.
- NotGuilty
This flag may be on for an Admission Control
failure, to indicate that the flowspec requested
by this receiver was strictly less than the
flowspec that got the error. This flag is set
at the receiver API.
Filter_spec_list and Flowspec will contain the
corresponding objects from the error flow descriptor
(see Section 3.1.6). List_count will specify the
number of FILTER_SPECS in Filter_spec_list. The
Policy_data _list parameter will contain any
POLICY_DATA objects in the RERR message.
5. Info_type = RESV_CONFIRM
A Confirmation event indicates that a RACK message
was received.
Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=RESV_CONFIRM,
Style, List_count,
Flowspec, Filter_spec_list,
[ Policy_data ]
The parameters are interpreted as in the Resv Error
upcall.
Although RSVP messages indicating path or resv events may Although RSVP messages indicating path or resv events 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. All error and confirmation events reported changes. All error and confirmation events
should be reported to the application. should be reported to the application.
3.9.2 RSVP/Traffic Control Interface 3.10.2 RSVP/Traffic Control Interface
In an RSVP-capable node, 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.
o Make a Reservation o Make a Reservation
Call: Rhandle = TC_AddFlowspec( Interface, TC_Flowspec, Call: Rhandle = TC_AddFlowspec( Interface, TC_Flowspec,
TC_Tspec, E_Police_Flag, TC_Tspec, Police_Flags )
M_Police_Flag, B_Police_Flag )
The TC_Flowspec parameter defines the desired effective The TC_Flowspec parameter defines the desired effective
QoS to admission control; its value is computed as the QoS to admission control; its value is computed as the
maximum over the flowspecs of different next hops (see the maximum over the flowspecs of different next hops (see the
Compare_Flowspecs call below). It contains the effective Compare_Flowspecs call below). It contains the effective
reservation Tspec Resv_Te (although the RSVP daemon itself reservation Tspec Resv_Te (although the RSVP daemon itself
has no means to extract the Tspec). The TC_Tspec has no means to extract the Tspec). The TC_Tspec
parameter defines the effective sender Tspec Path_Te (see parameter defines the effective sender Tspec Path_Te (see
Section 2.3). We assume that traffic control takes the Section 2.3). We assume that traffic control takes the
min of Resv_Te and Path_Te (see step (4) in Section 2.3). GLB of Resv_Te and Path_Te (see step (4) in Section 2.3).
The Police_Flags parameter carries the three flags
E_Police_Flag, M_Police_Flag, and B_Police_Flag are E_Police_Flag, M_Police_Flag, and B_Police_Flag; see
Boolean parameters whose values should be set as described Section 3.7.
in Section 3.6.
The TC_AddFlowspec call returns an error code if Flowspec The TC_AddFlowspec call returns an error code if Flowspec
is malformed or if the requested resources are is malformed or if the requested resources are
unavailable. Otherwise, it establishes a new reservation unavailable. Otherwise, it establishes a new reservation
channel corresponding to Rhandle. It returns the opaque channel corresponding to Rhandle. It returns the opaque
number Rhandle for subsequent references to this number Rhandle for subsequent references to this
reservation. reservation.
o Modify Reservation o Modify Reservation
Call: TC_ModFlowspec( Rhandle, new_Flowspec, Call: TC_ModFlowspec( Interface, Rhandle, new_Flowspec,
Sender_Tspec, E_Police_flag,
M_Police_Flag, B_Police_Flag )
This call can modify an existing reservation. If Sender_Tspec, Police_flags )
new_Flowspec is included, it is passed to Admission This call is used to modify an existing reservation.
Control; if it is rejected, the current flowspec is left New_Flowspec is passed to Admission Control; if it is
in force. The corresponding filter specs, if any, are not rejected, the current flowspec is left in force. The
affected. The other parameters are defined as in corresponding filter specs, if any, are not affected. The
TC_AddFlowspec. other parameters are defined as in TC_AddFlowspec.
o Delete Flowspec o Delete Flowspec
Call: TC_DelFlowspec( Rhandle ) Call: TC_DelFlowspec( Interface, 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.
o Add Filter Spec o Add Filter Spec
Call: FHandle = TC_AddFilter( Rhandle, Session , FilterSpec ) Call: FHandle = TC_AddFilter( Interface, 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.
o Delete Filter Spec o Delete Filter Spec
Call: TC_DelFilter( FHandle ) Call: TC_DelFilter( Interface, 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.
o OPWA Update o OPWA Update
Call: TC_Advertise( interface, Adspec, Call: TC_Advertise( Interface, Adspec )
[ , Non_RSVP_flag ] ) -> New_Adspec -> 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.
o 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 preempt an existing
existing reservation. This might be reflected in an reservation. This might be reflected in an upcall to
upcall to RSVP, passing the RHandle of the preempted RSVP, passing the RHandle of the preempted reservation and
reservation, and some indication of the reason. a sub-code indicating the reason.
3.9.3 RSVP/Routing Interface 3.10.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 packet received for IP protocol 46 must be diverted to Packets received for IP protocol 46 but not addressed to
the RSVP program for processing, without being forwarded. the node must be diverted to the RSVP program for
On a router, the identity of the interface, real or processing, without being forwarded. On a router, the
virtual, on which it is received must also be available to identity of the interface, real or virtual, on which it is
the RSVP daemon. received must also be available to the RSVP daemon.
The RSVP messages to be diverted will carry the Router
Alert IP option, which can be used to pick them out of a
high-speed forwarding path. Alternatively, the node can
intercept all protocol 46 packets.
o Route Query o Route Query
To forward PATH and PTEAR messages, an RSVP daemon must be To forward PATH and PTEAR messages, an RSVP daemon must be
able to query the routing daemon(s) for routes. able to query the routing daemon(s) for routes.
Ucast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag ) Ucast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag )
-> OutInterface -> OutInterface
Mcast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag ) Mcast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag )
-> [ IncInterface, ] OutInterface_list -> [ IncInterface, ] OutInterface_list
Depending upon the routing protocol, the query may or may Depending upon the routing protocol, the query may or may
not depend upon SrcAddress, i.e., upon the sender host IP not depend upon SrcAddress, i.e., upon the sender host IP
address, which is also the IP source address of the address, which is also the IP source address of the
message. Here IncInterface is the interface through which message. Here IncInterface is the interface through which
the packet is expected to arrive; some multicast routing the packet is expected to arrive; some multicast routing
protocols may not provide it. protocols may not provide it. If the Notify_flag is True,
routing will save state necessary to issue unsolicited
If the Notify_flag is True, routing will save state route change notification callbacks (see below) whenever
necessary to issue unsolicited route change notification the specified route changes.
callbacks (see below) whenever the specified route
changes. Such callbacks will be enabled until routing
receives a route query call with the Notify_Flag set
False.
A multicast route query may return an empty A multicast route query may return an empty
OutInterface_list if there are no receivers downstream of OutInterface_list if there are no receivers downstream of
a particular router. A route query may also return a `No a particular router. A route query may also return a `No
such route' error, probably as a result of a transient such route' error, probably as a result of a transient
inconsistency in the routing (since a PATH or PTEAR inconsistency in the routing (since a PATH or PTEAR
message for the requested route did arrive at this node). message for the requested route did arrive at this node).
In either case, the local state should be updated as In either case, the local state should be updated as
requested by the message, although it cannot be forwarded requested by the message, which cannot be forwarded
further. Updating local state will make path state further. Updating local state will make path state
available immediately for a new local receiver, or it will available immediately for a new local receiver, or it will
tear down path state immediately. 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
the RSVP daemon that a specified route has changed. the RSVP daemon that a specified route has changed.
Ucast_Route_Change( ) -> DestAddress, OutInterface Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
OutInterface
Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress, Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
[ IncInterface, ] 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
skipping to change at page 63, line 41 skipping to change at page 67, line 51
o Source Address Specification o Source Address Specification
RSVP must be able to specify the IP source address to be RSVP must be able to specify the IP source address to be
used when sending PATH messages. used when sending PATH messages.
o Interface List Discovery 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.
3.9.4 Service-Dependent Manipulations It should be possible to logically disable an interface
for RSVP. When an interface is disabled for RSVP, a PATH
message should never be forwarded out that interface, and
if an RSVP message is received on that interface, the
message should be silently discarded (perhaps with local
logging).
3.10.4 Service-Dependent Manipulations
Flowspecs, Tspecs, and Adspecs are opaque objects to RSVP; Flowspecs, Tspecs, and Adspecs are opaque objects to RSVP;
their contents are defined in service specification documents. their contents are defined in service specification documents.
In order to manipulate these objects, RSVP daemon must have In order to manipulate these objects, RSVP daemon must have
available to it the following service-dependent routines. available to it the following service-dependent routines.
o Compare Flowspecs o Compare Flowspecs
Compare_Flowspecs( Flowspec_1, Flowspec_2 ) -> result_code Compare_Flowspecs( Flowspec_1, Flowspec_2 ) -> result_code
The possible result_codes indicate: flowspecs are equal, The possible result_codes indicate: flowspecs are equal,
Flowspec_1 is greater, Flowspec_2 is greater, flowspecs Flowspec_1 is greater, Flowspec_2 is greater, flowspecs
are incomparable but LUB can be computed, or flowspecs are are incomparable but LUB can be computed, or flowspecs are
incompatible. incompatible.
Note that comparing two flowspecs implicitly compares the Note that comparing two flowspecs implicitly compares the
Tspecs that are contained. Although the RSVP daemon Tspecs that are contained. Although the RSVP daemon
cannot itself parse a flowspec to extract the Tspec, it cannot itself parse a flowspec to extract the Tspec, it
skipping to change at page 64, line 22 skipping to change at page 68, line 37
Tspecs that are contained. Although the RSVP daemon Tspecs that are contained. Although the RSVP daemon
cannot itself parse a flowspec to extract the Tspec, it cannot itself parse a flowspec to extract the Tspec, it
can use the Compare_Flowspecs call to implicitly calculate can use the Compare_Flowspecs call to implicitly calculate
Resv_Te (see Section 2.3). Resv_Te (see Section 2.3).
o Compute LUB of Flowspecs o Compute LUB of Flowspecs
LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) -> LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
Flowspec_LUB Flowspec_LUB
o Compute GLB of Flowspecs
GLB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
Flowspec_GLB
o Compare Tspecs o Compare Tspecs
Compare_Tspecs( Tspec_1, Tspec_2 ) -> result_code Compare_Tspecs( Tspec_1, Tspec_2 ) -> result_code
The possible result_codes indicate: Tspecs are equal, or The possible result_codes indicate: Tspecs are equal, or
Tspecs are unequal. Tspecs are unequal.
o Sum Tspecs o Sum Tspecs
Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum
This call is used to compute Path_Te (see Section 2.3). This call is used to compute Path_Te (see Section 2.3).
4. Message Processing Rules 4. Message Processing Rules
skipping to change at page 65, line 9 skipping to change at page 70, line 9
o Sum Tspecs o Sum Tspecs
Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum
This call is used to compute Path_Te (see Section 2.3). This call is used to compute Path_Te (see Section 2.3).
4. Message Processing Rules 4. Message Processing Rules
This section provides a generic description of the rules for RSVP This section provides a generic description of the rules for RSVP
operation. It is intended to outline a set of algorithms that will operation. It is intended to outline a set of algorithms that will
accomplish the needed function. An actual implementation may use accomplish the needed function, omitting some details.
different but equivalent algorithms. This section assumes the
generic interface calls defined in Section 3.9 and the following data
structures. An actual implementation may use additional or different
data structures and interfaces.
[NOTE: This section is always the last to be updated when changes are This section assumes the generic interface calls defined in Section
made, and it is neither correct nor complete at the present time. 3.10 and the following data structures. An actual implementation may
Therefore, when this section disagrees with the rest of the text, you use additional or different data structures and interfaces. The data
should believe the rest of the text!] structure fields that a shown are required unless they are explicitly
labelled as optional.
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, defined by SESSION and SENDER_TEMPLATE objects, pair, defined by SESSION and SENDER_TEMPLATE objects,
respectively, received in a PATH message. respectively, received in a PATH message.
PSB contents include the following values from a PATH message: PSB contents include the following values from a PATH message:
- The previous hop IP address from a PHOP object (required) - Session
- LIH, the Logical Interface Handle from the previous hop, - Sender_Template
from a PHOP object (required).
- The remaining IP TTL (required) - Sender_Tspec
- SENDER_TSPEC (required) - The previous hop IP address and the Logical Interface
Handle (LIH) from a PHOP object
- The remaining IP TTL
- POLICY_DATA and/or ADSPEC objects (optional) - POLICY_DATA and/or ADSPEC objects (optional)
- Non_RSVP flag (required); see Section 3.6. - Non_RSVP and Maybe_RSVP flags; see Section 3.7.
- E_Police flag (Section 3.7)
- Local_Only flag (Section 3.8)
In addition, the PSB contains the following information provided In addition, the PSB contains the following information provided
by routing: OutInterface_list, the list of outgoing interfaces by routing: OutInterface_list, which is the list of outgoing
for this (sender, destination), and IncInterface, the expected interfaces for this (sender, destination), and IncInterface,
incoming interface. For a unicast destination, which is the expected incoming interface. For a unicast
OutInterface_list contains one entry and IncInterface is destination, OutInterface_list contains one entry and
undefined. IncInterface is undefined.
o RSB -- Reservation State Block o RSB -- Reservation State Block
Each RSB holds a reservation request that arrived in a Each RSB holds a reservation request that arrived in a
particular RESV message, corresponding to the triple: (session, particular RESV message, corresponding to the triple: (session,
next hop, filter_spec_list). Here "filter_spec_list" may be a next hop, Filter_spec_list). Here "Filter_spec_list" may be a
list of FILTER_SPECs (for SE style), a single FILTER_SPEC (FF list of FILTER_SPECs (for SE style), a single FILTER_SPEC (FF
style), or empty (WF style). We use the symbol "FILTER_SPEC*" style), or empty (WF style). We define a virtual object type
to indicate such a FILTER_SPEC list. "FILTER_SPEC*" for such a data structure.
RSB contents include: RSB contents include:
- Session specification
- Next hop IP address
- Filter_spec_list
- The outgoing (logical) interface OI on which the - The outgoing (logical) interface OI on which the
reservation is to be made or has been made (required). reservation is to be made or has been made (required).
- FLOWSPEC*, list of FLOWSPEC objects (required) - Style
- The style (required) - Flowspec
- A POLICY_DATA object (optional) - A POLICY_DATA object (optional)
- A SCOPE object (optional, depending on style) - A SCOPE object (optional, depending on style)
- A RESV_CONFIRM object (optional) - A RESV_CONFIRM object (optional)
o TCSB -- Traffic Control State Block o TCSB -- Traffic Control State Block
TCSB's hold the reservation specifications that have been handed Each TCSB holds the reservation specification that has been
to traffic control for specific outgoing interfaces. In handed to traffic control for a specific outgoing interface. In
general, information in TCSB's is derived from RSB's for the general, TCSB information is derived from RSB's for the same
same outgoing interface. Each TCSB defines a single reservation outgoing interface. Each TCSB defines a single reservation for
for a particular triple: (session, OI, filter_spec_list). TCSB a particular triple: (session, OI, Filter_spec_list). TCSB
contents include: contents include:
- Session
- OI
- Filter_spec_list
- TC_Flowspec, the effective flowspec, i.e., the maximum over - TC_Flowspec, the effective flowspec, i.e., the maximum over
the corresponding FLOWSPEC values from matching RSB's. the corresponding FLOWSPEC values from matching RSB's.
TC_Flowspec is passed to traffic control to make the actual TC_Flowspec is passed to traffic control to make the actual
reservation. The Tspec part of TC_Flowspec is the reservation. The Tspec part of TC_Flowspec is the
effective reservation Tspec Resv_Te (Section 2.3). effective reservation Tspec Resv_Te (Section 2.3).
- TC_Tspec, equal to the effective sender Tspec Path_Te. - TC_Tspec, equal to Path_Te, the effective sender Tspec.
- Police Flags - Police Flags
The flags E_Police_Flag, M_Police_Flag,and B_Police_Flag The flags E_Police_Flag, M_Police_Flag,and B_Police_Flag
are defined in Section 3.6. are defined in Section 3.7.
- Rhandle, F_Handle_list - Rhandle, F_Handle_list
Handles returned by the traffic control interface, Handles returned by the traffic control interface,
corresponding to the reservation (flowspec) and to the list corresponding to the reservation (flowspec) and to the list
of filter specs. of filter specs.
Boolean flags Path_Refresh_Needed, Resv_Refresh_Needed, and o BSB -- Blockade State Block
Tear_Needed will also be used in this section.
[LZ: It might be very helpful to have a short section to summarize Each BSB contains an element of blockade state. Depending upon
the management of all the timers.] the reservation style in use, the BSB's may be per (session,
sender_template) or per (session, PHOP). In practice, an
implementation might embed a BSB within a PSB; however, for
clarity we describe BSB's independently.
MESSAGE ARRIVES The contents of a BSB include:
Verify version number and checksum fields of common header, and - Session
discard message if any mismatch is found.
Reassemble a fragmented message. - Sender_Template (which is also a filter spec)
Parse the sequence of objects in the message to verify the length - PHOP
field of the common header; discard message if there is a mismatch.
- FLOWSPEC Qb
- Blockade timer Tb
The following other variables are also used in this section: Boolean
flags Path_Refresh_Needed, Resv_Refresh_Needed, Tear_Needed,
Need_Scope, B_Merge, and NeworMod, and Refresh_PHOP_list, a
variable-length list of PHOPs to be refreshed.
MESSAGE ARRIVES
Verify version number and RSVP checksum, and discard message if any
mismatch is found.
If the message type is not PATH or PTEAR and if the IP destination 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, address does not match any of the addresses of the local interfaces,
then forward the message to IP destination address and return. then forward the message to IP destination address and return.
Verify the INTEGRITY object, if any. If the check fails, discard the Verify the INTEGRITY object, if any. If the check fails, discard the
message and return. message and return.
Reassemble fragments of message.
Parse the sequence of objects in the message, and discard message if
any required objects are missing. Verify the length field of the
common header, and discard message if there is a mismatch.
Verify the consistent use of port fields. If the DstPort in the
SESSION object is zero but the SrcPort in a SENDER_TEMPLATE or
FILTER_SPEC object is non-zero, the the message has a "conflicting
source port" error; discard the message and return.
Further processing depends upon message type. Further processing depends upon message type.
PATH MESSAGE ARRIVES PATH MESSAGE ARRIVES
Process the sender descriptor object sequence in the message as Process the sender descriptor object sequence in the message as
follows. The flags Path_Refresh_Needed and Resv_Refresh_Needed follows. The Path_Refresh_Needed and Resv_Refresh_Needed flags
flags are initially off. are initially off.
o 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.
o If the DstPort in the SESSION object is zero but the o Search for a path state block (PSB) whose (session,
SrcPort in the SENDER_TEMPLATE object is non-zero, build a sender_template) pair matches the corresponding objects in
send a "Conflicting Src Port" PERR message, drop the PATH the message.
message, and return.
o Search for a path state block (PSB) whose (SESSION,
SENDER_TEMPLATE) pair matches the corresponding objects in
the message, considering any wildcard ports.
o If, during the PSB search, a PSB is found whose session o If, during the PSB search, a PSB is found whose session
matches the DestAddress and Protocol Id fields of the matches the DestAddress and Protocol Id fields of the
received SESSION object, but the DstPorts differ and one is received SESSION object, but the DstPorts differ and one is
zero, then build and send a "Conflicting Dst Port" PERR zero, then build and send a "Conflicting Dst Port" PERR
message, drop the PATH message, and return. message, drop the PATH message, and return.
o If, during the PSB search, a PSB is found with a matching o If, during the PSB search, a PSB is found with a matching
sender host (in SENDER_TEMPLATE) but the SrcPorts differ sender host but the SrcPorts differ and one of the SrcPorts
and one is zero, then build and send a "Ambiguous Path" is zero, then build and send an "Ambiguous Path" PERR
PERR message, drop the PATH message, and return. message, drop the PATH message, and return.
o If there was no matching PSB, then: o If there was no matching PSB, then:
1. Create a new PSB. 1. Create a new PSB.
2. Call the appropriate Route_Query routine, using 2. Copy contents of the SESSION, SENDER_TEMPLATE,
SENDER_TSPEC, and PHOP (IP address and LIH) objects
into the PSB.
3. Calculate initial routing information. If the sender
is from the local API, OutInterface_List is set to the
single interface whose address matches the sender
address, and IncInterface is undefined. Otherwise,
call the appropriate Route_Query routine, using
DestAddress from SESSION and (for multicast routing) DestAddress from SESSION and (for multicast routing)
SrcAddress from SENDER_TEMPLATE. Store the values of SrcAddress from SENDER_TEMPLATE. Store the values of
OutInterface_list and IncInterface into the PSB. 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 4. If IncInterface is defined and if a multicast message
arrived on an interface different from IncInterface, arrived on an interface different from IncInterface,
drop the message and return. turn on the Local_Only flag in the PSB.
4. Set a cleanup timer for the PSB. If this is the first
PSB for the session, set a refresh timer for the
session.
5. Copy contents of the SESSION, SENDER_TEMPLATE, 5. If this is the first PSB for the session, set a
SENDER_TSPEC, and PHOP (IP address and LIH) objects refresh timer for the session.
into the PSB. Store the received TTL into the PSB.
Copy into the PSB either of the following objects that
are present: POLICY_DATA and ADSPEC.
6. Turn on the Path_Refresh_Needed flag. 6. Turn on the Path_Refresh_Needed flag.
o Otherwise (there is a matching PSB and there is no dest o Otherwise (there is a matching PSB and there is no dest
port conflict): port conflict):
1. If there is no route change notification in place, 1. If there is no route change notification in place,
call the appropriate Route_Query routine using call the appropriate Route_Query routine using
DestAddress from SESSION and (for multicast routing) DestAddress from SESSION and (for multicast routing)
SrcAddress from SENDER_TEMPLATE. SrcAddress from Sender_Template.
- If the OutInterface_list that is returned differs - If the OutInterface_list that is returned differs
from that in the PSB, execute the PATH LOCAL from that in the PSB, then execute the PATH LOCAL
REPAIR event sequence below. REPAIR event sequence below.
- If a multicast message arrived on an interface - If a multicast message arrived on an interface
different from IncInterface, drop the message and different from IncInterface, then execute the
return. RESV REFRESH event sequence below for the
previous hop.
2. If the PHOP IP address, the LIH, or SENDER_TSPEC 2. If the PHOP IP address, the LIH, or Sender_Tspec
differs between the message and the PSB, copy the new differs between the message and the PSB, copy the new
value into the PSB, execute the RESV REFRESH event value into the PSB and turn on the Path_Refresh_Needed
sequence for the sender defined by the PSB, and turn flag.
on the Path_Refresh_Needed flag.
[LZ: [When] should ADSPEC change trigger a refresh?] o If the message contains an ADSPEC object, copy it into the
PSB.
However, if the PATH message being processed came from o Start or Restart the cleanup timer for the PSB.
a local application and if there is reservation state
for this session, then make a Resv Event upcall to
that application instead of executing the RESV REFRESH
sequence.
Call: <Upcall_Proc>( session-id, Resv Event, 1, o Copy E_Police flag from SESSION object into PSB.
{Flowspec}, NULL, NULL, NULL )
3. Restart the cleanup timer. o Store the received TTL into the PSB.
o If the message arrived with a TTL different from Send_TTL If the the received TTL differs from Send_TTL in the RSVP
in the RSVP common header, set the Non_RSVP flag on in the common header, set the Non_RSVP flag on in the PSB.
PSB.
o If the Path_Refresh_Needed flag is now set then: o The Path_Refresh_Needed flag is now set if the path state
is new or modified. If so:
1. If this PATH message came from a network interface and 1. If this PATH message came from a network interface and
not from a local application, make a Path Event upcall not from a local application, make a Path Event upcall
for each local application for this session: for each local application for this session:
Call: <Upcall_Proc>( session-id, Path Event, 1, Call: <Upcall_Proc>( session-id, PATH_EVENT,
{SENDER_TSPEC}, {SENDER_TEMPLATE}, flags, sender_tspec, sender_template,
{ADSPEC}, {POLICY_DATA} ) [ADSPEC], [POLICY_DATA] )
2. Execute the PATH REFRESH event sequence (below) for 2. Execute the PATH REFRESH event sequence (below) for
the sender defined by the PSB. the sender defined by the PSB.
3. If there is no reservation state for this SESSION
(i.e., no RSB's exist), then drop the PATH message and
return.
4. Otherwise (there is reservation state):
- Execute the event sequence UPDATE TRAFFIC CONTROL
below, to update the local traffic control state
if necessary. This will turn on the
Resv_Refresh_Needed flag if the traffic control
state changes; if so, execute the RESV REFRESH
event sequence (below) for the sender in the PSB.
However, if the PATH message came from a local
application, then make a RESV_EVENT upcall to
that application.
o Drop the PATH message and return.
PATH TEAR MESSAGE ARRIVES PATH TEAR MESSAGE ARRIVES
o Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair o Search for a PSB whose (Session, Sender_Template) pair
matches the corresponding objects in the message. If no matches the corresponding objects in the message. If no
matching PSB is found, drop the PTEAR message and return. matching PSB is found, drop the PTEAR message and return.
o Forward a copy of the PTEAR message to each outgoing o Forward a copy of the PTEAR message to each outgoing
interface listed in OutInterface_list of the PSB. interface listed in OutInterface_list of the PSB.
o Find each RSB that matches this PSB, i.e., whose o Find each RSB that matches this PSB, i.e., that whose
FILTER_SPEC object matches the SENDER_TEMPLATE in the PSB Filter_spec_list matches Sender_Template in the PSB and
and whose OI is included in OutInterface_list. whose OI is included in OutInterface_list.
If this RSB matches no other PSB, then tear down the RSB, If this RSB matches no other PSB, then tear down the RSB,
as described below under RESV TEAR MESSAGE ARRIVES. as described below under RESV TEAR MESSAGE ARRIVES.
o Delete the PSB. 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 Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair o Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair
matches the corresponding objects in the message. If no matches the corresponding objects in the message. If no
matching PSB is found, drop the PERR message and return. matching PSB is found, drop the PERR message and return.
o If the previous hop address in the PSB is the local API, o If the previous hop address in the PSB is the local API,
make an error upcall to the application: 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, Node_Addr, Error_code, Error_value,
0, 1, NULL, SENDER_TEMPLATE, Node_Addr, Sender_Template,
NULL, Policy_Data) [Policy_Data] )
Any POLICY_DATA, SENDER_TSPEC, or ADSPEC object in the Any SENDER_TSPEC or ADSPEC object in the message is
message is ignored. [LZ: Why we don't send these objects ignored.
up to application? They might of some help to understand
the errors.] Drop the PERR message and return.
o Otherwise, send a copy of the PERR message to the PHOP IP Otherwise, send a copy of the PERR message to the PHOP IP
address, drop the PERR message, and return. address.
o Drop the PERR message and return.
RESV MESSAGE ARRIVES RESV MESSAGE ARRIVES
Initially, the Resv_Refresh_PHOP* list is empty and the Initially, Refresh_PHOP_list is empty and the
Resv_Refresh_Needed flag is off. These variables are used to Resv_Refresh_Needed and NeworMod flags are off. These variables
control immediate reservation refreshes. are used to control immediate reservation refreshes.
o Process the NHOP object o Determine the Outgoing Interface OI
The logical outgoing interface OI is taken from the LIH in The logical outgoing interface OI is taken from the LIH in
the NHOP object. (If the physical interface is not implied the NHOP object. (If the physical interface is not implied
by the LIH, it can be learned from the interface matching by the LIH, it can be learned from the interface matching
the IP destination address). 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
wildcard reservation scope and this is the receiver host
itself.
[LZ: Explain this?]
o Check the S_POLICY_DATA object. o Check the S_POLICY_DATA object.
If there is an S_POLICY_DATA object in the message, check If there is an S_POLICY_DATA object in the message, check
permission to create a reservation for the session. If the permission to create a reservation for the session. If the
check fails, build and send an "Administrative rejection" check fails, build and send an "Administrative rejection"
RERR message, drop the RESV message, and return. RERR message, drop the RESV message, and return.
Otherwise, copy the S_POLICY_DATA object into the RSB. Otherwise, copy the S_POLICY_DATA object into the RSB.
Now process the STYLE object and the flow descriptor list to o Check for incompatible styles.
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 If any existing RSB for the session has a style that is
triple: (SESSION, NHOP, FILTER_SPEC*). Call this the incompatible with the style of the message, build and send
"active RSB". a RERR message specifying "Conflicting Style", drop the
RESV message, and return.
o If the RSB is not new and if its style is incompatible with Process the flow descriptor list to make reservations, as
the STYLE object in the message, build and send a RERR follows, depending upon the style. The following uses a filter
message specifying "Conflicting Style", drop the RESV spec list struct Filtss, of type FILTER_SPEC* (defined earlier).
message, and return.
o Start or restart the cleanup timer on the the active RSB. For FF style: execute the following steps independently for each
flow descriptor in the message, i.e., for each (FLOWSPEC,
Filtss) pair. Here the structure Filtss consists of the
FILTER_SPEC from the flow descriptor.
o If the active RSB is not new, check whether FLOWSPEC or For SE style, execute the following steps once for (FLOWSPEC,
SCOPE objects have changed. If not, continue with the next Filtss), with Filtss consisting of the list of FILTER_SPEC
flow descriptor in the RESV message, if any. objects from the flow descriptor.
o If the active RSB is new, set its OI and style, and copy For WF style, execute the following steps once for (FLOWSPEC,
any FLOWSPEC, POLICY_DATA, and/or SCOPE objects into it. Filtss), with Filtss an empty list.
o If there is a RESV_CONFIRM in the message, turn on o If the DstPort in the SESSION object is zero but the
Resv_Refresh_Needed and save the object in the RSB. SrcPort in a FILTER_SPEC object (in Filtss) is non-zero,
build nd send a "Conflicting Src Port" RERR message, drop
the RESV message, and return.
o The active RSB must be new or changed. Compute the traffic o Check the path state, as follows.
control parameters, using the following steps.
1. Locate the set of PSBs (senders) whose 1. Locate the set of PSBs (senders) whose
SENDER_TEMPLATEs match FILTER_SPEC* in the active RSB SENDER_TEMPLATEs match Filtss and whose
and whose OutInterface_list includes OI. OutInterface_list includes OI.
If this set is empty, build and send an error message If this set is empty, build and send an error message
specifying "No sender information", and continue with specifying "No sender information", and continue with
the next flow descriptor in the RESV message. the next flow descriptor in the RESV message.
2. If this set contains more than one PSB and if the 2. If the style has explicit sender selection (e.g., FF
style has explicit sender selection (e.g., FF or SE), or SE) and if any FILTER_SPEC included in Filtss
build and send an error message specifying "Ambiguous matches more than one PSB, build and send a RERR
filter spec" and continue with the next flow message specifying "Ambiguous filter spec" and
descriptor. continue with the next flow descriptor in the RESV
message.
3. Add the PHOP from the PSB to the Resv_Refresh_PHOP*
list, if the PHOP is not already on the list.
4. Set TC_E_Police_flag on if any of these PSBs have
their E_Police flag on. Set TC_M_Police_flag on if it
is a shared style and there is more than one PSB in
the set.
5. Compute Path_Te as the sum of the SENDER_TSPEC objects
in this set of PSBs.
6. Scan all RSB's matching the SESSION and
Filter_Spec_list from the message.
- If any of these RSB's has a style that is
incompatible with the specifying "Conflicting
Style", drop the RESV message, delete the RSB if
it has just been created, and return.
- Set TC_B_Police_flag on if TC_Flowspec is smaller
than, or incomparable to, any FLOWSPEC in those
RSB's.
7. Consider the set of RSB's for the same (SESSION, OI,
Filter_Spec_list) triple from the message.
- Compute the effective kernel flowspec,
TC_Flowspec, as the maximum of the FLOWSPEC
values in these RSB's.
- Compute the effective kernel filter spec (list),
TC_Filter*. by merging the FILTER_SPEC* object
(lists) from these RSB's.
o Search for a TCSB matching the triple (SESSION, OI,
FILTER_SPEC*), taken from the RSB.
1. If none is found but style is SE, search for a TCSB
matching (SESSION, OI). If find one and if TCSB's
TC_Flowspec, Path_Te, and police flags match the
computed values, then
- Make an appropriate set of TC_DelFilter and
TC_AddFilter calls to transform the
Filter_Spec_list in the TCSB into the
Filter_Spec_list from the message.
- Set Resv_Refresh_Needed on, drop the RESV
message, and return.
2. Otherwise, if none is found:
- Create a new TCSB.
- Store TC_Flowspec, Filter_Spec_list, Path_Te, and 3. Add the PHOP from the PSB to Refresh_PHOP_list, if the
the police flags into TCSB. PHOP is not already on the list.
[SCOPE?] o Find or create a reservation state block (RSB) for the
triple: (session, NHOP, Filtss). Call this the "active
RSB".
- Set Resv_Refresh_Needed on. o If the active RSB is new:
- Make the traffic control call: 1. Set the session, NHOP, OI and style of the RSB from
the message.
Rhandle = TC_AddFlowspec( OI, TC_flowspec, Path_Te, 2. Copy Filtss into the Filter_spec_list of the RSB.
TC_E_Police_flag, TC_M_Police_flag,
TC_B_Police_flag )
If this call fails, build and send a RERR message 3. Copy the FLOWSPEC and any SCOPE object from the
specifying "Admission control failed", and message into the RSB.
continue with the next flow descriptor.
Otherwise, record Rhandle in the TCSB.
- For each filter_spec F in Filter_Spec_list, call: 4. Set NeworMod flag on.
Fhandle = TC_AddFilter( Rhandle, SESSION, F) o Start or restart the cleanup timer on the the active RSB.
and record the returned Fhandle in the TCSB. o If there is a RESV_CONFIRM in the message, turn on
Resv_Refresh_Needed and save the object in the RSB.
- Continue with the next flow descriptor. o If the active RSB is not new, check whether STYLE, FLOWSPEC
or SCOPE objects have changed; if so, copy changed object
into RSB and turn on the NeworMod flag.
3. Otherwise (found existing TCSB), check whether o If NeworMod flag is off, continue with the next flow
TC_Flowspec, Path_Te, and/or any of the police flags descriptor in the RESV message, if any.
has changed, and if so:
- Store TC_Flowspec, Filter_Spec_list, Path_Te, and o Otherwise (the NeworMod flag is on, i.e., the active RSB is
the police flags into it. new or modified), execute the UPDATE TRAFFIC CONTROL event
sequence (below). If the result is to modify the traffic
control state, it will turn on the Resv_Refresh_Needed
flag.
[SCOPE?] o For any local sender, make an RESV_EVENT upcall to the
application:
- Set Resv_Refresh_Needed on. Call: <Upcall_Proc>( session-id, RESV_EVENT,
style, Flowspec, Filter_spec_list,
[POLICY_DATA] )
- Make the traffic control call: where the parameters come from the active RSB.
TC_ModFlowspec( Rhandle, K_Flowspec, Path_Te, o Continue with the next flow descriptor.
TC_E_Police_flag, TC_M_Police_flag,
TC_B_Police_flag )
4. Continue with the next flow descriptor. o When all flow descriptors have been processed, check the
Resv_Refresh_Needed flag. If it is now on, execute the
RESV REFRESH sequence (below) for each PHOP in
Refresh_PHOP_list.
o If the Resv_Refresh_Needed flag is now on, execute the RESV o Drop the RESV message and return.
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 is set to the IP address
the IP address of OI, and the message is sent unicast to NHOP. of OI, and the message is sent unicast to NHOP.
RESV TEAR MESSAGE ARRIVES RESV TEAR MESSAGE ARRIVES
A RTEAR message arrives with an IP destination address matching A RTEAR message arrives with an IP destination address matching
outgoing interface OI. Flags Tear_Needed and outgoing interface OI. Flags Tear_Needed and
Resv_Refresh_Needed are initially off and Resv_Refresh_PHOP* Resv_Refresh_Needed are initially off and Refresh_PHOP_list is
list is empty. empty.
o Process the STYLE object and the flow descriptor list in o Process the STYLE object and the flow descriptor list in
the RTEAR message to tear down local reservation state, as the RTEAR message to tear down local reservation state, as
follows. follows.
For FF style, execute the following steps for each b flow The following uses a filter spec list struct Filtss, of
descriptor, i.e., for each (FLOWSPEC, FILTER_SPEC) pair type FILTER_SPEC* (defined earlier).
independently, with Filter_Spec_list consisting of a single
FILTER_SPEC object.
For SE style, execute the following steps once, with
Filter_Spec_list consisting of a list of FILTER_SPEC
objects.
For WF style, execute the following steps once, with
Filter_Spec_list consisting of a single internal
placeholder "WILD_FILTER".
1. Find matching RSB for the 4-tuple: (SESSION, NHOP,
style, Filter_Spec_list); call this the active RSB.
If no active RSB is found, continue with next flow
descriptor.
2. Delete the active RSB.
3. Find TCSB for the triple: (SESSION, OI,
Filter_Spec_list).
4. Consider the set of RSB's matching this TCSB. If
there are none:
- Call the traffic control interface routine: For FF style: execute the following steps independently for
each flow descriptor in the message, i.e., for each
(FLOWSPEC, Filtss) pair. Here the structure Filtss
consists of the FILTER_SPEC from the flow descriptor.
TC_DelFlowspec( Rhandle ) For SE style, execute the following steps once for
(FLOWSPEC, Filtss), with Filtss consisting of the list of
FILTER_SPEC objects from the flow descriptor.
- Delete the TCSB and set Tear_Needed flag on. For WF style, execute the following steps once for
(FLOWSPEC, Filtss), with Filtss an empty list.
- Continue with the next flow descriptor. 1. Find matching RSB for the triple: (SESSION, NHOP,
Filtss); call this the active RSB. If no active RSB
is found, continue with next flow descriptor.
5. Otherwise (there are other RSB's for the same TCSB), 2. Delete the active RSB.
recompute TC_Flowspec and Path_Te (see RESV MESSAGE
ARRIVES). (This also adds the appropriate PHOP
addresses to the Resv_Refresh_PHOP* list>) If either
changed, update the TCSB, set flag Resv_Refresh_Needed
on, and call the traffic control interface module:
TC_ModFlowspec( Rhandle, TC_Flowspec, Path_Te) 3. Execute the event sequence UPDATE TRAFFIC CONTROL
TC_E_Police_flag, TC_M_Police_flag, (below) to update the traffic control state to be
TC_B_Police_flag ) consistent with the reservation state.
This kernel call should not fail, since the 4. Search for a TCSB remaining for the (session, OI,
reservation can only be reduced. Filtss) triple; if not, set the Tear_Needed flag on.
[LZ: Suppose receiver R has the credential to make the 5. Continue with the next flow descriptor.
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, o If Tear_Needed and Resv_Refresh_Needed flags are both off,
then drop the RTEAR message and return. then drop the RTEAR message and return.
o If Tear_Needed is off but Resv_Refresh_Needed is on, then o If Tear_Needed is off but Resv_Refresh_Needed is on, then
execute the RESV REFRESH sequence for each PHOP in the execute the RESV REFRESH sequence for each PHOP in
Resv_Refresh_PHOP* set, drop the RTEAR message, and return. Refresh_PHOP_list, drop the RTEAR message, and return.
o Otherwise (Tear_Needed is on), need to forward RTEAR and/or o Otherwise (Tear_Needed is on), need to forward RTEAR and/or
RESV refresh messages. RESV refresh messages.
Do the following for each PSB whose OutInterface_list Do the following for each PSB whose OutInterface_list
includes the outgoing interface OI: 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 the PSB, and do the whose FILTER_SPEC matches the PSB, and do the
following. following.
skipping to change at page 77, line 6 skipping to change at page 80, line 50
built. built.
- Otherwise (there is a matching RSB), note the PSB - Otherwise (there is a matching RSB), note the PSB
as needing a RESV refresh message and set the as needing a RESV refresh message and set the
Resv_Refresh_Needed flag True. Resv_Refresh_Needed flag True.
2. If the new RTEAR message contains any flow 2. If the new RTEAR message contains any flow
descriptors, send it to PHOP in the PSB. descriptors, send it to PHOP in the PSB.
o If the Resv_Refresh_Needed flag is now on, execute the RESV o If the Resv_Refresh_Needed flag is now on, execute the RESV
REFRESH sequence (below) for each PHOP in the REFRESH sequence (below) for each PHOP in
Resv_Refresh_PHOP* set. Refresh_PHOP_list.
If the Refresh_Needed flag is true, then execute the RESV
REFRESH sequence for the PSB's that have been noted.
o Drop the RTEAR message and return. o Drop the RTEAR message and return.
RESV ERROR MESSAGE ARRIVES RESV ERROR MESSAGE ARRIVES
A RERR message arrives through the (real) incoming interface A RERR message arrives through the (real) incoming interface
In_If. In_If.
o If there is no path state for SESSION, drop the RERR o If there is no path state for SESSION, drop the RERR
message and return. message and return.
o Do the following with each RSB for this SESSION whose OI o If the Error Code = 01 (Admission Control failure), do
does not match In_If and whose FILTER_SPEC matches that in special processing as follows:
the RERR message.
1. Copy the error flow descriptor from the incoming RERR 1. Find or create a Blockade State Block (BSB), in the
message. following style-dependent manner.
2. Compare the FLOWSPEC in the RERR message with the For WF (wildcard) style, there will be one BSB per
FLOWSPEC in the RSB. If they don't match along any (session, PHOP) pair.
coordinate (i.e., if the RSB FLOWSPEC is strictly
`smaller'), continue with the next RSB.
If they agree on some but not all coordinates, turn on For FF style, there will be one BSB per (session,
the LUB-used flag. filter_spec) pair. Note that an FF style RERR message
carries only one flow descriptor.
3. If NHOP in RSB is the local API, deliver an error For SE style, there will be one BSB per (session,
upcall to application: filter_spec), for each filter_spec contained in the
filter spec list of the flow descriptor.
Call: <Upcall_Proc>( session-id, Resv Error, 2. For each BSB in the preceding step, set (or replace)
Error_code, Error_value, Node_Addr, its FLOWSPEC Qb with FLOWSPEC from the message, and
LUB-Used, set (or reset) its timer Tb to Kb*R seconds [Section
3.4]. If the BSB is new, set its PHOP value, and set
its Sender_Template equal to the appropriate
filter_spec from the message.
3. Partially execute the RESV REFRESH event sequence
shown below, for the previous hop PHOP.
In particular, execute the refresh sequence with the
B_Merge flag off. If this results in no refresh
messages being generated, because all matching
reservations are blockaded, do not turn B_Merge on but
instead exit the refresh sequence and return here.
o For all RERR messages, execute the following for each RSB
for this session whose OI differs from In_If and whose
Filter_spec_list has at least one filter spec in common
with the FILTER_SPEC* in the RERR message. For WF style,
empty FILTER_SPEC* structures are assumed to match.
1. If Error_Code = 01 and the InPlace flag is 1 and one
or more of the BSB's found/created above has a Qb that
is strictly greater than Flowspec in the RSB, then
continue with the next matching RSB, if any.
2. If NHOP in the RSB is the local API, then:
- If the FLOWSPEC in the RERR message is strictly
greater than the RSB Flowspec, then turn on the
NotGuilty flag in the ERROR_SPEC.
- Deliver an error upcall to application:
Call: <Upcall_Proc>( session-id, RESV_ERROR,
Error_code, Error_value,
Node_Addr, Error_flags,
Flowspec, Filter_Spec_List, Flowspec, Filter_Spec_List,
NULL, NULL) [Policy_data] )
and continue with the next RSB. Here k, and continue with the next RSB.
Filter_Spec_List, and Flowspec_List are constructed
from the error flow descriptor.
4. If the RESV message has wildcard sender selection, use 3. If the style has wildcard sender selection, use the
its SCOPE object SC.In to construct a SCOPE object SCOPE object SC.In from the RERR message to construct
SC.Out to be forwarded. SC.Out should contain those a SCOPE object SC.Out to be forwarded. SC.Out should
sender addresses that appeared in SC.In and that route contain those sender addresses that appeared in SC.In
to OI [LIH?], as determined by scanning the PSB's. If and that route to OI [LIH?], as determined by scanning
SC.Out is empty, continue with the next RSB. the PSB's. If SC.Out is empty, continue with the next
RSB.
5. Create a new RERR message containing the error flow 4. Create a new RERR message containing the error flow
descriptor and send to the NHOP address specified by descriptor and send to the NHOP address specified by
the RSB. Include SC.Out if the sender selection is the RSB. Include SC.Out if the style has wildcard
wildcard. sender selection.
6. Continue with the next RSB. 5. Continue with the next RSB.
o Drop the RERR message and return. o Drop the RERR message and return.
RESV CONFIRMATION ARRIVES RESV CONFIRM ARRIVES
If the (unicast) IP address found in its RESV_CONFIRM object o If the (unicast) IP address found in the RESV_CONFIRM
matches an interface of the node, a confirmation upcall is made object in the RACK message matches an interface of the
to the matching application: node, a confirmation upcall is made to the matching
application:
Call: <Upcall_Proc>( session-id, Resv Confirm, Call: <Upcall_Proc>( session-id, RESV_CONFIRM,
Error_code, Error_value, Node_Addr, Error_code, Error_value, Node_Addr,
LUB-Used, nlist, Flowspec, LUB-Used, nlist, Flowspec,
Filter_Spec_List, NULL, NULL ) Filter_Spec_List, NULL, NULL )
Otherwise, the RACK message is forwarded immediately to the o Otherwise, the RACK message is forwarded immediately to the
address in the IP address in its RESV_CONFIRM object. address in the IP address in its RESV_CONFIRM object.
o Drop the RACK message and return.
UPDATE TRAFFIC CONTROL
The sequence is invoked by the PATH MESSAGE ARRIVES or the RESV
MESSAGE ARRIVES sequence, to (re-)calculate and adjust the local
traffic control state in accordance with the current reservation
and path state. If the result is to modify the traffic control
state, this sequence turns on the Resv_Refresh_Needed flag.
o Compute the traffic control parameters using the following
steps.
1. Consider the set of RSB's matching SESSION and OI from
the message.
- Compute the effective kernel flowspec,
TC_Flowspec, as the maximum/LUB of the FLOWSPEC
values in these RSB's.
- Compute the effective traffic control filter spec
(list) TC_Filter_Spec*, by merging the
Filter_spec_lists from these RSB's.
2. Scan all RSB's matching session and Filtss, for all
OI. Set TC_B_Police_flag on if TC_Flowspec is smaller
than, or incomparable to, any FLOWSPEC in those RSB's.
3. Locate the set of PSBs (senders) whose
SENDER_TEMPLATEs match Filter_spec_list in the active
RSB and whose OutInterface_list includes OI.
4. Set TC_E_Police_flag on if any of these PSBs have
their E_Police flag on. Set TC_M_Police_flag on if it
is a shared style and there is more than one PSB in
the set.
5. Compute Path_Te as the sum of the SENDER_TSPEC objects
in this set of PSBs.
o Search for a TCSB matching SESSION and OI; for distinct
style (FF), it must also match Filter_spec_list.
If none is found, create a new TCSB.
o If TCSB is new:
1. Store TC_Flowspec, TC_Filter_Spec*, Path_Te, and the
police flags into TCSB.
2. Turn the Resv_Refresh_Needed flag on and make the
traffic control call:
Rhandle = TC_AddFlowspec( OI, TC_Flowspec,
Path_Te, police_flags)
3. If this call succeeds, record Rhandle in the TCSB and,
for each filter_spec F in TC_Filter_Spec*, call:
Fhandle = TC_AddFilter( OI, Rhandle, Session, F)
and record the returned Fhandle in the TCSB.
4. Otherwise, build and send a RERR message specifying
"Admission control failed" and with the InPlace flag
off.
o If TCSB is not new but the TC_Flowspec, Path_Te, and/or
police flags just computed differ from corresponding values
in the TCSB, then:
1. Turn the Resv_Refresh_Needed flag on and make the
traffic control call:
TC_ModFlowspec( OI, Rhandle, TC_Flowspec,
Path_Te, police_flags )
2. If this call fails, build and send a RERR message
specifying "Admission control failed" and with the
InPlace bit on. If the call succeeds, update the TCSB
with the new values.
o If the TCSB is not new but the TC_Filter_Spec* just
computed differ from the FILTER_SPEC* in the TCSB, then:
1. Make an appropriate set of TC_DelFilter and
TC_AddFilter calls to transform the Filter_spec_list
in the TCSB into the new TC_Filter_Spec*.
o Return to the event sequence that invoked this one.
PATH REFRESH PATH REFRESH
This sequence sends a path refresh for a particular sender, This sequence sends a path refresh for a particular sender,
i.e., a PSB. This sequence may be entered by either the i.e., a PSB. This sequence may be entered by either the
expiration of the path refresh timer or directly as the result expiration of the path refresh timer or directly as the result
of the Path_Refresh_Needed flag being turned on during the of the Path_Refresh_Needed flag being turned on during the
processing of a received PATH message. processing of a received PATH message.
o Compute the IP TTL for the PATH message as one less than o Compute the IP TTL for the PATH message as one less than
the maximum of the TTL values from the senders included in the maximum of the TTL values from the senders included in
skipping to change at page 79, line 28 skipping to change at page 86, line 10
o Send a copy of the PATH message to each interface in o Send a copy of the PATH message to each interface in
OutInterfact_list. Before sending each copy, insert into OutInterfact_list. Before sending each copy, insert into
its PHOP object the interface address and the LIH for the its PHOP object the interface address and the LIH for the
interface. interface.
RESV REFRESH RESV REFRESH
This sequence sends a reservation refresh towards a particular This sequence sends a reservation refresh towards a particular
previous hop with IP address PH. This sequence may be entered previous hop with IP address PH. This sequence may be entered
by either the expiration of a reservation refresh timer or by either the expiration of a reservation refresh timer or
directly as the result of the Resv_Refresh_Needed flag being directly as a result of the Resv_Refresh_Needed flag being
turned on as the result of processing a RESV or RTEAR message. turned on by processing a RESV or RTEAR message.
In general, this sequence considers each of the PSB's with PHOP In general, this sequence considers each of the PSB's with PHOP
address PH. For a given PSB, it scans the RSBs for matching address PH. For a given PSB, it scans the RSBs for matching
reservations and merges the styles, FLOWSPECs and FILTER_SPEC*'s reservations and merges the styles, FLOWSPECs and
appropriately. It then builds a RESV message and sends it to Filter_spec_list's appropriately. It then builds a RESV message
PH. The details depend upon the attributes of the style(s) and sends it to PH. The details depend upon the attributes of
included in the reservations. the style(s) included in the reservations.
o If there are PSB's from more than one PHOP and if the o Create an output message containing INTEGRITY (if
multicast routing protocol does not use shared trees, set supported), SESSION, RSVP_HOP, and TIME_VALUES objects.
the Need_Scope flag on, otherwise set it off.
o Create an output message containing SESSION, RSVP_HOP, o Determine the style for these reservations from the first
INTEGRITY, and TIME_VALUES objects. RSB for the session, and move the STYLE object into the
proto-message. (Note that the present set of styles are
never themselves merged; if future styles can be merged,
these rules will become more complex).
o If style is wildcard and if there are PSB's from more than
one PHOP and if the multicast routing protocol does not use
shared trees, set the Need_Scope flag on, otherwise set it
off.
o Select each sender PSB whose PHOP has address PH. o Select each sender PSB whose PHOP has address PH.
1. Select all RSB's whose FILTER_SPEC*'s match the 1. Set local flag B_Merge off.
2. Select all RSB's whose Filter_spec_list's match the
SENDER_TEMPLATE object in the PSB and whose OI appears SENDER_TEMPLATE object in the PSB and whose OI appears
in the OutInterface_list of the PSB. in the OutInterface_list of the PSB.
2. Get a STYLE object from the first RSB and move it into 3. If B_Merge flag is off then ignore a blockaded RSB, as
the output message. (Note that the present set of follows.
styles are never themselves merged; if future styles
can be merged, these rules will become more complex).
3. Compute the maximum/LUB over the FLOWSPEC objects of - Select BSB's that match this RSB; if any of these
this set of RSB's. BSB's has a Qb that is not strictly larger than
RSB Flowspec, then continue processing with the
next RSB.
4. While computing the maximum/LUB, check for a However, if steps 1 and 2 result in finding that all
RESV_CONFIRM object in each RSB. If a RESV_CONFIRM RSB's matching this PSB are blockaded, then:
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.
- Include the RESV_CONFIRM object in the RACK - If this RESV REFRESH sequence was invoked from
message. RESV ERROR RECEIVED, then return now to the
latter.
- Build a confirmation ERROR_SPEC object and - Otherwise, turn on the B_Merge flag and restart
include it in the RACK message. The Error_Node with this procedure step 1. above.
parameter in this object should be the IP address
of OI from the RSB.
Then delete the RESV_CONFIRM object from the RSB. 4. Merge the flowspecs, as follows:
5. Merge the matching FILTER_SPEC objects from this set - If B_Merge flag is off, compute the LUB over the
of RSB's. The merging rule depend upon the style: Flowspec objects of this set of RSB's.
Explicit sender selection (FF, SE) styles: While computing the LUB, check for a RESV_CONFIRM
object in each RSB. If a RESV_CONFIRM object is
found:
Use the SENDER_TEMPLATE as the merged - If the FLOWSPEC in that RSB is larger than
FILTER_SPEC. all other (non-blockaded) flowspecs being
compared, then save this RESV_CONFIRM object
for forwarding.
Wildcard sender selection (WF) style: - Otherwise (the corresponding FLOWSPEC is not
the largest) then create and send a RACK
message containing the RESV_CONFIRM object
to the address in the RESV_CONFIRM object.
Include the RESV_CONFIRM object in the RACK
message. The RACK message should also
include an ERROR_SPEC object whose
Error_Node parameter is IP address of OI
from the RSB.
There is no filter spec to merge. - Then delete the RESV_CONFIRM object from the
RSB.
6. If the Need_Scope flag is on, compute a new SCOPE - Otherwise (B_Merge flag is on), compute the GLB
over the Flowspec objects of this set of RSB's.
While computing the GLB, check for a RESV_CONFIRM
object in each RSB. If one is found, delete it.
5. If the Need_Scope flag is on, compute a new SCOPE
object as the union of the SCOPE objects found in the object as the union of the SCOPE objects found in the
RSB's. RSB's.
7. Merge the F_POLICY_DATA objects from the RSB's. 6. Merge the F_POLICY_DATA objects from the RSB's.
8. (All matching RSB's have been processed). The next 7. (All matching RSB's have been processed). The next
step depends upon the style attributes. step depends upon the style attributes.
8. Merge the matching FILTER_SPEC objects from this set
of RSB's. For explicit sender selection (FF, SE)
styles, use the SENDER_TEMPLATE as the merged
FILTER_SPEC; for wildcard sender selection (WF) style,
there is no filter spec to be merged.
Distinct reservation (FF) style Distinct reservation (FF) style
Pack the merged (FLOWSPEC, FILTER_SPEC, Use the Sender_Template as the merged
F_POLICY_DATA) triplet into the message as a flow FILTER_SPEC. Pack the merged (FLOWSPEC,
descriptor. FILTER_SPEC, F_POLICY_DATA) triplet into the
message as a flow descriptor.
Shared reservation (SE, WF) styles Shared wildcard reservation (WF) style
Merge (take the maximum) across all PSB's the There is no merged FILTER_SPEC. Merge (take the
merged FLOWSPECS from the RSB's. maximum of) the merged FLOWSPECS from the RSB's,
across all PSB's for PH.
If the sender selection is not wildcard (i.e., if Shared distinct reservation (SE) style
it is SE), form the union of the FILTER_SPECs
obtained from the RSB's. For Wildcard sender Using the Sender_Template as the merged
selection (WF) style, there is not filter spec to FILTER_SPEC, form the union of the FILTER_SPECS
merge. obtained from the RSB's. Merge (take the maximum
of) the merged FLOWSPECS from the RSB's, across
all PSB's for PH.
9. If the Need_Scope flag is on, remove from the merged 9. If the Need_Scope flag is on, remove from the merged
SCOPE object all sender addresses that do not match SCOPE object all sender addresses that do not match
the set of PSB's for PH, and all senders addresses the set of PSB's for PH, and all senders addresses
that are local. If the resulting set is empty, no that are local. If the resulting set is empty, no
RESV should be forwarded to this PHOP; return; RESV should be forwarded to this PHOP; return.
otherwise (set is not empty), move the new SCOPE Otherwise (set is not empty), move the new SCOPE
object into the message. object into the message.
o (All PSB's have been processed). If a shared reservation o (All PSB's have been processed). If a shared reservation
style is being built, move the final merged FLOWSPEC, style is being built, move the final merged FLOWSPEC,
F_POLICY_DATA, and FILTER_SPEC (if SE) objects into the F_POLICY_DATA, and FILTER_SPEC (if SE) objects into the
message. message.
o If a RESV_CONFIRM object was saved earlier, copy it into o If a RESV_CONFIRM object was saved earlier, copy it into
the new RESV message and delete it from the RSB in which it the new RESV message and delete it from the RSB in which it
was found. was found.
o Set the RSVP_HOP object in the message to contain the o Set the RSVP_HOP object in the message to contain the
IncInterface address through which it will be sent and the IncInterface address through which it will be sent and the
LIH from (one of) the PSB's. LIH from (one of) the PSB's.
o Send the message to the address PH. o Send the message to the address PH.
PATH LOCAL REPAIR
The sequence is entered when RSVP learns from routing that the
set of outgoing interfaces for some destination (G,DstPort) has
changed.
o Wait for a delay time of W seconds [Section 3.5].
o For each session that exists for destination IP address G,
execute the PATH REFRESH event sequence above for each
sender (PSB) for that session.
5. Acknowledgments
The design of RSVP is based upon research performed in 1992-1993 by a
collaboration including Lixia Zhang (Xerox PARC), Deborah Estrin
(USC/ISI), Scott Shenker (Xerox PARC), Sugih Jamin (USC/Xerox PARC),
and Daniel Zappala (USC). Sugih Jamin developed the first prototype
implementation of RSVP and successfully demonstrated it in May 1993.
Shai Herzog, and later Steve Berson, continued development of RSVP
prototypes.
Since 1993, many members of the Internet research community have
contributed to the design and development of RSVP; these include (in
alphabetical order) Steve Berson, Bob Braden, Lee Breslau, Dave
Clark, Deborah Estrin, Shai Herzog, Craig Partridge, Scott Shenker,
John Wroclawski, and Daniel Zappala. In addition, a number of host
and router vendors have made valuable contributions, particularly
Fred Baker (Cisco), Mark Baugher (Intel), Don Hoffman (Sun), Steve
Jakowski (NetManage), John Krawczyk (Bay Networks), and Bill Nowicki
(SGI). Ron Frederick, Bobby Minnear, Eve Schooler, and Garrett
Wollman did early interfacing of multicast applications to RSVP.
Steve Deering, Bill Fenner, and Ajit Thyagarajan helped with the
interface between RSVP and multicast routing.
APPENDIX A. Object Definitions APPENDIX A. Object Definitions
C-Types are defined for the two Internet address families IPv4 and C-Types are defined for the two Internet address families IPv4 and
IP6. To accommodate other address families, additional C-Types could IP6. To accommodate other address families, additional C-Types could
easily be defined. These definitions are contained as an Appendix, easily be defined. These definitions are contained as an Appendix,
to ease updating. to ease updating.
All unused fields should be sent as zero and ignored on receipt. All unused fields should be sent as zero and ignored on receipt.
A.1 SESSION Class A.1 SESSION Class
skipping to change at page 82, line 43 skipping to change at page 90, line 43
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort | | Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
DestAddress DestAddress
The IP unicast or multicast destination address of the The IP unicast or multicast destination address of the
session. This parameter must be supplied. session. This field must be non-zero.
Protocol Id Protocol Id
The IP Protocol Identifier for the data flow. This parameter The IP Protocol Identifier for the data flow. This field
must be supplied. must be non-zero.
Flags Flags
0x01 = E_Police flag 0x01 = E_Police flag
The E_Police flag is used in PATH messages to determine The E_Police flag is used in PATH messages to determine
the effective "edge" of the network, to control traffic the effective "edge" of the network, to control traffic
policing. If the sender host is not itself capable of policing. If the sender host is not itself capable of
traffic policing, it will set this bit on in PATH traffic policing, it will set this bit on in PATH
messages it sends. The first node whose RSVP is capable messages it sends. The first node whose RSVP is capable
of traffic policing will do so (if appropriate to the of traffic policing will do so (if appropriate to the
service) and turn the flag off. service) and turn the flag off.
[It might make more sense to include this flag in ADSPEC 0x10 = Non_RSVP flag
object.]
The Non_RSVP flag is turned on in the SESSION object of
a PATH message whenever the RSVP daemon detects that the
previous RSVP hop included one or more non-RSVP-capable
routers. This flag is forwarded hop-by-hop and passed
to a receiver application. If it is on, it indicates to
the application that even a successful reservation
request may not install the requested QoS at every node
along the path.
0x20 = Maybe_RSVP flag
The Maybe_RSVP flag is turned on in the SESSION object
of a PATH message whenever the RSVP daemon is unable to
ascertain whether or not the previous hop included one
or more non-RSVP-capable routers. This flag is
forwarded hop-by-hop and passed to a receiver
application. If it is on and the Non_RSVP flag is off,
the application cannot tell whether or not a successful
reservation request may not install the requested QoS at
every node along the path.
DstPort DstPort
The UDP/TCP destination port for the session. Zero may be The UDP/TCP destination port for the session. Zero may be
used to indicate a `wildcard', i.e., any port. used to indicate `none'.
Other SESSION C-Types could be defined in the future to Other SESSION C-Types could be defined in the future to
support other demultiplexing conventions in the transport- support other demultiplexing conventions in the transport-
layer or application layer. layer or application layer.
A.2 RSVP_HOP Class A.2 RSVP_HOP Class
RSVP_HOP class = 3. RSVP_HOP class = 3.
o IPv4 RSVP_HOP object: Class = 3, C-Type = 1 o IPv4 RSVP_HOP object: Class = 3, C-Type = 1
skipping to change at page 85, line 9 skipping to change at page 93, line 9
the last RSVP-knowledgeable hop forwarded this message. The the last RSVP-knowledgeable hop forwarded this message. The
Logical Interface Handle is a 32-bit number which may be used to Logical Interface Handle is a 32-bit number which may be used to
distinguish logical outgoing interfaces as described in Section distinguish logical outgoing interfaces as described in Section
3.2; it should be identically zero if there is no logical 3.2; it should be identically zero if there is no logical
interface handle. interface handle.
A.3 INTEGRITY Class A.3 INTEGRITY Class
INTEGRITY class = 4. INTEGRITY class = 4.
See draft-ietf-rsvp-md5-00.txt. See [Baker96].
A.4 TIME_VALUES Class A.4 TIME_VALUES Class
TIME_VALUES class = 5. TIME_VALUES class = 5.
o TIME_VALUES Object: Class = 5, C-Type = 1 o TIME_VALUES Object: Class = 5, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Refresh Period | | Refresh Period R |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
Refresh Period Refresh Period
The refresh timeout period R used to generate this message; The refresh timeout period R used to generate this message;
in milliseconds. in milliseconds.
A.5 ERROR_SPEC Class A.5 ERROR_SPEC Class
ERROR_SPEC class = 6. ERROR_SPEC class = 6.
skipping to change at page 86, line 37 skipping to change at page 94, line 37
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value | | Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
Error Node Address Error Node Address
The IP address of the node in which the error was detected. The IP address of the node in which the error was detected.
Flags Flags
0x01 = LUB-Used 0x01 = InPlace
The use of this flag is described in section 3.1.5. This flag is used only for an ERROR_SPEC object in a
RERR message. If it on, this flag indicates that there
was, and still is, a reservation in place at the failure
point.
0x02 = NotGuilty
This flag is used only for an ERROR_SPEC object in a
RERR message, and it is only set in the interface to the
receiver application. If it on, this flag indicates
that the FLOWSPEC that failed was strictly greater than
the FLOWSPEC requested by this receiver.
Error Code Error Code
A one-octet error description. A one-octet error description.
Error Value Error Value
A two-octet field containing additional information about the A two-octet field containing additional information about the
error. Its contents depend upon the Error Type. error. Its contents depend upon the Error Type.
skipping to change at page 88, line 11 skipping to change at page 97, line 11
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
A.7 STYLE Class A.7 STYLE Class
STYLE class = 8. STYLE class = 8.
o STYLE object: Class = 8, C-Type = 1 o STYLE object: Class = 8, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Option Vector | | Flags | Option Vector |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
Option Vector Flags: 8 bits
(None assigned yet)
Option Vector: 24 bits
A set of bit fields giving values for the reservation A set of bit fields giving values for the reservation
options. If new options are added in the future, options. If new options are added in the future,
corresponding fields in the option vector will be assigned corresponding fields in the option vector will be assigned
from the least-significant end. If a node does not recognize from the least-significant end. If a node does not recognize
a style ID, it may interpret as much of the option vector as a style ID, it may interpret as much of the option vector as
it can, ignoring new fields that may have been defined. it can, ignoring new fields that may have been defined.
The option vector bits are assigned (from the left) as The option vector bits are assigned (from the left) as
follows: follows:
27 bits: Reserved 19 bits: Reserved
2 bits: Sharing control 2 bits: Sharing control
00b: Reserved 00b: Reserved
01b: Distinct reservations 01b: Distinct reservations
10b: Shared reservations 10b: Shared reservations
11b: Reserved 11b: Reserved
skipping to change at page 90, line 8 skipping to change at page 99, line 8
The low order bits of the option vector are determined by the The low order bits of the option vector are determined by the
style, as follows: style, as follows:
WF 10001b WF 10001b
FF 01010b FF 01010b
SE 10010b SE 10010b
A.8 FLOWSPEC Class A.8 FLOWSPEC Class
FLOWSPEC class = 9. FLOWSPEC class = 9.
o Class = 9, C-Type = 1: int-serv flowspec o Class = 9, C-Type = 2: int-serv flowspec
The contents of this object will be specified in documents The contents of this object will be specified in documents
prepared by the int-serv working group. prepared by the int-serv working group.
o Class = 9, C-Type = 254: Unmerged Flowspec List
+-------------+-------------+-------------+-------------+
| |
// FLOWSPEC object 1 //
| |
+-------------+-------------+-------------+-------------+
| |
// FLOWSPEC object 2 //
| |
+-------------+-------------+-------------+-------------+
// //
// //
+-------------+-------------+-------------+-------------+
| |
// FLOWSPEC object k //
| |
+-------------+-------------+-------------+-------------+
This is a container C-Type, used to enclose a set of FLOWSPEC
objects that could not be merged at the next hop downstream
because they include unrecognized C-Types. The node that
receives this object may merge those it recognizes and
forward the rest in another Unmerged Flowspec List object.
A.9 FILTER_SPEC Class A.9 FILTER_SPEC Class
FILTER_SPEC class = 10. FILTER_SPEC class = 10.
o IPv4 FILTER_SPEC object: Class = 10, C-Type = 1 o IPv4 FILTER_SPEC object: Class = 10, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 SrcAddress (4 bytes) | | IPv4 SrcAddress (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| ////// | ////// | SrcPort | | ////// | ////// | SrcPort |
skipping to change at page 91, line 47 skipping to change at page 100, line 47
+ IP6 SrcAddress (16 bytes) + + IP6 SrcAddress (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| /////// | Flow Label (24 bits) | | /////// | Flow Label (24 bits) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
SrcAddress SrcAddress
The IP source address for a sender host, or zero to indicate The IP source address for a sender host. Must be non-zero.
a `wildcard'.
SrcPort SrcPort
The UDP/TCP source port for a sender, or zero to indicate a The UDP/TCP source port for a sender, or zero to indicate
`wildcard' (i.e., any port). `none'.
Flow Label Flow Label
A 24-bit Flow Label, defined in IP6. This value may be used A 24-bit Flow Label, defined in IP6. This value may be used
by the packet classifier to efficiently identify the packets by the packet classifier to efficiently identify the packets
belonging to a particular (sender->destination) data flow. belonging to a particular (sender->destination) data flow.
A.10 SENDER_TEMPLATE Class A.10 SENDER_TEMPLATE Class
SENDER_TEMPLATE class = 11. SENDER_TEMPLATE class = 11.
skipping to change at page 93, line 21 skipping to change at page 102, line 21
Definition same as IPv4/UDP FILTER_SPEC object. Definition same as IPv4/UDP FILTER_SPEC object.
o IP6/UDP SENDER_TEMPLATE object: Class = 11, C-Type = 2 o IP6/UDP SENDER_TEMPLATE object: Class = 11, C-Type = 2
Definition same as IP6/UDP FILTER_SPEC object. Definition same as IP6/UDP FILTER_SPEC object.
A.11 SENDER_TSPEC Class A.11 SENDER_TSPEC Class
SENDER_TSPEC class = 12. SENDER_TSPEC class = 12.
o Token Bucket SENDER_TSPEC object: Class = 12, C-Type = 1 o Intserv SENDER_TSPEC object: Class = 12, C-Type = 1
The contents of this object will be specified in documents The contents of this object are specified in service
prepared by the int-serv working group. specification documents prepared by the int-serv working
group.
A.12 ADSPEC Class A.12 ADSPEC Class
ADSPEC class = 13. ADSPEC class = 13.
The contents of this object will be specified in documents o Intserv ADSPEC object: Class = 13, C-Type = 2
prepared by the int-serv working group.
The contents of this object are specified in service
specification documents prepared by the int-serv working
group.
A.13 POLICY_DATA Class A.13 POLICY_DATA Class
POLICY_DATA class = 14. POLICY_DATA class = 14.
o Type 1 POLICY_DATA object: Class = 14, C-Type = 1 o Type 1 POLICY_DATA object: Class = 14, C-Type = 1
The contents of this object are for further study. The contents of this object are for further study.
o Unmerged POLICY_DATA object: Class = 14, C-Type = 254
This object is a container for a list of POLICY_DATA objects
(none of which may have C-Type = 254). The contained objects
have not yet been merged.
+-------------+-------------+-------------+-------------+
| |
// POLICY_DATA object 1 //
| |
+-------------+-------------+-------------+-------------+
| |
// POLICY_DATA object 2 //
| |
+-------------+-------------+-------------+-------------+
// //
// //
+-------------+-------------+-------------+-------------+
| |
// POLICY_DATA object k //
| |
+-------------+-------------+-------------+-------------+
A.14 RESV_CONFIRM Class A.14 RESV_CONFIRM Class
RESV_CONFIRM class = 15. RESV_CONFIRM class = 15.
o IPv4 RESV_CONFIRM object: Class = 15, C-Type = 1 o IPv4 RESV_CONFIRM object: Class = 15, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 Receiver Address (4 bytes) | | IPv4 Receiver Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 97, line 7 skipping to change at page 106, line 7
+ + + +
| | | |
+ IP6 Receiver Address (16 bytes) + + IP6 Receiver Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
APPENDIX B. Error Codes and Values APPENDIX B. Error Codes and Values
The following Error Codes are defined. The following Error Codes may appear in ERROR_SPEC objects and be
passed to end systems. Except where noted, these Error Codes may
appear only in RERR messages.
o Error Code = 01: Admission failure o Error Code = 00: Confirmation
Reservation rejected by admission control. This code is reserved for use in the ERROR_SPEC object of a RACK
message. The Error Value will also be zero.
For this Error Code, the 16 bits of the Error Value field are: o Error Code = 01: Admission Control failure
ussr cccc cccc cccc Reservation request was rejected by Admission Control due to
unavailable resources.
where the bits are: For this Error Code, the 16 bits of the Error Value field are:
u = 0: RSVP rejects the message without updating local state. ssur cccc cccc cccc
u = 1: RSVP may use message to update local state and forward where the bits are:
the message.
ss = 00: Low order 12 bits contain a globally-defined sub-code ss = 00: Low order 12 bits contain a globally-defined sub-code
(values listed below). (values listed below).
ss = 10: Low order 12 bits contain a sub-code that is specific ss = 10: Low order 12 bits contain a organization-specific sub-
to local organization. RSVP is not expected to be able to code. RSVP is not expected to be able to interpret this
interpret this except as a numeric value. except as a numeric value.
ss = 11: Low order 12 bits contain a sub-code that is specific ss = 11: Low order 12 bits contain a service-specific sub-code.
to the service. RSVP is not expected to be able to RSVP is not expected to be able to interpret this except as
interpret this except as a numeric value. Since the a numeric value.
traffic control mechanism might substitute a different
service, this encoding may include some representation of Since the traffic control mechanism might substitute a
the service in use. different service, this encoding may include some
representation of the service in use.
u = 0: RSVP rejects the message without updating local
state.
u = 1: RSVP may use message to update local state and forward
the message. This means that the message is informational.
r: Reserved bit, should be zero. r: Reserved bit, should be zero.
cccc cccc cccc: 12 bit code. cccc cccc cccc: 12 bit code.
The following globally-defined sub-codes may appear in the low- The following globally-defined sub-codes may appear in the low-
order 12 bits when ss = 00: order 12 bits when ssur = 0000:
- Sub-code = 1: Delay bound cannot be met - Sub-code = 1: Delay bound cannot be met
- Sub-code = 2: Requested bandwidth unavailable - Sub-code = 2: Requested bandwidth unavailable
- Sub-code = 11: Service conflict o Error Code = 02: Policy Control failure
- Sub-code = 12: Service unsupported Reservation has been rejected for administrative reasons, for
example, required credentials not submitted, insufficient quota
or balance, or administrative preemption. This Error Code may
appear in a PERR or RERR message.
Traffic control can provide neither the requested service Contents of the Error Value field are to be determined in the
nor an acceptable replacement. future.
- Sub-code = 13: Bad Flowspec or Tspec value o Error Code = 03: No path information for this Resv message.
Unreasonable reques