< draft-ietf-rsvp-spec-14.txt   draft-ietf-rsvp-spec-15.txt >
Internet Draft R. Braden, Ed. Internet Draft R. Braden, Ed.
Expiration: May 1997 ISI Expiration: November 1997 ISI
File: draft-ietf-rsvp-spec-14.txt L. Zhang File: draft-ietf-rsvp-spec-15.txt L. Zhang
PARC PARC
S. Berson S. Berson
ISI ISI
S. Herzog S. Herzog
ISI IBM Research
S. Jamin S. Jamin
USC Univ. of Michigan
Resource ReSerVation Protocol (RSVP) -- Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification Version 1 Functional Specification
November 5, 1996 May 27, 1997
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 ........................................................3 1. Introduction ........................................................4
1.1 Data Flows ......................................................6 1.1 Data Flows ......................................................7
1.2 Reservation Model ...............................................7 1.2 Reservation Model ...............................................8
1.3 Reservation Styles ..............................................10 1.3 Reservation Styles ..............................................11
1.4 Examples of Styles ..............................................12 1.4 Examples of Styles ..............................................14
2. RSVP Protocol Mechanisms ............................................17 2. RSVP Protocol Mechanisms ............................................19
2.1 RSVP Messages ...................................................17 2.1 RSVP Messages ...................................................19
2.2 Merging Flowspecs ...............................................19 2.2 Merging Flowspecs ...............................................21
2.3 Soft State ......................................................20 2.3 Soft State ......................................................22
2.4 Teardown ........................................................22 2.4 Teardown ........................................................24
2.5 Errors ..........................................................23 2.5 Errors ..........................................................25
2.6 Confirmation ....................................................25 2.6 Confirmation ....................................................27
2.7 Policy and Security .............................................25 2.7 Policy Control ..................................................27
2.8 Non-RSVP Clouds .................................................26 2.8 Security ........................................................28
2.9 Host Model ......................................................27 2.9 Non-RSVP Clouds .................................................29
3. RSVP Functional Specification .......................................29 2.10 Host Model .....................................................30
3.1 RSVP Message Formats ............................................29 3. RSVP Functional Specification .......................................32
3.2 Port Usage ......................................................42 3.1 RSVP Message Formats ............................................32
3.3 Sending RSVP Messages ...........................................43 3.2 Port Usage ......................................................46
3.4 Avoiding RSVP Message Loops .....................................45 3.3 Sending RSVP Messages ...........................................47
3.5 Blockade State ..................................................48 3.4 Avoiding RSVP Message Loops .....................................49
3.6 Local Repair ....................................................50 3.5 Blockade State ..................................................53
3.7 Time Parameters .................................................51 3.6 Local Repair ....................................................55
3.8 Traffic Policing and Non-Integrated Service Hops ................52 3.7 Time Parameters .................................................56
3.9 Multihomed Hosts ................................................53 3.8 Traffic Policing and Non-Integrated Service Hops ................57
3.10 Future Compatibility ...........................................55 3.9 Multihomed Hosts ................................................58
3.11 RSVP Interfaces ................................................57 3.10 Future Compatibility ...........................................60
APPENDIX A. Object Definitions .........................................69 3.11 RSVP Interfaces ................................................62
APPENDIX B. Error Codes and Values .....................................84 APPENDIX A. Object Definitions .........................................75
APPENDIX C. UDP Encapsulation ..........................................89 APPENDIX B. Error Codes and Values .....................................90
APPENDIX D. Glossary ...................................................93 APPENDIX C. UDP Encapsulation ..........................................95
APPENDIX D. Glossary ...................................................99
What's Changed
This revision contains the following very minor changes from the ID14
version.
o For clarity, each message type is now defined separately in
Section 3.1.
o We added more precise and complete rules for accepting Path
messages for unicast and multicast destinations (Section
3.1.3).
o We added more precise and complete rules for processing and
forwarding PathTear messages (Section 3.1.5).
o A note was added that a SCOPE object will be ignored if it
appears in a ResvTear message (Section 3.1.6).
o A note was added that a SENDER_TSPEC or ADSPEC object will be
ignored if it appears in a PathTear message (Section 3.1.5).
o The obsolete error code Ambiguous Filter Spec (09) was
removed, and a new (and more consistent) name was given to
error code 08 (Appendix B).
o In the generic interface to traffic control, the Adspec was
added as a parameter to the AddFlow and ModFlow calls
(3.11.2). This is needed to accommodate a node that updates
the slack term (S) of Guaranteed service.
o An error subtype was added for an Adspec error (Appendix B).
o Additional explanation was added for handling a CONFIRM
object (Section 3.1.4).
o The rules for forwarding objects with unknown class type were
clarified.
o Additional discussion was added to the Introduction and to
Section 3.11.2 about the relationship of RSVP to the link
layer. (Section 3.10).
o Section 2.7 on Policy and Security was split into two
sections, and some additional discussion of security was
included.
o There were some minor editorial improvements.
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 to request specific qualities of
The RSVP protocol is used by a host, on behalf of an application data service from the network for particular application data streams or
stream, to request a specific quality of service (QoS) from the flows. RSVP is also used by routers to deliver quality-of-service
network for particular data streams or flows. The RSVP protocol is (QoS) requests to all nodes along the path(s) of the flows and to
also used by routers to deliver QoS control requests to all nodes establish and maintain state to provide the requested service. RSVP
along the path(s) of the flows and to establish and maintain state to requests will generally result in resources being reserved in each
provide the requested service. RSVP requests will generally,
although not necessarily, result in resources being reserved in each
node along the data path. node along the data path.
RSVP requests resources for simplex flows, i.e., it requests RSVP requests resources for simplex flows, 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 IPv6), occupying the place RSVP operates on top of IPv4 or IPv6, occupying the place of a
of a transport protocol in the protocol stack. However, RSVP does transport protocol in the protocol stack. However, RSVP does not
not transport application data but is rather an Internet control 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 process consults the local routing database(s) to obtain routes. RSVP process consults the local routing database(s) to obtain routes.
In the multicast case, for example, a host sends IGMP messages to In the multicast case, for example, a host sends IGMP messages to
join a multicast group and then sends RSVP messages to reserve join a multicast group and then sends RSVP messages to reserve
resources along the delivery path(s) of that group. Routing resources along the delivery path(s) of that group. Routing
protocols determine where packets get forwarded; RSVP is only protocols determine where packets get forwarded; RSVP is only
concerned with the QoS of those packets that are forwarded in concerned with the QoS of those packets that are forwarded in
accordance with routing. accordance with routing.
In order to efficiently accommodate large groups, dynamic group In order to efficiently accommodate large groups, dynamic group
membership, and heterogeneous receiver requirements, RSVP makes membership, and heterogeneous receiver requirements, RSVP makes
receivers responsible for requesting QoS control [RSVP93]. A QoS receivers responsible for requesting a specific QoS [RSVP93]. A QoS
control request from a receiver host application is passed to the request from a receiver host application is passed to the local RSVP
local RSVP process. The RSVP protocol then carries the request to process. The RSVP protocol then carries the request to all the nodes
all the nodes (routers and hosts) along the reverse data path(s) to (routers and hosts) along the reverse data path(s) to the data
the data source(s). source(s), but only as far as the router where the receiver's data
path joins the multicast distribution tree. As a result, RSVP's
reservation overhead is in general logarithmic rather than linear in
the number of receivers.
HOST ROUTER HOST ROUTER
_____________________________ ____________________________ _____________________________ ____________________________
| _______ | | | | _______ | | |
| | | _______ | | _______ | | | | _______ | | _______ |
| |Appli- | | | |RSVP | | | | | |Appli- | | | |RSVP | | | |
| | cation| | RSVP <---------------------------> RSVP <----------> | | cation| | RSVP <---------------------------> RSVP <---------->
| | <--> | | | _______ | | | | | <--> | | | _______ | | |
| | | |process| _____ | ||Routing| |process| _____ | | | | |process| _____ | ||Routing| |process| _____ |
skipping to change at page 4, line 30 skipping to change at page 5, line 30
| _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl|| | _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl||
| | | | | |_____|| | | | | ||_____|| | | | | | |_____|| | | | | ||_____||
| |Class-| | Packet | | | |Class-| | Packet | | | |Class-| | Packet | | | |Class-| | Packet | |
| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========> | | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>
| |______| |________| |data | |______| |________| |data | |______| |________| |data | |______| |________| |data
| | | | | | | |
|_____________________________| |____________________________| |_____________________________| |____________________________|
Figure 1: RSVP in Hosts and Routers Figure 1: RSVP in Hosts and Routers
Each node that is capable of QoS control passes incoming data packets Quality of service is implemented for a particular data flow by
through a "packet classifier", which determines the route and the QoS mechanisms collectively called "traffic control". These mechanisms
class for each packet. On each outgoing interface, a "packet include (1) a packet classifier, (2) admission control, and (3) a
scheduler" then makes forwarding decisions for every packet, to "packet scheduler" or some other link-layer-dependent mechanism to
achieve the promised QoS on the particular link-layer medium used by determine when particular packets are forwarded. The "packet
that interface. classifier" determines the QoS class (and perhaps the route) for each
packet. For each outgoing interface, the "packet scheduler" or other
link-layer-dependent mechanism achieves the promised QoS. Traffic
control implements QoS service models defined by the Integrated
Services Working Group.
At each node, an RSVP QoS control request is passed to two local During reservation setup, an RSVP QoS request is passed to two local
decision modules, "admission control" and "policy control". decision modules, "admission control" and "policy control".
Admission control determines whether the node has sufficient Admission control determines whether the node has sufficient
available resources to supply the requested QoS. Policy control available resources to supply the requested QoS. Policy control
determines whether the user has administrative permission to make the determines whether the user has administrative permission to make the
reservation. If both checks succeed, parameters are set in the reservation. If both checks succeed, parameters are set in the
packet classifier and in the scheduler, to obtain the desired QoS. packet classifier and in the link layer interface (e.g., in the
If either check fails, the RSVP program returns an error notification packet scheduler) to obtain the desired QoS. If either check fails,
to the application process that originated the request. We refer to the RSVP program returns an error notification to the application
the packet classifier, packet scheduler, and admission control process that originated the request.
components as "traffic control". The packet scheduler and admission
control components implement QoS service models defined by the
Integrated Services Working Group.
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 itself transfers and manipulates QoS or unicast delivery paths. RSVP itself transfers and manipulates QoS
control parameters as opaque data, passing them to the appropriate and policy control parameters as opaque data, passing them to the
traffic control modules for interpretation. The structure and appropriate traffic control and policy control modules for
contents of the QoS parameters are documented in specifications interpretation. The structure and contents of the QoS parameters are
developed by the Integrated Services Working Group. In particular, documented in specifications developed by the Integrated Services
[ISrsvp96] describes these data structures and how RSVP fits into the Working Group; see [ISrsvp96]. The structure and contents of the
larger integrated service architecture. policy parameters are under development.
RSVP is designed to scale well for very large multicast groups. Since the membership of a large multicast group and the resulting
Since both the membership of a large group and the topology of large multicast tree topology are likely to change with time, the RSVP
multicast trees are likely to change with time, the RSVP design design assumes that state for RSVP and traffic control state is to be
assumes that router state for traffic control will be built and built and destroyed incrementally in routers and hosts. For this
destroyed incrementally. For this purpose, RSVP uses "soft state" in purpose, RSVP establishes "soft" state; that is, RSVP sends periodic
the routers. That is, RSVP sends periodic refresh messages to refresh messages to maintain the state along the reserved path(s).
maintain the state along the reserved path(s); in absence of In the absence of refresh messages, the state automatically times out
refreshes, the state will automatically time out and be deleted. and is deleted.
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 to changing routes. group membership as well as to changing routes.
o RSVP is simplex, i.e., it makes reservations for unidirectional o RSVP is simplex, i.e., it makes reservations for unidirectional
data flows. 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 routers and hosts, providing
support for dynamic membership changes and automatic adaptation graceful support for dynamic membership changes and automatic
to routing changes. adaptation to routing changes.
o RSVP is not a routing protocol but depends upon present and o RSVP is not a routing protocol but depends upon present and
future routing protocols. future routing protocols.
o RSVP transports and maintains opaque state for traffic control, o RSVP transports and maintains traffic control and policy control
and policy control. parameters that are opaque to RSVP.
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. 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] and [ISInt93]. RSVP design are presented in [RSVP93] and [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 a UDP encapsulation of RSVP messages, for hosts whose
operating systems provide inadequate raw network I/O support.
1.1 Data Flows 1.1 Data Flows
RSVP defines a "session" to be 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. RSVP treats each
session is defined by DestAddress, the IP destination address of session independently, and this document often omits the implied
the data packets, by the IP protocol ID, and perhaps by DstPort, a qualification "for the same session".
An RSVP session is defined by the triple: (DestAddress, ProtocolId
[, DstPort]). Here DestAddress, the IP destination address of the
data packets, may be a unicast or multicast address. ProtocolId
is the IP protocol ID. The optional DstPort parameter is a
"generalized destination port", i.e., some further demultiplexing "generalized destination port", i.e., some further demultiplexing
point in the transport or application protocol layer. RSVP treats point in the transport or application protocol layer. DstPort
each session independently, and this document often omits the could be defined by a UDP/TCP destination port field, by an
implied qualification "for the same session". equivalent field in another transport protocol, or by some
application-specific information.
DestAddress is a group address for multicast delivery or the Although the RSVP protocol is designed to be easily extensible for
unicast address of a single receiver. DstPort could be defined by greater generality, the basic protocol documented here supports
a UDP/TCP destination port field, by an equivalent field in only UDP/TCP ports as generalized ports. Note that it is not
another transport protocol, or by some application-specific strictly necessary to include DstPort in the session definition
information. Although the RSVP protocol is designed to be easily when DestAddress is multicast, since different sessions can always
extensible for greater generality, the basic protocol documented have different multicast addresses. However, DstPort is necessary
here supports only UDP/TCP ports as generalized ports. Note that to allow more than one unicast session addressed to the same
it is not strictly necessary to include DstPort in the session receiver host.
definition when DestAddress is multicast, since different sessions
can always have different multicast addresses. However, DstPort
is necessary to allow more than one unicast session addressed 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".
skipping to change at page 7, line 29 skipping to change at page 8, line 32
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 in 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 or other link layer mechanism, while the filter
the filter spec is used to set parameters in the packet spec is used to set parameters in the packet classifier. Data
classifier. Data packets that are addressed to a particular packets that are addressed to a particular session but do not
session but do not match any of the filter specs for that session match any of the filter specs for that session are handled as
are handled as best-effort traffic. best-effort traffic.
Note that the action to control QoS occurs at the place where the
data enters the medium, i.e., at the upstream end of the logical
or physical link, although an RSVP reservation request originates
from receiver(s) downstream. In this document, we define the
directional terms "upstream" vs. "downstream", "previous hop" vs.
"next hop", and "incoming interface" vs "outgoing interface" with
respect to the direction of data flow.
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 negotiation with the link layer to obtain the QoS
requested by RSVP. This mapping to the link layer QoS may be
accomplished in a number of possible ways; the details will be
medium-dependent. On a QoS-passive medium such as a leased line,
the scheduler itself allocates packet transmission capacity. The
scheduler may also allocate other system resources such as CPU
time or buffers.
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 models [ISrsvp96] and are generally opaque to RSVP. service models [ISrsvp96] and are generally opaque to RSVP.
The exact format of a filter spec depends upon whether IPv4 or The exact format of a filter spec depends upon whether IPv4 or
IPv6 is in use; see Appendix A. In the most general approach IPv6 is in use; see Appendix A. In the most general approach
[RSVP93], filter specs may select arbitrary subsets of the packets [RSVP93], filter specs may select arbitrary subsets of the packets
in a given session. Such subsets might be defined in terms of in a given session. Such subsets might be defined in terms of
senders (i.e., sender IP address and generalized source port), in senders (i.e., sender IP address and generalized source port), in
terms of a higher-level protocol, or generally in terms of any terms of a higher-level protocol, or generally in terms of any
fields in any protocol headers in the packet. For example, filter fields in any protocol headers in the packet. For example, filter
specs might be used to select different subflows in a specs might be used to select different subflows of a
hierarchically-encoded signal by selecting on fields in an hierarchically-encoded video stream by selecting on fields in an
application-layer header. In the interest of simplicity (and to application-layer header. In the interest of simplicity (and to
minimize layer violation), the present RSVP version uses a much minimize layer violation), the basic filter spec format defined in
more restricted form of filter spec, consisting of sender IP the present RSVP specification has a very restricted form: sender
address and optionally the UDP/TCP port number SrcPort. IP address and optionally the UDP/TCP port 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.
This raises three potential problems. This raises three potential problems.
1. It is necessary to avoid IP fragmentation of a data flow for 1. It is necessary to avoid IP fragmentation of a data flow for
which a resource reservation is desired. which a resource reservation is desired.
Document [ISrsvp96] specifies a procedure for applications Document [ISrsvp96] specifies a procedure for applications
using RSVP facilities to compute the minimum MTU over a using RSVP facilities to compute the minimum MTU over a
skipping to change at page 9, line 6 skipping to change at page 9, line 40
details will be provided in the future. details will be provided in the future.
3. IP-level Security, under either IPv4 or IPv6, may encrypt the 3. IP-level Security, under either IPv4 or IPv6, may encrypt the
entire transport header, hiding the port numbers of data entire transport header, hiding the port numbers of data
packets from intermediate routers. packets from intermediate routers.
A small extension to RSVP for IP Security under IPv4 and IPv6 A small extension to RSVP for IP Security under IPv4 and IPv6
is described separately in [IPSEC96]. is described separately in [IPSEC96].
RSVP messages carrying reservation requests originate at receivers RSVP messages carrying reservation requests originate at receivers
and are passed upstream towards the sender(s). At each and are passed upstream towards the sender(s). Note: in this
intermediate node, two general actions are taken on a request. document, we define the directional terms "upstream" vs.
"downstream", "previous hop" vs. "next hop", and "incoming
interface" vs "outgoing interface" with respect to the direction
of data flow.
1. Make a reservation At each intermediate node, a reservation request triggers two
general actions, as follows:
The request is passed to admission control and policy 1. Make a reservation on a link
control. If either test fails, the reservation is rejected
and RSVP returns an error message to the appropriate The RSVP process passes the request to admission control and
receiver(s). If both succeed, the node uses the flowspec to policy control. If either test fails, the reservation is
set up the packet scheduler for the desired QoS and the rejected and the RSVP process returns an error message to the
filter spec to set the packet classifier to select the appropriate receiver(s). If both succeed, the node sets the
appropriate data packets. packet classifier to select the data packets defined by the
filter spec, and it interacts with the appropriate link layer
to obtain the desired QoS defined by the flowspec.
The detailed rules for satisfying an RSVP QoS request depend
upon the particular link layer technology in use on each
interface. Specifications are under development in the ISSLL
Working Group for mapping reservation requests into popular
link layer technologies. For a simple leased line, the
desired QoS will be obtained from the packet scheduler in the
link layer driver, for example. If the link-layer technology
implements its own QoS management capability, then RSVP must
negotiate with the link layer to obtain the requested QoS.
Note that the action to control QoS occurs at the place where
the data enters the link-layer medium, i.e., at the upstream
end of the logical or physical link, although an RSVP
reservation request originates from receiver(s) downstream.
2. Forward the request upstream 2. Forward the request upstream
The reservation request is propagated upstream towards the A 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
from the request that it received from downstream, for two differ from the request that it received from downstream, for
reasons. First, the traffic control mechanism may modify the two reasons. The traffic control mechanism may modify the
flowspec hop-by-hop. Second, reservations for the same sender, or flowspec hop-by-hop. More importantly, reservations from
the same set of senders, from different downstream branches of the different downstream branches of the multicast tree(s) from
multicast tree(s) are "merged" as reservations travel upstream; as the same sender (or set of senders) must be " merged" as
a result, a node forwards upstream only the reservation request reservations travel upstream.
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; the node may then send a reservation confirmation message further; the node may then send a reservation confirmation message
back to the receiver. Note that the receipt of a confirmation is back to the receiver. Note that the receipt of a confirmation is
skipping to change at page 13, line 11 skipping to change at page 14, line 33
Figure 4 illustrates a router with two incoming interfaces, Figure 4 illustrates a router with two incoming interfaces,
labeled (a) and (b), through which flows will arrive, and two labeled (a) and (b), through which flows will arrive, and two
outgoing interfaces, labeled (c) and (d), through which data will outgoing interfaces, labeled (c) and (d), through which data will
be forwarded. This topology will be assumed in the examples that be forwarded. This topology will be assumed in the examples that
follow. There are three upstream senders; packets from sender S1 follow. There are three upstream senders; packets from sender S1
(S2 and S3) arrive through previous hop (a) ((b), respectively). (S2 and S3) arrive through previous hop (a) ((b), respectively).
There are also three downstream receivers; packets bound for R1 There are also three downstream receivers; packets bound for R1
(R2 and R3) are routed via outgoing interface (c) ((d), (R2 and R3) are routed via outgoing interface (c) ((d),
respectively). We furthermore assume that outgoing interface (d) respectively). We furthermore assume that outgoing interface (d)
is connected to a broadcast LAN, and that R2 and R3 are reached is connected to a broadcast LAN, i.e., that replication occurs in
via different next hop routers (not shown). the network; R2 and R3 are reached via different next hop routers
(not shown).
We must also specify the multicast routes within the node of We must also specify the multicast routes within the node of
Figure 4. Assume first that data packets from each Si shown in Figure 4. Assume first that data packets from each Si shown in
Figure 4 are routed to both outgoing interfaces. Under this Figure 4 are routed to both outgoing interfaces. Under this
assumption, Figures 5, 6, and 7 illustrate Wildcard-Filter, assumption, Figures 5, 6, and 7 illustrate Wildcard-Filter,
Fixed-Filter, and Shared-Explicit reservations, respectively. Fixed-Filter, and Shared-Explicit reservations, respectively.
________________ ________________
(a)| | (c) (a)| | (c)
( S1 ) ---------->| |----------> ( R1 ) ( S1 ) ---------->| |----------> ( R1 )
skipping to change at page 13, line 28 skipping to change at page 15, line 13
Fixed-Filter, and Shared-Explicit reservations, respectively. Fixed-Filter, and Shared-Explicit reservations, respectively.
________________ ________________
(a)| | (c) (a)| | (c)
( S1 ) ---------->| |----------> ( R1 ) ( S1 ) ---------->| |----------> ( R1 )
| Router | | | Router | |
(b)| | (d) |---> ( R2 ) (b)| | (d) |---> ( R2 )
( S2,S3 ) ------->| |------| ( S2,S3 ) ------->| |------|
|________________| |---> ( R3 ) |________________| |---> ( 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 "Receives" 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 "Reserves" column shows the
resulting reservation state for each interface. The "Send" resulting reservation state for each interface. The "Sends"
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 "Reserves" 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 two distinct Figure 5, showing the WF style, illustrates two distinct
situations in which merging is required. (1) Each of the two next situations in which merging is required. (1) Each of the two next
hops on interface (d) results in a separate RSVP reservation hops on interface (d) results in a separate RSVP reservation
request, as shown; these two requests must be merged into the request, as shown; these two requests must be merged into the
effective flowspec, 3B, that is used to make the reservation on effective flowspec, 3B, that is used to make the reservation on
interface (d). (2) The reservations on the interfaces (c) and (d) interface (d). (2) The reservations on the interfaces (c) and (d)
must be merged in order to forward the reservation requests must be merged in order to forward the reservation requests
upstream; as a result, the larger flowspec 4B is forwarded upstream; as a result, the larger flowspec 4B is forwarded
upstream to each previous hop. upstream to each previous hop.
| |
Send | Reserve Receive Sends | Reserves Receives
| |
| _______ | _______
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. For each
descriptors for senders S2 and S3, received from outgoing outgoing interface, there is a separate reservation for each
source that has been requested, but this reservation will be
shared among all the receivers that made the request. The flow
descriptors for senders S2 and S3, received through outgoing
interfaces (c) and (d), are packed (not merged) into the request interfaces (c) and (d), are packed (not merged) into the request
forwarded to previous hop (b). On the other hand, the three forwarded to previous hop (b). On the other hand, the three
different flow descriptors specifying sender S1 are merged into different flow descriptors specifying sender S1 are merged into
the single request FF( S1{4B} ) that is sent to previous hop (a). the single request FF( S1{4B} ) that is sent to previous hop (a).
For each outgoing interface, there is a separate reservation for
each source that has been requested, but this reservation will be
shared among all the receivers that made the request.
| |
Send | Reserve Receive Sends | Reserves Receives
| |
| ________ | ________
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} )
skipping to change at page 15, line 9 skipping to change at page 17, line 9
| |________| | |________|
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. and the resulting flowspec is the largest flowspec.
| |
Send | Reserve Receive Sends | Reserves Receives
| |
| ________ | ________
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} |
| |________| | |________|
---------------------|--------------------------------------------- ---------------------|---------------------------------------------
| __________ | __________
<- (b) | (d) |(S1,S2,S3)| (d) <- SE( (S1,S3){3B} ) <- (b) | (d) |(S1,S2,S3)| (d) <- SE( (S1,S3){3B} )
SE( (S2,S3){3B} ) | | {3B} | <- SE( S2{2B} ) SE( (S2,S3){3B} ) | | {3B} | <- SE( S2{2B} )
| |__________| | |__________|
skipping to change at page 16, line 8 skipping to change at page 18, line 8
and S3 are not forwarded to interface (c), e.g., because the and S3 are not forwarded to interface (c), e.g., because the
network topology provides a shorter path for these senders towards network topology provides a shorter path for these senders towards
R1, not traversing this node. The bottom part of Figure 8 shows R1, not traversing this node. The bottom part of Figure 8 shows
WF style reservations under this assumption. Since there is no WF style reservations under this assumption. Since there is no
route from (b) to (c), the reservation forwarded out interface (b) route from (b) to (c), the reservation forwarded out interface (b)
considers only the reservation on interface (d). considers only the reservation on interface (d).
_______________ _______________
(a)| | (c) (a)| | (c)
( S1 ) ---------->| >-----------> |----------> ( R1 ) ( S1 ) ---------->| >-----------> |----------> ( R1 )
| - | | > |
| - | | > |
(b)| - | (d) (b)| > | (d)
( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 ) ( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 )
|_______________| |_______________|
Router Configuration Router Configuration
| |
Send | Reserve Receive Sends | Reserves Receives
| |
| _______ | _______
WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} ) WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} )
| |_______| | |_______|
| |
-----------------------|---------------------------------------- -----------------------|----------------------------------------
| _______ | _______
WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} ) WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} )
| |_______| <- WF( * {2B} ) | |_______| <- WF( * {2B} )
skipping to change at page 17, line 32 skipping to change at page 19, line 32
_____ | <--Resv|_____________________| <-- Resv | | | _____ | <--Resv|_____________________| <-- Resv | | |
| | | |--| D' | | | | |--| D' |
| B' |--| | |_____| | B' |--| | |_____|
|_____| | | |_____| | |
Figure 9: Router Using RSVP Figure 9: Router Using RSVP
Figure 9 illustrates RSVP's model of a router node. Each data Figure 9 illustrates RSVP's model of a router node. Each data
flow arrives from a "previous hop" through a corresponding flow 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 interface may act in both the incoming
incoming and outgoing roles for different data flows in the same and outgoing roles for different data flows in the same session.
session. Multiple previous hops and/or next hops may be reached Multiple previous hops and/or next hops may be reached through a
through a given physical interface, as a result of the connected given physical interface; for example, the figure implies that D
network being a shared medium, or the existence of non-RSVP and D' are connected to (d) with a broadcast LAN.
routers in the path to the next RSVP hop (see Section 2.8).
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 messages must follow exactly upstream towards the senders. These messages must follow exactly
the reverse of the path(s) the data packets will use, upstream to the reverse of the path(s) the data packets will use, upstream to
all the sender hosts included in the sender selection. They all the sender hosts included in the sender selection. They
create and maintain "reservation state" in each node along the create and maintain "reservation state" in each node along the
path(s). Resv messages must finally be delivered to the sender path(s). Resv messages must finally be delivered to the sender
hosts themselves, so that the hosts can set up appropriate traffic hosts themselves, so that the hosts can set up appropriate traffic
skipping to change at page 18, line 50 skipping to change at page 20, line 50
o Adspec o Adspec
A Path message may carry a package of OPWA advertising A Path message may carry a package of OPWA advertising
information, known as an "Adspec". An Adspec received in a information, known as an "Adspec". An Adspec received in a
Path message is passed to the local traffic control, which Path message is passed to the local traffic control, which
returns an updated Adspec; the updated version is then returns an updated Adspec; the updated version is then
forwarded in Path messages sent downstream. 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.8). On the other hand, through non-RSVP clouds (see Section 2.9). On the other hand,
Resv messages are sent hop-by-hop; each RSVP-speaking node Resv messages are sent hop-by-hop; each RSVP-speaking node
forwards a Resv message to the unicast address of a previous RSVP forwards a Resv message to the unicast address of a previous RSVP
hop. hop.
2.2 Merging Flowspecs 2.2 Merging Flowspecs
As noted earlier, a single physical interface may receive multiple A Resv message forwarded to a previous hop carries a flowspec that
is the "largest" of the flowspecs requested by the next hops to
which the data flow will be sent (however, see Section 3.5 for a
different merging rule used in certain cases). We say the
flowspecs have been "merged". The examples shown in Section 1.4
illustrated another case of merging, when there are 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. Here again, the installed
have an effective flowspec that is the "largest" of the flowspecs reservation should have an effective flowspec that is the
requested by the different next hops. Similarly, a Resv message "largest" of the flowspecs requested by the different next hops.
forwarded to a previous hop should carry a flowspec that is the
"largest" of the flowspecs requested by the different next hops
(however, in certain cases the "smallest" is taken rather than the
largest, see Section 3.5). These cases both represent flowspec
merging.
Flowspec merging requires calculation of the "largest" of a set of Since flowspecs are opaque to RSVP, the actual rules for comparing
flowspecs. However, flowspecs are opaque to RSVP, so the actual flowspecs must be defined and implemented outside RSVP proper.
rules for comparing flowspecs must be defined and implemented The comparison rules are defined in the appropriate integrated
outside RSVP proper. The comparison rules are defined in the service specification document. An RSVP implementation will need
appropriate integrated service specification document; see to call service-specific routines to perform flowspec merging.
[ISrsvp96]. An RSVP implementation will need to call service-
specific routines to perform flowspec merging.
Note that flowspecs are generally multi-dimensional vectors; they Note that flowspecs are generally multi-dimensional vectors; they
may contain both Tspec and Rspec components, each of which may may contain both Tspec and Rspec components, each of which may
itself be multi-dimensional. Therefore, it may not be possible to itself be multi-dimensional. Therefore, it may not be possible to
strictly order two flowspecs. For example, if one request calls strictly order two flowspecs. For example, if one request calls
for a higher bandwidth and another calls for a tighter delay for a higher bandwidth and another calls for a tighter delay
bound, one is not "larger" than the other. In such a case, bound, one is not "larger" than the other. In such a case,
instead of taking the larger, the service-specific merging instead of taking the larger, the service-specific merging
routines must be able to return a third flowspec that is at least routines must be able to return a third flowspec that is at least
as large as each; mathematically, this is the "least upper bound" as large as each; mathematically, this is the "least upper bound"
(LUB). In some cases, a flowspec at least as small is needed; (LUB). In some cases, a flowspec at least as small is needed;
this is the "greatest lower bound" (GLB) GLB (Greatest Lower this is the "greatest lower bound" (GLB) GLB (Greatest Lower
Bound). Bound).
The following steps are used to calculate the effective flowspec The following steps are used to calculate the effective flowspec
(Te, Re) to be installed on an interface [ISrsvp96]. Here Te is (Re, Te) to be installed on an interface [ISrsvp96]. Here Te is
the effective Tspec and Re is the effective Rspec. As an example, the effective Tspec and Re is the effective Rspec.
consider interface (d) in Figure 9.
1. A service-specific calculation of the LUB of the flowspecs 1. An effective flowspec is determined for the outgoing
that arrived in Resv messages from different next hops (e.g., interface. Depending upon the link-layer technology, this
D and D') but the same outgoing interface (d) is performed. may require merging flowspecs from different next hops; this
means computing the effective flowspec as the LUB of the
flowspecs. Note that what flowspecs to merge is determined
by the link layer medium (see Section 3.11.2), while how to
merge them is determined by the service model in use
[ISrsvp96].
The result is a flowspec that is opaque to RSVP but actually The result is a flowspec that is opaque to RSVP but actually
consists of the pair (Re, Resv_Te), where Re is the LUB of consists of the pair (Re, Resv_Te), where is Re is the
the Rspecs and Resv_Te is the LUB of the Tspecs from the Resv effective Rspec and Resv_Te is the effective Tspec.
messages.
2. A service-specific calculation of Path_Te, the sum of all 2. A service-specific calculation of Path_Te, the sum of all
Tspecs that were supplied in Path messages from different Tspecs that were supplied in Path messages from different
previous hops (e.g., some or all of A, B, and B' in Figure previous hops (e.g., some or all of A, B, and B' in Figure
9), is performed. 9), is performed.
3. RSVP passes these two results, (Re, Resv_Te) and Path_Te, to 3. (Re, Resv_Te) and Path_Te are passed to traffic control.
traffic control. Traffic control will compute the "minimum" Traffic control will compute the effective flowspec as the
of Path_Te and Resv_Te in a service-dependent manner, to be "minimum" of Path_Te and Resv_Te, in a service-dependent
the effective flowspec. manner.
A generic set of service-specific calls to compare flowspecs and Section 3.11.6 defines a generic set of service-specific calls to
compute the LUB and GLB of flowspecs, and to compare and sum compare flowspecs, to compute the LUB and GLB of flowspecs, and to
Tspecs, is defined in Section 3.11.5. compare and sum Tspecs.
2.3 Soft State 2.3 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
skipping to change at page 21, line 10 skipping to change at page 23, line 12
minimal bandwidth for RSVP messages to protect them from minimal bandwidth for RSVP messages to 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; unused state will time out if it is not explicitly torn path; unused state will time out if it is not explicitly torn
down. down.
In steady state, refreshing is performed hop-by-hop, to allow In steady state, state is refreshed hop-by-hop to allow merging.
merging. When the received state differs from the stored state, When the received state differs from the stored state, the stored
the stored state is updated. If this update results in state is updated. If this update results in modification of state
modification of state to be forwarded in refresh messages, these to be forwarded in refresh messages, these refresh messages must
refresh messages must be generated and forwarded immediately, so be generated and forwarded immediately, so that state changes can
that state changes can be propagated end-to-end without delay. be propagated end-to-end without delay. However, propagation of a
However, propagation of a change stops when and if it reaches a change stops when and if it reaches a point where merging causes
point where merging causes no resulting state change. This no resulting state change. This minimizes RSVP control traffic
minimizes RSVP control traffic due to changes and is essential for due to changes and is essential for scaling to large multicast
scaling to large multicast groups. groups.
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-style reservations, session. Both receivers are making wildcard-style reservations,
skipping to change at page 22, line 28 skipping to change at page 24, line 28
Reserve on (a) | Reserve on (c) Reserve on (a) | Reserve on (c)
__________ | __________ __________ | __________
| * {4B} | | | * {3B} | | * {4B} | | | * {3B} |
|__________| | |__________| |__________| | |__________|
| |
Figure 10: Independent Reservations Figure 10: Independent Reservations
2.4 Teardown 2.4 Teardown
Upon arrival, RSVP "teardown" messages remove path and reservation RSVP "teardown" messages remove path or reservation state
state immediately. Although it is not necessary to explicitly immediately. Although it is not necessary to explicitly tear down
tear down an old reservation, we recommend that all end hosts send an old reservation, we recommend that all end hosts send a
a teardown request as soon as an application finishes. teardown request as soon as an application finishes.
There are two types of RSVP teardown message, PathTear and There are two types of RSVP teardown message, PathTear and
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).
skipping to change at page 25, line 12 skipping to change at page 27, line 12
blockade state timeout interval). Such intermittent behavior blockade state timeout interval). Such intermittent behavior
might be very distressing for users. might be very distressing for users.
2.6 Confirmation 2.6 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 is
are not forwarded further, and if the Resv included a not forwarded further, and if the Resv included a confirmation-
confirmation-request object, a ResvConf message is sent back to request object, a ResvConf message is sent back to Rj. If the
Rj. If the confirmation request is forwarded, it is forwarded confirmation request is forwarded, it is forwarded immediately,
immediately, and no more than once for each request. and no more than once for each request.
This confirmation mechanism has the following consequences: 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
reservation was the second to arrive at that node, may reservation was the second to arrive at that node, may
receive a ResvConf from that node while R1's request has not receive a ResvConf from that node while R1's request has not
yet propagated all the way to a matching sender and may still yet propagated all the way to a matching sender and may still
fail. Thus, R2 may receive a ResvConf although there is no fail. Thus, R2 may receive a ResvConf although there is no
end-to-end reservation in place; furthermore, R2 may receive end-to-end reservation in place; furthermore, R2 may receive
a ResvConf followed by a ResvErr. a ResvConf followed by a ResvErr.
2.7 Policy and Security 2.7 Policy Control
RSVP-mediated QoS requests will result in particular user(s) RSVP-mediated QoS requests allow particular user(s) to obtain
getting preferential access to network resources. To prevent preferential access to network resources. To prevent abuse, some
abuse, some form of back pressure on users is likely to be form of back pressure will generally be required on users who make
required. This back pressure might take the form of reservations. For example, such back pressure may be accomplished
administrative rules, or of some form of real or virtual billing by administrative access policies, or it may depend upon some form
for the "cost" of a reservation. The form and contents of such of user feedback such as real or virtual billing for the "cost" of
back pressure is a matter of administrative policy that may be a reservation. In any case, reliable user identification and
determined independently by each administrative domain in the selective admission will generally be needed when a reservation is
Internet. requested.
Therefore, there is likely to be policy control as well as The term "policy control" is used for the mechanisms required to
admission control over the establishment of reservations. As support access policies and back pressure for RSVP reservations.
input to policy control, RSVP messages may carry "policy data". When a new reservation is requested, each node must answer two
Policy data may include credentials identifying users or user questions: "Are enough resources available to meet this request?"
classes, account numbers, limits, quotas, etc. RSVP will pass the and "Is this user allowed to make this reservation?" These two
"policy data" to a "Local Policy Module" (LPM) for a decision. decisions are termed the "admission control" decision and the
"policy control" decision, respectively, and both must be
favorable in order for RSVP to make a reservation. Different
administrative domains in the Internet may have different
reservation policies.
To protect the integrity of the policy control mechanisms, it may The input to policy control is referred to as "policy data", which
be necessary to ensure the integrity of RSVP messages against RSVP carries in POLICY_DATA objects. Policy data may include
corruption or spoofing, hop by hop. For this purpose, RSVP credentials identifying users or user classes, account numbers,
messages may carry integrity objects that can be created and limits, quotas, etc. Like flowspecs, policy data is opaque to
verified by neighbor RSVP-capable nodes. These objects use a RSVP, which simply passes it to policy control when required.
keyed cryptographic digest technique and assume that RSVP Similarly, merging of policy data must be done by the policy
neighbors share a secret [Baker96]. control mechanism rather than by RSVP itself. Note that the merge
points for policy data are likely to be at the boundaries of
administrative domains. It may therefore be necessary to carry
accumulated and unmerged policy data upstream through multiple
nodes before reaching one of these merge points.
User policy data in reservation request messages presents a Carrying user-provided policy data in Resv messages presents a
scaling problem. When a multicast group has a large number of potential scaling problem. When a multicast group has a large
receivers, it will be impossible or undesirable to carry all number of receivers, it will be impossible or undesirable to carry
receivers' policy data upstream to the sender(s). The policy data all receivers' policy data upstream. The policy data will have to
will have to be administratively merged at places near the be administratively merged at places near the receivers, to avoid
receivers, to avoid excessive policy data. Administrative merging excessive policy data. Further discussion of these issues and an
implies checking the user credentials and accounting data and then example of a policy control scheme will be found in [PolArch96].
substituting a token indicating the check has succeeded. A chain Specifications for the format of policy data objects and RSVP
of trust established using integrity fields will allow upstream processing rules for them are under development.
nodes to accept these tokens.
In summary, different administrative domains in the Internet may 2.8 Security
have different policies regarding their resource usage and
reservation. The role of RSVP is to carry policy data associated
with each reservation to the network as needed. Note that the
merge points for policy data are likely to be at the boundaries of
administrative domains. It may be necessary to carry accumulated
and unmerged policy data upstream through multiple nodes before
reaching one of these merge points.
This document does not specify the contents of policy data, the RSVP raises the following security issues.
structure of an LPM, or any generic policy models. These will be
defined in the future.
2.8 Non-RSVP Clouds o Message integrity and node authentication
Corrupted or spoofed reservation requests could lead to theft
of service by unauthorized parties or to denial of service
caused by locking up network resources. RSVP protects
against such attacks with a hop-by-hop authentication
mechanism using an encrypted hash function. The mechanism is
supported by INTEGRITY objects that may appear in any RSVP
message. These objects use a keyed cryptographic digest
technique, which assumes that RSVP neighbors share a secret.
Although this mechanism is part of the base RSVP
specification, it is described in a companion document
[Baker96].
Widespread use of the RSVP integrity mechanism will require
the availability of the long-sought key management and
distribution infrastructure for routers. Until that
infrastructure becomes available, manual key management will
be required to secure RSVP message integrity.
o User authentication
Policy control will depend upon positive authentication of
the user responsible for each reservation request. Policy
data may therefore include cryptographically protected user
certificates. Specification of such certificates is a future
issue.
Even without globally-verifiable user certificates, it may be
possible to provide practical user authentication in many
cases by establishing a chain of trust, using the hop-by-hop
INTEGRITY mechanism described earlier.
o Secure data streams
The first two security issues concerned RSVP's operation. A
third security issue concerns resource reservations for
secure data streams. In particular, the use of IPSEC (IP
Security) in the data stream poses a problem for RSVP: if
the transport and higher level headers are encrypted, RSVP's
generalized port numbers cannot be used to define a session
or a sender.
To solve this problem, an RSVP extension has been defined in
which the security association identifier (IPSEC SPI) plays a
role roughly equivalent to the generalized ports [IPSEC97].
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 useful realtime service. capacity, it may still provide useful realtime service.
skipping to change at page 27, line 42 skipping to change at page 30, line 39
the logical outgoing interface; both values are stored in the path the logical outgoing interface; both values are stored in the path
state. A Resv message arriving at the addressed node carries both state. A Resv message arriving at the addressed node carries both
the IP address and the LIH of the correct outgoing interface, i.e, the IP address and the LIH of the correct outgoing interface, i.e,
the interface that should receive the requested reservation, the interface that should receive the requested reservation,
regardless of which interface it arrives on. regardless of which interface it arrives on.
The LIH may also be useful when RSVP reservations are made over a The LIH may also be useful when RSVP reservations are made over a
complex link layer, to map between IP layer and link layer flow complex link layer, to map between IP layer and link layer flow
entities. entities.
2.9 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, ProtocolId, and perhaps the generalized (DestAddress, ProtocolId [, DstPort]) must be assigned and
destination port, must be assigned and communicated to all the communicated to all the senders and receivers by some out-of-band
senders and receivers by some out-of-band mechanism. When an RSVP mechanism. When an RSVP session is being set up, the following
session is being set up, the following events happen at the end events happen at the end systems.
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 33, line 29 skipping to change at page 36, line 29
The maximum object content length is 65528 bytes. The Class- The maximum object content length is 65528 bytes. The Class-
Num and C-Type fields may be used together as a 16-bit number Num and C-Type fields may be used together as a 16-bit number
to define a unique type for each object. to define a unique type for each object.
The high-order two bits of the Class-Num is used to determine The high-order two bits of the Class-Num is used to determine
what action a node should take if it does not recognize the what action a node should take if it does not recognize the
Class-Num of an object; see Section 3.10. Class-Num of an object; see Section 3.10.
3.1.3 Path Messages 3.1.3 Path Messages
Each sender host periodically sends a Path message for each
data flow it originates. It contains a SENDER_TEMPLATE object
defining the format of the data packets and a SENDER_TSPEC
object specifying the traffic characteristics of the flow.
Optionally, it may contain may be an ADSPEC object carrying
advertising (OPWA) data for the flow.
A Path message travels from a sender to receiver(s) along the
same path(s) used by the data packets. The IP source address
of a Path message must be an address of the sender it
describes, while the destination address must be the
DestAddress for the session. These addresses assure that the
message will be correctly routed through a non-RSVP cloud.
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> ... ]
skipping to change at page 33, line 50 skipping to change at page 37, line 16
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ] [ <ADSPEC> ]
If the INTEGRITY object is present, it must immediately follow If the INTEGRITY object is present, it must immediately follow
the common header. There are no other requirements on the common header. There are no other requirements on
transmission order, although the above order is recommended. transmission order, although the above order is recommended.
Any number of POLICY_DATA objects may appear. Any number of POLICY_DATA objects may appear.
The PHOP (i.e., the RSVP_HOP) object of each Path message The PHOP (i.e., RSVP_HOP) object of each Path message contains
contains the previous hop address, i.e., the IP address of the the previous hop address, i.e., the IP address of the interface
interface through which the Path message was most recently through which the Path message was most recently sent. It also
sent. It also carries a logical interface handle (LIH). carries a logical interface handle (LIH).
Each sender host periodically sends a Path message for each
data flow it originates. The SENDER_TEMPLATE object defines
the format of the data packets, while the SENDER_TSPEC object
specifies the traffic characteristics of the flow. Optionally,
there may be an ADSPEC object carrying advertising (OPWA) data
for the flow.
The Path message travels from a sender to receiver(s) along the
same path(s) used by the data packets. The IP source address
of a Path message is an address of the sender it describes,
while the destination address is the DestAddress for the
session. These addresses assure that the message will be
correctly routed through a non-RSVP cloud.
Each RSVP-capable node along the path(s) captures a Path Each RSVP-capable node along the path(s) captures a Path
message and processes it to create path state for the sender message and processes it to create path state for the sender
defined by the SENDER_TEMPLATE and SESSION objects. Any defined by the SENDER_TEMPLATE and SESSION objects. Any
POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in
the path state. If an error is encountered while processing a the path state. If an error is encountered while processing a
Path message, a PathErr message is sent to the originating Path message, a PathErr message is sent to the originating
sender of the Path message. Path messages must satisfy the sender of the Path message. Path messages must satisfy the
rules on SrcPort and DstPort in Section 3.2. rules on SrcPort and DstPort in Section 3.2.
skipping to change at page 35, line 5 skipping to change at page 37, line 51
The route depends upon the session DestAddress, and for some The route depends upon the session DestAddress, and for some
routing protocols also upon the source (sender's IP) address. routing protocols also upon the source (sender's IP) address.
The routing information generally includes the list of zero or The routing information generally includes the list of zero or
more outgoing interfaces to which the Path message is to be more outgoing interfaces to which the Path message is to be
forwarded. Because each outgoing interface has a different IP forwarded. Because each outgoing interface has a different IP
address, the Path messages sent out different interfaces address, the Path messages sent out different interfaces
contain different PHOP addresses. In addition, ADSPEC objects contain different PHOP addresses. In addition, ADSPEC objects
carried in Path messages will also generally differ for carried in Path messages will also generally differ for
different outgoing interfaces. different outgoing interfaces.
Some IP multicast routing protocols (e.g., DVMRP, PIM, and Path state for a given session and sender may not necessarily
MOSPF) also keep track of the expected incoming interface for have a unique PHOP or unique incoming interface. There are two
each source host to a multicast group. Whenever this cases, corresponding to multicast and unicast sessions.
information is available, RSVP should check the incoming
interface of each Path message and do special handling of those o Multicast Sessions
messages Path messages that have arrived on the wrong
interface; see Section 3.9. Multicast routing allows a stable distribution tree in
which Path messages from the same sender arrive from more
than one PHOP, and RSVP must be prepared to maintain all
such path state. The RSVP rules for handling this
situation are contained in Section 3.9. RSVP must not
forward (according to the rules of Section 3.9) Path
messages that arrive on an incoming interface different
from that provided by routing.
o Unicast Sessions
For a short period following a unicast route change
upstream, a node may receive Path messages from multiple
PHOPs for a given (session, sender) pair. The node cannot
reliably determine which is the right PHOP, although the
node will receive data from only one of the PHOPs at a
time. One implementation choice for RSVP is to ignore
PHOP in matching unicast past state, and allow the PHOP to
flip among the candidates. Another implementation choice
is to maintain path state for each PHOP and to send Resv
messages upstream towards all such PHOPs. In either case,
the situation is a transient; the unused path state will
time out or be torn down (because upstream path state
timed out).
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.
skipping to change at page 37, line 29 skipping to change at page 41, line 5
A request with wildcard sender selection will match all A request with wildcard sender selection will match all
senders that route to the given outgoing interface. senders that route to the given outgoing interface.
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.4 below); must be included in the message (see Section 3.4 below);
in this case, the scope for forwarding the reservation is in this case, the scope for forwarding the reservation is
constrained to just the sender IP addresses explicitly constrained to just the sender IP addresses explicitly
listed in the SCOPE object. listed in the SCOPE object.
3.1.5 Teardown Messages A Resv message that is forwarded by a node is generally
the result of merging a set of incoming Resv messages
(that are not blockaded; see Section 3.5). If one of
these merged messages contains a RESV_CONFIRM object and
has a FLOWSPEC larger than the FLOWSPECs of the other
merged reservation requests, then this RESV_CONFIRM object
is forwarded in the outgoing Resv message. A RESV_CONFIRM
object in one of the other merged requests (whose
flowspecs are equal to, smaller than, or incomparable to,
the merged flowspec, and which is not blockaded) will
trigger the generation of an ResvConf message containing
the RESV_CONFIRM. A RESV_CONFIRM object in a request that
is blockaded will be neither forwarded nor returned; it
will be dropped in the current node.
There are two types of RSVP teardown message, PathTear and 3.1.5 Path Teardown Messages
ResvTear.
o A PathTear message deletes path state (which in turn Receipt of a PathTear (path teardown) message deletes matching
deletes any reservation state for that sender), traveling path state. Matching state must have match the SESSION,
towards all receivers that are downstream from the SENDER_TEMPLATE, and PHOP objects. In addition, a PathTear
initiating node. A PathTear message must be routed message for a multicast session can only match path state for
exactly like the corresponding Path message. Therefore, the incoming interface on which the PathTear arrived. If there
its IP destination address must be the session is no matching path state, a PathTear message should be
DestAddress, and its IP source address must be the address discarded and not forwarded.
of the sender being torn down.
o A ResvTear message deletes reservation state, traveling PathTear messages are initiated explicitly by senders or by
towards all matching senders upstream from the initiating path state timeout in any node, and they travel downstream
node. A ResvTear message must be routed like the towards all receivers. A unicast PathTear must not be
corresponding Resv message, and its IP destination address forwarded if there is path state for the same (session, sender)
will be the unicast address of a previous hop. A ResvTear pair but a different PHOP. Forwarding of multicast PathTear
message will be initiated by a receiver, by a node in messages is governed by the rules of Section 3.9.
which reservation state has timed out, or by a node in
which a reservation has been preempted. A PathTear message must be routed exactly like the
corresponding Path message. Therefore, its IP destination
address must be the session DestAddress, and its IP source
address must be the sender address from the path state being
torn down.
<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)
A PathTear message may include a SENDER_TSPEC or ADSPEC object
in its sender descriptor, but these must be ignored. The order
requirements are as given earlier for a Path message, but the
above order is recommended.
Deletion of path state as the result of a PathTear message or a
timeout must also adjust related reservation state as required
to maintain consistency in the local node. The adjustment
depends upon the reservation style. For example, suppose a
PathTear deletes the path state for a sender S. If the style
specifies explicit sender selection (FF or SE), any reservation
with a filter spec matching S should be deleted; if the style
has wildcard sender selection (WF), the reservation should be
deleted if S is the last sender to the session. These
reservation changes should not trigger an immediate Resv
refresh message, since the PathTear message has already made
the required changes upstream. They should not trigger a
ResvErr message, since the result could be to generate a shower
of such messages.
3.1.6 Resv Teardown Messages
Receipt of a ResvTear (reservation teardown) message deletes
matching reservation state. Matching reservation state must
match the SESSION, STYLE, and FILTER_SPEC objects as well as
the LIH in the RSVP_HOP object. If there is no matching
reservation state, a ResvTear message should be discarded. A
ResvTear message may tear down any subset of the filter specs
in FF-style or SE-style reservation state.
ResvTear messages are initiated explicitly by receivers or by
any node in which reservation state has timed out, and they
travel upstream towards all matching senders.
A ResvTear message must be routed like the corresponding Resv
message, and its IP destination address will be the unicast
address of a previous hop.
<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
requirements for INTEGRITY object, sender descriptor, STYLE requirements for INTEGRITY object, sender descriptor, STYLE
object, and flow descriptor list are as given earlier for Path object, and flow descriptor list are as given earlier for a
and Resv messages. A ResvTear message may specify any subset Resv message, but the above order is recommended. A ResvTear
of the filter specs in FF-style or SE-style reservation state. message may include a SCOPE object, but it must be ignored.
Note that, unless it is accidentally dropped along the way, a
PathTear message will reach all receivers downstream from the
originating node. On the other hand, a ResvTear message will
cease to be forwarded at the node where merging would have
suppressed forwarding of the corresponding Resv message.
Depending upon the resulting state change in a node, receipt of
a ResvTear message may cause a ResvTear message to be
forwarded, a modified Resv message to be forwarded, or no
message to be forwarded.
These three cases can be illustrated in the case of the FF- A ResvTear message will cease to be forwarded at the node where
style reservations shown in Figure 6. merging would have suppressed forwarding of the corresponding
Resv message. Depending upon the resulting state change in a
node, receipt of a ResvTear message may cause a ResvTear
message to be forwarded, a modified Resv message to be
forwarded, or no message to be forwarded. These three cases
can be illustrated in the case of the FF-style reservations
shown in Figure 6.
o If receiver R2 sends a ResvTear message for its o If receiver R2 sends a ResvTear message for its
reservation S3{B}, the corresponding reservation is reservation S3{B}, the corresponding reservation is
removed from interface (d) and an ResvTear for S3{B} is removed from interface (d) and a ResvTear for S3{B} is
forwarded out (b). forwarded out (b).
o If receiver R1 sends a ResvTear for its reservation o If receiver R1 sends a ResvTear for its reservation
S1{4B}, the corresponding reservation is removed from S1{4B}, the corresponding reservation is removed from
interface (c) and a modified Resv message FF( S1{3B} ) is interface (c) and a modified Resv message FF( S1{3B} ) is
immediately forwarded out (a). immediately forwarded out (a).
o If receiver R3 sends a ResvTear message for S1{B}, there o If receiver R3 sends a ResvTear message for S1{B}, there
is no change in the effective reservation S1{3B} on (d) is no change in the effective reservation S1{3B} on (d)
and no message is forwarded. and no message is forwarded.
Deletion of path state as the result of a PathTear message or a 3.1.7 Path Error Messages
timeout must cause any adjustments in related reservation state
required to maintain consistency in the local node. The
adjustment in reservation state depends upon the style. For
example, suppose a PathTear deletes the path state for a sender
S. If the style specifies explicit sender selection (FF or
SE), any reservation with a filter spec matching S should be
deleted; if the style has wildcard sender selection (WF), the
reservation should be deleted if S is the last sender to the
session. These reservation changes should not trigger an
immediate Resv refresh message, since the PathTear message has
already made the required changes upstream. However, at the
node in which a ResvTear message stops, the change of
reservation state may trigger a Resv refresh starting at that
node.
3.1.6 Error Messages
There are two types of RSVP error messages.
o PathErr messages result from Path messages and travel
upstream towards senders. PathErr messages are routed
hop-by-hop using the path state; at each hop, the IP
destination address is the unicast address of a previous
hop. PathErr messages do not modify the state of any node
through which they pass; instead, they are only reported
to the sender application.
o ResvErr messages result from Resv messages and travel PathErr (path error) messages report errors in processing Path
downstream towards the appropriate receivers. They are messages. They are travel upstream towards senders and are
routed hop-by-hop using the reservation state; at each routed hop-by-hop using the path state. At each hop, the IP
hop, the IP destination address is the unicast address of destination address is the unicast address of a previous hop.
a next-hop node. PathErr messages do not modify the state of any node through
which they pass; they are only reported to the sender
application.
<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)
The ERROR_SPEC object specifies the error and includes the IP
address of the node that detected the error (Error Node
Address). One or more POLICY_DATA objects may be included
message to provide relevant information. The sender descriptor
is copied from the message in error. The object order
requirements are as given earlier for a Path message, but the
above order is recommended.
3.1.8 Resv Error Messages
ResvErr (reservation error) messages report errors in
processing Resv messages, or they may report the spontaneous
disruption of a reservation, e.g., by administrative
preemption.
ResvErr messages travel downstream towards the appropriate
receivers, routed hop-by-hop using the reservation state. At
each hop, the IP destination address is the unicast address of
a next-hop node.
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ] <ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ] <ERROR_SPEC> [ <SCOPE> ]
[ <POLICY_DATA> ...] [ <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 (e.g.,, when a
administrative failure is being reported). In a ResvErr policy control error is being reported). The RSVP_HOP object
message, the RSVP_HOP object contains the previous hop address, contains the previous hop address, and the STYLE object is
and the STYLE object is copied from the Resv message in error. copied from the Resv message in error. The use of the SCOPE
The use of the SCOPE object in a ResvErr message is defined object in a ResvErr message is defined below in Section 3.4.
below in Section 3.4. The object order requirements are as given for Resv messages,
but the above order is recommended.
The following style-dependent rules define the composition of a The following style-dependent rules define the composition of a
valid error flow descriptor; the object order requirements are valid error flow descriptor; the object order requirements are
as given earlier for a Resv message. as given earlier for flow descriptor.
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 Each flow descriptor in a FF-style Resv message must be
skipping to change at page 41, line 4 skipping to change at page 45, line 26
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 An SE-style ResvErr message may list the subset of the
filter specs in the corresponding Resv message to which filter specs in the corresponding Resv message to which
the error applies. 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 ResvErr message to the next hop from which the sends a ResvErr message to the next hop node from which
erroneous reservation came. the erroneous reservation came.
This message must contain the information required to This ResvErr message must contain the information required
define the error and to route the error message in later to define the error and to route the error message in
hops. It therefore includes an ERROR_SPEC object, a copy later hops. It therefore includes an ERROR_SPEC object, a
of the STYLE object, and the appropriate error flow copy 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 must be left in place, while attempting to increase an existing reservation, then
and the InPlace flag bit must be on in the ERROR_SPEC of the existing reservation must be left in place and the
the ResvErr message. InPlace flag bit must be on in the ERROR_SPEC of 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.4. There is also a rule restricting the forwarding of a 3.4. There is also a rule restricting the forwarding of a
Resv message after an Admission Control failure; see Resv message after an Admission Control failure; see
Section 3.5. Section 3.5.
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(s) 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 3.1.9 Confirmation Messages
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
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.
skipping to change at page 42, line 20 skipping to change at page 46, line 39
<SESSION> <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 The object order requirements are the same as those given
earlier for a Resv message. earlier for a Resv message, but the above order is recommended.
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.
skipping to change at page 43, line 18 skipping to change at page 47, line 39
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 reservation state for the same DestAddress and Path state and reservation state for the same DestAddress and
ProtocolId must each 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 Ports" 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 "Bad
"Conflicting Src Port" error. Src Ports" error.
3. Source Ports must be consistent. 3. Source Ports must be consistent.
A sender host must not send path state both with and without A sender host must not send path state both with and without
a zero SrcPort. Violation of this condition is an "Ambiguous a zero SrcPort. Violation of this condition is a
Path" error. "Conflicting Sender Port" error.
Note that RSVP has no "wildcard" ports, i.e., a zero port cannot
match a non-zero port.
3.3 Sending RSVP Messages 3.3 Sending RSVP Messages
RSVP messages are sent hop-by-hop between RSVP-capable routers as RSVP messages are sent hop-by-hop between RSVP-capable routers as
"raw" IP datagrams with protocol number 46. Raw IP datagrams are "raw" IP datagrams with protocol number 46. Raw IP datagrams are
also intended to be used between an end system and the first/last also intended to be used between an end system and the first/last
hop router, although it is also possible to encapsulate RSVP hop router, although it is also possible to encapsulate RSVP
messages as UDP datagrams for end-system communication, as messages as UDP datagrams for end-system communication, as
described in Appendix C. UDP encapsulation is needed for systems described in Appendix C. UDP encapsulation is needed for systems
that cannot 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 [Katz97] 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 state modification immediately. However, node must forward the state modification immediately. However,
this must not trigger sending a message out the interface through this must not trigger sending a message out the interface through
which M arrived (which could happen if the implementation simply which 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.
skipping to change at page 44, line 28 skipping to change at page 49, line 4
Future versions of the protocol will provide solutions for these Future versions of the protocol will provide solutions for these
problems if they prove burdensome. The most likely direction will problems if they prove burdensome. The most likely direction will
be to perform "semantic fragmentation", i.e., break the path or be to perform "semantic fragmentation", i.e., break the path or
reservation state being transmitted into multiple self-contained reservation state being transmitted into multiple self-contained
messages, each of an acceptable size. 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 queuing 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.7). can be used for the timeout factor K (see section 3.7).
Some multicast routing protocols provide for "multicast tunnels", Some multicast routing protocols provide for "multicast tunnels",
which do IP encapsulation of multicast packets for transmission which do IP encapsulation of multicast packets for transmission
through routers that do not have multicast capability. A through routers that do not have multicast capability. A
multicast tunnel looks like a logical outgoing interface that is multicast tunnel looks like a logical outgoing interface that is
mapped into some physical interface. A multicast routing protocol mapped into some physical interface. A multicast routing protocol
skipping to change at page 48, line 12 skipping to change at page 52, line 48
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-style 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.8. 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.5 Blockade State 3.5 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
skipping to change at page 49, line 49 skipping to change at page 54, line 38
particular was made because it is simple to define and particular was made because it is simple to define and
implement, and no reason is known for using a different implement, and no reason is known for using a different
definition of "minimum" here). definition of "minimum" here).
This refresh merging algorithm is applied separately to each flow This refresh merging algorithm is applied separately to each flow
(each sender or PHOP) contributing to a shared reservation (WF or (each sender or PHOP) contributing to a shared reservation (WF or
SE style). SE style).
Figure 12 shows an example of the the application of blockade Figure 12 shows an example of the the application of blockade
state for a shared reservation (WF style). There are two previous state for a shared reservation (WF style). There are two previous
hops labelled (a) and (b), and two next hops labelled (c) and (d). hops labeled (a) and (b), and two next hops labeled (c) and (d).
The larger reservation 4B arrived from (c) first, but it failed The larger reservation 4B arrived from (c) first, but it failed
somewhere upstream via PHOP (a), but not via PHOP (b). The somewhere upstream via PHOP (a), but not via PHOP (b). The
figures show the final "steady state" after the smaller figures show the final "steady state" after the smaller
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
skipping to change at page 54, line 50 skipping to change at page 59, line 40
interface Iapp that differs from Isp, the shortest-path interface Iapp that differs from Isp, the shortest-path
interface to the sender. Then there are two possible ways interface to the sender. Then there are two possible ways
for multicast routing to deliver data packets to the for multicast routing to deliver data packets to the
application. The RSVP process must determine which case application. The RSVP process must determine which case
holds by examining the path state, to decide which incoming holds by examining the path state, to decide which incoming
interface to use for sending Resv messages. interface to use for sending Resv messages.
1. The multicast routing protocol may create a separate 1. The multicast routing protocol may create a separate
branch of the multicast distribution `tree' to deliver branch of the multicast distribution `tree' to deliver
to Iapp. In this case, there will be path state for to Iapp. In this case, there will be path state for
both Isp and Iapp. The path state on Iapp should only both interfaces Isp and Iapp. The path state on Iapp
match a reservation from the local application; it must should only match a reservation from the local
be marked "Local_only" by the RSVP process. If application; it must be marked "Local_only" by the RSVP
"Local_only" path state for Iapp exists, the Resv process. If "Local_only" path state for Iapp exists,
message should be sent out Iapp. the Resv message should be sent out Iapp.
Note that it is possible for the path state blocks for Note that it is possible for the path state blocks for
Isp and Iapp to have the same next hop, if there is an Isp and Iapp to have the same next hop, if there is an
intervening non-RSVP cloud. intervening non-RSVP cloud.
2. The multicast routing protocol may forward data within 2. The multicast routing protocol may forward data within
the router from Isp to Iapp. In this case, Iapp will the router from Isp to Iapp. In this case, Iapp will
appear in the list of outgoing interfaces of the path appear in the list of outgoing interfaces of the path
state for Isp, and the Resv message should be sent out state for Isp, and the Resv message should be sent out
Isp. Isp.
3. When Path and PathTear messages are forwarded, path
state marked "Local_Only" must be ignored.
3.10 Future Compatibility 3.10 Future Compatibility
We may expect that in the future new object C-Types will be We may expect that in the future new object C-Types will be
defined for existing object classes, and perhaps new object defined for existing object classes, and perhaps new object
classes will be defined. It will be desirable to employ such new classes will be defined. It will be desirable to employ such new
objects within the Internet using older implementations that do objects within the Internet using older implementations that do
not recognize them. Unfortunately, this is only possible to a not recognize them. Unfortunately, this is only possible to a
limited degree with reasonable complexity. The rules are as limited degree with reasonable complexity. The rules are as
follows (`b' represents a bit). follows (`b' represents a bit).
skipping to change at page 55, line 48 skipping to change at page 60, line 42
o Class-Num = 10bbbbbb o Class-Num = 10bbbbbb
The node should ignore the object, neither forwarding it The node should ignore the object, neither forwarding it
nor sending an error message. nor sending an error message.
o Class-Num = 11bbbbbb o Class-Num = 11bbbbbb
The node should ignore the object but forward it, The node should ignore the object but forward it,
unexamined and unmodified, in all messages resulting unexamined and unmodified, in all messages resulting
from the state contained in this message. from this message.
For example, suppose that a Resv message that is received The following more detailed rules hold for unknown-class
contains an object of unknown class number 11bbbbbb. Such an objects with a Class-Num of the form 11bbbbbb:
object should be saved in the reservation state without
further examination; however, only the latest object with a
given (unknown class, C-Type) pair should be saved. When a
Resv message is forwarded, it should include copies of such
saved unknown-class objects from all reservations that are
merged to form the new Resv message.
Note that objects with unknown class cannot be merged; 1. Such unknown-class objects received in PathTear,
however, unmerged objects may be forwarded until they reach a ResvTear, PathErr, or ResvErr messages should be
node that knows how to merge them. Forwarding objects with forwarded immediately in the same messages.
unknown class enables incremental deployment of new objects;
however, the scaling limitations of doing so must be
carefully examined before a new object class is deployed with
both high bits on.
These rules should be considered when any new Class-Num is 2. Such unknown-class objects received in Path or Resv
defined. messages should be saved with the corresponding state
and forwarded in any refresh message resulting from that
state.
3. When a Resv refresh is generated by merging multiple
reservation requests, the refresh message should include
the union of unknown-class objects from the component
requests. Only one copy of each unique unknown-class
object should be included in this union.
4. The original order of such unknown-class objects need
not be retained; however, the message that is forwarded
must obey the general order requirements for its message
type.
Although objects with unknown class cannot be merged, these
rules will forward such objects until they reach a node that
knows how to merge them. Forwarding objects with unknown
class enables incremental deployment of new objects; however,
the scaling limitations of doing so must be carefully
examined before a new object class is deployed with both high
bits on.
2. Unknown C-Type for Known Class 2. Unknown C-Type for Known Class
One might expect the known Class-Num to provide information One might expect the known Class-Num to provide information
that could allow intelligent handling of such an object. that could allow intelligent handling of such an object.
However, in practice such class-dependent handling is However, in practice such class-dependent handling is
complex, and in many cases it is not useful. complex, and in many cases it is not useful.
Generally, the appearance of an object with unknown C-Type Generally, the appearance of an object with unknown C-Type
should result in rejection of the entire message and should result in rejection of the entire message and
skipping to change at page 62, line 29 skipping to change at page 67, line 29
- NotGuilty - NotGuilty
This flag may be on for an Admission Control This flag may be on for an Admission Control
failure, to indicate that the flowspec requested failure, to indicate that the flowspec requested
by this receiver was strictly less than the by this receiver was strictly less than the
flowspec that got the error. This flag is set flowspec that got the error. This flag is set
at the receiver API. at the receiver API.
Filter_spec_list and Flowspec will contain the Filter_spec_list and Flowspec will contain the
corresponding objects from the error flow descriptor corresponding objects from the error flow descriptor
(see Section 3.1.6). List_count will specify the (see Section 3.1.8). List_count will specify the
number of FILTER_SPECS in Filter_spec_list. The number of FILTER_SPECS in Filter_spec_list. The
Policy_data_list parameter will contain any Policy_data_list parameter will contain any
POLICY_DATA objects from the ResvErr message. POLICY_DATA objects from the ResvErr message.
5. Info_type = RESV_CONFIRM 5. Info_type = RESV_CONFIRM
A Confirmation event indicates that a ResvConf A Confirmation event indicates that a ResvConf
message was received. message was received.
Upcall: <Upcall_Proc>( ) -> session-id, Upcall: <Upcall_Proc>( ) -> session-id,
skipping to change at page 63, line 14 skipping to change at page 68, line 14
Although RSVP messages indicating path or resv events may Although RSVP messages indicating path or resv events may
be received periodically, the API should make the be received periodically, the API should make the
corresponding asynchronous upcall to the application only corresponding asynchronous upcall to the application only
on the first occurrence or when the information to be on the first occurrence or when the information to be
reported changes. All error and confirmation events reported changes. All error and confirmation events
should be reported to the application. should be reported to the application.
3.11.2 RSVP/Traffic Control Interface 3.11.2 RSVP/Traffic Control Interface
In an RSVP-capable node, enhanced QoS is achieved by a group of It is difficult to present a generic interface to traffic
inter-related traffic control functions: a packet classifier, control, because the details of establishing a reservation
an admission control module, and a packet scheduler. This depend strongly upon the particular link layer technology in
section describes a generic RSVP interface to traffic control. use on an interface.
Merging of RSVP reservations is required because of multicast
data delivery, which replicates data packets for delivery to
different next-hop nodes. At each such replication point, RSVP
must merge reservation requests from the corresponding next
hops by computing the "maximum" of their flowspecs. At a given
router or host, one or more of the following three replication
locations may be in use.
1. IP layer
IP multicast forwarding performs replication in the IP
layer. In this case, RSVP must merge the reservations
that are in place on the corresponding outgoing interfaces
in order to forward a request upstream.
2. "The network"
Replication might take place downstream from the node,
e.g., in a broadcast LAN, in link-layer switches, or in a
mesh of non-RSVP-capable routers (see Section 2.8). In
these cases, RSVP must merge the reservations from the
different next hops in order to make the reservation on
the single outgoing interface. It must also merge
reservations requests from all outgoing interfaces in
order to forward a request upstream.
3. Link-layer driver
For a multi-access technology, replication may occur in
the link layer driver or interface card. For example,
this case might arise when there is a separate ATM point-
to-point VC towards each next hop. RSVP may need to apply
traffic control independently to each VC, without merging
requests from different next hops.
In general, these complexities do not impact the protocol
processing that is required by RSVP, except to determine
exactly what reservation requests need to be merged. It may be
desirable to organize an RSVP implementation into two parts: a
core that performs link-layer-independent processing, and a
link-layer-dependent adaptation layer. However, we present
here a generic interface that assumes that replication can
occur only at the IP layer or in "the network".
o Make a Reservation o Make a Reservation
Call: TC_AddFlowspec( Interface, TC_Flowspec, Call: TC_AddFlowspec( Interface, TC_Flowspec,
TC_Tspec, Police_Flags ) TC_Tspec, TC_Adspec, Police_Flags )
-> RHandle [, Fwd_Flowspec] -> 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). The TC_Tspec parameter Compare_Flowspecs call below). The TC_Tspec parameter
defines the effective sender Tspec Path_Te (see Section defines the effective sender Tspec Path_Te (see Section
2.2). The Police_Flags parameter carries the three flags 2.2). The TC_Adspec parameter defines the effective
E_Police_Flag, M_Police_Flag, and B_Police_Flag; see Adspec. The Police_Flags parameter carries the three
flags E_Police_Flag, M_Police_Flag, and B_Police_Flag; see
Section 3.8. Section 3.8.
If this call is successful, it establishes a new If this call is successful, it establishes a new
reservation channel corresponding to RHandle; otherwise, reservation channel corresponding to RHandle; otherwise,
it returns an error code. The opaque number RHandle is it returns an error code. The opaque number RHandle is
used by the caller for subsequent references to this used by the caller for subsequent references to this
reservation. If the traffic control service updates the reservation. If the traffic control service updates the
flowspec, the call will also return the updated object as flowspec, the call will also return the updated object as
Fwd_Flowspec. Fwd_Flowspec.
o Modify Reservation o Modify Reservation
Call: TC_ModFlowspec( Interface, RHandle, TC_Flowspec, Call: TC_ModFlowspec( Interface, RHandle, TC_Flowspec,
Sender_Tspec, Police_flags ) TC_Tspec, TC_Adspec, Police_flags )
[ -> Fwd_Flowspec ] [ -> Fwd_Flowspec ]
This call is used to modify an existing reservation. This call is used to modify an existing reservation.
TC_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. If the other parameters are defined as in TC_AddFlowspec. If the
service updates the flowspec, the call will also return service updates the flowspec, the call will also return
the updated object as Fwd_Flowspec. the updated object as Fwd_Flowspec.
o Delete Flowspec o Delete Flowspec
Call: TC_DelFlowspec( Interface, RHandle ) Call: TC_DelFlowspec( Interface, RHandle )
skipping to change at page 64, line 47 skipping to change at page 70, line 46
o OPWA Update o OPWA Update
Call: TC_Advertise( Interface, Adspec, Call: TC_Advertise( Interface, Adspec,
Non_RSVP_Hop_flag ) -> New_Adspec Non_RSVP_Hop_flag ) -> New_Adspec
This call is used for OPWA to compute the outgoing This call is used for OPWA to compute the outgoing
advertisement New_Adspec for a specified interface. The advertisement New_Adspec for a specified interface. The
flag bit Non_RSVP_Hop_flag should be set whenever the RSVP flag bit Non_RSVP_Hop_flag should be set whenever the RSVP
process detects that the previous RSVP hop included one or daemon detects that the previous RSVP hop included one or
more non-RSVP-capable routers. TC_Advertise will insert more non-RSVP-capable routers. TC_Advertise will insert
this information into New_Adspec to indicate that a non- this information into New_Adspec to indicate that a non-
integrated-service hop was found; see Section 3.8. integrated-service hop was found; see Section 3.8.
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 control modules may preempt one or control and/or policy control modules may preempt one or
skipping to change at page 65, line 25 skipping to change at page 71, line 24
reservation, passing the RHandle of the reservation and a reservation, passing the RHandle of the reservation and a
sub-code indicating the reason. sub-code indicating the reason.
3.11.3 RSVP/Policy Control Interface 3.11.3 RSVP/Policy Control Interface
This interface will be specified in a future document. This interface will be specified in a future document.
3.11.4 RSVP/Routing Interface 3.11.4 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. routing mechanisms of the node.
o Promiscuous Receive Mode for RSVP Messages
Packets received for IP protocol 46 but not addressed to
the node must be diverted to the RSVP program for
processing, without being forwarded. On a router, the
identity of the interface, real or virtual, on which it is
received as well as the IP source address and IP TTL with
which it arrived must also be available to the RSVP
process.
The RSVP messages to be diverted will carry the Router
Alert IP option, which can be used to pick them out of a
high-speed forwarding path. Alternatively, the node can
intercept all protocol 46 packets.
o Route Query o Route Query
To forward Path and PathTear messages, an RSVP process To forward Path and PathTear messages, an RSVP process
must be able to query the routing process(s) for routes. must be able to query the routing process(s) for routes.
Ucast_Route_Query( [ SrcAddress, ] DestAddress, Ucast_Route_Query( [ SrcAddress, ] DestAddress,
Notify_flag ) -> OutInterface Notify_flag ) -> OutInterface
skipping to change at page 66, line 47 skipping to change at page 72, line 32
to the RSVP process that a specified route has changed. to the RSVP process that a specified route has changed.
Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress, Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
OutInterface OutInterface
Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress, Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
[ IncInterface, ] OutInterface_list [ IncInterface, ] OutInterface_list
o Outgoing Link Specification
RSVP must be able to force a (multicast) datagram to be
sent on a specific outgoing virtual link, bypassing the
normal routing mechanism. A virtual link may be a real
outgoing link or a multicast tunnel. Outgoing link
specification is necessary to send different versions of
an outgoing Path message on different interfaces. It is
also necessary in some cases to avoid routing loops.
o Source Address Specification
RSVP must be able to specify the IP source address to be
used when sending Path messages.
o Interface List Discovery o Interface List Discovery
RSVP must be able to learn what real and virtual RSVP must be able to learn what real and virtual
interfaces are active, with their IP addresses. interfaces are active, with their IP addresses.
It should be possible to logically disable an interface It should be possible to logically disable an interface
for RSVP. When an interface is disabled for RSVP, a Path for RSVP. When an interface is disabled for RSVP, a Path
message should never be forwarded out that interface, and message should never be forwarded out that interface, and
if an RSVP message is received on that interface, the if an RSVP message is received on that interface, the
message should be silently discarded (perhaps with local message should be silently discarded (perhaps with local
logging). logging).
3.11.5 Service-Dependent Manipulations 3.11.5 RSVP/Packet I/O Interface
An RSVP implementation needs the following support from the
packet I/O and forwarding mechanisms of the node.
o Promiscuous Receive Mode for RSVP Messages
Packets received for IP protocol 46 but not addressed to
the node must be diverted to the RSVP program for
processing, without being forwarded. The RSVP messages to
be diverted in this manner will include Path, PathTear,
and ResvConf messages. These message types carry the
Router Alert IP option, which can be used to pick them out
of a high-speed forwarding path. Alternatively, the node
can intercept all protocol 46 packets.
On a router or multi-homed host, the identity of the
interface (real or virtual) on which a diverted message is
received, as well as the IP source address and IP TTL with
which it arrived, must also be available to the RSVP
process.
o Outgoing Link Specification
RSVP must be able to force a (multicast) datagram to be
sent on a specific outgoing real or virtual link,
bypassing the normal routing mechanism. A virtual link
might be a multicast tunnel, for example. Outgoing link
specification is necessary to send different versions of
an outgoing Path message on different interfaces, and to
avoid routing loops in some cases.
o Source Address and TTL Specification
RSVP must be able to specify the IP source address and IP
TTL to be used when sending Path messages.
o Router Alert
RSVP must be able to cause Path, PathTear, and ResvConf
message to be sent with the Router Alert IP option.
3.11.6 Service-Dependent Manipulations
Flowspecs, Tspecs, and Adspecs are opaque objects to RSVP; Flowspecs, Tspecs, and Adspecs are opaque objects to RSVP;
their contents are defined in service specification documents. their contents are defined in service specification documents.
In order to manipulate these objects, RSVP process must have In order to manipulate these objects, RSVP process must have
available to it the following service-dependent routines. available to it the following service-dependent routines.
o Compare Flowspecs o Compare Flowspecs
Compare_Flowspecs( Flowspec_1, Flowspec_2 ) -> Compare_Flowspecs( Flowspec_1, Flowspec_2 ) ->
skipping to change at page 71, line 28 skipping to change at page 77, line 28
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IPv6 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 carries the IP address of the interface through which the
the last RSVP-knowledgeable hop forwarded this message. The Logical last RSVP-knowledgeable hop forwarded this message. The Logical
Interface Handle is a 32-bit number which may be used to distinguish Interface Handle (LIH) is used to distinguish logical outgoing
logical outgoing interfaces as described in Section 3.3; it should be interfaces, as discussed in Sections 3.3 and 3.9. A node receiving
identically zero if there is no logical interface handle. an LIH in a Path message saves its value and returns it in the HOP
objects of subsequent Resv messages sent to the node that originated
the LIH. The LIH should be identically zero if there is no logical
interface handle.
A.3 INTEGRITY Class A.3 INTEGRITY Class
INTEGRITY class = 4. INTEGRITY class = 4.
See [Baker96]. See [Baker96].
A.4 TIME_VALUES Class A.4 TIME_VALUES Class
TIME_VALUES class = 5. TIME_VALUES class = 5.
skipping to change at page 85, line 50 skipping to change at page 91, line 50
Reservation style conflicts with style(s) of existing reservation Reservation style conflicts with style(s) of existing reservation
state. The Error Value field contains the low-order 16 bits of the state. The Error Value field contains the low-order 16 bits of the
Option Vector of the existing style with which the conflict Option Vector of the existing style with which the conflict
occurred. This Resv message cannot be forwarded. occurred. This Resv message cannot be forwarded.
o Error Code = 06: Unknown reservation style o Error Code = 06: Unknown reservation style
Reservation style is unknown. This Resv message cannot be Reservation style is unknown. This Resv message cannot be
forwarded. forwarded.
o Error Code = 07: Conflicting dest port o Error Code = 07: Conflicting dest ports
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 may with both zero and non-zero dest port fields. This Error Code may
appear in a PathErr or ResvErr message. appear in a PathErr or ResvErr message.
o Error Code = 08: Ambiguous path o Error Code = 08: Conflicting sender ports
Sender port appears both zero and non-zero in same session in a
Path message. This Error Code may appear only in a PathErr
message.
o Error Code = 09: Ambiguous Filter Spec
Message contains a filter spec that matches more than one sender, Sender port is both zero and non-zero in Path messages for the same
but an explicit style that requires an exact match. session. This Error Code may appear only in a PathErr message.
o Error Code = 10, 11: (reserved) o Error Code = 09, 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 87, line 4 skipping to change at page 92, line 44
message. message.
o Error Code = 14: Unknown object C-Type o Error Code = 14: Unknown object C-Type
Error Value contains 16-bit value composed of (Class-Num, C-Type) Error Value contains 16-bit value composed of (Class-Num, C-Type)
of object. of object.
o Error Code = 15-19: (reserved) o Error Code = 15-19: (reserved)
o Error Code = 20: Reserved for API o Error Code = 20: Reserved for API
Error Value field contains an API error code, for an API error that Error Value field contains an API error code, for an API error that
was detected asynchronously and must be reported via an upcall. was detected asynchronously and must be reported via an upcall.
o Error Code = 21: Traffic Control Error o Error Code = 21: Traffic Control Error
Reservation request was rejected by Traffic Control due to the Traffic Control call failed due to the format or contents of the
format or contents of the request. This Resv message cannot be parameters to the request. The Resv or Path message that caused
forwarded, and continued attempts would be futile. the call cannot be forwarded, and repeating the call would be
futile.
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:
ss00 cccc cccc cccc ss00 cccc cccc cccc
Here the high-order bits ss are as defined under Error Code 01. Here the high-order bits ss are as defined under Error Code 01.
The following globally-defined sub-codes may appear in the low The following globally-defined sub-codes may appear in the low
order 12 bits (cccc cccc cccc) when ss = 00: order 12 bits (cccc cccc cccc) when ss = 00:
skipping to change at page 87, line 39 skipping to change at page 93, line 34
an acceptable replacement. an acceptable replacement.
- Sub-code = 03: Bad Flowspec value - Sub-code = 03: Bad Flowspec value
Malformed or unreasonable request. Malformed or unreasonable request.
- Sub-code = 04: Bad Tspec value - Sub-code = 04: Bad Tspec value
Malformed or unreasonable request. Malformed or unreasonable request.
- Sub-code = 05: Bad Adspec value
Malformed or unreasonable request.
o Error Code = 22: Traffic Control System error o Error Code = 22: Traffic Control System error
A system error was detected and reported by the traffic control A system error was detected and reported by the traffic control
modules. The Error Value will contain a system-specific value modules. The Error Value will contain a system-specific value
giving more information about the error. RSVP is not expected to giving more information about the error. RSVP is not expected to
be able to interpret this value. be able to interpret this value.
o Error Code = 23: RSVP System error o Error Code = 23: RSVP System error
The Error Value field will provide implementation-dependent The Error Value field will provide implementation-dependent
skipping to change at page 88, line 37 skipping to change at page 94, line 37
o Bad RSVP checksum o Bad RSVP checksum
o INTEGRITY failure o INTEGRITY failure
o Illegal RSVP message Type o Illegal RSVP message Type
o Illegal object length: not a multiple of 4, or less than 4. o Illegal object length: not a multiple of 4, or less than 4.
o Next hop/Previous hop address in HOP object is illegal. o Next hop/Previous hop address in HOP object is illegal.
o Conflicting source port: Source port is non-zero in a filter spec o Bad source port: Source port is non-zero in a filter spec or sender
or sender template for a session with destination port zero. template for a session with destination port zero.
o Required object class (specify) missing o Required object class (specify) missing
o Illegal object class (specify) in this message type. o Illegal object class (specify) in this message type.
o Violation of required object order o Violation of required object order
o Flow descriptor count wrong for style o Flow descriptor count wrong for style or message type
o Logical Interface Handle invalid o Logical Interface Handle invalid
o Unknown object Class-Num. o Unknown object Class-Num.
o Destination address of ResvConf message does not match Receiver o Destination address of ResvConf message does not match Receiver
Address in the RESV_CONFIRM object it contains. Address in the RESV_CONFIRM object it contains.
APPENDIX C. UDP Encapsulation APPENDIX C. UDP Encapsulation
skipping to change at page 91, line 14 skipping to change at page 97, line 14
group that is limited to the local connected network. group that is limited to the local connected network.
o Pu and Pu' are two well-known UDP ports for UDP encapsulation of o Pu and Pu' are two well-known UDP ports for UDP encapsulation of
RSVP, with values 1698 and 1699. RSVP, with values 1698 and 1699.
o Ra is the IP address of the router interface `a'. o Ra is the IP address of the router interface `a'.
o Router interface `a' is on the local network connected to Hu and o Router interface `a' is on the local network connected to Hu and
Hr. Hr.
o [RA] indicates that the Router Alert option is sent. o
The following notes apply to these figures: The following notes apply to these figures:
[Note 1] Hu sends a unicast Path message either to the destination [Note 1] Hu sends a unicast Path message either to the destination
address D, if D is local, or to the address Ra of the first-hop address D, if D is local, or to the address Ra of the first-hop
router. Ra is presumably known to the host. router. Ra is presumably known to the host.
[Note 2] Here D is the address of the local interface through which [Note 2] Here D is the address of the local interface through which
the message arrived. the message arrived.
skipping to change at page 91, line 36 skipping to change at page 97, line 36
UNICAST DESTINATION D: UNICAST DESTINATION D:
RSVP RSVP RSVP RSVP
Node Send Receive Node Send Receive
___ _____________ _______________ ___ _____________ _______________
Hu UDP(D/Ra,Pu) UDP(D,Pu) Hu UDP(D/Ra,Pu) UDP(D,Pu)
[Note 1] and UDP(D,Pu') [Note 1] and UDP(D,Pu')
[Note 2] [Note 2]
Hr Raw(D)[RA] Raw() Hr Raw(D) Raw()
and if (UDP) and UDP(D, Pu) and if (UDP) and UDP(D, Pu)
then UDP(D,Pu') [Note 2] then UDP(D,Pu') [Note 2]
(Ignore Pu') (Ignore Pu')
R (Interface a): R (Interface a):
Raw(D)[RA] Raw() Raw(D) Raw()
and if (UDP) and UDP(Ra, Pu) and if (UDP) and UDP(Ra, Pu)
then UDP(D,Pu') (Ignore Pu') then UDP(D,Pu') (Ignore Pu')
Figure 13: UDP Encapsulation Rules for Unicast Path and Resv Messages Figure 13: UDP Encapsulation Rules for Unicast Path and Resv Messages
MULTICAST DESTINATION D: MULTICAST DESTINATION D:
RSVP RSVP RSVP RSVP
Node Send Receive Node Send Receive
___ _____________ _________________ ___ _____________ _________________
Hu UDP(G*,Pu) UDP(D,Pu') Hu UDP(G*,Pu) UDP(D,Pu')
[Note 3] [Note 3]
and UDP(G*,Pu) and UDP(G*,Pu)
Hr Raw(D,Tr)[RA] Raw() Hr Raw(D,Tr) Raw()
and if (UDP) and UDP(G*,Pu) and if (UDP) and UDP(G*,Pu)
then UDP(D,Pu') (Ignore Pu') then UDP(D,Pu') (Ignore Pu')
R (Interface a): R (Interface a):
Raw(D,Tr)[RA] Raw() Raw(D,Tr) Raw()
and if (UDP) and UDP(G*,Pu) and if (UDP) and UDP(G*,Pu)
then UDP(D,Pu') (Ignore Pu') then UDP(D,Pu') (Ignore Pu')
Figure 14: UDP Encapsulation Rules for Multicast Path Messages Figure 14: UDP Encapsulation Rules for Multicast Path Messages
A router may determine if its interface X needs UDP encapsulation by A router may determine if its interface X needs UDP encapsulation by
listening for UDP-encapsulated Path messages that were sent to either G* listening for UDP-encapsulated Path messages that were sent to either G*
(multicast D) or to the address of interface X (unicast D). There is (multicast D) or to the address of interface X (unicast D). There is
one failure mode for this scheme: if no host on the connected network one failure mode for this scheme: if no host on the connected network
acts as an RSVP sender, there will be no Path messages to trigger UDP acts as an RSVP sender, there will be no Path messages to trigger UDP
skipping to change at page 96, line 6 skipping to change at page 102, line 6
o Flow descriptor o Flow descriptor
The combination of a flowspec and a filterspec. The combination of a flowspec and a filterspec.
o Flowspec o Flowspec
Defines the QoS to be provided for a flow. The flowspec is used to Defines the QoS to be provided for a flow. The flowspec is used to
set parameters in the packet scheduling function to provide the set parameters in the packet scheduling function to provide the
requested quality of service. A flowspec is carried in a FLOWSPEC requested quality of service. A flowspec is carried in a FLOWSPEC
object. The flowspec format is opaque to RSVP, and is defined by object. The flowspec format is opaque to RSVP and is defined by
the Integrated Services Working Group. the Integrated Services Working Group.
o Generalized destination port o Generalized destination port
The component of a session definition that provides further The component of a session definition that provides further
transport or application protocol layer demultiplexing beyond transport or application protocol layer demultiplexing beyond
DestAddress. See "session". DestAddress. See "session".
o Generalized source port o Generalized source port
skipping to change at page 96, line 46 skipping to change at page 102, line 46
o Killer reservation problem o Killer reservation problem
The killer reservation problem describes a case where a receiver The killer reservation problem describes a case where a receiver
attempting and failing to make a large QoS reservation prevents attempting and failing to make a large QoS reservation prevents
smaller QoS reservations from being established. See Sections 2.5 smaller QoS reservations from being established. See Sections 2.5
and 3.5 for more information. and 3.5 for more information.
o LIH o LIH
The LIH (Logical Interface Handle) is used to help deal with non- The LIH (Logical Interface Handle) is used to help deal with non-
RSVP clouds. See Section 2.8 for more information. RSVP clouds. See Section 2.9 for more information.
o Local repair o Local repair
Allows RSVP to rapidly adapt its reservations to changes in Allows RSVP to rapidly adapt its reservations to changes in
routing. See Section 3.6 for more information. routing. See Section 3.6 for more information.
o LPM o LPM
Local Policy Module. the function that exerts policy control. Local Policy Module. the function that exerts policy control.
skipping to change at page 97, line 46 skipping to change at page 103, line 46
messages. messages.
o Node o Node
A router or host system. A router or host system.
o Non-RSVP clouds o Non-RSVP clouds
Groups of hosts and routers that do not run RSVP. Dealing with Groups of hosts and routers that do not run RSVP. Dealing with
nodes that do not support RSVP is important for backwards nodes that do not support RSVP is important for backwards
compatibility. See section 2.8. compatibility. See section 2.9.
o Object o Object
An element of an RSVP control message; a type, length, value An element of an RSVP control message; a type, length, value
triplet. triplet.
o OPWA o OPWA
Abbreviation for "One Pass With Advertising". Describes a Abbreviation for "One Pass With Advertising". Describes a
reservation setup model in which (Path) messages sent downstream reservation setup model in which (Path) messages sent downstream
skipping to change at page 100, line 15 skipping to change at page 106, line 15
request has failed or an active reservation has been preempted. request has failed or an active reservation has been preempted.
o ResvTear o ResvTear
Reservation Teardown RSVP control message, deletes reservation Reservation Teardown RSVP control message, deletes reservation
state. state.
o Rspec o Rspec
The component of a flowspec that defines a desired QoS. The Rspec The component of a flowspec that defines a desired QoS. The Rspec
format is opaque to RSVP, and is defined by the Integrated Services format is opaque to RSVP and is defined by the Integrated Services
Working Group of the IETF. Working Group of the IETF.
o RSVP_HOP o RSVP_HOP
Object of an RSVP control message that carries the PHOP or NHOP Object of an RSVP control message that carries the PHOP or NHOP
address of the source of the message. address of the source of the message.
o Scope o Scope
The set of sender hosts to which a given reservation request is to The set of sender hosts to which a given reservation request is to
skipping to change at page 102, line 29 skipping to change at page 108, line 29
selection and shared attributes. selection and shared attributes.
o Wildcard sender selection o Wildcard sender selection
A (reservation) style attribute: traffic from any sender to a A (reservation) style attribute: traffic from any sender to a
specific session receives the same QoS. See also "explicit sender specific session receives the same QoS. See also "explicit sender
selection". selection".
References References
[Baker96] Baker, F., "RSVP Cryptographic Authentication", Work in [Baker96] Baker, F., "RSVP Cryptographic Authentication", Internet
Progress, February 1996. Draft <draft-ietf-rsvp-md5-02.txt>, June 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.
[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.
[IPSEC96] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC IPv4 [IPSEC96] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
Data Flows", Internet Draft, <draft-ietf-rsvp-ext-04.txt>, Flows", Internet Draft, <draft-ietf-rsvp-ext-07.txt>, Fore Systems
Integrated Services Working Group, June 1996. and BBN, March 1997.
[Katz95] Katz, D., "IP Router Alert Option", Work in Progress, November
1995.
[ISdata96] Wroclawski, J., "Data Element Naming and Encoding for [Katz97] Katz, D., "IP Router Alert Option", RFC 2113, cisco Systems,
Integrated Services Messages", <draft-ietf-intserv-data-encoding- February 1997.
02.txt>, Integrated Services Working Group, July 1996.
[ISrsvp96] Wroclawski, J., "The Use of RSVP with Integrated Services", [ISrsvp96] Wroclawski, J., "The Use of RSVP with Integrated Services",
<draft-ietf-intserv-rsvp-use.00.txt>, Integrated Services Working <draft-ietf-intserv-rsvp-use.01.txt>, MIT, October 1996.
Group, July 1996.
[ISTempl96] Shenker, S. and J. Wroclawski, "Network Element QoS Control [PolArch96] Herzog, S., "Policy Control for RSVP: Architectural
Service Specification Template", <draft-ietf-intserv-serv-template- Overview". <draft-ietf-rsvp-policy-arch-01.txt>, IBM, November
03.txt>, Integrated Services Working Group, July 1996. 1996.
[OPWA95] Shenker, S. and L. Breslau, "Two Issues in Reservation [OPWA95] Shenker, S. and L. Breslau, "Two Issues in Reservation
Establishment", Proc. ACM SIGCOMM '95, Cambridge, MA, August 1995. Establishment", Proc. ACM SIGCOMM '95, Cambridge, MA, August 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.
Security Considerations Security Considerations
See Section 2.7. See Section 2.8.
Authors' Addresses Authors' Addresses
Bob Braden Bob Braden
USC Information Sciences Institute USC Information Sciences Institute
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292 Marina del Rey, CA 90292
Phone: (310) 822-1511 Phone: (310) 822-1511
EMail: Braden@ISI.EDU EMail: Braden@ISI.EDU
skipping to change at page 104, line 4 skipping to change at page 109, line 35
Phone: (310) 822-1511 Phone: (310) 822-1511
EMail: Braden@ISI.EDU EMail: Braden@ISI.EDU
Lixia Zhang Lixia Zhang
Xerox Palo Alto Research Center Xerox Palo Alto Research Center
3333 Coyote Hill Road 3333 Coyote Hill Road
Palo Alto, CA 94304 Palo Alto, CA 94304
Phone: (415) 812-4415 Phone: (415) 812-4415
EMail: Lixia@PARC.XEROX.COM EMail: Lixia@PARC.XEROX.COM
Steve Berson Steve Berson
USC Information Sciences Institute USC Information Sciences Institute
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292 Marina del Rey, CA 90292
Phone: (310) 822-1511 Phone: (310) 822-1511
EMail: Berson@ISI.EDU EMail: Berson@ISI.EDU
Shai Herzog Shai Herzog
USC Information Sciences Institute IBM T. J. Watson Research Center
4676 Admiralty Way P.O Box 704
Marina del Rey, CA 90292 Yorktown Heights, NY 10598
Phone: (310) 822 1511 Phone: (914) 784-6059
EMail: Herzog@ISI.EDU EMail: Herzog@WATSON.IBM.COM
Sugih Jamin Sugih Jamin
Computer Science Department University of Michigan
University of Southern California CSE/EECS
Los Angeles, CA 90089-0871 1301 Beal Ave.
Ann Arbor, MI 48109-2122
Phone: (213) 740-6578 Phone: (313) 763-1583
EMail: jamin@catarina.usc.edu
EMail: jamin@EECS.UMICH.EDU
 End of changes. 140 change blocks. 
531 lines changed or deleted 770 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/