draft-ietf-rsvp-spec-12.txt   draft-ietf-rsvp-spec-13.txt 
Internet Draft R. Braden, Ed. Internet Draft R. Braden, Ed.
Expiration: November 1996 ISI Expiration: February 1997 ISI
File: draft-ietf-rsvp-spec-12.txt L. Zhang File: draft-ietf-rsvp-spec-13.txt L. Zhang
PARC PARC
S. Berson S. Berson
ISI ISI
S. Herzog S. Herzog
ISI ISI
S. Jamin S. Jamin
USC USC
Resource ReSerVation Protocol (RSVP) -- Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification Version 1 Functional Specification
May 6, 1996 August 12, 1996
Status of Memo Status of Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 36 skipping to change at page 2, line 36
3.3 Avoiding RSVP Message Loops .....................................45 3.3 Avoiding RSVP Message Loops .....................................45
3.4 Blockade State ..................................................48 3.4 Blockade State ..................................................48
3.5 Local Repair ....................................................50 3.5 Local Repair ....................................................50
3.6 Time Parameters .................................................51 3.6 Time Parameters .................................................51
3.7 Traffic Policing and Non-Integrated Service Hops ................52 3.7 Traffic Policing and Non-Integrated Service Hops ................52
3.8 Multihomed Hosts ................................................53 3.8 Multihomed Hosts ................................................53
3.9 Future Compatibility ............................................55 3.9 Future Compatibility ............................................55
3.10 RSVP Interfaces ................................................57 3.10 RSVP Interfaces ................................................57
4. Message Processing Rules ............................................69 4. Message Processing Rules ............................................69
5. Acknowledgments .....................................................91 5. Acknowledgments .....................................................91
APPENDIX A. Object Definitions .........................................92 APPENDIX A. Object Definitions .........................................93
APPENDIX B. Error Codes and Values .....................................107 APPENDIX B. Error Codes and Values .....................................108
APPENDIX C. UDP Encapsulation ..........................................113 APPENDIX C. UDP Encapsulation ..........................................114
1. Introduction 1. Introduction
This document defines RSVP, a resource reservation setup protocol This document defines RSVP, a resource reservation setup protocol
designed for an integrated services Internet [RSVP93,ISInt93]. designed for an integrated services Internet [RSVP93,ISInt93].
The RSVP protocol is used by a host, on behalf of an application data The RSVP protocol is used by a host, on behalf of an application data
stream, to request a specific quality of service (QoS) from the stream, to request a specific quality of service (QoS) from the
network. The RSVP protocol is also used by routers to deliver QoS network. The RSVP protocol is also used by routers to deliver QoS
requests to all nodes along the path(s) of the data stream and to control requests to all nodes along the path(s) of the data stream
establish and maintain state to provide the requested service. RSVP and to establish and maintain state to provide the requested service.
requests will generally, although not necessarily, result in RSVP requests will generally, although not necessarily, result in
resources being reserved along the data path. resources being reserved in each node along the data path.
RSVP requests resources for simplex data streams, i.e., it requests RSVP requests resources for simplex data streams, i.e., it requests
resources in only one direction. Therefore, RSVP treats a sender as resources in only one direction. Therefore, RSVP treats a sender as
logically distinct from a receiver, although the same application logically distinct from a receiver, although the same application
process may act as both a sender and a receiver at the same time. process may act as both a sender and a receiver at the same time.
RSVP operates on top of IP (either IPv4 or IPv6), occupying the place RSVP operates on top of IP (either IPv4 or IPv6), occupying the place
of a transport protocol in the protocol stack. However, RSVP does of a transport protocol in the protocol stack. However, RSVP does
not transport application data but is rather an Internet control not transport application data but is rather an Internet control
protocol, like ICMP, IGMP, or routing protocols. Like the protocol, like ICMP, IGMP, or routing protocols. Like the
implementations of routing and management protocols, an implementations of routing and management protocols, an
skipping to change at page 4, line 5 skipping to change at page 3, line 40
RSVP is not itself a routing protocol; RSVP is designed to operate RSVP is not itself a routing protocol; RSVP is designed to operate
with current and future unicast and multicast routing protocols. An with current and future unicast and multicast routing protocols. An
RSVP daemon consults the local routing database(s) to obtain routes. RSVP daemon consults the local routing database(s) to obtain routes.
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
membership, and heterogeneous receiver requirements, RSVP makes
receivers responsible for requesting QoS control [RSVP93]. A QoS
control request from a receiver host application is passed to the
local RSVP implementation, shown as a daemon process in Figure 1.
The RSVP protocol then carries the request to all the nodes (routers
and hosts) along the reverse data path(s) to the data source(s).
HOST ROUTER HOST ROUTER
HOST ROUTER HOST ROUTER
_____________________________ ____________________________ _____________________________ ____________________________
| | .-----------. | | | .-----------. |
| _______ ______ | / | ________ . ______ | | _______ ______ | / | ________ . ______ |
| | | | | | RSVP || | . | | | RSVP | | | | | | RSVP || | . | | | RSVP
| |Applic-| | RSVP <---------/ ||Routing | -> RSVP <----------> | |Applic-| | RSVP <---------/ ||Routing | -> RSVP <---------->
| | ation<--->daemon| _____ | ||Protocol| |daemon| _____ | | | ation<--->daemon| _____ | ||Protocol| |daemon| _____ |
skipping to change at page 4, line 29 skipping to change at page 4, line 29
| | ..........| .____ | | | ..........| .____ | | | ..........| .____ | | | ..........| .____ |
| _V__V_ ____V___ |Admis|| | _V__V_ ____V___ |Admis|| | _V__V_ ____V___ |Admis|| | _V__V_ ____V___ |Admis||
| |Class-| | ||Cntrl|| | |Class-| | ||Cntrl|| | |Class-| | ||Cntrl|| | |Class-| | ||Cntrl||
| | ifier|==> Packet ||_____|| .===> ifier|==> Packet ||_____|| | | ifier|==> Packet ||_____|| .===> ifier|==> Packet ||_____||
| |______| |Schedulr|===========/ | |______| |Schedulr|===========> | |______| |Schedulr|===========/ | |______| |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 resource reservation passes incoming Each node that is capable of QoS control passes incoming data packets
data packets through a "packet classifier", which determines the through a "packet classifier", which determines the route and the QoS
route and the QoS class for each packet. On outgoing interface, a class for each packet. On each outgoing interface, a "packet
"packet scheduler" then makes forwarding decisions for every packet, scheduler" then makes forwarding decisions for every packet, to
to achieve the promised QoS on the particular link-layer medium used achieve the promised QoS on the particular link-layer medium used by
by that interface. that interface.
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.
In order to efficiently accommodate large groups, dynamic group At each node, an RSVP QoS control request is passed to two local
membership, and heterogeneous receiver requirements, RSVP makes decision modules, "admission control" and "policy control".
receivers responsible for requesting QoS [RSVP93]. A QoS request, Admission control determines whether the node has sufficient
which typically originates from a receiver host application, is available resources to supply the requested QoS. Policy control
passed to the local RSVP implementation, shown as a daemon process in determines whether the user has administrative permission to make the
Figure 1. The RSVP protocol then carries the request to all the reservation. If both checks succeed, parameters are set in the
nodes (routers and hosts) along the reverse data path(s) to the data packet classifier and in the scheduler, to obtain the desired QoS.
source(s). If either check fails, the RSVP program returns an error notification
to the application process that originated the request. We refer to
the packet classifier, packet scheduler, and admission control
components as "traffic control". The packet schedular and admission
control components implement QoS service models defined by the
Integrated Services Working Group.
At each node, the RSVP daemon communicates with two local decision RSVP protocol mechanisms provide a general facility for creating and
modules, "admission control" and "policy control". Admission control maintaining distributed reservation state across a mesh of multicast
determines whether the node has sufficient available resources to or unicast delivery paths. RSVP itself transfers and manipulates QoS
supply the requested QoS. Policy control determines whether the user control parameters as opaque data, passing them to the appropriate
has administrative permission to make the reservation. If both traffic control modules for interpretation. The structure and
checks succeed, the RSVP daemon sets parameters in the packet contents of the QoS parameters are documented in specifications
classifier and scheduler to obtain the desired QoS. If either check developed by the Integrated Services Working Group. In particular,
fails, the RSVP program returns an error notification to the [ISrsvp96] describes these data structures and how RSVP fits into the
application process that originated the request. We refer to the larger integrated service architecture.
packet classifier, packet scheduler, and admission control components
as "traffic control".
RSVP is designed to scale well for very large multicast groups. RSVP is designed to scale well for very large multicast groups.
Since both the membership of a large group and the topology of large Since both the membership of a large group and the topology of large
multicast trees are likely to change with time, the RSVP design multicast trees are likely to change with time, the RSVP design
assumes that router state for traffic control will be built and assumes that router state for traffic control will be built and
destroyed incrementally. For this purpose, RSVP uses "soft state" in destroyed incrementally. For this purpose, RSVP uses "soft state" in
the routers. That is, RSVP sends periodic refresh messages to the routers. That is, RSVP sends periodic refresh messages to
maintain the state along the reserved path(s); in absence of maintain the state along the reserved path(s); in absence of
refreshes, the state will automatically time out and be deleted. refreshes, the state will automatically time out and be deleted.
RSVP protocol mechanisms provide a general facility for creating and
maintaining distributed reservation state across a mesh of multicast
or unicast delivery paths. Except for certain well-defined
operations on the parameters, RSVP transfers QoS and policy
parameters as opaque data, passing them to the appropriate traffic
control and policy control modules for interpretation.
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
skipping to change at page 6, line 20 skipping to change at page 6, line 8
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,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 an extension for UDP encapsulation of RSVP messages.
1.1 Data Flows 1.1 Data Flows
skipping to change at page 8, line 6 skipping to change at page 7, line 43
are handled as best-effort traffic. are handled as best-effort traffic.
Note that the action to control QoS occurs at the place where the Note that the action to control QoS occurs at the place where the
data enters the medium, i.e., at the upstream end of the logical data enters the medium, i.e., at the upstream end of the logical
or physical link, although an RSVP reservation request originates or physical link, although an RSVP reservation request originates
from receiver(s) downstream. In this document, we define the from receiver(s) downstream. In this document, we define the
directional terms "upstream" vs. "downstream", "previous hop" vs. directional terms "upstream" vs. "downstream", "previous hop" vs.
"next hop", and "incoming interface" vs "outgoing interface" with "next hop", and "incoming interface" vs "outgoing interface" with
respect to the direction of data flow. 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 model [ServTempl95, ISdata95], and are generally opaque to service models [ISrsvp96] and are generally opaque to RSVP.
RSVP. The exact format of a filter spec depends upon whether IPv4
or IPv6 is in use; see Appendix A.
In the most general approach [RSVP93], filter specs may select The exact format of a filter spec depends upon whether IPv4 or
arbitrary subsets of the packets in a given session. Such subsets IPv6 is in use; see Appendix A. In the most general approach
might be defined in terms of senders (i.e., sender IP address and [RSVP93], filter specs may select arbitrary subsets of the packets
generalized source port), in terms of a higher-level protocol, or in a given session. Such subsets might be defined in terms of
generally in terms of any fields in any protocol headers in the senders (i.e., sender IP address and generalized source port), in
packet. For example, filter specs might be used to select terms of a higher-level protocol, or generally in terms of any
different subflows in a hierarchically-encoded signal by selecting fields in any protocol headers in the packet. For example, filter
on fields in an application-layer header. In the interest of specs might be used to select different subflows in a
simplicity (and to minimize layer violation), the present RSVP hierarchically-encoded signal by selecting on fields in an
version uses a much more restricted form of filter spec, application-layer header. In the interest of simplicity (and to
consisting of sender IP address and optionally the UDP/TCP port minimize layer violation), the present RSVP version uses a much
number SrcPort. more restricted form of filter spec, consisting of sender 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.
As a result, it is generally necessary to avoid IP fragmentation This raises three potential problems.
of a data stream for which a resource reservation is desired.
There are two cases where the use of transport-layer ports for 1. It is necessary to avoid IP fragmentation of a data stream
selecting an RSVP flow may cause problems. for which a resource reservation is desired.
1. IPv6 inserts a variable number of variable-length Internet- Document [ISrsvp96] specifies a procedure for applications
using RSVP facilities to compute the minimum MTU over a
multicast tree and return the result to the senders.
2. IPv6 inserts a variable number of variable-length Internet-
layer headers before the transport header, increasing the layer headers before the transport header, increasing the
difficulty and cost of packet classification for QoS. difficulty and cost of packet classification for QoS.
Efficient classification of IPv6 data packets could be Efficient classification of IPv6 data packets could be
obtained using the Flow Label field of the IPv6 header. The obtained using the Flow Label field of the IPv6 header. The
details will be provided in the future. details will be provided in the future.
2. 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, rendering the port numbers invisible entire transport header, hiding the port numbers of data
to intermediate routers. packets from intermediate routers.
A small extension to RSVP for IP Security under IPv4 is A small extension to RSVP for IP Security under IPv4 and IPv6
described separately in [IPSEC96]. A corresponding solution is described separately in [IPSEC96].
for IPv6 will be provided in the future.
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). At each
intermediate node, two general actions are taken on a request. intermediate node, two general actions are taken on a request.
1. Make a reservation 1. Make a reservation
The request is passed to admission control and policy The request is passed to admission control and policy
control. If either test fails, the reservation is rejected control. If either test fails, the reservation is rejected
and RSVP returns an error message to the appropriate and RSVP returns an error message to the appropriate
skipping to change at page 18, line 15 skipping to change at page 18, line 15
Each RSVP sender host transmits RSVP "Path" messages downstream Each RSVP sender host transmits RSVP "Path" messages downstream
along the uni-/multicast routes provided by the routing along the uni-/multicast routes provided by the routing
protocol(s), following the paths of the data. These Path messages protocol(s), following the paths of the data. These Path messages
store "path state" in each node along the way. This path state store "path state" in each node along the way. This path state
includes at least the unicast IP address of the previous hop node, includes at least the unicast IP address of the previous hop node,
which is used to route the Resv messages hop-by-hop in the reverse which is used to route the Resv messages hop-by-hop in the reverse
direction. (In the future, some routing protocols may supply direction. (In the future, some routing protocols may supply
reverse path forwarding information directly, replacing the reverse path forwarding information directly, replacing the
reverse-routing function of path state). reverse-routing function of path state).
A Path message may carry the following information in addition to A Path message contains the following information in addition to
the previous hop address: the previous hop address:
o Sender Template o Sender Template
A Path message is required to carry a Sender Template, which A Path message is required to carry a Sender Template, which
describes the format of data packets that the sender will describes the format of data packets that the sender will
originate. This template is in the form of a filter spec originate. This template is in the form of a filter spec
that could be used to select this sender's packets from that could be used to select this sender's packets from
others in the same session on the same link. others in the same session on the same link.
skipping to change at page 18, line 42 skipping to change at page 18, line 42
o Sender Tspec o Sender Tspec
A Path message is required to carry a Sender Tspec, which A Path message is required to carry a Sender Tspec, which
defines the traffic characteristics of the data stream that defines the traffic characteristics of the data stream that
the sender will generate. This Tspec is used by traffic the sender will generate. This Tspec is used by traffic
control to prevent over-reservation, and perhaps unnecessary control to prevent over-reservation, and perhaps unnecessary
Admission Control failures. Admission Control failures.
o Adspec o Adspec
A Path message may optionally carry a package of OPWA A Path message may carry a package of OPWA advertising
advertising information, known as an "Adspec". An Adspec information, known as an "Adspec". An Adspec received in a
received in a Path message is passed to the local traffic Path message is passed to the local traffic control, which
control, which returns an updated Adspec; the updated version returns an updated Adspec; the updated version is then
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.9). On the other hand, through non-RSVP clouds (see Section 2.9). On the other hand,
Resv messages are sent hop-by-hop; each RSVP-speaking node Resv messages are sent hop-by-hop; each RSVP-speaking node
forwards a Resv message to the unicast address of a previous RSVP forwards a Resv message to the unicast address of a previous RSVP
hop. hop.
2.2 Port Usage 2.2 Port Usage
skipping to change at page 27, line 4 skipping to change at page 27, line 4
administrative rules, or of some form of real or virtual billing administrative rules, or of some form of real or virtual billing
for the "cost" of a reservation. The form and contents of such for the "cost" of a reservation. The form and contents of such
back pressure is a matter of administrative policy that may be back pressure is a matter of administrative policy that may be
determined independently by each administrative domain in the determined independently by each administrative domain in the
Internet. Internet.
Therefore, there is likely to be policy control as well as Therefore, there is likely to be policy control as well as
admission control over the establishment of reservations. As admission control over the establishment of reservations. As
input to policy control, RSVP messages may carry "policy data". input to policy control, RSVP messages may carry "policy data".
Policy data may include credentials identifying users or user Policy data may include credentials identifying users or user
classes, account numbers, limits, quotas, etc. Like flowspecs, classes, account numbers, limits, quotas, etc. RSVP will pass the
policy data will be opaque to RSVP, which will simply pass it to a "policy data" to a "Local Policy Module" (LPM) for a decision.
"Local Policy Module" (LPM) for a decision.
To protect the integrity of the policy control mechanisms, it may To protect the integrity of the policy control mechanisms, it may
be necessary to ensure the integrity of RSVP messages against be necessary to ensure the integrity of RSVP messages against
corruption or spoofing, hop by hop. For this purpose, RSVP corruption or spoofing, hop by hop. For this purpose, RSVP
messages may carry integrity objects that can be created and messages may carry integrity objects that can be created and
verified by neighbor RSVP-capable nodes. These objects use a verified by neighbor RSVP-capable nodes. These objects use a
keyed cryptographic digest technique and assume that RSVP keyed cryptographic digest technique and assume that RSVP
neighbors share a secret [Baker96]. neighbors share a secret [Baker96].
User policy data in reservation request messages presents a User policy data in reservation request messages presents a
skipping to change at page 28, line 16 skipping to change at page 28, line 15
routing table. Therefore, the routing of Path messages will be routing table. Therefore, the routing of Path messages will be
unaffected by non-RSVP routers in the path. When a Path message unaffected by non-RSVP routers in the path. When a Path message
traverses a non-RSVP cloud, it carries to the next RSVP-capable traverses a non-RSVP cloud, it carries to the next RSVP-capable
node the IP address of the last RSVP-capable router before node the IP address of the last RSVP-capable router before
entering the cloud. An Resv message is then forwarded directly to entering the cloud. An Resv message is then forwarded directly to
the next RSVP-capable router on the path(s) back towards the the next RSVP-capable router on the path(s) back towards the
source. source.
Even though RSVP operates correctly through a non-RSVP cloud, the Even though RSVP operates correctly through a non-RSVP cloud, the
non-RSVP-capable nodes will in general perturb the QoS provided to non-RSVP-capable nodes will in general perturb the QoS provided to
a receiver. Therefore, RSVP tries to inform the receiver when a receiver. Therefore, RSVP passes a `NonRSVP' flag bit to the
there are non-RSVP-capable hops in the path to a given sender, by local traffic control mechanism when there are non-RSVP-capable
means of two flag bits in the SESSION object of a Path message; hops in the path to a given sender. Traffic control combines this
see Section 3.7 and Appendix A. flag bit with its own sources of information, and forwards the
composed information on integrated service capability along the
path to receivers using Adspecs [ISrsvp96].
Some topologies of RSVP routers and non-RSVP routers can cause Some topologies of RSVP routers and non-RSVP routers can cause
Resv messages to arrive at the wrong RSVP-capable node, or to Resv messages to arrive at the wrong RSVP-capable node, or to
arrive at the wrong interface of the correct node. An RSVP daemon arrive at the wrong interface of the correct node. An RSVP daemon
must be prepared to handle either situation. If the destination must be prepared to handle either situation. If the destination
address does not match any local interface and the message is not address does not match any local interface and the message is not
a Path or PathTear, the message must be forwarded without further a Path or PathTear, the message must be forwarded without further
processing by this node. When a Resv message does arrive at the processing by this node. To handle the wrong interface case, a
addressed node, the IP destination address (or the LIH, defined "Logical Interface Handle" (LIH) is used. The previous hop
later) must be used to determine the interface to receive the information included in a Path message includes not only the IP
reservation. address of the previous node but also an LIH defining the logical
outgoing interface; both values are stored in the path 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
interface that should receive the requested reservation,
regardless of which interface it arrives on.
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
entities.
2.10 Host Model 2.10 Host Model
Before a session can be created, the session identification, Before a session can be created, the session identification,
comprised of DestAddress, ProtocolId, and perhaps the generalized comprised of DestAddress, ProtocolId, and perhaps the generalized
destination port, must be assigned and communicated to all the destination port, must be assigned and communicated to all the
senders and receivers by some out-of-band mechanism. When an RSVP senders and receivers by some out-of-band mechanism. When an RSVP
session is being set up, the following events happen at the end session is being set up, the following events happen at the end
systems. systems.
skipping to change at page 41, line 6 skipping to change at page 41, line 6
<SESSION> <ERROR_SPEC> <SESSION> <ERROR_SPEC>
[ <POLICY_DATA> ...] [ <POLICY_DATA> ...]
<sender descriptor> <sender descriptor>
<sender descriptor> ::= (see earlier definition) <sender descriptor> ::= (see earlier definition)
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ] <ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC> <SESSION> <RSVP_HOP>
[ <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 (i.e., when an
administrative failure is being reported). The STYLE object is administrative failure is being reported). In a ResvErr
copied from the Resv message in error. The use of the SCOPE message, the RSVP_HOP object contains the previous hop address,
object in a ResvErr message is defined below in Section 3.3. and the STYLE object is copied from the Resv message in error.
The use of the SCOPE object in a ResvErr message is defined
below in Section 3.3.
The following style-dependent rules define the composition of a The following style-dependent rules define the composition of a
valid error flow descriptor; 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 a Resv message.
o WF Style: o WF Style:
<error flow descriptor> ::= <WF flow descriptor> <error flow descriptor> ::= <WF flow descriptor>
o FF style: o FF style:
skipping to change at page 53, line 24 skipping to change at page 53, line 29
This flag should be set on for a reservation using a shared This flag should be set on for a reservation using a shared
style (WF or SE) when flows from more than one sender are style (WF or SE) when flows from more than one sender are
being merged. being merged.
o B_Police_Flag -- Branch Policing o B_Police_Flag -- Branch Policing
This flag should be set on when the flowspec being installed This flag should be set on when the flowspec being installed
is smaller than, or incomparable to, a FLOWSPEC in place on is smaller than, or incomparable to, a FLOWSPEC in place on
any other interface, for the same FILTER_SPEC and SESSION. any other interface, for the same FILTER_SPEC and SESSION.
RSVP must also detect and report to receivers the presence of RSVP must also test for the presence of non-RSVP hops in the path
non-RSVP (which implies non-integrated-service compliant) hops in and pass this information to traffic control. From this flag bit
the path. For this purpose, an RSVP daemon sets the Non_RSVP flag that the RSVP daemon supplies and from its own local knowledge,
bit in the SESSION object of Path messages. With normal IP traffic control can detect the presence of a hop in the path that
forwarding, RSVP can detect a non-RSVP hop by comparing the IP TTL is not capable of QoS control, and it passes this information to
with which a Path message is sent to the TTL with which it is the receivers in Adspecs [ISrsvp96].
received, and set the Non_RSVP bit on. For this purpose, the
transmission TTL is placed in the common header.
However, the TTL is not always a reliable indicator of non-RSVP With normal IP forwarding, RSVP can detect a non-RSVP hop by
hops, and other means must be used. For example, if the routing comparing the IP TTL with which a Path message is sent to the TTL
protocol uses IP encapsulating tunnels, then the routing protocol with which it is received; for this purpose, the transmission TTL
must inform RSVP when non-RSVP hops are included. If no automatic is placed in the common header. However, the TTL is not always a
mechanism will work, manual configuration will be required. reliable indicator of non-RSVP hops, and other means must
Finally, there may still be cases where an RSVP cannot reliably sometimes be used. For example, if the routing protocol uses IP
determine whether or not a non-RSVP hop was used. To report this encapsulating tunnels, then the routing protocol must inform RSVP
to the receiver, the SESSION object carries another flag bit, when non-RSVP hops are included. If no automatic mechanism will
Maybe_RSVP. work, manual configuration will be required.
3.8 Multihomed Hosts 3.8 Multihomed Hosts
Accommodating multihomed hosts requires some special rules in Accommodating multihomed hosts requires some special rules in
RSVP. We use the term `multihomed host' to cover both hosts (end RSVP. We use the term `multihomed host' to cover both hosts (end
systems) with more than one network interface and routers that are systems) with more than one network interface and routers that are
supporting local application programs. supporting local application programs.
An application executing on a multihomed host may explicitly An application executing on a multihomed host may explicitly
specify which interface any given flow will use for sending and/or specify which interface any given flow will use for sending and/or
skipping to change at page 57, line 49 skipping to change at page 57, line 49
future. Normally SESSION_object will be omitted. future. Normally SESSION_object will be omitted.
o Define Sender o Define Sender
Call: SENDER( Session-id Call: SENDER( Session-id
[ , Source_Address ] [ , Source_Port ] [ , Source_Address ] [ , Source_Port ]
[ , Sender_Template ] [ , Sender_Template ]
[ , Sender_Tspec ] [ , Data_TTL ] [ , Sender_Tspec ] [ , Adspec ]
[ , Policy_data ] ) [ , Data_TTL ] [ , Policy_data ] )
A sender uses this call to define, or to modify the A sender uses this call to define, or to modify the
definition of, the attributes of the data stream. The definition of, the attributes of the data stream. The
first SENDER call for the session registered as `Session- first SENDER call for the session registered as `Session-
id' will cause RSVP to begin sending Path messages for id' will cause RSVP to begin sending Path messages for
this session; later calls will modify the path this session; later calls will modify the path
information. information.
The SENDER parameters are interpreted as follows: The SENDER parameters are interpreted as follows:
- Source_Address - Source_Address
skipping to change at page 58, line 34 skipping to change at page 58, line 34
- Sender_Template - Sender_Template
This parameter is included as an escape mechanism to This parameter is included as an escape mechanism to
support a more general definition of the sender support a more general definition of the sender
("generalized source port"). Normally this parameter ("generalized source port"). Normally this parameter
may be omitted. may be omitted.
- Sender_Tspec - Sender_Tspec
This parameter describes the traffic flow to be sent. This parameter describes the traffic flow to be sent;
It may be included to prevent over-reservation on the see [ISrsvp96].
initial hops.
- Adspec
This parameter may be specified to initialize the
computation of QoS properties along the path; see
[ISrsvp96].
- Data_TTL - Data_TTL
This is the (non-default) IP Time-To-Live parameter This is the (non-default) IP Time-To-Live parameter
that is being supplied on the data packets. It is that is being supplied on the data packets. It is
needed to ensure that Path messages do not have a needed to ensure that Path messages do not have a
scope larger than multicast data packets. scope larger than multicast data packets.
- Policy_data - Policy_data
This optional parameter passes policy data for the This optional parameter passes policy data for the
sender. This data may be supplied by a system sender. This data may be supplied by a system
service, with the application treating it as opaque. service, with the application treating it as opaque.
o Reserve o Reserve
Call: RESERVE( session-id, [ receiver_address , ] Call: RESERVE( session-id, [ receiver_address , ]
[ CONF_flag, ] [ Policy_data, ] [ CONF_flag, ] [ Policy_data, ]
style, style-dependent-parms ) style, style-dependent-parms )
A receiver uses this call to make or to modify a resource A receiver uses this call to make or to modify a resource
reservation for the session registered as `session-id'. reservation for the session registered as `session-id'.
The first RESERVE call will initiate the periodic The first RESERVE call will initiate the periodic
transmission of Resv messages. A later RESERVE call may transmission of Resv messages. A later RESERVE call may
skipping to change at page 60, line 22 skipping to change at page 60, line 26
A Path Event upcall results from receipt of the first A Path Event upcall results from receipt of the first
Path message for this session, indicating to a Path message for this session, indicating to a
receiver application that there is at least one receiver application that there is at least one
active sender, or if the path state changes. active sender, or if the path state changes.
Upcall: <Upcall_Proc>( ) -> session-id, Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=PATH_EVENT, Info_type=PATH_EVENT,
flags,
Sender_Tspec, Sender_Template Sender_Tspec, Sender_Template
[ , Adspec ] [ , Policy_data ] [ , Adspec ] [ , Policy_data ]
This upcall presents the Sender_Tspec and the This upcall presents the Sender_Tspec, the
Sender_Template from a Path message; it also passes Sender_Template, the Adspec, and any policy data from
the advertisement and policy data if they are a Path message.
present. The possible flags correspond to Non_RSVP
and Maybe_RSVP flags of the SESSION object.
2. Info_type = RESV_EVENT 2. Info_type = RESV_EVENT
A Resv Event upcall is triggered by the receipt of A Resv Event upcall is triggered by the receipt of
the first RESV message, or by modification of a the first RESV message, or by modification of a
previous reservation state, for this session. previous reservation state, for this session.
Upcall: <Upcall_Proc>( ) -> session-id, Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=RESV_EVENT, Info_type=RESV_EVENT,
skipping to change at page 64, line 39 skipping to change at page 64, line 39
o Delete Filter Spec o Delete Filter Spec
Call: TC_DelFilter( Interface, FHandle ) Call: TC_DelFilter( Interface, FHandle )
This call is used to remove a specific filter, specified This call is used to remove a specific filter, specified
by FHandle. by FHandle.
o OPWA Update o OPWA Update
Call: TC_Advertise( Interface, Adspec ) Call: TC_Advertise( Interface, Adspec,
-> 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. advertisement New_Adspec for a specified interface. The
flag bit Non_RSVP_Hop_flag should be set whenever the RSVP
daemon detects that the previous RSVP hop included one or
more non-RSVP-capable routers. TC_Advertise will insert
this information into New_Adspec to indicate that a non-
integrated-service hop was found; see Section 3.7.
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
more existing reservations. This will trigger a more existing reservations. This will trigger a
TC_Preempt() upcall to RSVP for each preempted TC_Preempt() upcall to RSVP for each preempted
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.10.3 RSVP/Policy Control Interface 3.10.3 RSVP/Policy Control Interface
skipping to change at page 69, line 38 skipping to change at page 69, line 38
- Sender_Tspec - Sender_Tspec
- The previous hop IP address and the Logical Interface - The previous hop IP address and the Logical Interface
Handle (LIH) from a PHOP object Handle (LIH) from a PHOP object
- The remaining IP TTL - The remaining IP TTL
- POLICY_DATA and/or ADSPEC objects (optional) - POLICY_DATA and/or ADSPEC objects (optional)
- Non_RSVP and Maybe_RSVP flags (Section 3.7). - Non_RSVP flag (Section 3.7).
- E_Police flag (Section 3.7) - E_Police flag (Section 3.7)
- Local_Only flag (Section 3.8) - Local_Only flag (Section 3.8)
In addition, the PSB contains the following information provided In addition, the PSB contains the following information provided
by routing: OutInterface_list, which is the list of outgoing by routing: OutInterface_list, which is the list of outgoing
interfaces for this (sender, destination), and IncInterface, interfaces for this (sender, destination), and IncInterface,
which is the expected incoming interface. For a unicast which is the expected incoming interface. For a unicast
destination, OutInterface_list contains one entry and destination, OutInterface_list contains one entry and
skipping to change at page 75, line 47 skipping to change at page 75, line 47
PathTear MESSAGE ARRIVES PathTear MESSAGE ARRIVES
o Search for a PSB whose (Session, Sender_Template) pair o Search for a PSB whose (Session, Sender_Template) pair
matches the corresponding objects in the message. If no matches the corresponding objects in the message. If no
matching PSB is found, drop the PathTear message and matching PSB is found, drop the PathTear message and
return. return.
o Forward a copy of the PathTear message to each outgoing o Forward a copy of the PathTear message to each outgoing
interface listed in OutInterface_list of the PSB. interface listed in OutInterface_list of the PSB.
o Find each RSB that matches this PSB, i.e., that whose o Find each RSB that matches this PSB, i.e., whose
Filter_spec_list matches Sender_Template in the PSB and Filter_spec_list matches Sender_Template in the PSB and
whose OI is included in OutInterface_list. whose OI is included in OutInterface_list.
If this RSB matches no other PSB, then: 1. If the RSB style is explicit, then:
1. Delete the RSB. - Delete from Filter_spec_list the FILTER_SPEC that
matches the PSB.
2. Execute the event sequence UPDATE TRAFFIC CONTROL - if Filter_spec_list is now empty, delete the RSB.
(below) to update the traffic control state to be
consistent with the current reservation state. 2. Otherwise (RSB style is wildcard) then:
- If this RSB matches no other PSB, then delete the
RSB.
3. If an RSB was found, execute the event sequence UPDATE
TRAFFIC CONTROL (below) to update the traffic control
state to be consistent with the current reservation
and path state.
o Delete the PSB. o Delete the PSB.
o Drop the PathTear message and return. o Drop the PathTear message and return.
PathErr MESSAGE ARRIVES PathErr MESSAGE ARRIVES
o Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair o Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair
matches the corresponding objects in the message. If no matches the corresponding objects in the message. If no
matching PSB is found, drop the PathErr message and return. matching PSB is found, drop the PathErr message and return.
skipping to change at page 77, line 44 skipping to change at page 78, line 6
For SE style, execute the following steps once for (FLOWSPEC, For SE style, execute the following steps once for (FLOWSPEC,
Filtss), with Filtss consisting of the list of FILTER_SPEC Filtss), with Filtss consisting of the list of FILTER_SPEC
objects from the flow descriptor. objects from the flow descriptor.
For WF style, execute the following steps once for (FLOWSPEC, For WF style, execute the following steps once for (FLOWSPEC,
Filtss), with Filtss an empty list. Filtss), with Filtss an empty list.
o Check the path state, as follows. o Check the path state, as follows.
1. Locate the set of PSBs (senders) that route to OI and 1. Locate the set of PSBs (senders) that route to OI and
whose SENDER_TEMPLATEs match Filtss. whose SENDER_TEMPLATEs match a FILTER_SPEC in Filtss.
If this set is empty, build and send an error message If this set is empty, build and send an error message
specifying "No sender information", and continue with specifying "No sender information", and continue with
the next flow descriptor in the Resv message. the next flow descriptor in the Resv message.
2. If the style has explicit sender selection (e.g., FF 2. If the style has explicit sender selection (e.g., FF
or SE) and if any FILTER_SPEC included in Filtss or SE) and if any FILTER_SPEC included in Filtss
matches more than one PSB, build and send a ResvErr matches more than one PSB, build and send a ResvErr
message specifying "Ambiguous filter spec" and message specifying "Ambiguous filter spec" and
continue with the next flow descriptor in the Resv continue with the next flow descriptor in the Resv
message. message.
3. Add the PHOP from the PSB to Refresh_PHOP_list, if the 3. If the style is SE and if some FILTER_SPEC included in
Filtss matches no PSB, delete that FILTER_SPEC from
Filtss.
4. Add the PHOP from the PSB to Refresh_PHOP_list, if the
PHOP is not already on the list. PHOP is not already on the list.
o Find or create a reservation state block (RSB) for o Find or create a reservation state block (RSB) for
(SESSION, PHOP). If the style is distinct, Filtss is also (SESSION, NHOP). If the style is distinct, Filtss is also
used in the selection. Call this the "active RSB". used in the selection. Call this the "active RSB".
o If the active RSB is new: o If the active RSB is new:
1. Set the session, NHOP, OI and style of the RSB from 1. Set the session, NHOP, OI and style of the RSB from
the message. the message.
2. Copy Filtss into the Filter_spec_list of the RSB. 2. Copy Filtss into the Filter_spec_list of the RSB.
3. Copy the FLOWSPEC and any SCOPE object from the 3. Copy the FLOWSPEC and any SCOPE object from the
skipping to change at page 80, line 8 skipping to change at page 80, line 20
(FLOWSPEC, Filtss) pair. Here the structure Filtss (FLOWSPEC, Filtss) pair. Here the structure Filtss
consists of the FILTER_SPEC from the flow descriptor. consists of the FILTER_SPEC from the flow descriptor.
For SE style, execute the following steps once for For SE style, execute the following steps once for
(FLOWSPEC, Filtss), with Filtss consisting of the list of (FLOWSPEC, Filtss), with Filtss consisting of the list of
FILTER_SPEC objects from the flow descriptor. FILTER_SPEC objects from the flow descriptor.
For WF style, execute the following steps once for For WF style, execute the following steps once for
(FLOWSPEC, Filtss), with Filtss an empty list. (FLOWSPEC, Filtss), with Filtss an empty list.
1. Find an RSB matching (SESSION, PHOP). If the style is 1. Find an RSB matching (SESSION, NHOP). If the style is
distinct, Filtss is also used in the selection. Call distinct, Filtss is also used in the selection. Call
this the "active RSB". If no active RSB is found, this the "active RSB". If no active RSB is found,
continue with next flow descriptor. continue with next flow descriptor.
2. Check the style 2. Check the style
If the active RSB has a style that is incompatible If the active RSB has a style that is incompatible
with the style of the message, drop the ResvTear with the style of the message, drop the ResvTear
message and return. message and return.
skipping to change at page 80, line 41 skipping to change at page 81, line 6
application. application.
6. Continue with the next flow descriptor. 6. Continue with the next flow descriptor.
o All flow descriptors have been processed. o All flow descriptors have been processed.
Build and send any ResvTear messages to be forwarded, in Build and send any ResvTear messages to be forwarded, in
the following manner. the following manner.
1. Select each PSB that routes to the outgoing interface 1. Select each PSB that routes to the outgoing interface
OI. OI, and, for distinct style, that has a
SENDER_TEMPLATE matching Filtss.
2. Select a flow descriptor Fj in the ResvTear message 2. Select a flow descriptor (Qj,Fj) (where Fj may be a
whose FILTER_SPEC matches the SENDER_TEMPLATE in the list) in the ResvTear message whose FILTER_SPEC
PSB, and do the following. However, if no match is matches the SENDER_TEMPLATE in the PSB. If not match
found, return to the previous step to select the next is found, return for next PSB.
PSB.
- Search for an RSB for outgoing interface OI whose - Search for an RSB (for any outgoing interface) to
FILTER_SPEC matches the PSB. which the PSB routes and whose Filter_spec_list
includes the SENDER_TEMPLATE from the PSB.
- If an RSB is found and if the Resv_Refresh_Needed - If an RSB is found, add the PHOP of the PSB to
flag is on, add the PHOP of the PSB to the the Refresh_PHOP_list.
Refresh_PHOP_list.
- If no such RSB is found then add Fj to the new - Otherwise (no RSB is found), add the flow
ResvTear message being built, in a manner descriptor (Qj,Fj) to the new ResvTear message
appropriate to the style. being built, in a manner appropriate to the
style.
- Continue with the next PSB. - Continue with the next PSB.
3. If the next PSB is for a different PHOP or the last 3. If the next PSB is for a different PHOP or the last
PSB has been processed, forward any ResvTear message PSB has been processed, forward any ResvTear message
that has been built. that has been built.
o If any PSB's were found in the preceding step, and if the o If any PSB's were found in the preceding step, and if the
Resv_Refresh_Needed flag is now on, execute the Resv Resv_Refresh_Needed flag is now on, execute the Resv
REFRESH sequence (below) for each PHOP in REFRESH sequence (below) for each PHOP in
skipping to change at page 84, line 5 skipping to change at page 84, line 18
If the result is to modify the traffic control state, this If the result is to modify the traffic control state, this
sequence notifies any matching local applications with a sequence notifies any matching local applications with a
RESV_EVENT upcall. If the state change is such that it should RESV_EVENT upcall. If the state change is such that it should
trigger immediate Resv refresh messages, it also turns on the trigger immediate Resv refresh messages, it also turns on the
Resv_Refresh_Needed flag. Resv_Refresh_Needed flag.
o Compute the traffic control parameters using the following o Compute the traffic control parameters using the following
steps. steps.
1. Consider the set of RSB's matching SESSION, 1. Initially the local flag Is_Biggest is off.
Filter_spec_list, and OI from the active RSB.
Initially the local flag Is_Biggest is off. 2. Consider the set of RSB's matching SESSION and OI from
the active RSB. If the style of the active RSB is
distinct, then the Filter_spec_list must also be
matched.
- Compute the effective kernel flowspec, - Compute the effective kernel flowspec,
TC_Flowspec, as the LUB of the FLOWSPEC values in TC_Flowspec, as the LUB of the FLOWSPEC values in
these RSB's. these RSB's.
- Compute the effective traffic control filter spec - Compute the effective traffic control filter spec
(list) TC_Filter_Spec* as the union of the (list) TC_Filter_Spec* as the union of the
Filter_spec_lists from these RSB's. Filter_spec_lists from these RSB's.
- If the active RSB has a FLOWSPEC larger than all - If the active RSB has a FLOWSPEC larger than all
the others, turn on the Is_Biggest flag. the others, turn on the Is_Biggest flag.
2. Scan all RSB's matching session and Filtss, for all 3. Scan all RSB's matching session and Filtss, for all
OI. Set TC_B_Police_flag on if TC_Flowspec is smaller OI. Set TC_B_Police_flag on if TC_Flowspec is smaller
than, or incomparable to, any FLOWSPEC in those RSB's. than, or incomparable to, any FLOWSPEC in those RSB's.
3. Locate the set of PSBs (senders) whose 4. Locate the set of PSBs (senders) whose
SENDER_TEMPLATEs match Filter_spec_list in the active SENDER_TEMPLATEs match Filter_spec_list in the active
RSB and whose OutInterface_list includes OI. RSB and whose OutInterface_list includes OI.
4. Set TC_E_Police_flag on if any of these PSBs have 5. Set TC_E_Police_flag on if any of these PSBs have
their E_Police flag on. Set TC_M_Police_flag on if it their E_Police flag on. Set TC_M_Police_flag on if it
is a shared style and there is more than one PSB in is a shared style and there is more than one PSB in
the set. the set.
5. Compute Path_Te as the sum of the SENDER_TSPEC objects 6. Compute Path_Te as the sum of the SENDER_TSPEC objects
in this set of PSBs. in this set of PSBs.
o Search for a TCSB matching SESSION and OI; for distinct o Search for a TCSB matching SESSION and OI; for distinct
style (FF), it must also match Filter_spec_list. style (FF), it must also match Filter_spec_list.
If none is found, create a new TCSB. If none is found, create a new TCSB.
o If TCSB is new: o If TCSB is new:
1. Store TC_Flowspec, TC_Filter_Spec*, Path_Te, and the 1. Store TC_Flowspec, TC_Filter_Spec*, Path_Te, and the
skipping to change at page 86, line 15 skipping to change at page 86, line 31
4. Otherwise (the call succeeds), update the TCSB with 4. Otherwise (the call succeeds), update the TCSB with
the new values and save Fwd_Flowspec in the TCSB. the new values and save Fwd_Flowspec in the TCSB.
o If the TCSB is not new but the TC_Filter_Spec* just o If the TCSB is not new but the TC_Filter_Spec* just
computed differs from the FILTER_SPEC* in the TCSB, then: computed differs from the FILTER_SPEC* in the TCSB, then:
1. Make an appropriate set of TC_DelFilter and 1. Make an appropriate set of TC_DelFilter and
TC_AddFilter calls to transform the Filter_spec_list TC_AddFilter calls to transform the Filter_spec_list
in the TCSB into the new TC_Filter_Spec*. in the TCSB into the new TC_Filter_Spec*.
2. Turn on the Resv_Refresh_Needed flag.
o If the active RSB contains a RESV_CONFIRM object, then: o If the active RSB contains a RESV_CONFIRM object, then:
1. If the Is_Biggest flag is on, move the RESV_CONFIRM 1. If the Is_Biggest flag is on, move the RESV_CONFIRM
object into the TCSB and turn on the object into the TCSB and turn on the
Resv_Refresh_Needed flag. (This will later cause the Resv_Refresh_Needed flag. (This will later cause the
Resv REFRESH sequence to be invoked, which will either Resv REFRESH sequence to be invoked, which will either
forward or return the RESV_CONFIRM object, deleting it forward or return the RESV_CONFIRM object, deleting it
from the TCSB in either case). from the TCSB in either case).
2. Otherwise, create and send a ResvConf message to the 2. Otherwise, create and send a ResvConf message to the
skipping to change at page 87, line 22 skipping to change at page 87, line 41
SENDER_TSPEC, and POLICY_DATA objects, if present in the SENDER_TSPEC, and POLICY_DATA objects, if present in the
PSB, and pack it into the Path message being built. PSB, and pack it into the Path message being built.
o Send a copy of the Path message to each interface OI in o Send a copy of the Path message to each interface OI in
OutInterface_list. Before sending each copy: OutInterface_list. Before sending each copy:
1. If the PSB has the E_Police flag on and if interface 1. If the PSB has the E_Police flag on and if interface
OI is not capable of policing, turn the E_Police flag OI is not capable of policing, turn the E_Police flag
on in the Path message being built. on in the Path message being built.
2. Pass any ADSPEC and SENDER_TSPEC objects present in 2. Pass the ADSPEC object and Non_RSVP flag present in
the PSB to the traffic control call TC_Advertise. the PSB to the traffic control call TC_Advertise.
Insert the modified ADSPEC object that is returned Insert the modified ADSPEC object that is returned
into the Path message being built. into the Path message being built.
3. Insert into its PHOP object the interface address and 3. Insert into its PHOP object the interface address and
the LIH for the interface. the LIH for the interface.
Resv REFRESH Resv REFRESH
This sequence sends a reservation refresh towards a particular This sequence sends a reservation refresh towards a particular
skipping to change at page 88, line 31 skipping to change at page 89, line 5
- If TCSB contains a CONFIRM object, then create - If TCSB contains a CONFIRM object, then create
and send a ResvConf message containing the object and send a ResvConf message containing the object
and delete the CONFIRM object from the TCSB. and delete the CONFIRM object from the TCSB.
- Continue with next PSB. - Continue with next PSB.
3. If B_Merge flag is off then ignore a blockaded TCSB, 3. If B_Merge flag is off then ignore a blockaded TCSB,
as follows. as follows.
- Select BSB's that match this TCSB. If any of - Select BSB's that match this TCSB. If a selected
these BSB's has a Qb that is not strictly larger BSB is expired, delete it. If any of the
than TC_Flowspec, then continue processing with unexpired BSB's has a Qb that is not strictly
the next TCSB. larger than TC_Flowspec, then continue processing
with the next TCSB.
However, if steps 1 and 2 result in finding that all However, if steps 1 and 2 result in finding that all
TCSB's matching this PSB are blockaded, then: TCSB's matching this PSB are blockaded, then:
- If this Resv REFRESH sequence was invoked from - If this Resv REFRESH sequence was invoked from
Resv ERROR RECEIVED, then return to the latter. Resv ERROR RECEIVED, then return to the latter.
- Otherwise, turn on the B_Merge flag and restart - Otherwise, turn on the B_Merge flag and restart
at step 1, immediately above. at step 1, immediately above.
skipping to change at page 93, line 17 skipping to change at page 94, line 17
0x01 = E_Police flag 0x01 = E_Police flag
The E_Police flag is used in Path messages to determine The E_Police flag is used in Path messages to determine
the effective "edge" of the network, to control traffic the effective "edge" of the network, to control traffic
policing. If the sender host is not itself capable of policing. If the sender host is not itself capable of
traffic policing, it will set this bit on in Path traffic policing, it will set this bit on in Path
messages it sends. The first node whose RSVP is capable messages it sends. The first node whose RSVP is capable
of traffic policing will do so (if appropriate to the of traffic policing will do so (if appropriate to the
service) and turn the flag off. service) and turn the flag off.
0x10 = Non_RSVP flag
The Non_RSVP flag is turned on in the SESSION object of
a Path message whenever the RSVP daemon detects that the
previous RSVP hop included one or more non-RSVP-capable
routers. This flag is forwarded hop-by-hop and passed
to a receiver application. If it is on, it indicates to
the application that even a successful reservation
request may not install the requested QoS at every node
along the path.
0x20 = Maybe_RSVP flag
The Maybe_RSVP flag is turned on in the SESSION object
of a Path message whenever the RSVP daemon is unable to
ascertain whether or not the previous hop included one
or more non-RSVP-capable routers. This flag is
forwarded hop-by-hop and passed to a receiver
application. If it is on and the Non_RSVP flag is off,
the application cannot tell whether or not the requested
QoS was installed at every node along the path.
DstPort DstPort
The UDP/TCP destination port for the session. Zero may be The UDP/TCP destination port for the session. Zero may be
used to indicate `none'. used to indicate `none'.
Other SESSION C-Types could be defined in the future to Other SESSION C-Types could be defined in the future to
support other demultiplexing conventions in the transport- support other demultiplexing conventions in the transport-
layer or application layer. layer or application layer.
A.2 RSVP_HOP Class A.2 RSVP_HOP Class
skipping to change at page 108, line 16 skipping to change at page 109, line 16
cccc cccc cccc: 12 bit code. cccc cccc cccc: 12 bit code.
The following globally-defined sub-codes may appear in the low- The following globally-defined sub-codes may appear in the low-
order 12 bits when ssur = 0000: order 12 bits when ssur = 0000:
- Sub-code = 1: Delay bound cannot be met - Sub-code = 1: Delay bound cannot be met
- Sub-code = 2: Requested bandwidth unavailable - Sub-code = 2: Requested bandwidth unavailable
- Sub-code = 3: MTU in flowspec larger than interface MTU.
o Error Code = 02: Policy Control failure o Error Code = 02: Policy Control failure
Reservation or path message has been rejected for administrative Reservation or path message has been rejected for administrative
reasons, for example, required credentials not submitted, reasons, for example, required credentials not submitted,
insufficient quota or balance, or administrative preemption. insufficient quota or balance, or administrative preemption.
This Error Code may appear in a PathErr or ResvErr message. This Error Code may appear in a PathErr or ResvErr message.
Contents of the Error Value field are to be determined in the Contents of the Error Value field are to be determined in the
future. future.
skipping to change at page 114, line 10 skipping to change at page 115, line 10
o D is the DestAddress for the particular session. o D is the DestAddress for the particular session.
o G* is a well-known group address of the form 224.0.0.14, i.e., a o G* is a well-known group address of the form 224.0.0.14, i.e., a
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 Tr is the TTL value of the specific Path message.
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 [RA] indicates that the Router Alert option is sent.
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,Tr)[RA] Raw() Hr Raw(D)[RA] 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,Tr)[RA] Raw() Raw(D)[RA] 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 Unicast Encapsulation Rules for Path 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)[RA] 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)[RA] 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 Multicast Encapsulation Rules for Path Messages Figure 14: UDP Encapsulation Rules for Multicast Path Messages
[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.
[Note 3] This assumes that the application has joined the group D. [Note 3] This assumes that the application has joined the group D.
skipping to change at page 116, line 39 skipping to change at page 117, line 39
[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., O'Malley, T., and R. Atkinson, "RSVP Extensions [IPSEC96] Berger, L., O'Malley, T., and R. Atkinson, "RSVP Extensions
for IPSEC IPv4 Data Flows", Work in Progress, 1996. for IPSEC IPv4 Data Flows", Internet Draft, <draft-ietf-rsvp-ext-
04.txt>, Integrated Services Working Group, June 1996.
[Katz95] Katz, D., "IP Router Alert Option", Work in Progress, November [Katz95] Katz, D., "IP Router Alert Option", Work in Progress, November
1995. 1995.
[ISdata95] Wroclawski, J., "Standard Data Encoding for Integrated [ISdata96] Wroclawski, J., "Data Element Naming and Encoding for
Services Objects", Work in Progress, November 1995. Integrated Services Messages", <draft-ietf-intserv-data-encoding-
02.txt>, Integrated Services Working Group, July 1996.
[RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. [ISrsvp] Wroclawski, J., "The Use of RSVP with Integrated Services",
Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network, <draft-ietf-intserv-rsvp-use.00.txt>, Integrated Services Working
September 1993. Group, July 1996.
[ServTempl95] Shenker, S., "Network Element Service Specification [ISTempl96] Shenker, S. and J. Wroclawski, "Network Element QoS Control
Template", Work in Progress, Integrated Services Working Group, Service Specification Template", <draft-ietf-intserv-serv-template-
November 1995. 03.txt>, Integrated Services Working Group, July 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.
Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network,
September 1993.
Security Considerations Security Considerations
See Section 2.8. 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
 End of changes. 

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