draft-ietf-rsvp-spec-10.txt   draft-ietf-rsvp-spec-11.txt 
Internet Draft R. Braden, Ed. Internet Draft R. Braden, Ed.
Expiration: August 1996 ISI Expiration: September 1996 ISI
File: draft-ietf-rsvp-spec-10.txt L. Zhang File: draft-ietf-rsvp-spec-11.txt L. Zhang
PARC PARC
S. Berson S. Berson
ISI ISI
S. Herzog S. Herzog
ISI ISI
S. Jamin S. Jamin
USC USC
Resource ReSerVation Protocol (RSVP) -- Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification Version 1 Functional Specification
February 21, 1996 March 18, 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 ..............................................11
1.4 Examples of Styles ..............................................14 1.4 Examples of Styles ..............................................13
2. RSVP Protocol Mechanisms ............................................19 2. RSVP Protocol Mechanisms ............................................18
2.1 RSVP Messages ...................................................19 2.1 RSVP Messages ...................................................18
2.2 Port Usage ......................................................21 2.2 Port Usage ......................................................20
2.3 Merging Flowspecs ...............................................22 2.3 Merging Flowspecs ...............................................21
2.4 Soft State ......................................................23 2.4 Soft State ......................................................22
2.5 Teardown ........................................................25 2.5 Teardown ........................................................24
2.6 Errors ..........................................................26 2.6 Errors ..........................................................25
2.7 Confirmation ....................................................28 2.7 Confirmation ....................................................27
2.8 Policy and Security .............................................28 2.8 Policy and Security .............................................27
2.9 Automatic RSVP Tunneling ........................................29 2.9 Non-RSVP Clouds .................................................28
2.10 Host Model .....................................................30 2.10 Host Model .....................................................29
3. RSVP Functional Specification .......................................32 3. RSVP Functional Specification .......................................31
3.1 RSVP Message Formats ............................................32 3.1 RSVP Message Formats ............................................31
3.2 Sending RSVP Messages ...........................................45 3.2 Sending RSVP Messages ...........................................44
3.3 Avoiding RSVP Message Loops .....................................47 3.3 Avoiding RSVP Message Loops .....................................45
3.4 Blockade State ..................................................50 3.4 Blockade State ..................................................49
3.5 Local Repair ....................................................52 3.5 Local Repair ....................................................51
3.6 Time Parameters .................................................53 3.6 Time Parameters .................................................52
3.7 Traffic Policing and Non-Integrated Service Hops ................54 3.7 Traffic Policing and Non-Integrated Service Hops ................53
3.8 Multihomed Hosts ................................................56 3.8 Multihomed Hosts ................................................54
3.9 Future Compatibility ............................................57 3.9 Future Compatibility ............................................56
3.10 RSVP Interfaces ................................................59 3.10 RSVP Interfaces ................................................58
4. Message Processing Rules ............................................71 4. Message Processing Rules ............................................70
5. Acknowledgments .....................................................90 5. Acknowledgments .....................................................90
APPENDIX A. Object Definitions .........................................91 APPENDIX A. Object Definitions .........................................91
APPENDIX B. Error Codes and Values .....................................107 APPENDIX B. Error Codes and Values .....................................107
APPENDIX C. UDP Encapsulation ..........................................112 APPENDIX C. UDP Encapsulation ..........................................112
What's Changed What's Changed
The most important changes in this document from the rsvp-spec-10
draft are:
o RSVP-layer fragmentation machinery was removed.
However, the common header was rearranged to allow message
length to be expanded beyond 16 bits in the future, should
that be necessary.
o A little more discussion of IPv6 in Introduction.
o Service preemption now triggers a ResvTear message.
o Traffic Control can return updated FLOWSPEC. (This forced a
significant change in the UPDATE TRAFFIC CONTROL processing
in section 4).
o The discussion at the end of Section 2.3 was rewritten.
o The Message Processing Rules were updated.
The most important changes in this document from the rsvp-spec-09 The most important changes in this document from the rsvp-spec-09
draft are: draft are:
o Multiple POLICY_DATA objects in any order are now allowed. o Multiple POLICY_DATA objects in any order are now allowed.
o The length field in the common header is now the total o The length field in the common header is now the total
message length [Section 3.1.1]. message length [Section 3.1.1].
o The meaning of Message Id is refined and more completely o The meaning of Message Id is refined and more completely
specified [Section 3.1.1]. specified [Section 3.1.1].
o RSVP fragmentation is specifically called for, and IP o RSVP fragmentation is specifically called for, and IP
fragmentation disallowed [Section 3.1.1]. fragmentation disallowed [Section 3.1.1].
o The granularity of state timeouts is now specified [Section o The granularity of state timeouts is now specified [Section
3.6]. 3.6].
The most important changes in this document from the rsvp-spec-08
draft are:
o The handling of reservation errors has been fundamentally
changed, to prevent the "second killer reservation problem".
A new kind of state has been introduced into a node,
"blockade state", which is created by a ResvErr message with
Error Code = 01, and which controls the merging process for
generating reservation refresh messages [Sections 2.6 and
3.4].
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 optional INTEGRITY object is now specified to immediately
follow the common header and to appear in every fragment
[Section 3.1].
o There are now two flag bits in an ERROR_SPEC object: InPlace
and NotGuilty [Section 3.10].
o The text now states that implementations should be as
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 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 The rules for handling an unrecognized object class are
changed to include a third possibility: ignore and do not
forward the object [Section 3.9].
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 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].
The RSVP protocol is used by a host, on behalf of an application data The RSVP protocol is used by a host, on behalf of an application data
stream, to request a specific quality of service (QoS) from the stream, to request a specific quality of service (QoS) from the
network. The RSVP protocol is also used by routers to deliver QoS network. The RSVP protocol is also used by routers to deliver QoS
requests to all nodes along the path(s) of the data stream and to requests to all nodes along the path(s) of the data stream and to
establish and maintain state to provide the requested service. RSVP establish and maintain state to provide the requested service. RSVP
requests will generally, although not necessarily, result in requests will generally, although not necessarily, result in
resources being reserved along the data path. 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, RSVP treats a sender as resources in only one direction. Therefore, RSVP treats a sender as
logically distinct from a receiver, although the same application logically distinct from a receiver, although the same application
process may act as both a sender and a receiver at the same time. process may act as both a sender and a receiver at the same time.
RSVP operates on top of IP (either IPv4 or IP6), occupying the place RSVP operates on top of IP (either IPv4 or IPv6), occupying the place
of a transport protocol in the protocol stack. However, RSVP does of a transport protocol in the protocol stack. However, RSVP does
not transport application data but is rather an Internet control not transport application data but is rather an Internet control
protocol, like ICMP, IGMP, or routing protocols. Like the protocol, like ICMP, IGMP, or routing protocols. Like the
implementations of routing and management protocols, an implementations of routing and management protocols, an
implementation of RSVP will typically execute in the background, not implementation of RSVP will typically execute in the background, not
in the data forwarding path, 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. An with current and future unicast and multicast routing protocols. An
RSVP daemon consults the local routing database(s) to obtain routes. RSVP daemon consults the local routing database(s) to obtain routes.
skipping to change at page 6, line 29 skipping to change at page 5, line 29
| | |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 node that is capable of resource reservation passes incoming Each node that is capable of resource reservation passes incoming
data packets through a "packet classifier", which determines the data packets through a "packet classifier", which determines the
route and the QoS class for each packet. For each outgoing route and the QoS class for each packet. On outgoing interface, a
interface, a " packet scheduler" then makes forwarding decisions for "packet scheduler" then makes forwarding decisions for every packet,
each packet to achieve the promised QoS on the particular link-layer to achieve the promised QoS on the particular link-layer medium used
medium used by that interface. by that interface.
If the link-layer medium is QoS-active, i.e., if it has its own QoS If the link-layer medium is QoS-active, i.e., if it has its own QoS
management capability, then the packet scheduler is responsible for management capability, then the packet scheduler is responsible for
negotiation with the link layer to obtain the QoS requested by RSVP. 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 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 large groups, dynamic group
dynamic group membership, RSVP makes receivers responsible for membership, and heterogeneous receiver requirements, RSVP makes
requesting QoS [RSVP93]. A QoS request, which typically originates receivers responsible for requesting QoS [RSVP93]. A QoS request,
from a receiver host application, is passed to the local RSVP which typically originates from a receiver host application, is
implementation, shown as a daemon process in Figure 1. The RSVP passed to the local RSVP implementation, shown as a daemon process in
protocol then carries the request to all the nodes (routers and Figure 1. The RSVP protocol then carries the request to all the
hosts) along the reverse data path(s) to the data source(s). nodes (routers and hosts) along the reverse data path(s) to the data
source(s).
At each node, the RSVP daemon communicates with two local decision At each node, the RSVP daemon communicates with two local decision
modules, "admission control" and "policy control". Admission control modules, "admission control" and "policy control". Admission control
determines whether the node has sufficient available resources to determines whether the node has sufficient available resources to
supply the requested QoS. Policy control determines whether the user supply the requested QoS. Policy control determines whether the user
has administrative permission to make the reservation. If both has administrative permission to make the reservation. If both
checks succeeds, the RSVP daemon sets parameters in the packet checks succeed, the RSVP daemon sets parameters in the packet
classifier and scheduler to obtain the desired QoS. If either check classifier and scheduler to obtain the desired QoS. If either check
fails, the RSVP program returns an error notification to the fails, the RSVP program returns an error notification to the
application process that originated the request. We refer 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
refreshes, the state will automatically time out and be deleted. refreshes, the state will automatically time out and be deleted.
RSVP protocol mechanisms provide a general facility for creating and RSVP protocol mechanisms provide a general facility for creating and
maintaining distributed reservation state across a mesh of multicast maintaining distributed reservation state across a mesh of multicast
or unicast delivery paths. RSVP transfers reservation parameters as or unicast delivery paths. Except for certain well-defined
opaque data (except for certain well-defined operations on the data), operations on the parameters, RSVP transfers QoS and policy
which it simply passes to traffic control for interpretation. parameters as opaque data, passing them to the appropriate traffic
Although the RSVP protocol mechanisms are largely independent of the control and policy control modules for interpretation.
encoding of these parameters, the encodings must be defined in the
reservation model that is presented to an application; see Appendix A
for more details.
In summary, RSVP has the following attributes: 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 to changing routes.
o RSVP is simplex, i.e., it reserves for a data flow in one o RSVP is simplex, i.e., it makes reservations for unidirectional
direction only. data flows.
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.
o RSVP is not a routing protocol but depends upon present and
future routing protocols.
o RSVP transports and maintains opaque state for traffic control,
and policy control.
o RSVP provides several reservation models or "styles" (defined o RSVP provides several reservation models or "styles" (defined
below) to fit a variety of applications. below) to fit a variety of applications.
o RSVP provides transparent operation through routers that do not o RSVP provides transparent operation through routers that do not
support it. support it.
o RSVP supports both IPv4 and IPv6.
Further discussion on the objectives and general justification for Further discussion on the objectives and general justification for
RSVP design are presented in [RSVP93,ISInt93]. RSVP design are presented in [RSVP93,ISInt93].
The remainder of this section describes the RSVP reservation The remainder of this section describes the RSVP reservation
services. Section 2 presents an overview of the RSVP protocol services. Section 2 presents an overview of the RSVP protocol
mechanisms. Section 3 contains the functional specification of RSVP, mechanisms. Section 3 contains the functional specification of RSVP,
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
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" to be a data flow with a particular
destination and transport-layer protocol. The destination of a destination and transport-layer protocol. The destination of a
session is generally defined by DestAddress, the IP destination session is defined by DestAddress, the IP destination address of
address of the data packets, and perhaps by DstPort, a the data packets, and perhaps by DstPort, a "generalized
"generalized destination port", i.e., some further demultiplexing destination port", i.e., some further demultiplexing point in the
point in the transport or application protocol layer. RSVP treats transport or application protocol layer. RSVP treats each session
each session independently, and this document often assumes the independently, and this document often omits the implied
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
extensible for greater generality, the present version supports extensible for greater generality, the basic protocol documented
only UDP/TCP ports as generalized ports. here supports only UDP/TCP ports as generalized ports. Note that
it is not strictly necessary to include DstPort in the session
Note that it is not strictly necessary to include ports in the definition when DestAddress is multicast, since different sessions
session definition when DestAddress is multicast, since different can always have different multicast addresses. However, DstPort
sessions can always have different multicast addresses. However, is necessary to allow more than one unicast session addressed to
destination ports are necessary to allow more than one unicast the same receiver host.
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 session, assuming multicast data distribution. The arrows
indicate data flowing from senders S1 and S2 to receivers R1, R2, indicate data flowing from senders S1 and S2 to receivers R1, R2,
and R3, 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 may distribution session has a single receiver R. Each sender Si may
be running in a unique Internet host, or a single host may contain be running in a unique Internet host, or a single host may contain
multiple senders, distinguished by generalized source ports. multiple senders distinguished by "generalized source 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 33 skipping to change at page 8, line 35
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 a session specification, defines the set of spec, together with a session specification, defines the set of
data 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 in 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 logical
although an RSVP reservation request originates from receiver(s) or physical link, although an RSVP reservation request originates
downstream. In this document, we define the directional terms from receiver(s) downstream. In this document, we define the
"upstream" vs. "downstream", "previous hop" vs. "next hop", and directional terms "upstream" vs. "downstream", "previous hop" vs.
"incoming interface" vs "outgoing interface" with respect to the "next hop", and "incoming interface" vs "outgoing interface" with
direction of data flow. respect to the 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 [ServTempl95, ISdata95], and are generally opaque to
RSVP. The exact format of a filter spec depends upon whether IPv4
or IPv6 is in use; see Appendix A.
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. In the interest of on fields in an application-layer header. In the interest of
simplicity (and to minimize layer violation), the present RSVP simplicity (and to minimize layer violation), the present RSVP
version uses a much more restricted form of filter spec, version uses a much more restricted form of filter spec,
consisting of sender IP address and optionally the UDP/TCP port consisting of sender IP address and optionally the UDP/TCP port
number SrcPort. number SrcPort.
Because the UDP/TCP port numbers are used for packet Because the UDP/TCP port numbers are used for packet
classification, each router must be able to examine these fields. classification, each router must be able to examine these fields.
As a result, it is generally necessary to avoid IP fragmentation As a result, it is generally necessary to avoid IP fragmentation
of a data stream for which a resource reservation is desired. of a data stream for which a resource reservation is desired.
RSVP reservation request messages originate at receivers and are There are two cases where the use of transport-layer ports for
passed upstream towards the sender(s). At each intermediate node, selecting an RSVP flow may cause problems.
two general actions are taken on the request.
1. IPv6 inserts a variable number of variable-length Internet-
layer headers before the transport header, increasing the
difficulty and cost of packet classification for QoS.
Efficient classification of IPv6 data packets could be
obtained using the Flow Label field of the IPv6 header. The
details will be provided in the future.
2. IP-level Security, under either IPv4 or IPv6, may encrypt the
entire transport header, rendering the port numbers invisible
to intermediate routers.
A small extension to RSVP for IP Security under IPv4 is
described separately in [IPSEC96]. A corresponding solution
for IPv6 will be provided in the future.
RSVP messages carrying reservation requests originate at receivers
and are passed upstream towards the sender(s). At each
intermediate node, two general actions are taken on a request.
1. Make a reservation 1. Make a reservation
The request is passed to admission control and policy The request is passed to admission control and policy
control. If either test fails, the reservation is rejected control. If either test fails, the reservation is rejected
and RSVP returns an error message to the appropriate and RSVP returns an error message to the appropriate
receiver(s). If both succeed, the node uses the flowspec to receiver(s). If both succeed, the node uses the flowspec to
set up the packet scheduler for the desired QoS and the set up the packet scheduler for the desired QoS and the
filter spec to set the packet classifier to select the filter spec to set the packet classifier to select the
appropriate data packets. 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, the traffic control mechanism may modify the
mechanism to modify the flowspec hop-by-hop, although none of the flowspec hop-by-hop. Second, reservations for the same sender, or
currently defined services does so. Second, reservations for the the same set of senders, from different downstream branches of the
same sender, or the same set of senders, from different downstream multicast tree(s) are "merged" as reservations travel upstream; as
branches of the multicast tree(s) are "merged" as reservations a result, a node forwards upstream only the reservation request
travel upstream; a node forwards upstream only the reservation 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 upstream along the multicast tree until it request propagates upstream along the multicast tree until it
reaches a point where an existing reservation is equal or greater reaches a point where an existing reservation is equal or greater
than that being requested. At that point, the arriving request is than that being requested. At that point, the arriving request is
merged with the reservation in place, and need not be forwarded merged with the reservation in place and need not be forwarded
further, and the node may then send a reservation confirmation further; the node may then send a reservation confirmation message
message back to the receiver. Note that the receipt of a back to the receiver. Note that the receipt of a confirmation is
confirmation is only a high-probability indication, not a only a high-probability indication, not a guarantee, that the
guarantee, that the requested service is in place all the way to requested service is in place all the way to the sender(s), as
the sender(s), as explained in Section 2.7. 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) [OPWA95]. With OPWA, RSVP
RSVP control packets are sent downstream, following the data control packets are sent downstream, following the data paths, to
paths, to gather information that may be used to predict the end- gather information that may be used to predict the end-to-end QoS.
to-end QoS. The results ("advertisements") are delivered by RSVP The results ("advertisements") are delivered by RSVP to the
to the receiver hosts and perhaps to the receiver applications. receiver hosts and perhaps to the receiver applications. The
The advertisements may then be used by the receiver to construct, advertisements may then be used by the receiver to construct, or
or to dynamically adjust, an appropriate reservation request. to dynamically adjust, an appropriate reservation request.
1.3 Reservation Styles 1.3 Reservation Styles
A reservation request includes a set of options, which are A reservation request includes a set of options that are
collectively called the reservation "style". collectively called the reservation "style".
One reservation option concerns the treatment of reservations for One reservation option concerns the treatment of reservations for
different 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 reservation option controls the selection of senders: an " Another reservation option controls the selection of senders; it
explicit" list of all selected senders, or a "wildcard" that may be an "explicit" list of all selected senders, or a "wildcard"
implicitly selects all the senders to the session. In an explicit that implicitly selects all the senders to the session. In an
sender-selection reservation, each filter spec must match exactly explicit sender-selection reservation, each filter spec must match
one sender, while in a wildcard sender-selection no filter spec is exactly one sender, while in a wildcard sender-selection no filter
needed. 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 |
|| | (WF) Style | || | (WF) Style |
__________||__________________|____________________| __________||__________________|____________________|
Figure 3: Reservation Attributes and Styles Figure 3: Reservation Attributes and Styles
The styles currently defined are as follows (see Figure 3): The following styles currently defined (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 shared by flows from all
upstream senders are mixed. This reservation may be thought upstream senders. This reservation may be thought of as a
of as a shared "pipe", whose "size" is the largest of the shared "pipe", whose "size" is the largest of the resource
resource requests from all receivers, independent of the requests from all receivers, independent of the number of
number of senders using it. A WF-style reservation is senders using it. A WF-style reservation is propagated
propagated upstream towards all sender hosts, and upstream towards all sender hosts, and it automatically
automatically extends to new senders as they appear. 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})
where the asterisk represents wildcard sender selection and Q where the asterisk represents wildcard sender selection and Q
represents the flowspec. represents the flowspec.
o Fixed-Filter (FF) Style o Fixed-Filter (FF) Style
The FF style implies the options: "distinct" reservations and The FF style implies the options: "distinct" reservations and
"explicit" sender selection. Thus, an elementary FF-style "explicit" sender selection. Thus, an elementary FF-style
reservation request creates a distinct reservation for data reservation request creates a distinct reservation for data
packets from a particular sender, not sharing them with other packets from a particular sender, not sharing them with other
senders' packets for the same session. senders' packets for the same session.
The total reservation on a link for a given session is the
total of the FF reservations for all requested senders. On
the other hand, FF reservations requested by different
receivers Rj but selecting the same sender Si must be merged
to share a single reservation.
Symbolically, we can represent an elementary FF reservation Symbolically, we can represent an elementary FF reservation
request by: request by:
FF( S{Q}) FF( S{Q})
where S is the selected sender and Q is the corresponding where S is the selected sender and Q is the corresponding
flowspec; the pair forms a flow descriptor. RSVP allows flowspec; the pair forms a flow descriptor. RSVP allows
multiple elementary FF-style reservations to be requested at multiple elementary FF-style reservations to be requested at
the same time, using a list of flow descriptors: the same time, using a list of flow descriptors:
FF( S1{Q1}, S2{Q2}, ...) FF( S1{Q1}, S2{Q2}, ...)
The total reservation on a link for a given session is the
`sum' of Q1, Q2, ... for all requested senders.
o Shared Explicit (SE) Style o Shared Explicit (SE) Style
The SE style implies the options: "shared" reservation and " The SE style implies the options: "shared" reservation and "
explicit" sender selection. Thus, an SE-style reservation explicit" sender selection. Thus, an SE-style reservation
creates a single reservation into which flows from all creates a single reservation shared by selected upstream
upstream senders are mixed. However, like the FF style, the senders. Unlike the WF style, the SE style allows a receiver
SE style allows a receiver to explicitly specify the set of to explicitly specify the set of senders to be included.
senders.
We can represent an SE reservation request containing a We can represent an SE reservation request containing a
flowspec Q and a list of senders S1, S2, ... by: flowspec Q and a list of senders S1, S2, ... by:
SE( (S1,S2,...){Q} ) SE( (S1,S2,...){Q} )
Both WF and SE styles create shared reservations, appropriate for Shared reservations, created by WF and SE styles, are appropriate
those multicast applications whose properties make it unlikely for those multicast applications in which multiple data sources
that multiple data sources will transmit simultaneously. are unlikely to transmit simultaneously. Packetized audio is an
Packetized audio is an example of an application suitable for example of an application suitable for shared reservations; since
shared reservations; since a limited number of people talk at a limited number of people talk at once, each receiver might issue
once, each receiver might issue a WF or SE reservation request for a WF or SE reservation request for twice the bandwidth required
twice the bandwidth required for one sender (to allow some over- for one sender (to allow some over-speaking). On the other hand,
speaking). On the other hand, the FF style, which creates the FF style, which creates distinct reservations for the flows
independent reservations for the flows from different senders, is from different 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 explicit sender incompatible. They also disallow merging explicit sender
selection with wildcard sender selection, since this might produce selection with wildcard sender selection, since this might produce
an 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.
It would seem possible to simulate the effect of a WF reservation It would seem possible to simulate the effect of a WF reservation
using the SE style. When an application asked for WF, the RSVP using the SE style. When an application asked for WF, the RSVP
daemon on the receiver host could use local path state to create daemon on the receiver host could use local state to create an
an equivalent SE reservation that explicitly listed all senders. equivalent SE reservation that explicitly listed all senders.
However, an SE reservation forces the packet classifier in each However, an SE reservation forces the packet classifier in each
node to explicitly select each sender in the list, while a WF node to explicitly select each sender in the list, while a WF
allows the packet classifier to simply "wild card" the sender allows the packet classifier to simply "wild card" the sender
address and port. When there is a large list of senders, a WF address and port. When there is a large list of senders, a WF
style reservation can therefore result in considerably less style reservation can therefore result in considerably less
overhead than an equivalent SE style reservation. For this overhead than an equivalent SE style reservation. For this
reason, both SE and WF are included in the protocol. reason, both SE and WF are included in the protocol.
Other reservation options and styles may be defined in the future. 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 shows the effects of merging. and shows the effects of merging.
Figure 4 illustrates a router with two incoming interfaces through Figure 4 illustrates a router with two incoming interfaces,
which data streams will arrive, labeled (a) and (b), and two labeled (a) and (b), through which data streams will arrive, and
outgoing interfaces through which data will be forwarded, labeled two outgoing interfaces, labeled (c) and (d), through which data
(c) and (d). This topology will be assumed in the examples that will be forwarded. This topology will be assumed in the examples
follow. There are three upstream senders; packets from sender S1 that follow. There are three upstream senders; packets from
(S2 and S3) arrive through previous hop (a) ((b), respectively). sender S1 (S2 and S3) arrive through previous hop (a) ((b),
There are also three downstream receivers; packets bound for R1 respectively). There are also three downstream receivers; packets
(R2 and R3) are routed via outgoing interface (c) ((d), bound for R1 (R2 and R3) are routed via outgoing interface (c)
respectively). We furthermore assume that R2 and R3 arrive via ((d), respectively). We furthermore assume that outgoing
different next hops, e.g., via the two routers D and D' in Figure interface (d) is connected to a broadcast LAN, and that R2 and R3
9. This illustrates the effect of a non-RSVP cloud or a broadcast are reached via different next hop routers (not shown).
LAN on interface (d).
In addition to the connectivity shown in 4, we must also specify We must also specify the multicast routes within the nod of Figure
the multicast routes within this node. Assume first that data 4. Assume first that data packets from each Si shown in Figure 4
packets from each Si shown in Figure 4 is routed to both outgoing is routed to both outgoing interfaces. Under this assumption,
interfaces. Under this assumption, Figures 5, 6, and 7 illustrate Figures 5, 6, and 7 illustrate Wildcard-Filter, Fixed-Filter, and
Wildcard-Filter, Fixed-Filter, and Shared-Explicit reservations, Shared-Explicit reservations, respectively.
respectively.
________________ ________________
(a)| | (c) (a)| | (c)
( S1 ) ---------->| |----------> ( R1 ) ( S1 ) ---------->| |----------> ( R1 )
| Router | | Router | |
(b)| | (d) (b)| | (d) |---> ( R2 )
( S2,S3 ) ------->| |----------> ( R2, R3 ) ( S2,S3 ) ------->| |------|
|________________| |________________| |---> ( R3 )
|
Figure 4: Router Configuration Figure 4: Router Configuration
For simplicity, these examples show flowspecs as one-dimensional For simplicity, these examples show flowspecs as one-dimensional
multiples of some base resource quantity B. The "Receive" column multiples of some base resource quantity B. The "Receive" column
shows the RSVP reservation requests received over outgoing shows the RSVP reservation requests received over outgoing
interfaces (c) and (d), and the "Reserve" column shows the interfaces (c) and (d), and the "Reserve" column shows the
resulting reservation state for each interface. The "Send" resulting reservation state for each interface. The "Send"
column shows the reservation requests that are sent upstream to column shows the reservation requests that are sent upstream to
previous hops (a) and (b). In the "Reserve" column, each box previous hops (a) and (b). In the "Reserve" column, each box
represents one reserved "pipe" on the outgoing link, with the represents one reserved "pipe" on the outgoing link, with the
corresponding flow descriptor. corresponding flow descriptor.
Figure 5, showing the WF style, illustrates the two possible Figure 5, showing the WF style, illustrates two distinct
merging situations. Each of the two next hops on interface (d) situations in which merging is required. (1) Each of the two next
results in a separate RSVP reservation request, as shown. These hops on interface (d) results in a separate RSVP reservation
two requests are merged into the effective flowspec 3B, which is request, as shown; these two requests must be merged into the
used to make the reservation on interface (d). To forward the effective flowspec, 3B, that is used to make the reservation on
reservation requests upstream, the reservations on the interfaces interface (d). (2) The reservations on the interfaces (c) and (d)
(c) and (d) are merged; as a result, the larger flowspec 4B is must be merged in order to forward the reservation requests
forwarded upstream to each previous hop. upstream; as a result, the larger flowspec 4B is forwarded
upstream to each previous hop.
| |
Send | Reserve Receive Send | Reserve Receive
| |
| _______ | _______
WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} ) WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} )
| |_______| | |_______|
| |
-----------------------|---------------------------------------- -----------------------|----------------------------------------
| _______ | _______
skipping to change at page 16, line 4 skipping to change at page 15, line 18
| _______ | _______
WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} ) WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} )
| |_______| | |_______|
| |
-----------------------|---------------------------------------- -----------------------|----------------------------------------
| _______ | _______
WF( *{4B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} ) WF( *{4B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} )
| |_______| <- WF( *{2B} ) | |_______| <- WF( *{2B} )
Figure 5: Wildcard-Filter (WF) Reservation Example Figure 5: Wildcard-Filter (WF) Reservation Example
Figure 6 shows Fixed-Filter (FF) style reservations. The flow Figure 6 shows Fixed-Filter (FF) style reservations. The flow
descriptors for senders S2 and S3, received from outgoing descriptors for senders S2 and S3, received from outgoing
interfaces (c) and (d), are packed into the request forwarded to interfaces (c) and (d), are packed (not merged) into the request
previous hop (b). On the other hand, the three different flow forwarded to previous hop (b). On the other hand, the three
descriptors for sender S1 are merged into the single request FF( different flow descriptors specifying sender S1 are merged into
S1{4B} ), which is sent to previous hop (a). For each outgoing the single request FF( S1{4B} ) that is sent to previous hop (a).
interface, there is a separate reservation for each source that For each outgoing interface, there is a separate reservation for
has been requested, but this reservation is shared among all the each source that has been requested, but this reservation will be
receivers that made the request. shared among all the receivers that made the request.
| |
Send | Reserve Receive Send | Reserve Receive
| |
| ________ | ________
FF( S1{4B} ) <- (a) | (c) | S1{4B} | (c) <- FF( S1{4B}, S2{5B} ) FF( S1{4B} ) <- (a) | (c) | S1{4B} | (c) <- FF( S1{4B}, S2{5B} )
| |________| | |________|
| | S2{5B} | | | S2{5B} |
| |________| | |________|
---------------------|--------------------------------------------- ---------------------|---------------------------------------------
| ________ | ________
<- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} ) <- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} )
FF( S2{5B}, S3{B} ) | |________| <- FF( S1{B} ) FF( S2{5B}, S3{B} ) | |________| <- FF( S1{B} )
| | S3{B} | | | S3{B} |
| |________| | |________|
Figure 6: Fixed-Filter (FF) Reservation Example Figure 6: Fixed-Filter (FF) Reservation Example
Figure 7 shows an example of Shared-Explicit (SE) style Figure 7 shows an example of Shared-Explicit (SE) style
reservations. When SE-style reservations are merged, the reservations. When SE-style reservations are merged, the
resulting filter spec is the union of the original filter specs. resulting filter spec is the union of the original filter specs,
and the resulting flowspec is the largest flowspec.
| |
Send | Reserve Receive Send | Reserve Receive
| |
| ________ | ________
SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} ) SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} )
| | {B} | | | {B} |
| |________| | |________|
---------------------|--------------------------------------------- ---------------------|---------------------------------------------
| __________ | __________
skipping to change at page 19, line 37 skipping to change at page 18, line 37
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.9). An routers in the path to the next RSVP hop (see Section 2.9).
RSVP daemon preserves the next and previous hop addresses in its
reservation and path state, respectively.
There are two fundamental RSVP message types: Resv and Path. 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 messages must follow exactly
follow exactly the reverse of the routes the data packets will the reverse of the path(s) the data packets will use, upstream to
use, upstream to all the sender hosts included in the sender all the sender hosts included in the sender selection. They
selection. Resv messages are delivered to the sender hosts create and maintain "reservation state" in each node along the
themselves so that the hosts can set up appropriate traffic path(s). Resv messages must finally be delivered to the sender
control parameters for the first hop. hosts themselves, so that the hosts can set up appropriate traffic
control parameters for the first hop. The processing of Resv
messages was discussed previously in Section 1.2.
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
messages store "path state" in each node along the way. This path store "path state" in each node along the way. This path state
state includes at least the unicast IP address of the previous hop includes at least the unicast IP address of the previous hop node,
node, which is used to route the Resv messages hop-by-hop in the which is used to route the Resv messages hop-by-hop in the reverse
reverse direction. (In the future, some routing protocols may direction. (In the future, some routing protocols may supply
supply reverse path forwarding information directly, replacing the reverse path forwarding information directly, 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 Sender Templates have exactly the same expressive power and
general at present, specifying only the sender IP address and format as filter specs that appear in Resv messages.
optionally the UDP/TCP sender port. It assumes the protocol Therefore a Sender Template may specify only the sender IP
Id specified for the session. address and optionally the UDP/TCP sender port, and it
assumes the protocol 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 upstream links. Admission Control failures.
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 in Path messages sent downstream. is then forwarded in Path messages sent downstream.
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.9). 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, An RSVP session is normally 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
ProtocolId specifies a protocol that does not have a destination ProtocolId specifies a protocol that does not have a destination
port field in the format used by UDP and TCP. port field in the format used by UDP and TCP.
RSVP allows any value for ProtocolId. However, end-system RSVP allows any value for ProtocolId. However, end-system
implementations of RSVP may know about certain values for this implementations of RSVP may know about certain values for this
field, and in particular must know about the values for UDP and field, and in particular the values for UDP and TCP (17 and 6,
TCP (17 and 6, respectively). An end system should give an error respectively). An end system may give an error to an application
to an application that either: 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 specify the pair: (SrcAddress, Filter specs and sender templates specify the pair: (SrcAddress,
SrcPort), where SrcPort is a UDP/TCP source port field (i.e., a SrcPort), where SrcPort is a UDP/TCP source port field (i.e., a
16-bit quantity carried at octet offset +0 in the transport 16-bit quantity carried at octet offset +0 in the transport
header). SrcPort may be omitted (set to zero) in certain cases. header). SrcPort may be omitted (set to zero) in certain cases.
The following rules hold for the use of zero DstPort and/or The following rules hold for the use of zero DstPort and/or
SrcPort fields in RSVP. 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 reservation state for the same DestAddress and
and ProtocolId must have DstPort values that are all zero or ProtocolId must each 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 UDP/TCP- 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.
skipping to change at page 22, line 17 skipping to change at page 21, line 20
As noted earlier, a single physical interface may receive multiple As noted earlier, a single physical interface may receive multiple
reservation requests 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. The installed reservation should reservation on that interface. The installed reservation should
have an effective flowspec that is the "largest" 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
"largest" of the flowspecs requested by the different next hops "largest" of the flowspecs requested by the different next hops
(however, in certain cases the "smallest" is taken rather than the (however, in certain cases the "smallest" is taken rather than the
largest, see Section 3.4). These cases all represent flowspec largest, see Section 3.4). These cases both represent flowspec
merging. merging.
Flowspec merging requires calculation of the "largest" of a set of Flowspec merging requires calculation of the "largest" of a set of
flowspecs. However, since flowspecs are generally multi- flowspecs. However, since flowspecs are generally multi-
dimensional vectors (they may contain both Tspec and Rspec dimensional vectors (they may contain both Tspec and Rspec
components, each of which may itself be multi-dimensional), it may components, each of which may itself be multi-dimensional), it may
not be possible to strictly order two flowspecs. For example, if not be possible to strictly order two flowspecs. For example, if
one request calls for a higher bandwidth and another calls for a one request calls for a higher bandwidth and another calls for a
tighter delay bound, one is not "larger" than the other. In such tighter delay bound, one is not "larger" than the other. In such
a case, instead of taking the larger, RSVP must compute and use a a case, instead of taking the larger, RSVP must compute and use a
third flowspec that is at least as large as each. Mathematically, third flowspec that is at least as large as each. Mathematically,
RSVP merges flowspecs using the " least upper bound" (LUB) instead RSVP merges flowspecs using the " least upper bound" (LUB) instead
of the maximum. Typically, the LUB is calculated by creating a of the maximum. Typically, the LUB is calculated by creating a
new flowspec whose components are individually either the max or new flowspec whose components are individually either the max or
the min of corresponding components of the flowspecs being merged. the min of corresponding components of the flowspecs being merged.
For example, the LUB of Tspecs defined by token bucket parameters For example, the LUB of Tspecs defined by token bucket parameters
is computed by taking the maximums of the bucket size and the rate is computed by taking the maximums of the bucket size and the rate
parameters. In several cases, the GLB (Greatest Lower Bound) is parameters. In some cases, the GLB (Greatest Lower Bound) is
used instead of the LUB; this simply interchanges max and min required instead of the LUB; this simply interchanges max and min
operations. operations.
We can now give the complete rules for calculating the effective The following steps are used to calculate the effective flowspec
flowspec (Te, Re) to be installed on an interface. Here Te is the (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. RSVP calculates the LUB of the flowspecs that arrived in Resv
of the Rspecs in Resv messages from different next hops messages from different next hops (e.g., D and D') but the
(e.g., D and D') but the same outgoing interface (d). same outgoing interface (d).
2. All Tspecs that were supplied in Path messages from different This calculation yields a flowspec that is opaque to RSVP but
previous hops (e.g., some or all of A, B, and B' in Figure 9) actually consists of the pair (Re, Resv_Te), where Re is the
are summed; call this sum Path_Te. LUB of the Rspecs and Resv_Te is the LUB of the Tspecs from
the Resv messages.
3. The maximum Tspec supplied in Resv messages from different 2. RSVP calculates Path_Te, the sum of all Tspecs that were
next hops (e.g., D and D') is calculated; call this Resv_Te. supplied in Path messages from different previous hops (e.g.,
some or all of A, B, and B' in Figure 9).
4. Te is the GLB (greatest lower bound) of Path_Te and Resv_Te. 3. RSVP passes these two results, (Re, Resv_Te) and Path_Te, to
traffic control. Traffic control will compute the "minimum"
of Path_Te and Resv_Te in an appropriate, perhaps service-
dependent, manner.
Flowspecs, Tspecs, and Adspecs are opaque to RSVP. Therefore, the The definition and implementation of the rules for comparing
last of these steps is actually performed by traffic control. The
definition and implementation of the rules for comparing
flowspecs, calculating LUBs and GLBs, and summing Tspecs are flowspecs, calculating LUBs and GLBs, and summing Tspecs are
outside the definition of RSVP [ServTempl95a]. Section 3.10.4 outside the definition of RSVP. Section 3.10.4 shows generic
shows generic calls that an RSVP daemon could use for these calls that an RSVP daemon could use for these functions.
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. State 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 existence of state at
node. that 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 an RSVP and routers is expected to handle the occasional loss of an RSVP
message. 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 deleting state. the network traffic
that the network traffic control mechanism be statically control mechanism should be statically configured to grant some
configured to grant some minimal bandwidth for RSVP messages to minimal bandwidth for RSVP messages to protect them from
protect them from congestion losses. 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 will be an sending revised Path and/or Resv messages. The result will be 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; unused state will time out if it is not explicitly torn
down.
In steady state, refreshing is performed hop-by-hop, to allow In steady state, refreshing is performed hop-by-hop, to allow
merging. When the received state differs from the stored state, merging. When the received state differs from the stored state,
the stored state is updated. If this update results in the stored state is updated. If this update results in
modification of state to be forwarded in refresh messages, these modification of state to be forwarded in refresh messages, these
refresh messages must be generated and forwarded immediately, so refresh messages must be generated and forwarded immediately, so
that 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
router with one sender and one receiver on each interface (and router with one sender and one receiver on each interface (and
assumes one next/previous hop per interface). Interfaces (a) and assumes one next/previous hop per interface). Interfaces (a) and
(c) serve as both outgoing and incoming interfaces for this (c) serve as both outgoing and incoming interfaces for this
session. Both receivers are making wildcard-scope reservations, session. Both receivers are making wildcard-style reservations,
in which the Resv messages are forwarded to all previous hops for in which the Resv messages are forwarded to all previous hops for
senders in the group, with the exception of the next hop from senders in the group, with the exception of the next hop from
which they came. The result is independent reservations in the which they came. The result is independent reservations in the
two directions. two directions.
There is an additional rule governing the forwarding of Resv There is an additional rule governing the forwarding of Resv
messages: state from RESV messages received from outgoing messages: state from RESV messages received from outgoing
interface Io should be forwarded to incoming interface Ii only if interface Io should be forwarded to incoming interface Ii only if
Path messages from Ii are forwarded to Io. Path messages from Ii are forwarded to Io.
skipping to change at page 25, line 44 skipping to change at page 24, line 44
ResvTear. A PathTear message travels towards all receivers ResvTear. A PathTear message travels towards all receivers
downstream from its point of initiation and deletes path state, as downstream from its point of initiation and deletes path state, as
well as all dependent reservation state, along the way. An well as all dependent reservation state, along the way. An
ResvTear message deletes reservation state and travels towards all ResvTear message deletes reservation state and travels towards all
senders upstream from its point of initiation. A PathTear senders upstream from its point of initiation. A PathTear
(ResvTear) message may be conceptualized as a reversed-sense Path (ResvTear) message may be conceptualized as a reversed-sense Path
message (Resv message, respectively). 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 or service preemption. Once initiated, a teardown
forwarded hop-by-hop without delay. A teardown message deletes request must be forwarded hop-by-hop without delay. A teardown
the specified state in the node where it is received. As always, message deletes the specified state in the node where it is
this state change will be propagated immediately to the next node, received. As always, this state change will be propagated
but only if there will be a net change after merging. As a immediately to the next node, but only if there will be a net
result, an ResvTear message will prune the reservation state back change after merging. As a result, an ResvTear message will prune
(only) as far as possible. the reservation state back (only) as far as possible.
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.
It should be possible to tear down any subset of the established
state. For path state, the granularity for teardown is a single
sender. For reservation state, the granularity is an individual
filter spec. For example, refer to Figure 7. Receiver R1 could
send a ResvTear message for sender S2 only (or for any subset of
the filter spec list), leaving S1 in place.
A ResvTear message specifies the style and filters; any flowspec
is ignored. Whatever flowspec is in place will be removed if all
its filter specs are torn down.
2.6 Errors 2.6 Errors
There are two RSVP error messages, ResvErr and PathErr. PERR There are two RSVP error messages, ResvErr and PathErr. PERR
messages are very simple. They are simply sent upstream to the messages are very simple; they are simply sent upstream to the
sender that created the error, and they do not change path state sender that created the error, and they do not change path state
in the nodes though which they pass. There are only a few in the nodes though which they pass. There are only a few
possible causes of path errors. possible causes of path errors.
However, there are a number of ways for a syntactically valid However, there are a number of ways for a syntactically valid
reservation request to fail at some node along the path, for reservation request to fail at some node along the path. A node
example: may also decide to preempt an established reservation. The
handling of ResvErr messages is somewhat complex (Section 3.4).
1. The effective flowspec that is computed using the new request Since a request that fails may be the result of merging a number
may fail admission control. of requests, a reservation error must be reported to all of the
responsible receivers. In addition, merging heterogeneous
2. Administrative policy may prevent the requested reservation.
3. There may be no matching path state, so that the request
cannot be forwarded towards the sender(s).
4. A reservation style that requires the explicit selection of a
unique sender may have a filter spec that is ambiguous, i.e.,
that matches more than one sender in the path state, due to
the use of wildcard fields in the filter spec.
5. The requested style may be incompatible with the style(s) of
existing reservations. The incompatibility may occur among
reservations for the same session on the same outgoing
interface, or among effective reservations on different
outgoing interfaces.
A node may also decide to preempt an established reservation.
The handling of ResvErr messages is somewhat complex (Section
3.4). Since a request that fails may be the result of merging a
number of requests, a reservation error must be reported to all of
the responsible receivers. In addition, merging heterogeneous
requests creates a potential difficulty known as the "killer requests creates a potential difficulty known as the "killer
reservation" problem, in which one request could deny service to reservation" problem, in which one request could deny service to
another. There are actually two killer-reservation problems. another. There are actually two killer-reservation problems.
1. The first killer reservation problem (KR-I) arises when there 1. The first killer reservation problem (KR-I) arises when there
is already a reservation Q0 in place. If another receiver is already a reservation Q0 in place. If another receiver
now makes a larger reservation Q1 > Q0, the result of merging now makes a larger reservation Q1 > Q0, the result of merging
Q0 and Q1 may be rejected by admission control in some Q0 and Q1 may be rejected by admission control in some
upstream node. This must not deny service to Q0. upstream node. This must not deny service to Q0.
The solution to this problem is simple: when admission The solution to this problem is simple: when admission
control fails for a reservation request, any existing control fails for a reservation request, any existing
reservation is left in place. reservation is left in place.
2. The second killer reservation problem (KR-II) is the 2. The second killer reservation problem (KR-II) is the
converse: the receiver making a reservation Q1 is persistent converse: the receiver making a reservation Q1 is persistent
even though Admission Control is failing for Q1 in some node. even though Admission Control is failing for Q1 in some node.
This must not prevent a different receiver from now This must not prevent a different receiver from now
establishing a smaller reservation Q0 that will succeed. establishing a smaller reservation Q0 that would succeed if
not merged with Q1.
To solve this problem, a ResvErr message establishes To solve this problem, a ResvErr message establishes
additional state, called "blockade state", in each node additional state, called "blockade state", in each node
through which it passes. Blockade state in a node modifies through which it passes. Blockade state in a node modifies
the merging procedure to omit the offending flowspec (Q1 in the merging procedure to omit the offending flowspec (Q1 in
the example) from the merge, allowing a smaller request to be the example) from the merge, allowing a smaller request to be
forwarded and established. The Q1 reservation state is said forwarded and established. The Q1 reservation state is said
to be "blockaded". Detailed rules are presented in Section to be "blockaded". Detailed rules are presented in Section
3.4. 3.4.
A reservation request that fails Admission Control creates A reservation request that fails Admission Control creates
blockade state but is left in place in nodes downstream of the blockade state but is left in place in nodes downstream of the
failure point. It has been suggested that these reservations failure point. It has been suggested that these reservations
downstream from the failure represent "wasted" reservations and downstream from the failure represent "wasted" reservations and
should be timed out if not actively deleted. However, in general should be timed out if not actively deleted. However, the
the downstream reservations will not be "wasted". downstream reservations are left in place, for the following
reasons:
o There are two possible reasons for a receiver persisting in a o There are two possible reasons for a receiver persisting in a
failed reservation: (1) it is polling for resource failed reservation: (1) it is polling for resource
availability along the entire path, or (2) it wants to obtain availability along the entire path, or (2) it wants to obtain
the desired QoS along as much of the path as possible. the desired QoS along as much of the path as possible.
Certainly in the second case, and perhaps in the first case, Certainly in the second case, and perhaps in the first case,
the receiver will want to hold onto the reservations it has the receiver will want to hold onto the reservations it has
made downstream from the failure. made downstream from the failure.
o If these downstream reservations were not retained, the o If these downstream reservations were not retained, the
skipping to change at page 28, line 4 skipping to change at page 26, line 43
the desired QoS along as much of the path as possible. the desired QoS along as much of the path as possible.
Certainly in the second case, and perhaps in the first case, Certainly in the second case, and perhaps in the first case,
the receiver will want to hold onto the reservations it has the receiver will want to hold onto the reservations it has
made downstream from the failure. made downstream from the failure.
o If these downstream reservations were not retained, the o If these downstream reservations were not retained, the
responsiveness of RSVP to certain transient failures would be responsiveness of RSVP to certain transient failures would be
impaired. For example, suppose a route "flaps" to an impaired. For example, suppose a route "flaps" to an
alternate route that is congested, so an existing reservation alternate route that is congested, so an existing reservation
suddenly fails, then quickly recovers to the original route. suddenly fails, then quickly recovers to the original route.
The blockade state in each downstream router must not remove The blockade state in each downstream router must not remove
the state or prevent its immediate refresh. the state or prevent its immediate refresh.
o If we did not refresh the downstream reservations, they might o If we did not refresh the downstream reservations, they might
time out, to be restored every Td seconds. Such on/off time out, to be restored every Tb seconds (where Tb is the
behavior might be very distressing for users. blockade state timeout interval). Such intermittent behavior
might be very distressing for users.
2.7 Confirmation 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 Rj's 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 a are not forwarded further, and if the Resv included a
confirmation-request object, a ResvConf message is sent back to confirmation-request object, a ResvConf message is sent back to
Rj. This mechanism has the following consequences: Rj. If the confirmation request is forwarded, it is forwarded
immediately, and no more than once for each request.
This confirmation 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 ResvErr place for a session will normally result in either a ResvErr
or a ResvConf message back to the receiver from each sender. or a ResvConf message back to the receiver from each sender.
In this case, the ResvConf message will be an end-to-end In this case, the ResvConf message will be an end-to-end
confirmation. confirmation.
o The receipt of a ResvConf gives no guarantees. Assume the o The receipt of a ResvConf gives no guarantees. Assume the
first two reservation requests from receivers R1 and R2 first two reservation requests from receivers R1 and R2
arrive at the node where they are merged. R2, whose arrive at the node where they are merged. R2, whose
skipping to change at page 29, line 5 skipping to change at page 27, line 48
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, there will be policy control as well as admission Therefore, there is likely to be policy control as well as
control over the establishment of reservations. As input to admission control over the establishment of reservations. As
policy control, RSVP messages may carry policy data. Policy data input to policy control, RSVP messages may carry "policy data".
may include credentials identifying users or user classes, account Policy data may include credentials identifying users or user
numbers, limits, quotas, etc. Like flowspecs, policy data will be classes, account numbers, limits, quotas, etc. Like flowspecs,
opaque to RSVP, which will simply pass it to a "Local Policy policy data will be opaque to RSVP, which will simply pass it to a
Module" (LPM) for a decision. "Local Policy Module" (LPM) for a decision.
To protect the integrity of the policy control mechanisms, it may To protect the integrity of the policy control mechanisms, it may
be necessary to ensure the integrity of RSVP messages against be necessary to ensure the integrity of RSVP messages against
corruption or spoofing, hop by hop. For this purpose, RSVP corruption or spoofing, hop by hop. For this purpose, RSVP
messages may carry integrity objects that can be created and messages may carry integrity objects that can be created and
verified by neighbor RSVP-capable nodes. These objects use a verified by neighbor RSVP-capable nodes. These objects use a
keyed cryptographic digest technique and assume that RSVP keyed cryptographic digest technique and assume that RSVP
neighbors share a secret [Baker96]. neighbors share a secret [Baker96].
User policy data in reservation request messages presents a User policy data in reservation request messages presents a
skipping to change at page 29, line 45 skipping to change at page 28, line 40
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.
This document does not specify the contents of policy data, the This document does not specify the contents of policy data, the
structure of an LPM, or any generic policy models. These will be structure of an LPM, or any generic policy models. These will be
defined in the future. defined in the future.
2.9 Automatic RSVP Tunneling 2.9 Non-RSVP Clouds
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 useful realtime service.
RSVP automatically tunnels through such a non-RSVP cloud. Both RSVP is designed to operate correctly through such a non-RSVP
RSVP and non-RSVP routers forward Path messages towards the cloud. Both RSVP and non-RSVP routers forward Path messages
destination address using their local uni-/multicast routing towards the destination address using their local uni-/multicast
table. Therefore, the routing of Path messages will be unaffected routing table. Therefore, the routing of Path messages will be
by non-RSVP routers in the path. When a Path message traverses a unaffected by non-RSVP routers in the path. When a Path message
non-RSVP cloud, it carries to the next RSVP-capable node the IP traverses a non-RSVP cloud, it carries to the next RSVP-capable
address of the last RSVP-capable router before entering the cloud. node the IP address of the last RSVP-capable router before
This effectively constructs a tunnel through the cloud for Resv entering the cloud. An Resv message is then forwarded directly to
messages, which can then be forwarded directly to the next RSVP- the next RSVP-capable router on the path(s) back towards the
capable router on the path(s) back towards the source. source.
Even though RSVP operates correctly through a non-RSVP cloud, the Even though RSVP operates correctly through a non-RSVP cloud, the
non-RSVP-capable nodes will in general perturb the QoS provided to non-RSVP-capable nodes will in general perturb the QoS provided to
a receiver. Therefore, RSVP tries to inform the receiver when a receiver. Therefore, RSVP tries to inform the receiver when
there are non-RSVP-capable hops in the path to a given sender, by there are non-RSVP-capable hops in the path to a given sender, by
means of two flag bits in the SESSION object of a Path message; means of two flag bits in the SESSION object of a Path message;
see Section 3.7 and Appendix A. see Section 3.7 and Appendix A.
Some topologies of RSVP routers and non-RSVP routers can cause Some topologies of RSVP routers and non-RSVP routers can cause
Resv messages to arrive at the wrong RSVP-capable node, or to Resv messages to arrive at the wrong RSVP-capable node, or to
arrive at the wrong interface of the correct node. An RSVP daemon arrive at the wrong interface of the correct node. An RSVP daemon
must be prepared to handle either situation. If the destination must be prepared to handle either situation. If the destination
address does not match any local interface and the message is not address does not match any local interface and the message is not
a Path or PathTear, the message must be forwarded without further a Path or PathTear, the message must be forwarded without further
processing by this node. When a Resv message does arrive at the processing by this node. When a Resv message does arrive at the
addessed node, the IP destination address (or the LIH, defined addressed node, the IP destination address (or the LIH, defined
later) must be used to determine the interface to receive the later) must be used to determine the interface to receive the
reservation. reservation.
2.10 Host Model 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, ProtocolId, and perhaps the generalized
port, must be assigned and communicated to all the senders and destination port, must be assigned and communicated to all the
receivers by some out-of-band mechanism. When an RSVP session is senders and receivers by some out-of-band mechanism. When an RSVP
being set up, the following events happen at the end systems. session is being set up, the following events happen at the end
systems.
H1 A receiver joins the multicast group specified by H1 A receiver joins the multicast group specified by
DestAddress, using IGMP. DestAddress, using IGMP.
H2 A potential sender starts sending RSVP Path messages to the H2 A potential sender starts sending RSVP Path messages to the
DestAddress. DestAddress.
H3 A receiver application receives a Path message. H3 A receiver application receives a Path message.
H4 A receiver starts sending appropriate Resv messages, H4 A receiver starts sending appropriate Resv messages,
skipping to change at page 32, line 9 skipping to change at page 31, line 9
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.10.1 discusses the general requirements and However, Section 3.10.1 discusses the general requirements and
outlines a generic interface. 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 or message fragment consists of a common header, An RSVP message consists of a common header, followed by a body
an optional integrity-check data structure, and a body consisting consisting of a variable number of variable-length, typed "
of a variable number of variable-length, typed "objects". The objects". The following subsections define the formats of the
integrity-check data structure is itself an object, of class common header, the standard object header, and each of the RSVP
INTEGRITY [Baker96]. In a fragmented message, INTEGRITY objects message types.
must occur either in every fragment or else in no fragment.
Fragmentation of a message allows division of an object across two
(or more) successive fragments.
The following subsections define the formats of the common header, For each RSVP message type, there is a set of rules for the
the object structures, and each of the RSVP message types. For
each RSVP message type, there is a set of rules for the
permissible choice of object types. These rules are specified permissible choice of object types. These rules are specified
using Backus-Naur Form (BNF) augmented with square brackets using Backus-Naur Form (BNF) augmented with square brackets
surrounding optional sub-sequences. The BNF implies an order for surrounding optional sub-sequences. The BNF implies an order for
the objects in a message. However, in many (but not all) cases, the objects in a message. However, in many (but not all) cases,
object order makes no logical difference. An implementation object order makes no logical difference. An implementation
should create messages with the objects in the order shown here, should create messages with the objects in the order shown here,
but accept the objects in any order except where the order is but accept the objects in any permissible order.
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| Msg Type | RSVP Checksum |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| RSVP Length | (Reserved) | Send_TTL | | Send_TTL | (Reserved) | RSVP Length |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Message ID |
+----------+--+-------------+-------------+-------------+
|(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
This flag indicates that an INTEGRITY object follows
immediately after the common header. The use of the
INTEGRITY object is described in [Baker96].
0x02-0x80: Reserved 0x01-0x08: Reserved
Type: 8 bits No flag bits are defined yet.
1 = PATH Msg Type: 8 bits
2 = RESV 1 = Path
3 = PERR 2 = Resv
3 = PathErr
4 = RERR 4 = ResvErr
5 = PTEAR 5 = PathTear
6 = RTEAR 6 = ResvTear
7 = RACK 7 = ResvConf
RSVP Checksum: 16 bits RSVP Checksum: 16 bits
The one's complement of the one's complement sum of the The one's complement of the one's complement sum of the
message (fragment), with the checksum field replaced by message, with the checksum field replaced by zero for the
zero for the purpose of computing the checksum. An all- purpose of computing the checksum. An all-zero value
zero value means that no checksum was transmitted. means that no checksum was transmitted.
RSVP Length: 16 bits
The total length of this RSVP packet in bytes, including
the common header and the variable-length objects that
follow. If the MF flag is on or the Fragment Offset field
is non-zero, this will generally differ from the length of
the current fragment.
Send_TTL: 8 bits Send_TTL: 8 bits
The IP TTL value with which the message was sent. The IP TTL value with which the message was sent. See
Section 3.7.
Message ID: 32 bits
An unique identifying value that is used to identify and
reassemble the fragments of a single message. It is
assigned to the RSVP message by the node whose address is
the IP source address of the message (fragment).
MF: More Fragments Flag: 1 bit
This flag is the low-order bit of a byte; the seven high-
order bits are reserved. It is on for all but the last
fragment of a message.
Fragment Offset: 24 bits
This field gives the byte offset of the current fragment
in the complete message.
For a Path or PathTear message, the Message Id is assigned by RSVP Length: 16 bits
the sender host, and it must be copied at each successive node
into forwarded messages. For other messages, it is assigned at
the most recent RSVP hop to forward the message. When a
message is fragmented, the Messsage Id must be copied into each
fragment. When a fragmented packet is received, it may be
reassembled by RSVP out of fragments carrying the same Message
Id and IP source address.
RSVP messages that exceed the MTU of the interface on which The total length of this RSVP message in bytes, including
they are being sent must be split into fragments, each of which the common header and the variable-length objects that
will fit into an MTU. follow.
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 35, line 23 skipping to change at page 33, line 24
A NULL object has a Class-Num of zero, and its C-Type A NULL object has a Class-Num of zero, and its C-Type
is ignored. Its length must be at least 4, but can is ignored. Its length must be at least 4, but can
be any multiple of 4. A NULL object may appear be any multiple of 4. A NULL object may appear
anywhere in a sequence of objects, and its contents anywhere in a sequence of objects, and its contents
will be ignored by the receiver. will be ignored by the receiver.
SESSION SESSION
Contains the IP destination address (DestAddress), Contains the IP destination address (DestAddress),
the IP protocol id, and a generalized destination the IP protocol id, and some form of generalized
port, to define a specific session for the other destination port, to define a specific session for
objects that follow. Required in every RSVP message. the other objects that follow. Required in every
RSVP message.
RSVP_HOP RSVP_HOP
Carries the IP address of the RSVP-capable node that Carries the IP address of the RSVP-capable node that
sent this message. This document refers to a sent this message and a logical outgoing interface
RSVP_HOP object as a PHOP ("previous hop") object for handle (LIH; see Section 3.2). This document refers
downstream messages or as a NHOP ("next hop") object to a RSVP_HOP object as a PHOP ("previous hop")
for upstream messages. object for downstream messages or as a NHOP (" next
hop") object 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.6. 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
skipping to change at page 35, line 48 skipping to change at page 34, line 4
the creator of the message; see 3.6. 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
Defines a desired QoS, in a Resv message. Defines a desired QoS, in a Resv message.
FILTER_SPEC FILTER_SPEC
Defines a subset of session data packets that should Defines a subset of session data packets that should
receive the desired QoS (specified by an FLOWSPEC receive the desired QoS (specified by an FLOWSPEC
object), in a Resv message. object), in a Resv message.
SENDER_TEMPLATE SENDER_TEMPLATE
Contains a sender IP address and perhaps some Contains a sender IP address and perhaps some
additional demultiplexing information to identify a additional demultiplexing information to identify a
sender, in a Path message. sender. Required in a Path message.
SENDER_TSPEC SENDER_TSPEC
Defines the traffic characteristics of a sender's Defines the traffic characteristics of a sender's
data stream, in a Path message. data stream. Required in a Path message.
ADSPEC ADSPEC
Carries OPWA data, in a Path message. Carries OPWA data, in a Path message.
ERROR_SPEC ERROR_SPEC
Specifies an error, in a PathErr or ResvErr message. Specifies an error in a PathErr, ResvErr, or a
confirmation in a ResvConf message.
POLICY_DATA POLICY_DATA
Carries information that will allow a local policy Carries information that will allow a local policy
module to decide whether an associated reservation is module to decide whether an associated reservation is
administratively permitted. May appear in Path, administratively permitted. May appear in Path,
Resv, PathErr, or ResvErr message. Resv, PathErr, or ResvErr message.
INTEGRITY INTEGRITY
Contains cryptographic data to authenticate the Carries cryptographic data to authenticate the
originating node and to verify the contents of this originating node and to verify the contents of this
RSVP message. See [Baker96]. RSVP message. The use of the INTEGRITY object is
described in [Baker96].
SCOPE SCOPE
An explicit list of sender hosts towards which to Carries an explicit list of sender hosts towards
forward a message. May appear in a Resv, ResvErr, or which the information in the message is to be
ResvTear message. forwarded. May appear in a Resv, ResvErr, or
ResvTear message. See Section 3.3.
RESV_CONFIRM RESV_CONFIRM
Carries the IP address of a receiver that requested a Carries the IP address of a receiver that requested a
confirmation. May appear in a Resv or ResvConf confirmation. May appear in a Resv or ResvConf
message. message.
C-Type C-Type
Object type, unique within Class-Num. Values are defined Object type, unique within Class-Num. Values are defined
skipping to change at page 37, line 29 skipping to change at page 35, line 35
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.
Each RSVP-capable node along the path(s) captures Path messages
and processes them to build local path state. The node then
forwards the Path messages towards the receiver(s), replicating
it as dictated by multicast routing, while preserving the
original IP source address. Path messages eventually reach the
applications on all receivers; however, they are not looped
back to a receiver running in the same application process as
the sender.
The format of a Path message is as follows: The format of a Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<sender descriptor> <sender descriptor>
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ] [ <ADSPEC> ]
If the INTEGRITY object is present, there must be an INTEGRITY
object immediately following the common header in every If the INTEGRITY object is present, it must immediately follow
fragment of the message, in this and all other messages. There the common header. There are no other requirements on
are no other requirements on transmission order, although the transmission order, although the above order is recommended.
above order is recommended. Any number of POLICY_DATA objects Any number of POLICY_DATA objects may appear.
may appear.
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 previous hop address, i.e., the IP address of the
message was most recently sent. The SENDER_TEMPLATE object interface through which the Path message was most recently
defines the format of data packets from this sender, while the sent. It also carries a logical interface handle (LIH).
SENDER_TSPEC object specifies the traffic characteristics of
the flow. Optionally, there may be an ADSPEC object carrying
advertising (OPWA) data.
A Path message received at a node is processed to create path The SENDER_TEMPLATE object defines the format of data packets
state for the sender defined by the SENDER_TEMPLATE and SESSION from this sender, while the SENDER_TSPEC object specifies the
objects. Any POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are traffic characteristics of the flow. Optionally, there may be
also saved in the path state. If an error is encountered while an ADSPEC object carrying advertising (OPWA) data.
processing a Path message, a PathErr message is sent to the
originating sender of the Path message. PATH messages must Each RSVP-capable node along the path(s) captures a Path
satisfy the rules on SrcPort and DstPort in Section 2.2. message and processes it to create path state for the sender
defined by the SENDER_TEMPLATE and SESSION objects. Any
POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in
the path state. If an error is encountered while processing a
Path message, a PathErr message is sent to the originating
sender of the Path message. PATH messages must satisfy the
rules on SrcPort and DstPort in Section 2.2.
Periodically, the RSVP daemon at a node scans the path state to Periodically, the RSVP daemon at a node scans the path state to
create new Path messages to forward downstream. Each message create new Path messages to forward towards the receiver(s).
contains a sender descriptor defining one sender. The RSVP Each message contains a sender descriptor defining one sender,
daemon forwards these messages using routing information it and carries the original sender's IP address as its IP source
obtains from the appropriate uni-/multicast routing daemon. address. Path messages eventually reach the applications on
The route depends upon the session DestAddress, and for some all receivers; however, they are not looped back to a receiver
routing protocols also upon the source (sender's IP) address. running in the same application process as the sender.
The routing information generally includes the list of none or
more outgoing interfaces to which the Path message to be The RSVP daemon forwards Path messages, and replicates them as
forwarded. Because each outgoing interface has a different IP required, using routing information it obtains from the
address, the Path messages sent out different interfaces appropriate uni-/multicast routing daemon. The route depends
contain different PHOP addresses. In addition, ADSPEC objects upon the session DestAddress, and for some routing protocols
carried in Path messages will also generally differ for also upon the source (sender's IP) address. The routing
different outgoing interfaces. information generally includes the list of none or more
outgoing interfaces to which the Path message to be forwarded.
Because each outgoing interface has a different IP address, the
Path messages sent out different interfaces contain different
PHOP addresses. In addition, ADSPEC objects carried in Path
messages will also generally differ for different outgoing
interfaces.
Some IP multicast routing protocols (e.g., DVMRP, PIM, and Some IP multicast routing protocols (e.g., DVMRP, PIM, and
MOSPF) also keep track of the expected incoming interface for MOSPF) also keep track of the expected incoming interface for
each source host to a multicast group. Whenever this each source host to a multicast group. Whenever this
information is available, RSVP should check the incoming information is available, RSVP should check the incoming
interface of each Path message and immediately discard those interface of each Path message and do special handling of those
messages that have arrived on the wrong interface. messages Path messages that have arrived on the wrong
interface; see Section 3.8.
3.1.4 Resv Messages 3.1.4 Resv Messages
Resv messages carry reservation requests hop-by-hop from Resv messages carry reservation requests hop-by-hop from
receivers to senders, along the reverse paths of data 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> [ <INTEGRITY> ] <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <POLICY_DATA> ... ]
[ <RESV_CONFIRM> ] [ <SCOPE> ] [ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list> <STYLE> <flow descriptor list>
<flow descriptor list> ::= <flow descriptor> | <flow descriptor list> ::= <flow descriptor> |
<flow descriptor list> <flow descriptor> <flow descriptor list> <flow descriptor>
The STYLE object followed by the flow descriptor list must
occur at the end of the message, and objects within the flow
descriptor list must follow the BNF given below. There are no
other requirements on transmission order, although the above
order is recommended.
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 interface through which the Resv message was sent. The the interface through which the Resv message was sent and the
appearance of a RESV_CONFIRM object signals a request for a LIH for the logical interface on which the reservation is
required.
The appearance of a RESV_CONFIRM object signals a request for a
reservation confirmation and carries the IP address of the reservation confirmation and carries the IP address of the
receiver to which the ResvConf should be sent. Any number of receiver to which the ResvConf should be sent. Any number of
POLICY_DATA objects may appear. POLICY_DATA objects may appear.
The STYLE object followed by the flow descriptor list must
occur at the end of the message. There are no other
requirements on transmission order, although the above order is
recommended.
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; the order descriptor list for each of the reservation styles.
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> <WF flow descriptor> ::= <FLOWSPEC>
o FF style: o FF style:
<flow descriptor list> ::= <flow descriptor list> ::=
skipping to change at page 40, line 29 skipping to change at page 38, line 36
[ <FLOWSPEC> ] <FILTER_SPEC> [ <FLOWSPEC> ] <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 ResvErr 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> <filter spec list> <FLOWSPEC> <filter spec list>
<filter spec list> ::= <FILTER_SPEC> <filter spec list> ::= <FILTER_SPEC>
| <filter spec list> <FILTER_SPEC> | <filter spec list> <FILTER_SPEC>
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 (after merging), is
follows: determined as follows:
o Explicit sender selection o Explicit sender selection
Select a particular sender by matching each FILTER_SPEC Select a particular sender by matching each FILTER_SPEC
object against the path state created from SENDER_TEMPLATE object against the path state created from SENDER_TEMPLATE
objects. An ambiguous match, i.e., a FILTER_SPEC matching objects. This match must follow the rules of Section 2.2.
more than one SENDER_TEMPLATE (e.g. through use of a
wildcard port), is an error.
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. of senders in the path state.
Whenever a Resv message with wildcard sender selection is Whenever a Resv message with wildcard sender selection is
forwarded to more than one previous hop, a SCOPE object forwarded to more than one previous hop, a SCOPE object
must be included in the message. See Section 3.3 below. must be included in the message. See Section 3.3 below.
3.1.5 Teardown Messages 3.1.5 Teardown Messages
There are two types of RSVP Teardown message, PathTear and There are two types of RSVP teardown message, PathTear and
ResvTear. ResvTear.
o A PathTear message deletes path state (which in turn o A PathTear message deletes path state (which in turn
deletes any reservation state for that sender) and travels deletes any reservation state for that sender), traveling
towards all receivers that are downstream from the towards all receivers that are downstream from the
initiating node. A PathTear message is routed like a Path initiating node. A PathTear message must be routed
message, and its IP destination address is DestAddress for exactly like the corresponding Path message. Therefore,
the session. its IP destination address must be the session
DestAddress, and its IP source address must be the address
of the sender being torn down.
o A ResvTear message deletes reservation state and travels o A ResvTear message deletes reservation state, travelling
towards all matching senders upstream from the initiating towards all matching senders upstream from the initiating
node. A ResvTear message is routed in the same way as a node. A ResvTear message must be routed link the
corresponding Resv message, and its IP destination address corresponding Resv message, and its IP destination address
is the unicast address of a previous hop. will be the unicast address of a previous hop. An
ResvTear message will be initiated by a receiver, by a
node in which reservation state has timed out, or by a
node in which a reservation has been preempted.
<PathTear Message> ::= <Common Header> [<INTEGRITY>] <PathTear Message> ::= <Common Header> [<INTEGRITY>]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<sender descriptor> <sender descriptor>
<sender descriptor> ::= (see earlier definition) <sender descriptor> ::= (see earlier definition)
<ResvTear Message> ::= <Common Header> [<INTEGRITY>] <ResvTear Message> ::= <Common Header> [<INTEGRITY>]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
[ <SCOPE> ] <STYLE> [ <SCOPE> ] <STYLE>
<flow descriptor list> <flow descriptor list>
<flow descriptor list> ::= (see earlier definition) <flow descriptor list> ::= (see earlier definition)
FLOWSPEC objects in the flow descriptor list of a ResvTear FLOWSPEC objects in the flow descriptor list of a ResvTear
message will be ignored and may be omitted. The order message will be ignored and may be omitted. The order
skipping to change at page 42, line 16 skipping to change at page 40, line 22
[ <SCOPE> ] <STYLE> [ <SCOPE> ] <STYLE>
<flow descriptor list> <flow descriptor list>
<flow descriptor list> ::= (see earlier definition) <flow descriptor list> ::= (see earlier definition)
FLOWSPEC objects in the flow descriptor list of a ResvTear FLOWSPEC objects in the flow descriptor list of a ResvTear
message will be ignored and may be omitted. The order message will be ignored and may be omitted. The order
requirements for sender descriptor, STYLE object, and flow requirements for sender descriptor, STYLE object, and flow
descriptor list are as given earlier for Path and Resv descriptor list are as given earlier for Path and Resv
messages. messages. A ResvTear message may specify any subset of the
filter specs in FF- or SE-style reservation state.
Note that, unless it is accidentally dropped along the way, a Note that, unless it is accidentally dropped along the way, a
PTEAR message will reach all receivers down stream from its PTEAR message will reach all receivers downstream from the
origination. On the other hand, a ResvTear message will cease originating node. On the other hand, a ResvTear message will
to be forwarded at the same node where merging suppresses cease to be forwarded at the node where merging would have
forwarding of the corresponding Resv messages. In each node N suppressed forwarding of the corresponding Resv message. In
along the way, if the ResvTear message causes the removal of each node N along the way, if the ResvTear message causes the
all state for this session, N will create a new teardown removal of all state for this session, N will create a new
message to be propagated further upstream; otherwise, the teardown message to be propagated further upstream; otherwise,
ResvTear message may result in the immediate forwarding of a the ResvTear message may result in the immediate forwarding of
modified Resv refresh message. a modified Resv refresh message.
For example, consider the FF-style reservations in Figure 6.
If receiver R3 send a ResvTear message for its reservation
S1{B}, there is no change in the effective reservation S1{3B}
on (d), and no message will be forwarded. If receiver R2 sends
a ResvTear message for its reservation S3{B}, the corresponding
reservation will be removed from (d) and an ResvTear for S3{B}
will be forwarded out interface (b). Finally, if receiver R1
sends a ResvTear for its reservation S1{4B}, the result will be
to remove the reservation from interface (c), and to forward
immediately a Resv message FF( S1{3B} ) out interface (a).
Deletion of path state as the result of a PathTear message or a Deletion of path state as the result of a PathTear message or a
timeout must cause any adjustments in related reservation state timeout must cause any adjustments in related reservation state
required to maintain consistency in the local node. The required to maintain consistency in the local node. The
adjustment in reservation state depends upon the style. For adjustment in reservation state depends upon the style. For
example, suppose a PathTear deletes the path state for a sender example, suppose a PathTear deletes the path state for a sender
S. If the style specifies explicit sender selection (FF or S. If the style specifies explicit sender selection (FF or
SE), any reservation with a filter spec matching S should be SE), any reservation with a filter spec matching S should be
deleted; if the style has wildcard sender selection (WF), the deleted; if the style has wildcard sender selection (WF), the
reservation should be deleted if S is the last sender to the reservation should be deleted if S is the last sender to the
skipping to change at page 42, line 50 skipping to change at page 41, line 21
already made the required changes upstream. However, at the already made the required changes upstream. However, at the
node in which a ResvTear message stops, the change of node in which a ResvTear message stops, the change of
reservation state may trigger a Resv refresh starting at that reservation state may trigger a Resv refresh starting at that
node. node.
3.1.6 Error Messages 3.1.6 Error Messages
There are two types of RSVP error messages. There are two types of RSVP error messages.
o PathErr messages result from Path messages and travel o PathErr messages result from Path messages and travel
upstream towards the senders. PathErr messages are routed upstream towards senders. PathErr messages are routed
hop-by-hop using the path state; at each hop, the IP hop-by-hop using the path state; at each hop, the IP
destination address is the unicast address of a previous destination address is the unicast address of a previous
hop. PathErr messages do not modify the state of any node hop. PathErr messages do not modify the state of any node
through which they pass; instead, they are only reported through which they pass; instead, they are only reported
to the sender application. to the sender application.
o ResvErr messages result from Resv messages and travel o ResvErr messages result from Resv messages and travel
downstream towards the appropriate receivers. They are downstream towards the appropriate receivers. They are
routed hop-by-hop using the reservation state; at each routed hop-by-hop using the reservation state; at each
hop, the IP destination address is the unicast address of hop, the IP destination address is the unicast address of
a next-hop node. 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> ] <PathErr message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC> <SESSION> <ERROR_SPEC>
[ <POLICY_DATA> ...] [ <POLICY_DATA> ...]
<sender descriptor> <sender descriptor>
<sender descriptor> ::= (see earlier definition) <sender descriptor> ::= (see earlier definition)
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ] <ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC> <SESSION> <ERROR_SPEC>
[ <POLICY_DATA> ...]
[ <SCOPE> ] [ <SCOPE> ]
[ <POLICY_DATA> ...]
<STYLE> <error flow descriptor> <STYLE> <error flow descriptor>
The ERROR_SPEC object specifies the error and includes the IP The ERROR_SPEC object specifies the error and includes the IP
address of the node that detected the error (Error Node address of the node that detected the error (Error Node
Address). One or more POLICY_DATA objects may be included in Address). One or more POLICY_DATA objects may be included in
an error message to provide relevant information (i.e., when an an error message to provide relevant information (i.e., when an
administrative failure is being reported). The STYLE object is administrative failure is being reported). The STYLE object is
copied from the Resv message in error. The use of the SCOPE copied from the Resv message in error. The use of the SCOPE
object in a ResvErr message is defined below in Section 3.3. object in a ResvErr message is defined below in Section 3.3.
skipping to change at page 44, line 17 skipping to change at page 42, line 28
as given earlier for a Resv message. 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>
Each flow descriptor in a FF-style Resv message must be
processed independently, and a separate ResvErr message
must be generated for each one that is in error.
o SE style: o SE style:
<error flow descriptor> ::= <SE flow descriptor> <error flow descriptor> ::= <SE flow descriptor>
An SE-style ResvErr message may list the subset of the
filter specs in the corresponding Resv message to which
the error applies.
Note that a ResvErr message contains only one flow descriptor. Note that a ResvErr message contains only one flow descriptor.
Therefore, a Resv message that contains N > 1 flow descriptors Therefore, a Resv message that contains N > 1 flow descriptors
(FF style) may create up to N separate ResvErr messages. (FF style) may create up to N separate ResvErr messages.
Generally speaking, a ResvErr message should be forwarded Generally speaking, a ResvErr message should be forwarded
towards all receivers that may have caused the error being towards all receivers that may have caused the error being
reported. More specifically: reported. More specifically:
o The node that detects an error in a reservation request o The node that detects an error in a reservation request
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.
This message must contain the information required to This message must contain the information required to
define the error and to route the error message in later define the error and to route the error message in later
hops. It therefore includes an ERROR_SPEC object, a copy hops. It therefore includes an ERROR_SPEC object, a copy
of the STYLE object, and the appropriate error flow of the STYLE object, and the appropriate error flow
descriptor. If the error is an admission control failure, descriptor. If the error is an admission control failure,
any reservation already in place will be left in place, any reservation already in place must be left in place,
and the InPlace flag bit must be on in the ERROR_SPEC of and the InPlace flag bit must be on in the ERROR_SPEC of
the ResvErr message. the ResvErr message.
o Succeeding nodes forward the ResvErr message to next hops o Succeeding nodes forward the ResvErr message to next hops
that have local reservation state. For reservations with that have local reservation state. For reservations with
wildcard scope, there is an additional limitation on wildcard scope, there is an additional limitation on
forwarding ResvErr messages, to avoid loops; see Section forwarding ResvErr messages, to avoid loops; see Section
3.3. There is also a rule restricting the forwarding of 3.3. There is also a rule restricting the forwarding of a
Resv messages for Admission Control failures; see Section Resv message after an Admission Control failure; see
3.4. Section 3.4.
A ResvErr message that is forwarded should carry the A ResvErr message that is forwarded should carry the
FILTER_SPEC from the corresponding reservation state. FILTER_SPEC from the corresponding reservation state.
o When a ResvErr message reaches a receiver, the STYLE o When a ResvErr message reaches a receiver, the STYLE
object, flow descriptor list, and ERROR_SPEC object object, flow descriptor list, and ERROR_SPEC object
(including its flags) should be delivered to the receiver (including its flags) should be delivered to the receiver
application. application.
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.
3.1.7 Confirmation Messages 3.1.7 Confirmation Messages
ResvConf messages are sent to (probabilistically) acknowledge ResvConf messages are sent to (probabilistically) acknowledge
reservation requests. A ResvConf message is sent as the result reservation requests. A ResvConf message is sent as the result
of the appearance of a RESV_CONFIRM object in a Resv message. of the appearance of a RESV_CONFIRM object in a Resv message.
A ResvConf message is sent to the unicast address of a receiver A ResvConf message is sent to the unicast address of a receiver
host; the address is obtained from the RESV_CONFIRM object. host; the address is obtained from the RESV_CONFIRM object.
However, a ResvConf message is forwarded to the receiver hop- However, a ResvConf message is forwarded to the receiver hop-
by-hop, to accommodate the hop-by-hop integrity check by-hop, to accommodate the hop-by-hop integrity check
mechanism. mechanism.
<ResvConf Message> ::= <Common Header> <SESSION> <ResvConf message> ::= <Common Header> [ <INTEGRITY> ]
<ERROR_SPEC>
<SESSION> <ERROR_SPEC>
<RESV_CONFIRM> <RESV_CONFIRM>
<STYLE> <flow descriptor list> <STYLE> <flow descriptor list>
<flow descriptor list> ::= (see earlier definition) <flow descriptor list> ::= (see earlier definition)
The object order requirements are the same as those given
earlier for a Resv message.
The RESV_CONFIRM object is a copy of that object in the Resv The RESV_CONFIRM object is a copy of that object in the Resv
message that triggered the confirmation. The ERROR_SPEC is message that triggered the confirmation. The ERROR_SPEC is
used only to carry the IP address of the originating node, in used only to carry the IP address of the originating node, in
the Error Node Address; the Error Code and Value are zero to the Error Node Address; the Error Code and Value are zero to
indicate a confirmation. The flow descriptor list specifies indicate a confirmation. The flow descriptor list specifies
the particular reservations that are being confirmed; it may be the particular reservations that are being confirmed; it may be
a subset of flow descriptor list of the Resv that requested the a subset of flow descriptor list of the Resv that requested the
confirmation. confirmation.
The object order requirements within the flow descriptor list
are the same as those given earlier for a Resv message.
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 datagrams with protocol number 46. Raw IP datagrams are
intended to be used between an end system and the first/last hop also intended to be used between an end system and the first/last
router, although it is also possible to encapsulate RSVP messages hop router, although it is also possible to encapsulate RSVP
as UDP datagrams for end-system communication, as described in messages as UDP datagrams for end-system communication, as
Appendix C. UDP encapsulation is needed for systems that cannot described in Appendix C. UDP encapsulation is needed for systems
do raw network I/O. that cannot do raw network I/O.
Path, PathTear, and ResvConf messages must be sent with the Router Path, PathTear, and ResvConf messages must be sent with the Router
Alert IP option [Katz95] in their IP headers. This option may be Alert IP option [Katz95] in their IP headers. This option may be
used in the fast forwarding path of a high-speed router to detect used 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 a message out the interface through which
which M arrived (as could happen if the implementation simply M arrived (which 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 In this version of the spec, each RSVP message must occupy exactly
MTU of the interface through which it will be sent. All fragments one IP datagram. If it exceeds the MTU, such a datagram will be
of the message should carry the same unique value of the Message fragmented by IP and reassembled at the recipient node. This has
ID field, as well as appropriate Fragment Offset and MF bits, in several consequences:
their common headers. When an RSVP message arrives, it must be
reassembled before it can be processed. The refresh period R can
be used as an appropriate reassembly timeout time.
Between adjacent RSVP-capable routers, RSVP-level fragmentation o A single RSVP message may not exceed the maximum IP datagram
mechanism should normally be used in lieu of fragmentation at the size, approximately 64K bytes.
IP level. However, IP-level fragmentation may still occur when
RSVP messages travel through a non-RSVP cloud. In case of IP6, o A congested non-RSVP cloud could lose individual message
which does not support IP fragmentation at routers, an RSVP fragments, and any lost fragment will lose the entire
implementation must use Path MTU Discovery or hand configuration message.
to obtain an appropriate MTU between adjacent RSVP neighbors.
Future versions of the protocol will provide solutions for these
problems if they prove burdensome. The most likely direction will
be to perform "semantic fragmentation", i.e., break the path or
reservation state being transmitted into multiple self-contained
messages, each of an acceptable size.
RSVP uses its periodic refresh mechanisms to recover from RSVP uses its periodic refresh mechanisms to recover from
occasional packet losses. Under network overload, however, occasional packet losses. Under network overload, however,
substantial losses of RSVP messages could cause a failure of substantial losses of RSVP messages could cause a failure of
resource reservations. To control the queueing delay and dropping resource reservations. To control the queueing delay and dropping
of RSVP packets, routers should be configured to offer them a of RSVP packets, routers should be configured to offer them a
preferred class of service. If RSVP packets experience noticeable preferred class of service. If RSVP packets experience noticeable
losses when crossing a congested non-RSVP cloud, a larger value losses when crossing a congested non-RSVP cloud, a larger value
can be used for the timeout factor K (see section 3.6 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 do IP encapsulation of multicast packets for transmission
routers that do not have multicast capability. A multicast tunnel through routers that do not have multicast capability. A
looks like a logical outgoing interface that is mapped into some multicast tunnel looks like a logical outgoing interface that is
physical interface. A multicast routing protocol that supports mapped into some physical interface. A multicast routing protocol
tunnels will describe a route using a list of logical rather than that supports tunnels will describe a route using a list of
physical interfaces. RSVP can run through multicast tunnels in logical rather than physical interfaces. RSVP can operate across
the following manner: such multicast tunnels in the following manner:
1. When a node N forwards a Path message out a logical outgoing 1. When a node N forwards a Path message out a logical outgoing
interface L, it includes in the message some encoding of the interface L, it includes in the message some encoding of the
identity of L, called the "logical interface handle" or LIH. identity of L, called the "logical interface handle" or LIH.
The LIH value is carried in the RSVP_HOP object. The LIH value is carried in the RSVP_HOP object.
2. The next hop node N' stores the LIH value in its path state. 2. The next hop node N' stores the LIH value in its path state.
3. When N' sends a Resv message to N, it includes the LIH value 3. When N' sends a Resv message to N, it includes the LIH value
from the path state (again, in the RSVP_HOP object). from the path state (again, in the RSVP_HOP object).
4. When the Resv message arrives at N, its LIH value provides 4. When the Resv message arrives at N, its LIH value provides
the information necessary to attach the reservation to the the information necessary to attach the reservation to the
appropriate logical interface. Note that N creates and appropriate logical interface. Note that N creates and
interprets the LIH; it is an opaque value to N'. interprets the LIH; it is an opaque value to N'.
Note that this only solves the routing problem posed by tunnels.
The tunnel appears to RSVP as a non-RSVP cloud. To establish RSVP
reservations within the tunnel, additional machinery will be
required, to be defined in the future.
3.3 Avoiding RSVP Message Loops 3.3 Avoiding RSVP Message Loops
Forwarding of RSVP messages must avoid looping. In steady state, Forwarding of RSVP messages must avoid looping. In steady state,
Path and Resv messages are forwarded only once per refresh period Path and Resv messages are forwarded on each hop only once per
on each hop. This avoids looping packets, but there is still the refresh period. This avoids looping packets, but there is still
possibility of an "auto-refresh" loop, clocked by the refresh the possibility of an "auto-refresh" loop, clocked by the refresh
period. Such auto-refresh loops keep state active "forever", even period. Such auto-refresh loops keep state active "forever", even
if the end nodes have ceased refreshing it, until either the if the end nodes have ceased refreshing it, until either the
receivers leave the multicast group and/or the senders stop receivers leave the multicast group and/or the senders stop
sending Path messages. On the other hand, error and teardown sending Path messages. On the other hand, error and teardown
messages are forwarded immediately and are therefore subject to messages are forwarded immediately and are therefore subject to
looping. direct looping.
Consider each message type. Consider each message type.
o Path Messages o Path Messages
Path messages are forwarded in exactly the same way as IP Path messages are forwarded in exactly the same way as IP
data packets. Therefore there should be no loops of Path data packets. Therefore there should be no loops of Path
messages, even in a topology with cycles. messages, even in a topology with cycles.
o PathTear Messages o PathTear Messages
skipping to change at page 50, line 4 skipping to change at page 48, line 31
Receive on (a): | Send on (c): Receive on (a): | Send on (c):
| |
WF( [S1,S2,S3]) --> | WF( [S2, S3]) --> WF( [S1,S2,S3]) --> | WF( [S2, S3]) -->
| |
Receive on (b): | Receive on (b): |
| |
WF( [S2,S3,S4]) --> | WF( [S2,S3,S4]) --> |
| |
Figure 11: SCOPE Objects in Wildcard-Scope Reservations Figure 11: SCOPE Objects in Wildcard-Scope Reservations
SCOPE objects are not necessary if the multicast routing uses SCOPE objects are not necessary if the multicast routing uses
shared trees or if the reservation style has explicit sender shared trees or if the reservation style has explicit sender
selection. Furthermore, attaching a SCOPE object to a reservation selection. Furthermore, attaching a SCOPE object to a reservation
may be deferred to a node which has more than one previous hop should be deferred to a node which has more than one previous hop
upstream. for the reservation state.
The following rules are used for SCOPE objects in ResvErr messages The following rules are used for SCOPE objects in ResvErr messages
with WF style: with WF style:
1. The node that detected the error initiates an ResvErr message 1. The node that detected the error initiates an ResvErr 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 ResvErr message arrives at a node 2. Suppose a wildcard-style ResvErr message arrives at a node
with a SCOPE object containing the sender host address list with a SCOPE object containing the sender host address list
L. The node forwards the ResvErr message using the rules of L. The node forwards the ResvErr message using the rules of
Section 3.1.6. However, the ResvErr message forwarded out OI Section 3.1.6. However, the ResvErr message forwarded out OI
must contain a SCOPE object derived from L by including only must contain a SCOPE object derived from L by including only
those senders that route to OI. If this SCOPE object is those senders that route to OI. If this SCOPE object is
empty, the ResvErr message should not be sent out OI. empty, the ResvErr message should not be sent out OI.
3.4 Blockade State 3.4 Blockade State
The basic rule for creating a Resv refresh message is to merge the The basic rule for creating a Resv refresh message is to merge the
flowspecs of the reservation requests in place in the node, by flowspecs of the reservation requests in place in the node, by
computing their LUB. However, this rule is modified by the computing their LUB. However, this rule is modified by the
existence of "blockade state" resulting from ResvErr messages, to existence of "blockade state" resulting from ResvErr messages, to
solve the KR-II problem (Section 2.6). The blockade state also solve the KR-II problem (Section 2.6). The blockade state also
enters into the routing of ResvErr messages for Admission Control enters into the routing of ResvErr messages for Admission Control
failure. failure.
When a ResvErr message for an Admission Control failure is When a ResvErr message for an Admission Control failure is
received, its flowspec Qe is used to create or refresh an element received, its flowspec Qe is used to create or refresh an element
of local blockade state. Each element of blockade state consists of local blockade state. Each element of blockade state consists
of a blockade flowspec Qb taken from the flowspec of the last of a blockade flowspec Qb taken from the flowspec of the ResvErr
ResvErr, and an associated blockade timer Tb. When the blockade message, and an associated blockade timer Tb. When a blockade
timer expires, the blockade state is deleted. timer expires, the corresponding blockade state is deleted.
The granularity of blockade state depends upon the style of the The granularity of blockade state depends upon the style of the
ResvErr message that created it. For an explicit style, there may ResvErr message that created it. For an explicit style, there may
be a blockade state element (Qb(S),Tb(S)) for each sender S. For be a blockade state element (Qb(S),Tb(S)) for each sender S. For
a wildcard style, blockade state is per previous hop P. a wildcard style, blockade state is per previous hop P.
An element of blockade state with flowspec Qb is said to An element of blockade state with flowspec Qb is said to
"blockade" a reservation with flowspec Qi if Qb is not (strictly) "blockade" a reservation with flowspec Qi if Qb is not (strictly)
greater than Qi. For example, suppose that the LUB of two greater than Qi. For example, suppose that the LUB of two
flowspecs is computed by taking the max of each of their flowspecs is computed by taking the max of each of their
skipping to change at page 52, line 16 skipping to change at page 51, line 6
reservation 2B subsequently arrived from (d). This steady state reservation 2B subsequently arrived from (d). This steady state
is perturbed roughly every Kb*R seconds, when the blockade state is perturbed roughly every Kb*R seconds, when the blockade state
times out. The next refresh then sends 4B to previous hop (a); times out. The next refresh then sends 4B to previous hop (a);
presumably this will fail, sending a ResvErr message that will presumably this will fail, sending a ResvErr message that will
re-establish the blockade state, returning to the situation shown re-establish the blockade state, returning to the situation shown
in the figure. At the same time, the ResvErr message will be in the figure. At the same time, the ResvErr message will be
forwarded to next hop (c) and to all receivers downstream forwarded to next hop (c) and to all receivers downstream
responsible for the 4B reservations. responsible for the 4B reservations.
Send Blockade| Reserve Receive Send Blockade| Reserve Receive
State| State {Qb}|
|
| ________ | ________
(a) <- WF(*{2B}) {4B} | | * {4B} | WF(*{4B}) <- (c) (a) <- WF(*{2B}) {4B} | | * {4B} | WF(*{4B}) <- (c)
| |________| | |________|
| |
---------------------------|------------------------------- ---------------------------|-------------------------------
| |
| ________ | ________
(b) <- WF(*{4B}) (none)| | * {2B} | WF(*{2B}) <- (d) (b) <- WF(*{4B}) (none)| | * {2B} | WF(*{2B}) <- (d)
| |________| | |________|
skipping to change at page 54, line 39 skipping to change at page 53, line 29
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.
The granularity of state for refresh and timeout is as follows:
o For reservation state, each FLOWSPEC is independently
refreshed and timed out.
o For path state, each sender is independently refreshed and
timed out.
3.7 Traffic Policing and Non-Integrated Service Hops 3.7 Traffic Policing and Non-Integrated Service Hops
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 being from upstream may be greater than the downstream reservation being
requested. RSVP knows where such points occur and must so requested. RSVP knows where such points occur and must so
indicate to the traffic control mechanism. On the other hand, indicate to the traffic control mechanism. On the other hand,
RSVP does not interpret the service embodied in the flowspec and RSVP does not interpret the service embodied in the flowspec and
therefore does not know whether policing will actually be applied therefore does not know whether policing will actually be applied
skipping to change at page 66, line 21 skipping to change at page 64, line 21
3.10.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: TC_AddFlowspec( Interface, TC_Flowspec,
TC_Tspec, Police_Flags ) TC_Tspec, Police_Flags )
-> RHandle [, Fwd_Flowspec]
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). The TC_Tspec parameter
reservation Tspec Resv_Te (although the RSVP daemon itself defines the effective sender Tspec Path_Te (see Section
has no means to extract the Tspec). The TC_Tspec 2.3). The Police_Flags parameter carries the three flags
parameter defines the effective sender Tspec Path_Te (see
Section 2.3). We assume that traffic control takes the
GLB of Resv_Te and Path_Te (see step (4) in Section 2.3).
The Police_Flags parameter carries the three flags
E_Police_Flag, M_Police_Flag, and B_Police_Flag; see E_Police_Flag, M_Police_Flag, and B_Police_Flag; see
Section 3.7. Section 3.7.
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. If the service updates the flowspec, the
call will also return the updated object as Fwd_Flowspec.
o Modify Reservation o Modify Reservation
Call: TC_ModFlowspec( Interface, Rhandle, new_Flowspec, Call: TC_ModFlowspec( Interface, Rhandle, TC_Flowspec,
Sender_Tspec, Police_flags ) Sender_Tspec, Police_flags )
-> [ Fwd_Flowspec ]
This call is used to modify an existing reservation. This call is used to modify an existing reservation.
New_Flowspec is passed to Admission Control; if it is TC_Flowspec is passed to Admission Control; if it is
rejected, the current flowspec is left in force. The rejected, the current flowspec is left in force. The
corresponding filter specs, if any, are not affected. The corresponding filter specs, if any, are not affected. The
other parameters are defined as in TC_AddFlowspec. other parameters are defined as in TC_AddFlowspec. If the
service updates the flowspec, the call will also return
the updated object as Fwd_Flowspec.
o Delete Flowspec o Delete Flowspec
Call: TC_DelFlowspec( Interface, 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( Interface, Rhandle, Call: TC_AddFilter( Interface, Rhandle,
Session , FilterSpec ) Session , FilterSpec ) -> FHandle
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( Interface, FHandle ) Call: TC_DelFilter( Interface, FHandle )
skipping to change at page 67, line 45 skipping to change at page 66, line 4
o OPWA Update o OPWA Update
Call: TC_Advertise( Interface, Adspec ) Call: TC_Advertise( Interface, Adspec )
-> 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 preempt an existing control and/or policy control modules may preempt one or
reservation. This might be reflected in an upcall to more existing reservations. This will trigger a
RSVP, passing the RHandle of the preempted reservation and TC_Preempt() upcall to RSVP for each preempted
a sub-code indicating the reason. reservation, passing the RHandle of the reservation and a
sub-code indicating the reason.
3.10.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
Packets received for IP protocol 46 but not addressed to Packets received for IP protocol 46 but not addressed to
the node must be diverted to the RSVP program for the node must be diverted to the RSVP program for
skipping to change at page 68, line 30 skipping to change at page 66, line 33
identity of the interface, real or virtual, on which it is identity of the interface, real or virtual, on which it is
received as well as the IP source address and IP TTL with received as well as the IP source address and IP TTL with
which it arrived must also be available to the RSVP which it arrived must also be available to the RSVP
daemon. daemon.
The RSVP messages to be diverted will carry the Router The RSVP messages to be diverted will carry the Router
Alert IP option, which can be used to pick them out of a Alert IP option, which can be used to pick them out of a
high-speed forwarding path. Alternatively, the node can high-speed forwarding path. Alternatively, the node can
intercept all protocol 46 packets. intercept all protocol 46 packets.
When an RSVP message (fragment) is handed to RSVP, the
actual length received must also be passed.
o Route Query o Route Query
To forward Path and PathTear messages, an RSVP daemon must To forward Path and PathTear messages, an RSVP daemon must
be able to query the routing daemon(s) for routes. be able to query the routing daemon(s) for routes.
Ucast_Route_Query( [ SrcAddress, ] DestAddress, Ucast_Route_Query( [ SrcAddress, ] DestAddress,
Notify_flag ) -> OutInterface Notify_flag ) -> OutInterface
Mcast_Route_Query( [ SrcAddress, ] DestAddress, Mcast_Route_Query( [ SrcAddress, ] DestAddress,
skipping to change at page 72, line 38 skipping to change at page 70, line 38
- Sender_Tspec - Sender_Tspec
- The previous hop IP address and the Logical Interface - The previous hop IP address and the Logical Interface
Handle (LIH) from a PHOP object Handle (LIH) from a PHOP object
- The remaining IP TTL - The remaining IP TTL
- POLICY_DATA and/or ADSPEC objects (optional) - POLICY_DATA and/or ADSPEC objects (optional)
- Non_RSVP and Maybe_RSVP flags; see Section 3.7. - Non_RSVP and Maybe_RSVP flags (Section 3.7).
- E_Police flag (Section 3.7) - E_Police flag (Section 3.7)
- Local_Only flag (Section 3.8) - 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, which is the list of outgoing by routing: OutInterface_list, which is the list of outgoing
interfaces for this (sender, destination), and IncInterface, interfaces for this (sender, destination), and IncInterface,
which is the expected incoming interface. For a unicast which is the expected incoming interface. For a unicast
destination, OutInterface_list contains one entry and destination, OutInterface_list contains one entry and
IncInterface is 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 define a virtual object type style), or empty (WF style). We define the virtual object type
"FILTER_SPEC*" for such a data structure. "FILTER_SPEC*" for such a data structure.
RSB contents include: RSB contents include:
- Session specification - Session specification
- Next hop IP address - Next hop IP address
- Filter_spec_list - 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.
- Style - Style
- Flowspec - Flowspec
- A POLICY_DATA object (optional) - A SCOPE object (optional, depending upon style)
- A SCOPE object (optional, depending on style)
- A RESV_CONFIRM object (optional) - RESV_CONFIRM object that was received (optional)
o TCSB -- Traffic Control State Block o TCSB -- Traffic Control State Block
Each TCSB holds the reservation specification that has been Each TCSB holds the reservation specification that has been
handed to traffic control for a specific outgoing interface. In handed to traffic control for a specific outgoing interface. In
general, TCSB information is derived from RSB's for the same general, TCSB information is derived from RSB's for the same
outgoing interface. Each TCSB defines a single reservation for outgoing interface. Each TCSB defines a single reservation for
a particular triple: (session, OI, Filter_spec_list). TCSB a particular triple: (session, OI, Filter_spec_list). TCSB
contents include: contents include:
- Session - Session
- OI - OI
- Filter_spec_list - Filter_spec_list
- TC_Flowspec, the effective flowspec, i.e., the maximum over - TC_Flowspec, the effective flowspec, i.e., the LUB over the
the corresponding FLOWSPEC values from matching RSB's. 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.
effective reservation Tspec Resv_Te (Section 2.3).
- Fwd_Flowspec, the updated object to be forwarded after
merging.
- TC_Tspec, equal to Path_Te, the effective sender Tspec. - 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.7. 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 a flowspec and perhaps a list of filter
of filter specs. specs.
- A RESV_CONFIRM object to be forwarded.
o BSB -- Blockade State Block o BSB -- Blockade State Block
Each BSB contains an element of blockade state. Depending upon Each BSB contains an element of blockade state. Depending upon
the reservation style in use, the BSB's may be per (session, the reservation style in use, the BSB's may be per (session,
sender_template) or per (session, PHOP). In practice, an sender_template) pair or per (session, PHOP) pair. In practice,
implementation might embed a BSB within a PSB; however, for an implementation might embed a BSB within a PSB; however, for
clarity we describe BSB's independently. clarity we describe BSB's independently.
The contents of a BSB include: The contents of a BSB include:
- Session - Session
- Sender_Template (which is also a filter spec) - Sender_Template (which is also a filter spec)
- PHOP - PHOP
- FLOWSPEC Qb - FLOWSPEC Qb
- Blockade timer Tb - Blockade timer Tb
The following other variables are also used in this section: Boolean The following Boolean Flag variables are used in this section:
flags Path_Refresh_Needed, Resv_Refresh_Needed, Tear_Needed, Path_Refresh_Needed, Resv_Refresh_Needed, Tear_Needed, Need_Scope,
Need_Scope, B_Merge, and NeworMod, and Refresh_PHOP_list, a B_Merge, and NeworMod. Refresh_PHOP_list is a variable-length list
variable-length list of PHOPs to be refreshed. of PHOPs to be refreshed.
MESSAGE ARRIVES MESSAGE ARRIVES
Verify version number and RSVP checksum, and discard message if any Verify version number and RSVP checksum, and discard message if any
mismatch is found. mismatch is found.
If the message type is ResvConf, forward the message to IP
destination address and return.
If the message type is not Path or PathTear and if the IP destination If the message type is not Path or PathTear 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.
Parse the sequence of objects in the message. If any required
objects are missing or the length field of the common header does not
match, discard the message 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 Verify the consistent use of port fields. If the DstPort in the
SESSION object is zero but the SrcPort in a SENDER_TEMPLATE or SESSION object is zero but the SrcPort in a SENDER_TEMPLATE or
FILTER_SPEC object is non-zero, the the message has a "conflicting FILTER_SPEC object is non-zero, then the message has a "conflicting
source port" error; discard the message and return. source port" error; silently discard the message and return.
Processing of POLICY_DATA objects will be specified in the future.
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 Path_Refresh_Needed and Resv_Refresh_Needed flags follows. The Path_Refresh_Needed and Resv_Refresh_Needed flags
are initially off. are initially off.
o If there is a POLICY_DATA object, verify it; if it is
unacceptable, build and send a "Administrative Rejection"
PathErr message, drop the Path message, and return.
o Search for a path state block (PSB) whose (session, o Search for a path state block (PSB) whose (session,
sender_template) pair matches the corresponding objects in sender_template) pair matches the corresponding objects in
the message. the message. During this search:
o If, during the PSB search, a PSB is found whose session 1. If a PSB is found whose session matches the
matches the DestAddress and Protocol Id fields of the DestAddress and Protocol Id fields of the received
received SESSION object, but the DstPorts differ and one is SESSION object, but the DstPorts differ and one is
zero, then build and send a "Conflicting Dst Port" PathErr zero, then build and send a "Conflicting Dst Port"
message, drop the Path message, and return. PathErr message, drop the Path message, and return.
o If, during the PSB search, a PSB is found with a matching 2. If a PSB is found with a matching sender host but the
sender host but the SrcPorts differ and one of the SrcPorts SrcPorts differ and one of the SrcPorts is zero, then
is zero, then build and send an "Ambiguous Path" PathErr build and send an "Ambiguous Path" PathErr message,
message, drop the Path message, and return. 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. Copy contents of the SESSION, SENDER_TEMPLATE, 2. Copy contents of the SESSION, SENDER_TEMPLATE,
SENDER_TSPEC, and PHOP (IP address and LIH) objects SENDER_TSPEC, and PHOP (IP address and LIH) objects
into the PSB. into the PSB.
3. Calculate initial routing information. If the sender 3. Calculate initial routing information. If the sender
is from the local API, OutInterface_List is set to the is from the local API, OutInterface_List is set to the
single interface whose address matches the sender single interface whose address matches the sender
address, and IncInterface is undefined. Otherwise, address, and IncInterface is undefined. Otherwise,
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. Store the values of SrcAddress from SENDER_TEMPLATE. Store the values of
OutInterface_list and IncInterface into the PSB. OutInterface_list and IncInterface from routing into
the PSB.
4. 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,
turn on the Local_Only flag in the PSB. turn on the Local_Only flag in the PSB and store the
actual incoming interface into IncInterface.
5. If this is the first PSB for the session, set a 5. If this is the first PSB for the session, set a
refresh timer for the session. refresh timer for the session.
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):
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, then 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, then execute the different from IncInterface, then execute the
Resv REFRESH event sequence below for the Resv REFRESH event sequence below for the
previous hop. 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 and turn on the Path_Refresh_Needed value into the PSB and turn on the Path_Refresh_Needed
flag. flag. If the PHOP IP address or the LIH differ, also
turn on the Resv_Refresh_Needed flag.
o If the message contains an ADSPEC object, copy it into the o Update the PSB
PSB.
o Start or Restart the cleanup timer for the PSB. 1. If the message contains an ADSPEC object, copy it into
the PSB.
o Copy E_Police flag from SESSION object into PSB. 2. Start or Restart the cleanup timer for the PSB.
o Store the received TTL into the PSB. 3. Copy E_Police flag from SESSION object into PSB.
If the the received TTL differs from Send_TTL in the RSVP 4. Store the received TTL into the PSB.
If the received TTL differs from Send_TTL in the RSVP
common header, set the Non_RSVP flag on in the PSB. common header, set the Non_RSVP flag on in the PSB.
o The Path_Refresh_Needed flag is now set if the path state o If the Path_Refresh_Needed flag is now off, drop the Path
is new or modified. If so: message and return.
Otherwise (the path state is new or modified) then do
refreshes, upcalls, and state updates.
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, Call: <Upcall_Proc>( session-id, PATH_EVENT,
flags, 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 3. Search for an RSB whose Filter_spec_list includes a
(i.e., no RSB's exist), then drop the Path message and FILTER_SPEC matching the SENDER_TEMPLATE and whose OI
return. appears in the OutInterface_list. If none is found,
drop the Path message and return.
4. Otherwise (there is reservation state):
- Execute the event sequence UPDATE TRAFFIC CONTROL Otherwise, make this the `active RSB' and execute the
below, to update the local traffic control state event sequence UPDATE TRAFFIC CONTROL to update the
if necessary. This will turn on the local traffic control state if necessary. If this
Resv_Refresh_Needed flag if the traffic control modifies the traffic control state, it will make a
state changes; if so, execute the Resv REFRESH RESV_EVENT upcall to any matching local application
event sequence (below) for the sender in the PSB. and turn on the Resv_Refresh_Needed flag.
However, if the Path message came from a local 4. If the Resv_Refresh_Needed flag is now on, execute the
application, then make a RESV_EVENT upcall to Resv REFRESH sequence for the PHOP in the PSB.
that application.
o Drop the Path message and return. o Drop the Path message and return.
PathTear MESSAGE ARRIVES PathTear 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 PathTear message and matching PSB is found, drop the PathTear message and
return. return.
skipping to change at page 78, line 45 skipping to change at page 77, line 4
o Drop the PathErr message and return. o Drop the PathErr message and return.
Resv MESSAGE ARRIVES Resv MESSAGE ARRIVES
Initially, Refresh_PHOP_list is empty and the Initially, Refresh_PHOP_list is empty and the
Resv_Refresh_Needed and NeworMod flags are off. These variables Resv_Refresh_Needed and NeworMod flags are off. These variables
are used to control immediate reservation refreshes. are used to control immediate reservation refreshes.
o Determine the Outgoing Interface OI 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 path state
If there are no existing PSB's for SESSION then build and
send a ResvErr message (as described later) specifying "No
path information", drop the Resv message, and return.
o Check the S_POLICY_DATA object. 1. If there are no existing PSB's for SESSION then build
and send a ResvErr message (as described later)
specifying "No path information", drop the Resv
message, and return.
If there is an S_POLICY_DATA object in the message, check 2. If a PSB is found with a matching sender host but the
permission to create a reservation for the session. If the SrcPorts differ and one of the SrcPorts is zero, then
check fails, build and send an "Administrative rejection" build and send an "Ambiguous Path" PathErr message,
ResvErr message, drop the Resv message, and return. drop the Resv message, and return.
Otherwise, copy the S_POLICY_DATA object into the RSB.
o Check for incompatible styles. o Check for incompatible styles.
If any existing RSB for the session has a style that is If any existing RSB for the session has a style that is
incompatible with the style of the message, build and send incompatible with the style of the message, build and send
a ResvErr message specifying "Conflicting Style", drop the a ResvErr message specifying "Conflicting Style", drop the
Resv message, and return. Resv message, and return.
Process the flow descriptor list to make reservations, as Process the flow descriptor list to make reservations, as
follows, depending upon the style. The following uses a filter follows, depending upon the style. The following uses a filter
skipping to change at page 79, line 42 skipping to change at page 77, line 44
Filtss) pair. Here the structure Filtss consists of the Filtss) pair. Here the structure Filtss consists of the
FILTER_SPEC from the flow descriptor. FILTER_SPEC from the flow descriptor.
For SE style, execute the following steps once for (FLOWSPEC, For SE style, execute the following steps once for (FLOWSPEC,
Filtss), with Filtss consisting of the list of FILTER_SPEC Filtss), with Filtss consisting of the list of FILTER_SPEC
objects from the flow descriptor. objects from the flow descriptor.
For WF style, execute the following steps once for (FLOWSPEC, For WF style, execute the following steps once for (FLOWSPEC,
Filtss), with Filtss an empty list. Filtss), with Filtss an empty list.
o If the DstPort in the SESSION object is zero but the
SrcPort in a FILTER_SPEC object (in Filtss) is non-zero,
build nd send a "Conflicting Src Port" ResvErr message,
drop the Resv message, and return.
o Check the path state, as follows. o Check the path state, as follows.
1. Locate the set of PSBs (senders) whose 1. Locate the set of PSBs (senders) whose
SENDER_TEMPLATEs match Filtss and whose SENDER_TEMPLATEs match Filtss 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.
skipping to change at page 80, line 35 skipping to change at page 78, line 32
1. Set the session, NHOP, OI and style of the RSB from 1. Set the session, NHOP, OI and style of the RSB from
the message. the message.
2. Copy Filtss into the Filter_spec_list of the RSB. 2. Copy Filtss into the Filter_spec_list of the RSB.
3. Copy the FLOWSPEC and any SCOPE object from the 3. Copy the FLOWSPEC and any SCOPE object from the
message into the RSB. message into the RSB.
4. Set NeworMod flag on. 4. Set NeworMod flag on.
o Start or restart the cleanup timer on the the active RSB. o Start or restart the cleanup timer on the active RSB.
o If there is a RESV_CONFIRM in the message, turn on o If the message contained a RESV_CONFIRM object, copy it
Resv_Refresh_Needed and save the object in the RSB. into the RSB and turn on Resv_Refresh_Needed flag.
o If the active RSB is not new, check whether STYLE, FLOWSPEC o If the active RSB is not new, check whether STYLE, FLOWSPEC
or SCOPE objects have changed; if so, copy changed object or SCOPE objects have changed; if so, copy changed object
into RSB and turn on the NeworMod flag. into RSB and turn on the NeworMod flag.
o If NeworMod flag is off, continue with the next flow o If NeworMod flag is off, continue with the next flow
descriptor in the Resv message, if any. descriptor in the Resv message, if any.
o Otherwise (the NeworMod flag is on, i.e., the active RSB is o Otherwise (the NeworMod flag is on, i.e., the active RSB is
new or modified), execute the UPDATE TRAFFIC CONTROL event new or modified), execute the UPDATE TRAFFIC CONTROL event
sequence (below). If the result is to modify the traffic sequence (below). If the result is to modify the traffic
control state, it will turn on the Resv_Refresh_Needed control state, the Resv_Refresh_Needed flag will be turned
flag. on and a RESV_EVENT upcall will be made to the application.
o For any local sender, make an RESV_EVENT upcall to the
application:
Call: <Upcall_Proc>( session-id, RESV_EVENT,
style, Flowspec, Filter_spec_list,
[POLICY_DATA] )
where the parameters come from the active RSB.
o Continue with the next flow descriptor. o Continue with the next flow descriptor.
o When all flow descriptors have been processed, check the o When all flow descriptors have been processed, check the
Resv_Refresh_Needed flag. If it is now on, execute the Resv_Refresh_Needed flag. If it is now on, execute the
Resv REFRESH sequence (below) for each PHOP in Resv REFRESH sequence (below) for each PHOP in
Refresh_PHOP_list. Refresh_PHOP_list.
o Drop the Resv message and return. o Drop the Resv message and return.
skipping to change at page 85, line 16 skipping to change at page 83, line 4
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 )
o Otherwise, the ResvConf message is forwarded immediately to o Otherwise, the ResvConf message is forwarded immediately to
the address in the IP address in its RESV_CONFIRM object. the address in the IP address in its RESV_CONFIRM object.
o Drop the ResvConf message and return. o Drop the ResvConf message and return.
UPDATE TRAFFIC CONTROL UPDATE TRAFFIC CONTROL
The sequence is invoked by the Path MESSAGE ARRIVES or the Resv The sequence is invoked by the Path MESSAGE ARRIVES or the Resv
MESSAGE ARRIVES sequence, to (re-)calculate and adjust the local MESSAGE ARRIVES sequence, to (re-)calculate and adjust the local
traffic control state in accordance with the current reservation traffic control state in accordance with the current reservation
and path state. If the result is to modify the traffic control and path state. An implicit parameter of this sequence is the
state, this sequence turns on the Resv_Refresh_Needed flag. `active' RSB.
If the result is to modify the traffic control state, this
sequence turns on the Resv_Refresh_Needed flag and notifies any
matching local applications with a RESV_EVENT upcall.
o Compute the traffic control parameters using the following o Compute the traffic control parameters using the following
steps. steps.
1. Consider the set of RSB's matching SESSION and OI from 1. Consider the set of RSB's matching SESSION,
the message. Filter_spec_list, and OI from the active RSB.
Initially the local flag Is_Biggest is off.
- Compute the effective kernel flowspec, - Compute the effective kernel flowspec,
TC_Flowspec, as the maximum/LUB of the FLOWSPEC TC_Flowspec, as the LUB of the FLOWSPEC values in
values in these RSB's. these RSB's.
- Compute the effective traffic control filter spec - Compute the effective traffic control filter spec
(list) TC_Filter_Spec*, by merging the (list) TC_Filter_Spec* as the union of the
Filter_spec_lists from these RSB's. Filter_spec_lists from these RSB's.
- If the active RSB has a FLOWSPEC larger than all
the others, turn on the Is_Biggest flag.
2. Scan all RSB's matching session and Filtss, for all 2. Scan all RSB's matching session and Filtss, for all
OI. Set TC_B_Police_flag on if TC_Flowspec is smaller OI. Set TC_B_Police_flag on if TC_Flowspec is smaller
than, or incomparable to, any FLOWSPEC in those RSB's. than, or incomparable to, any FLOWSPEC in those RSB's.
3. Locate the set of PSBs (senders) whose 3. Locate the set of PSBs (senders) whose
SENDER_TEMPLATEs match Filter_spec_list in the active SENDER_TEMPLATEs match Filter_spec_list in the active
RSB and whose OutInterface_list includes OI. RSB and whose OutInterface_list includes OI.
4. Set TC_E_Police_flag on if any of these PSBs have 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 their E_Police flag on. Set TC_M_Police_flag on if it
skipping to change at page 86, line 19 skipping to change at page 84, line 13
If none is found, create a new TCSB. If none is found, create a new TCSB.
o If TCSB is new: o If TCSB is new:
1. Store TC_Flowspec, TC_Filter_Spec*, Path_Te, and the 1. Store TC_Flowspec, TC_Filter_Spec*, Path_Te, and the
police flags into TCSB. police flags into TCSB.
2. Turn the Resv_Refresh_Needed flag on and make the 2. Turn the Resv_Refresh_Needed flag on and make the
traffic control call: traffic control call:
Rhandle = TC_AddFlowspec( OI, TC_Flowspec, TC_AddFlowspec( OI, TC_Flowspec,
Path_Te, police_flags) Path_Te, police_flags)
-> Rhandle, Fwd_Flowspec
3. If this call succeeds, record Rhandle in the TCSB and, 3. If this call fails, build and send a ResvErr message
for each filter_spec F in TC_Filter_Spec*, call: specifying "Admission control failed" and with the
InPlace flag off. Delete any RESV_CONFIRM object from
the active RSB and return.
Fhandle = TC_AddFilter( OI, Rhandle, Session, F) 4. Otherwise (call succeeds), record Rhandle and
Fwd_Flowspec in the TCSB. For each filter_spec F in
TC_Filter_Spec*, call:
and record the returned Fhandle in the TCSB. TC_AddFilter( OI, Rhandle, Session, F)
-> Fhandle
4. Otherwise, build and send a ResvErr message specifying and record the returned Fhandle in the TCSB.
"Admission control failed" and with the InPlace flag
off.
o If TCSB is not new but the TC_Flowspec, Path_Te, and/or o Otherwise, if TCSB is not new but the TC_Flowspec, Path_Te,
police flags just computed differ from corresponding values and/or police flags just computed differ from corresponding
in the TCSB, then: values in the TCSB, then:
1. Turn the Resv_Refresh_Needed flag on and make the 1. Turn the Resv_Refresh_Needed flag on and make the
traffic control call: traffic control call:
TC_ModFlowspec( OI, Rhandle, TC_Flowspec, TC_ModFlowspec( OI, Rhandle, TC_Flowspec,
Path_Te, police_flags ) Path_Te, police_flags )
-> Fwd_Flowspec
2. If this call fails, build and send a ResvErr message 2. If this call fails, build and send a ResvErr message
specifying "Admission control failed" and with the specifying "Admission control failed" and with the
InPlace bit on. If the call succeeds, update the TCSB InPlace bit on. Delete any RESV_CONFIRM object from
with the new values. the active RSB and return.
o If the TCSB is not new but the TC_Filter_Spec* just 3. Otherwise (the call succeeds), update the TCSB with
computed differ from the FILTER_SPEC* in the TCSB, then: the new values and save Fwd_Flowspec in the TCSB.
1. Make an appropriate set of TC_DelFilter and o Otherwise, if the TCSB is not new but the TC_Filter_Spec*
just computed differs from the FILTER_SPEC* in the TCSB,
then:
1. Turn on the Resv_Refresh_Needed flag.
2. Make an appropriate set of TC_DelFilter and
TC_AddFilter calls to transform the Filter_spec_list TC_AddFilter calls to transform the Filter_spec_list
in the TCSB into the new TC_Filter_Spec*. in the TCSB into the new TC_Filter_Spec*.
o If the active RSB contains a RESV_CONFIRM object, then:
1. If the Is_Biggest flag is on, move the RESV_CONFIRM
object into the TCSB and turn on the
Resv_Refresh_Needed flag. (This will invoke the Resv
REFRESH sequence, which will either forward or return
the RESV_CONFIRM object, deleting it from the TCSB
again).
2. Otherwise, create and send a ResvConf message to the
address in the RESV_CONFIRM object. Include the
RESV_CONFIRM object in the ResvConf message. The RACK
message should also include an ERROR_SPEC object whose
Error_Node parameter is IP address of OI from the TCSB
and that specifies "No Error".
o If the Resv_Refresh_Needed flag is on, make a RESV_EVENT
upcall to the application:
Call: <Upcall_Proc>( session-id, RESV_EVENT,
style, Flowspec, Filter_spec_list,
[POLICY_DATA] )
where Flowspec and Filter_spec_list come from the TCSB and
the style comes from the active RSB.
o Return to the event sequence that invoked this one. 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 Insert TIME_VALUES object into the Path message being
the maximum of the TTL values from the senders included in built. Compute the IP TTL for the Path message as one less
the message. However, if the result is zero, return than the TTL value received in the message. However, if
without sending the Path message. the result is zero, return without sending the Path
message.
o Insert TIME_VALUES and PHOP objects into the Path message
being built.
o Create a sender descriptor containing the SENDER_TEMPLATE, o Create a sender descriptor containing the SENDER_TEMPLATE,
SENDER_TSPEC, and POLICY_DATA objects, if present in the SENDER_TSPEC, and POLICY_DATA objects, if present in the
PSB, and pack it into the Path message being built. PSB, and pack it into the Path message being built.
o Pass any ADSPEC and SENDER_TSPEC objects present in the PSB o Send a copy of the Path message to each interface OI in
to the traffic control call TC_Advertise. Insert the OutInterfact_list. Before sending each copy:
modified ADSPEC object that is returned into the Path
message being built.
o If the PSB has the E_Police flag on and if interface OI is 1. If the PSB has the E_Police flag on and if interface
not capable of policing, turn the E_Police flag on in the OI is not capable of policing, turn the E_Police flag
Path message being built. on in the Path message being built.
o Send a copy of the Path message to each interface in 2. Pass any ADSPEC and SENDER_TSPEC objects present in
OutInterfact_list. Before sending each copy, insert into the PSB to the traffic control call TC_Advertise.
its PHOP object the interface address and the LIH for the Insert the modified ADSPEC object that is returned
interface. into the Path message being built.
3. Insert into its PHOP object the interface address and
the LIH for the 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 the expiration of a reservation refresh timer, or invoked
directly as a result of the Resv_Refresh_Needed flag being from the Path MESSAGE ARRIVES, Resv MESSAGE ARRIVES, or ResvErr
turned on by processing a Resv or ResvTear message. MESSAGE ARRIVES sequence.
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 TCSBs for matching
reservations and merges the styles, FLOWSPECs and reservations and merges the styles, FLOWSPECs and
Filter_spec_list's appropriately. It then builds a Resv message Filter_spec_list's appropriately. It then builds a Resv message
and sends it to PH. The details depend upon the attributes of and sends it to PH. The details depend upon the attributes of
the style(s) included in the reservations. the style(s) included in the reservations.
Initially the Need_Scope flag is off and the new_SCOPE object is
empty.
o Create an output message containing INTEGRITY (if o Create an output message containing INTEGRITY (if
supported), SESSION, RSVP_HOP, and TIME_VALUES objects. configured), SESSION, RSVP_HOP, and TIME_VALUES objects.
o Determine the style for these reservations from the first o Determine the style for these reservations from the first
RSB for the session, and move the STYLE object into the RSB for the session, and move the STYLE object into the
proto-message. (Note that the present set of styles are proto-message. (Note that the present set of styles are
never themselves merged; if future styles can be merged, never themselves merged; if future styles can be merged,
these rules will become more complex). these rules will become more complex).
o If style is wildcard and if there are PSB's from more than 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 one PHOP and if the multicast routing protocol does not use
shared trees, set the Need_Scope flag on, otherwise set it shared trees, set the Need_Scope flag on.
off.
o Select each sender PSB whose PHOP has address PH.
1. Set local flag B_Merge off. o Select each sender PSB whose PHOP has address PH. Set the
local flag B_Merge off and execute the following steps.
2. Select all RSB's whose Filter_spec_list's match the 1. Select all TCSB'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.
3. If B_Merge flag is off then ignore a blockaded RSB, as 2. If B_Merge flag is off then ignore a blockaded TCSB,
follows. as follows.
- Select BSB's that match this RSB; if any of these - Select BSB's that match this TCSB. If any of
BSB's has a Qb that is not strictly larger than these BSB's has a Qb that is not strictly larger
RSB Flowspec, then continue processing with the than TC_Flowspec, then continue processing with
next RSB. the next TCSB.
However, if steps 1 and 2 result in finding that all However, if steps 1 and 2 result in finding that all
RSB's matching this PSB are blockaded, then: TCSB's matching this PSB are blockaded, then:
- If this Resv REFRESH sequence was invoked from - If this Resv REFRESH sequence was invoked from
RESV ERROR RECEIVED, then return now to the RESV ERROR RECEIVED, then return to the latter.
latter.
- Otherwise, turn on the B_Merge flag and restart - Otherwise, turn on the B_Merge flag and restart
with this procedure step 1. above. at step 1, immediately above.
4. Merge the flowspecs, as follows: 3. Merge the flowspecs from this set of TCSB's, as
follows:
- If B_Merge flag is off, compute the LUB over the - If B_Merge flag is off, compute the LUB over the
Flowspec objects of this set of RSB's. flowspec objects. From each TCSB, use the
Fwd_Flowspec object if present, else use the
normal Flowspec object.
While computing the LUB, check for a RESV_CONFIRM While computing the LUB, check for a RESV_CONFIRM
object in each RSB. If a RESV_CONFIRM object is object in each TCSB. If a RESV_CONFIRM object is
found: found:
- If the FLOWSPEC in that RSB is larger than - If the flowspec (Fwd_Flowspec or Flowspec)
all other (non-blockaded) flowspecs being in that TCSB is larger than all other (non-
compared, then save this RESV_CONFIRM object blockaded) flowspecs being compared, then
for forwarding. save this RESV_CONFIRM object for forwarding
and delete from the TCSB.
- Otherwise (the corresponding FLOWSPEC is not - Otherwise (the corresponding flowspec is not
the largest) then create and send a ResvConf the largest), create and send a ResvConf
message containing the RESV_CONFIRM object message to the address in the RESV_CONFIRM
to the address in the RESV_CONFIRM object. object. Include the RESV_CONFIRM object in
Include the RESV_CONFIRM object in the the ResvConf message. The ResvConf message
ResvConf message. The RACK message should should also include an ERROR_SPEC object
also include an ERROR_SPEC object whose whose Error_Node parameter is IP address of
Error_Node parameter is IP address of OI OI from the TCSB and specifying "No Error".
from the RSB.
- Then delete the RESV_CONFIRM object from the - Delete the RESV_CONFIRM object from the
RSB. TCSB.
- Otherwise (B_Merge flag is on), compute the GLB - Otherwise (B_Merge flag is on), compute the GLB
over the Flowspec objects of this set of RSB's. over the Flowspec objects of this set of TCSB's.
While computing the GLB, check for a RESV_CONFIRM While computing the GLB, check for a RESV_CONFIRM
object in each RSB. If one is found, delete it. object in each TCSB. 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
RSB's.
6. Merge the F_POLICY_DATA objects from the RSB's.
7. (All matching RSB's have been processed). The next 4. (All matching TCSB'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
Use the Sender_Template as the merged Use the Sender_Template as the merged
FILTER_SPEC. Pack the merged (FLOWSPEC, FILTER_SPEC. Pack the merged (FLOWSPEC,
FILTER_SPEC, F_POLICY_DATA) triplet into the FILTER_SPEC, F_POLICY_DATA) triplet into the
message as a flow descriptor. message as a flow descriptor.
Shared wildcard reservation (WF) style Shared wildcard reservation (WF) style
There is no merged FILTER_SPEC. Merge (take the There is no merged FILTER_SPEC. Merge (compute
maximum of) the merged FLOWSPECS from the RSB's, the LUB of) the merged FLOWSPECS from the TCSB's,
across all PSB's for PH. across all PSB's for PH.
Shared distinct reservation (SE) style Shared distinct reservation (SE) style
Using the Sender_Template as the merged Using the Sender_Template as the merged
FILTER_SPEC, form the union of the FILTER_SPECS FILTER_SPEC, form the union of the FILTER_SPECS
obtained from the RSB's. Merge (take the maximum obtained from the TCSB's. Merge (compute the LUB
of) the merged FLOWSPECS from the RSB's, across of) the merged FLOWSPECS from the TCSB's, across
all PSB's for PH. all PSB's for PH.
9. If the Need_Scope flag is on, remove from the merged 5. If the Need_Scope flag is on and the sender specified
SCOPE object all sender addresses that do not match by the PSB is not the local API:
the set of PSB's for PH, and all senders addresses
that are local. If the resulting set is empty, no
Resv should be forwarded to this PHOP; return.
Otherwise (set is not empty), move the new SCOPE
object into the message.
o (All PSB's have been processed). If a shared reservation - Find each RSB that matches this PSB, i.e., whose
style is being built, move the final merged FLOWSPEC, Filter_spec_list matches Sender_Template in the
F_POLICY_DATA, and FILTER_SPEC (if SE) objects into the PSB and whose OI is included in
OutInterface_list.
- If the RSB either has no SCOPE list or its SCOPE
list includes the sender IP address from the PSB,
insert the sender IP address into new_SCOPE.
o (All PSB's for PH have been processed). Finish the Resv
message. message.
o If a RESV_CONFIRM object was saved earlier, copy it into 1. If Need_Scope flag is on but new_SCOPE is empty, no
the new Resv message and delete it from the RSB in which it RESV message should be sent; return. Otherwise, if
was found. Need_Scope is on, move new_SCOPE into the message.
o Set the RSVP_HOP object in the message to contain the 2. If a shared reservation style is being built, move the
IncInterface address through which it will be sent and the final merged FLOWSPEC object and filter spec list into
LIH from (one of) the PSB's. the message.
3. If a RESV_CONFIRM object was saved earlier, copy it
into the new Resv message.
4. Set the RSVP_HOP object in the message to contain the
IncInterface address through which it will be sent and
the LIH from (one of) the PSB's.
o Send the message to the address PH. o Send the message to the address PH.
ROUTE CHANGE NOTIFICATION
This sequence is triggered when routing sends a route change
notification to RSVP.
o Each PSB is located whose SESSION matches the destination
address and whose SENDER_TEMPLATE matches the source
address (for multicast).
1. If the OutInterface_list from the notification differs
from that in the PSB, execute the Path LOCAL REPAIR
sequence.
2. If the IncInterface from the notification differs from
that in the PSB, update the PSB.
Path LOCAL REPAIR Path LOCAL REPAIR
The sequence is entered when RSVP learns from routing that the The sequence is entered to effect local repair after a route
set of outgoing interfaces for some destination (G,DstPort) has change for a given PSB.
changed.
o Wait for a delay time of W seconds [Section 3.5]. o Wait for a delay time of W seconds [Section 3.5].
o For each session that exists for destination IP address G, o Execute the Path REFRESH event sequence (above) for the
execute the Path REFRESH event sequence above for each PSB.
sender (PSB) for that session.
5. Acknowledgments 5. Acknowledgments
The design of RSVP is based upon research performed in 1992-1993 by a The design of RSVP is based upon research performed in 1992-1993 by a
collaboration including Lixia Zhang (Xerox PARC), Deborah Estrin collaboration including Lixia Zhang (Xerox PARC), Deborah Estrin
(USC/ISI), Scott Shenker (Xerox PARC), Sugih Jamin (USC/Xerox PARC), (USC/ISI), Scott Shenker (Xerox PARC), Sugih Jamin (USC/Xerox PARC),
and Daniel Zappala (USC). Sugih Jamin developed the first prototype and Daniel Zappala (USC). Sugih Jamin developed the first prototype
implementation of RSVP and successfully demonstrated it in May 1993. implementation of RSVP and successfully demonstrated it in May 1993.
Shai Herzog, and later Steve Berson, continued development of RSVP Shai Herzog, and later Steve Berson, continued development of RSVP
prototypes. prototypes.
skipping to change at page 92, line 8 skipping to change at page 91, line 8
Fred Baker (Cisco), Mark Baugher (Intel), Don Hoffman (Sun), Steve Fred Baker (Cisco), Mark Baugher (Intel), Don Hoffman (Sun), Steve
Jakowski (NetManage), John Krawczyk (Bay Networks), and Bill Nowicki Jakowski (NetManage), John Krawczyk (Bay Networks), and Bill Nowicki
(SGI). Ron Frederick, Bobby Minnear, Eve Schooler, and Garrett (SGI). Ron Frederick, Bobby Minnear, Eve Schooler, and Garrett
Wollman did early interfacing of multicast applications to RSVP. Wollman did early interfacing of multicast applications to RSVP.
Steve Deering, Bill Fenner, and Ajit Thyagarajan helped with the Steve Deering, Bill Fenner, and Ajit Thyagarajan helped with the
interface between RSVP and multicast routing. 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 IPv6. To accommodate other address families, additional C-Types
easily be defined. These definitions are contained as an Appendix, could easily be defined. These definitions are contained as an
to ease updating. Appendix, 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
SESSION Class = 1. SESSION Class = 1.
o IPv4/UDP SESSION object: Class = 1, C-Type = 1 o IPv4/UDP SESSION object: Class = 1, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) | | IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort | | Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o IP/UDP SESSION object: Class = 1, C-Type = 2 o IPv6/UDP SESSION object: Class = 1, C-Type = 2
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IP6 DestAddress (16 bytes) + + IPv6 DestAddress (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| 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
skipping to change at page 94, line 17 skipping to change at page 93, line 17
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
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 Next/Previous Hop Address | | IPv4 Next/Previous Hop Address |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Logical Interface Handle | | Logical Interface Handle |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o IP6 RSVP_HOP object: Class = 3, C-Type = 2 o IPv6 RSVP_HOP object: Class = 3, C-Type = 2
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IP6 Next/Previous Hop Address + + IPv6 Next/Previous Hop Address +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Logical Interface Handle | | Logical Interface Handle |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
This object provides the IP address of the interface through which This object provides the IP address of the interface through which
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
skipping to change at page 96, line 12 skipping to change at page 95, line 12
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.
o IPv4 ERROR_SPEC object: Class = 6, C-Type = 1 o IPv4 ERROR_SPEC object: Class = 6, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IP4 Error Node Address (4 bytes) | | IPv4 Error Node Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value | | Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o IP6 ERROR_SPEC object: Class = 6, C-Type = 2 o IPv6 ERROR_SPEC object: Class = 6, C-Type = 2
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IP6 Error Node Address (16 bytes) + + IPv6 Error Node Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| 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.
skipping to change at page 98, line 16 skipping to change at page 97, line 16
SCOPE class = 7. SCOPE class = 7.
This object contains a list of IP addresses, used for routing This object contains a list of IP addresses, used for routing
messages with wildcard scope without loops. The addresses must be messages with wildcard scope without loops. The addresses must be
listed in ascending numerical order. listed in ascending numerical order.
o IPv4 SCOPE List object: Class = 7, C-Type = 1 o IPv4 SCOPE List object: Class = 7, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IP4 Src Address (4 bytes) | | IPv4 Src Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
// // // //
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IP4 Src Address (4 bytes) | | IPv4 Src Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o IP6 SCOPE list object: Class = 7, C-Type = 2 o IPv6 SCOPE list object: Class = 7, C-Type = 2
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IP6 Src Address (16 bytes) + + IPv6 Src Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
// // // //
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IP6 Src Address (16 bytes) + + IPv6 Src Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
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
skipping to change at page 102, line 17 skipping to change at page 101, line 17
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 |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o IP6 FILTER_SPEC object: Class = 10, C-Type = 2 o IPv6 FILTER_SPEC object: Class = 10, C-Type = 2
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IP6 SrcAddress (16 bytes) + + IPv6 SrcAddress (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| ////// | ////// | SrcPort | | ////// | ////// | SrcPort |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o IP6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3 o IPv6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IP6 SrcAddress (16 bytes) + + IPv6 SrcAddress (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| /////// | Flow Label (24 bits) | | /////// | Flow Label (24 bits) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
SrcAddress SrcAddress
The IP source address for a sender host. Must be non-zero. The IP source address for a sender host. Must be non-zero.
SrcPort SrcPort
The UDP/TCP source port for a sender, or zero to indicate The UDP/TCP source port for a sender, or zero to indicate
`none'. `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 IPv6. 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.
o IPv4/UDP SENDER_TEMPLATE object: Class = 11, C-Type = 1 o IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 1
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 IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 2
Definition same as IP6/UDP FILTER_SPEC object. Definition same as IPv6/UDP FILTER_SPEC object.
A.11 SENDER_TSPEC Class A.11 SENDER_TSPEC Class
SENDER_TSPEC class = 12. SENDER_TSPEC class = 12.
o Intserv SENDER_TSPEC object: Class = 12, C-Type = 1 o Intserv SENDER_TSPEC object: Class = 12, C-Type = 1
The contents of this object are specified in service The contents of this object are specified in service
specification documents prepared by the int-serv working specification documents prepared by the int-serv working
group. group.
skipping to change at page 107, line 15 skipping to change at page 106, line 15
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) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o IP6 RESV_CONFIRM object: Class = 15, C-Type = 2 o IPv6 RESV_CONFIRM object: Class = 15, C-Type = 2
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IP6 Receiver Address (16 bytes) + + IPv6 Receiver Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
APPENDIX B. Error Codes and Values APPENDIX B. Error Codes and Values
The following Error Codes may appear in ERROR_SPEC objects and be The following Error Codes may appear in ERROR_SPEC objects and be
passed to end systems. Except where noted, these Error Codes may passed to end systems. Except where noted, these Error Codes may
appear only in ResvErr messages. appear only in ResvErr messages.
skipping to change at page 110, line 13 skipping to change at page 109, line 13
Sessions for same destination address and protocol have appeared Sessions for same destination address and protocol have appeared
with both zero and non-zero dest port fields. This Error Code with both zero and non-zero dest port fields. This Error Code
may appear in a PathErr or ResvErr message. may appear in a PathErr or ResvErr message.
o Error Code = 08: Ambiguous path o Error Code = 08: Ambiguous path
Sender port appears both zero and non-zero in same session in a Sender port appears both zero and non-zero in same session in a
Path message. This Error Code may appear only in a PathErr Path message. This Error Code may appear only in a PathErr
message. message.
o Error Code = 09, 10, 11: (reserved) o Error Code = 09: Ambiguous Filter Spec
Message contains a filter spec that matches more than one
sender, but an explicit style that requires an exact match.
o Error Code = 10, 11: (reserved)
o Error Code = 12: Service preempted o Error Code = 12: Service preempted
The service request defined by the STYLE object and the flow The service request defined by the STYLE object and the flow
descriptor has been administratively preempted. descriptor has been administratively preempted.
For this Error Code, the 16 bits of the Error Value field are: For this Error Code, the 16 bits of the Error Value field are:
ssur cccc cccc cccc ssur cccc cccc cccc
skipping to change at page 116, line 28 skipping to change at page 115, line 28
configured with Ra and Ta. configured with Ra and Ta.
2. A particular host on the LAN connected to Hu could be designated 2. A particular host on the LAN connected to Hu could be designated
as an "RSVP relay host". A relay host would listen on (G*,Pu) as an "RSVP relay host". A relay host would listen on (G*,Pu)
and forward any Path messages directly to R, although it would and forward any Path messages directly to R, although it would
not be in the data path. The relay host would have to be not be in the data path. The relay host would have to be
configured with Ra and Ta. configured with Ra and Ta.
References References
[Baker96] Baker, Fred, "RSVP Cryptographic Authentication", Internet [Baker96] Baker, Fred, "RSVP Cryptographic Authentication", Work in
Draft draft-ietf-rsvp-md5-01.txt, February 1996. Progress, February 1996.
[ISInt93] Braden, R., Clark, D., and S. Shenker, "Integrated Services [ISInt93] Braden, R., Clark, D., and S. Shenker, "Integrated Services
in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and
PARC, June 1994. PARC, June 1994.
[CSZ92] Clark, D., Shenker, S., and L. Zhang, "Supporting Real-Time
Applications in an Integrated Services Packet Network: Architecture
and Mechanisms", Proc. SIGCOMM '92, Baltimore, MD, August 1992.
[FJ94] Floyd, S. and V. Jacobson, "Synchronization of Periodic Routing [FJ94] Floyd, S. and V. Jacobson, "Synchronization of Periodic Routing
Messages", IEEE/ACM Transactions on Networking, Vol. 2, No. 2, Messages", IEEE/ACM Transactions on Networking, Vol. 2, No. 2,
April, 1994. April, 1994.
[Katz95] Katz, D., "IP Router Alert Option", Internet Draft draft- [IPSEC96] Berger, L., O'Malley, T., and R. Atkinson, "RSVP Extensions
katz-router-alert-01.txt, Cisco Systems, November 16, 1995. for IPSEC IPv4 Data Flows", Work in Progress, 1996.
[Partridge92] Partridge, C., "A Proposed Flow Specification", RFC 1363, [Katz95] Katz, D., "IP Router Alert Option", Work in Progress, November
BBN, September 1992. 1995.
[IServ93] Shenker, S., Clark, D., and L. Zhang, "A Service Model for an [ISdata95] Wroclawski, J., "Standard Data Encoding for Integrated
Integrated Services Internet", Work in Progress, October 1993. Services Objects", Work in Progress, November 1995.
[RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. [RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D.
Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network, Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network,
September 1993. September 1993.
[ServTempl95a] Shenker, S., "Network Element Service Specification [ServTempl95] Shenker, S., "Network Element Service Specification
Template", Internet Draft draft-ietf-intserv-svc-template-00.txt, Template", Internet Draft draft-ietf-intserv-svc-template-00.txt,
Integrated Services Working Group, March 1995. Integrated Services Working Group, March 1995.
[Shenker94] Shenker, S., "Two-Pass or Not Two-Pass", Current Meeting [OPWA95] Shenker, S. and L. Breslau, "Two Issues in Reservation
Report, RSVP Working Group, Proceedings of the Thirtieth Internet Establishment", Proc. ACM SIGCOMM '95, Cambridge, MA, August 1995.
Engineering Task Force, Toronto, Canada, July 1994.
Security Considerations Security Considerations
See Section 2.8. See Section 2.8.
Authors' Addresses Authors' Addresses
Lixia Zhang Lixia Zhang
Xerox Palo Alto Research Center Xerox Palo Alto Research Center
3333 Coyote Hill Road 3333 Coyote Hill Road
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/