draft-ietf-rsvp-spec-09.txt   draft-ietf-rsvp-spec-10.txt 
Internet Draft R. Braden, Ed. Internet Draft R. Braden, Ed.
Expiration: August 1996 ISI Expiration: August 1996 ISI
File: draft-ietf-rsvp-spec-09.txt L. Zhang File: draft-ietf-rsvp-spec-10.txt L. Zhang
PARC PARC
S. Berson S. Berson
ISI ISI
S. Herzog S. Herzog
ISI ISI
S. Jamin S. Jamin
USC USC
Resource ReSerVation Protocol (RSVP) -- Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification Version 1 Functional Specification
February 12, 1996 February 21, 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
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
linebreak "1id-abstracts.txt" listing contained in the Internet- "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
Drafts Shadow Directories on ds.internic.net (US East Coast), Directories on ds.internic.net (US East Coast), nic.nordu.net
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
(Pacific Rim). Rim).
Abstract Abstract
This memo describes version 1 of RSVP, a resource reservation setup This memo describes version 1 of RSVP, a resource reservation setup
protocol designed for an integrated services Internet. RSVP provides protocol designed for an integrated services Internet. RSVP provides
receiver-initiated setup of resource reservations for multicast or receiver-initiated setup of resource reservations for multicast or
unicast data flows, with good scaling and robustness properties. unicast data flows, with good scaling and robustness properties.
Table of Contents Table of Contents
1. Introduction ........................................................4 1. Introduction ........................................................5
1.1 Data Flows ......................................................7 1.1 Data Flows ......................................................8
1.2 Reservation Model ...............................................8 1.2 Reservation Model ...............................................9
1.3 Reservation Styles ..............................................10 1.3 Reservation Styles ..............................................11
1.4 Examples of Styles ..............................................13 1.4 Examples of Styles ..............................................14
2. RSVP Protocol Mechanisms ............................................18 2. RSVP Protocol Mechanisms ............................................19
2.1 RSVP Messages ...................................................18 2.1 RSVP Messages ...................................................19
2.2 Port Usage ......................................................20 2.2 Port Usage ......................................................21
2.3 Merging Flowspecs ...............................................21 2.3 Merging Flowspecs ...............................................22
2.4 Soft State ......................................................22 2.4 Soft State ......................................................23
2.5 Teardown ........................................................24 2.5 Teardown ........................................................25
2.6 Errors ..........................................................25 2.6 Errors ..........................................................26
2.7 Confirmation ....................................................27 2.7 Confirmation ....................................................28
2.8 Policy and Security .............................................27 2.8 Policy and Security .............................................28
2.9 Automatic RSVP Tunneling ........................................28 2.9 Automatic RSVP Tunneling ........................................29
2.10 Host Model .....................................................29 2.10 Host Model .....................................................30
3. RSVP Functional Specification .......................................31 3. RSVP Functional Specification .......................................32
3.1 RSVP Message Formats ............................................31 3.1 RSVP Message Formats ............................................32
3.2 Sending RSVP Messages ...........................................44 3.2 Sending RSVP Messages ...........................................45
3.3 Avoiding RSVP Message Loops .....................................45 3.3 Avoiding RSVP Message Loops .....................................47
3.4 Blockade State ..................................................49 3.4 Blockade State ..................................................50
3.5 Local Repair ....................................................51 3.5 Local Repair ....................................................52
3.6 Time Parameters .................................................52 3.6 Time Parameters .................................................53
3.7 Traffic Policing and Non-Integrated Service Hops ................53 3.7 Traffic Policing and Non-Integrated Service Hops ................54
3.8 Multihomed Hosts ................................................54 3.8 Multihomed Hosts ................................................56
3.9 Future Compatibility ............................................56 3.9 Future Compatibility ............................................57
3.10 RSVP Interfaces ................................................58 3.10 RSVP Interfaces ................................................59
4. Message Processing Rules ............................................70 4. Message Processing Rules ............................................71
5. Acknowledgments .....................................................89 5. Acknowledgments .....................................................90
APPENDIX A. Object Definitions .........................................90 APPENDIX A. Object Definitions .........................................91
APPENDIX B. Error Codes and Values .....................................106 APPENDIX B. Error Codes and Values .....................................107
APPENDIX C. UDP Encapsulation ..........................................111 APPENDIX C. UDP Encapsulation ..........................................112
What's Changed What's Changed
The most important changes in this document from the rsvp-spec-08 draft The most important changes in this document from the rsvp-spec-09
are: draft are:
o Multiple POLICY_DATA objects in any order are now allowed.
o The length field in the common header is now the total
message length [Section 3.1.1].
o The meaning of Message Id is refined and more completely
specified [Section 3.1.1].
o RSVP fragmentation is specifically called for, and IP
fragmentation disallowed [Section 3.1.1].
o The granularity of state timeouts is now specified [Section
3.6].
The most important changes in this document from the rsvp-spec-08
draft are:
o The handling of reservation errors has been fundamentally o The handling of reservation errors has been fundamentally
changed, to prevent the "second killer reservation problem". changed, to prevent the "second killer reservation problem".
A new kind of state has been introduced into a node, A new kind of state has been introduced into a node,
"blockade state", which is created by a RERR message with "blockade state", which is created by a ResvErr message with
Error Code = 01, and which controls the merging process for Error Code = 01, and which controls the merging process for
generating reservation refresh messages [Sections 2.6 and generating reservation refresh messages [Sections 2.6 and
3.4]. 3.4].
o RSVP now carries two flag bits in the SESSION object to o RSVP now carries two flag bits in the SESSION object to
indicate to a receiver whether there are non-RSVP-capable indicate to a receiver whether there are non-RSVP-capable
nodes along the path to a given sender [Sections 2.9 and nodes along the path to a given sender [Sections 2.9 and
3.7]. 3.7].
o The optional INTEGRITY object is now specified to immediately o The optional INTEGRITY object is now specified to immediately
skipping to change at page 12, line 35 skipping to change at page 13, line 35
o Shared Explicit (SE) Style o Shared Explicit (SE) Style
The SE style implies the options: "shared" reservation and " The SE style implies the options: "shared" reservation and "
explicit" sender selection. Thus, an SE-style reservation explicit" sender selection. Thus, an SE-style reservation
creates a single reservation into which flows from all creates a single reservation into which flows from all
upstream senders are mixed. However, like the FF style, the upstream senders are mixed. However, like the FF style, the
SE style allows a receiver to explicitly specify the set of SE style allows a receiver to explicitly specify the set of
senders. senders.
Symbolically, we can represent an SE reservation request by: We can represent an SE reservation request containing a
flowspec Q and a list of senders S1, S2, ... by:
SE( (S1,S2,...){Q} ),
i.e., a flow descriptor composed of a flowspec Q and a list SE( (S1,S2,...){Q} )
of senders S1, S2, etc.
Both WF and SE styles create shared reservations, appropriate for Both WF and SE styles create shared reservations, appropriate for
those multicast applications whose properties make it unlikely those multicast applications whose properties make it unlikely
that multiple data sources will transmit simultaneously. that multiple data sources will transmit simultaneously.
Packetized audio is an example of an application suitable for Packetized audio is an example of an application suitable for
shared reservations; since a limited number of people talk at shared reservations; since a limited number of people talk at
once, each receiver might issue a WF or SE reservation request for once, each receiver might issue a WF or SE reservation request for
twice the bandwidth required for one sender (to allow some over- twice the bandwidth required for one sender (to allow some over-
speaking). On the other hand, the FF style, which creates speaking). On the other hand, the FF style, which creates
independent reservations for the flows from different senders, is independent reservations for the flows from different senders, is
skipping to change at page 18, line 41 skipping to change at page 19, line 41
"incoming interface" and departs through one or more "outgoing "incoming interface" and departs through one or more "outgoing
interface"(s). The same physical interface may act in both the interface"(s). The same physical interface may act in both the
incoming and outgoing roles for different data flows in the same incoming and outgoing roles for different data flows in the same
session. Multiple previous hops and/or next hops may be reached session. Multiple previous hops and/or next hops may be reached
through a given physical interface, as a result of the connected through a given physical interface, as a result of the connected
network being a shared medium, or the existence of non-RSVP network being a shared medium, or the existence of non-RSVP
routers in the path to the next RSVP hop (see Section 2.9). An routers in the path to the next RSVP hop (see Section 2.9). An
RSVP daemon preserves the next and previous hop addresses in its RSVP daemon preserves the next and previous hop addresses in its
reservation and path state, respectively. reservation and path state, respectively.
There are two fundamental RSVP message types: RESV and PATH. There are two fundamental RSVP message types: Resv and Path.
Each receiver host sends RSVP reservation request (RESV) messages Each receiver host sends RSVP reservation request (Resv) messages
upstream towards the senders. These reservation messages must upstream towards the senders. These reservation messages must
follow exactly the reverse of the routes the data packets will follow exactly the reverse of the routes the data packets will
use, upstream to all the sender hosts included in the sender use, upstream to all the sender hosts included in the sender
selection. RESV messages are delivered to the sender hosts selection. Resv messages are delivered to the sender hosts
themselves so that the hosts can set up appropriate traffic themselves so that the hosts can set up appropriate traffic
control parameters for the first hop. control parameters for the first hop.
Each RSVP sender host transmits RSVP PATH messages downstream Each RSVP sender host transmits RSVP Path messages downstream
along the uni-/multicast routes provided by the routing along the uni-/multicast routes provided by the routing
protocol(s), following the paths of the data. These "Path" protocol(s), following the paths of the data. These "Path"
messages store "path state" in each node along the way. This path messages store "path state" in each node along the way. This path
state includes at least the unicast IP address of the previous hop state includes at least the unicast IP address of the previous hop
node, which is used to route the RESV messages hop-by-hop in the node, which is used to route the Resv messages hop-by-hop in the
reverse direction. (In the future, some routing protocols may reverse direction. (In the future, some routing protocols may
supply reverse path forwarding information directly, replacing the supply reverse path forwarding information directly, replacing the
reverse-routing function of path state). reverse-routing function of path state).
A PATH message may carry the following information in addition to A Path message may carry the following information in addition to
the previous hop address: the previous hop address:
o Sender Template o Sender Template
A PATH message is required to carry a Sender Template, which A Path message is required to carry a Sender Template, which
describes the format of data packets that the sender will describes the format of data packets that the sender will
originate. This template is in the form of a filter spec originate. This template is in the form of a filter spec
that could be used to select this sender's packets from that could be used to select this sender's packets from
others in the same session on the same link. others in the same session on the same link.
Like a filter spec, the Sender Template is less than fully Like a filter spec, the Sender Template is less than fully
general at present, specifying only the sender IP address and general at present, specifying only the sender IP address and
optionally the UDP/TCP sender port. It assumes the protocol optionally the UDP/TCP sender port. It assumes the protocol
Id specified for the session. Id specified for the session.
o Sender Tspec o Sender Tspec
A PATH message is required to carry a Sender Tspec, which A Path message is required to carry a Sender Tspec, which
defines the traffic characteristics of the data stream that defines the traffic characteristics of the data stream that
the sender will generate. This Tspec is used by traffic the sender will generate. This Tspec is used by traffic
control to prevent over-reservation (and perhaps unnecessary control to prevent over-reservation (and perhaps unnecessary
Admission Control failure) on upstream links. Admission Control failure) on upstream links.
o Adspec o Adspec
A PATH message may optionally carry a package of OPWA A Path message may optionally carry a package of OPWA
advertising information, known as an "Adspec". An Adspec advertising information, known as an "Adspec". An Adspec
received in a PATH message is passed to the local traffic received in a Path message is passed to the local traffic
control, which returns an updated Adspec; the updated version control, which returns an updated Adspec; the updated version
is then forwarded in PATH messages sent downstream. is then forwarded in Path messages sent downstream.
PATH messages are sent with the same source and destination Path messages are sent with the same source and destination
addresses as the data, so that they will be routed correctly addresses as the data, so that they will be routed correctly
through non-RSVP clouds (see Section 2.9). On the other hand, through non-RSVP clouds (see Section 2.9). On the other hand,
RESV messages are sent hop-by-hop; each RSVP-speaking node Resv messages are sent hop-by-hop; each RSVP-speaking node
forwards a RESV message to the unicast address of a previous RSVP forwards a Resv message to the unicast address of a previous RSVP
hop. hop.
2.2 Port Usage 2.2 Port Usage
At present an RSVP session is defined by the triple: (DestAddress, At present an RSVP session is defined by the triple: (DestAddress,
ProtocolId, DstPort). Here DstPort is a UDP/TCP destination port ProtocolId, DstPort). Here DstPort is a UDP/TCP destination port
field (i.e., a 16-bit quantity carried at octet offset +2 in the field (i.e., a 16-bit quantity carried at octet offset +2 in the
transport header). DstPort may be omitted (set to zero) if the transport header). DstPort may be omitted (set to zero) if the
ProtocolId specifies a protocol that does not have a destination ProtocolId specifies a protocol that does not have a destination
port field in the format used by UDP and TCP. port field in the format used by UDP and TCP.
skipping to change at page 21, line 13 skipping to change at page 22, line 13
a zero SrcPort. Violation of this condition is an "Ambiguous a zero SrcPort. Violation of this condition is an "Ambiguous
Path" error. Path" error.
2.3 Merging Flowspecs 2.3 Merging Flowspecs
As noted earlier, a single physical interface may receive multiple As noted earlier, a single physical interface may receive multiple
reservation requests from different next hops for the same session reservation requests from different next hops for the same session
and with the same filter spec, but RSVP should install only one and with the same filter spec, but RSVP should install only one
reservation on that interface. The installed reservation should reservation on that interface. The installed reservation should
have an effective flowspec that is the "largest" of the flowspecs have an effective flowspec that is the "largest" of the flowspecs
requested by the different next hops. Similarly, a RESV message requested by the different next hops. Similarly, a Resv message
forwarded to a previous hop should carry a flowspec that is the forwarded to a previous hop should carry a flowspec that is the
"largest" of the flowspecs requested by the different next hops "largest" of the flowspecs requested by the different next hops
(however, in certain cases the "smallest" is taken rather than the (however, in certain cases the "smallest" is taken rather than the
largest, see Section 3.4). These cases all represent flowspec largest, see Section 3.4). These cases all represent flowspec
merging. merging.
Flowspec merging requires calculation of the "largest" of a set of Flowspec merging requires calculation of the "largest" of a set of
flowspecs. However, since flowspecs are generally multi- flowspecs. However, since flowspecs are generally multi-
dimensional vectors (they may contain both Tspec and Rspec dimensional vectors (they may contain both Tspec and Rspec
components, each of which may itself be multi-dimensional), it may components, each of which may itself be multi-dimensional), it may
skipping to change at page 21, line 45 skipping to change at page 22, line 45
parameters. In several cases, the GLB (Greatest Lower Bound) is parameters. In several cases, the GLB (Greatest Lower Bound) is
used instead of the LUB; this simply interchanges max and min used instead of the LUB; this simply interchanges max and min
operations. operations.
We can now give the complete rules for calculating the effective We can now give the complete rules for calculating the effective
flowspec (Te, Re) to be installed on an interface. Here Te is the flowspec (Te, Re) to be installed on an interface. Here Te is the
effective Tspec and Re is the effective Rspec. As an example, effective Tspec and Re is the effective Rspec. As an example,
consider interface (d) in Figure 9. consider interface (d) in Figure 9.
1. Re is calculated as the largest (using an LUB if necessary) 1. Re is calculated as the largest (using an LUB if necessary)
of the Rspecs in RESV messages from different next hops of the Rspecs in Resv messages from different next hops
(e.g., D and D') but the same outgoing interface (d). (e.g., D and D') but the same outgoing interface (d).
2. All Tspecs that were supplied in PATH messages from different 2. All Tspecs that were supplied in Path messages from different
previous hops (e.g., some or all of A, B, and B' in Figure 9) previous hops (e.g., some or all of A, B, and B' in Figure 9)
are summed; call this sum Path_Te. are summed; call this sum Path_Te.
3. The maximum Tspec supplied in RESV messages from different 3. The maximum Tspec supplied in Resv messages from different
next hops (e.g., D and D') is calculated; call this Resv_Te. next hops (e.g., D and D') is calculated; call this Resv_Te.
4. Te is the GLB (greatest lower bound) of Path_Te and Resv_Te. 4. Te is the GLB (greatest lower bound) of Path_Te and Resv_Te.
Flowspecs, Tspecs, and Adspecs are opaque to RSVP. Therefore, the Flowspecs, Tspecs, and Adspecs are opaque to RSVP. Therefore, the
last of these steps is actually performed by traffic control. The last of these steps is actually performed by traffic control. The
definition and implementation of the rules for comparing definition and implementation of the rules for comparing
flowspecs, calculating LUBs and GLBs, and summing Tspecs are flowspecs, calculating LUBs and GLBs, and summing Tspecs are
outside the definition of RSVP [ServTempl95a]. Section 3.10.4 outside the definition of RSVP [ServTempl95a]. Section 3.10.4
shows generic calls that an RSVP daemon could use for these shows generic calls that an RSVP daemon could use for these
functions. functions.
2.4 Soft State 2.4 Soft State
RSVP takes a "soft state" approach to managing the reservation RSVP takes a "soft state" approach to managing the reservation
state in routers and hosts. RSVP soft state is created and state in routers and hosts. RSVP soft state is created and
periodically refreshed by PATH and RESV messages. The state is periodically refreshed by Path and Resv messages. The state is
deleted if no matching refresh messages arrive before the deleted if no matching refresh messages arrive before the
expiration of a "cleanup timeout" interval. State may also be expiration of a "cleanup timeout" interval. State may also be
deleted by an explicit "teardown" message, described in the next deleted by an explicit "teardown" message, described in the next
section. At the expiration of each "refresh timeout" period and section. At the expiration of each "refresh timeout" period and
after a state change, RSVP scans its state to build and forward after a state change, RSVP scans its state to build and forward
PATH and RESV refresh messages to succeeding hops. Path and Resv refresh messages to succeeding hops.
PATH and RESV messages are idempotent. When a route changes, the Path and Resv messages are idempotent. When a route changes, the
next PATH message will initialize the path state on the new route, next Path message will initialize the path state on the new route,
and future RESV messages will establish reservation state there; and future Resv messages will establish reservation state there;
the state on the now-unused segment of the route will time out. the state on the now-unused segment of the route will time out.
Thus, whether a message is "new" or a "refresh" is determined Thus, whether a message is "new" or a "refresh" is determined
separately at each node, depending upon the existing state at that separately at each node, depending upon the existing state at that
node. node.
RSVP sends its messages as IP datagrams with no reliability RSVP sends its messages as IP datagrams with no reliability
enhancement. Periodic transmission of refresh messages by hosts enhancement. Periodic transmission of refresh messages by hosts
and routers is expected to handle the occasional loss of an RSVP and routers is expected to handle the occasional loss of an RSVP
message. If the effective cleanup timeout is set to K times the message. If the effective cleanup timeout is set to K times the
refresh timeout period, then RSVP can tolerate K-1 successive RSVP refresh timeout period, then RSVP can tolerate K-1 successive RSVP
packet losses without falsely erasing a reservation. We recommend packet losses without falsely erasing a reservation. We recommend
that the network traffic control mechanism be statically that the network traffic control mechanism be statically
configured to grant some minimal bandwidth for RSVP messages to configured to grant some minimal bandwidth for RSVP messages to
protect them from congestion losses. protect them from congestion losses.
The state maintained by RSVP is dynamic; to change the set of The state maintained by RSVP is dynamic; to change the set of
senders Si or to change any QoS request, a host simply starts senders Si or to change any QoS request, a host simply starts
sending revised PATH and/or RESV messages. The result will be an sending revised Path and/or Resv messages. The result will be an
appropriate adjustment in the RSVP state in all nodes along the appropriate adjustment in the RSVP state in all nodes along the
path. path.
In steady state, refreshing is performed hop-by-hop, to allow In steady state, refreshing is performed hop-by-hop, to allow
merging. When the received state differs from the stored state, merging. When the received state differs from the stored state,
the stored state is updated. If this update results in the stored state is updated. If this update results in
modification of state to be forwarded in refresh messages, these modification of state to be forwarded in refresh messages, these
refresh messages must be generated and forwarded immediately, so refresh messages must be generated and forwarded immediately, so
that state changes can be propagated end-to-end without delay. that state changes can be propagated end-to-end without delay.
However, propagation of a change stops when and if it reaches a However, propagation of a change stops when and if it reaches a
skipping to change at page 23, line 25 skipping to change at page 24, line 25
State that is received through a particular interface I* should State that is received through a particular interface I* should
never be forwarded out the same interface. Conversely, state that never be forwarded out the same interface. Conversely, state that
is forwarded out interface I* must be computed using only state is forwarded out interface I* must be computed using only state
that arrived on interfaces different from I*. A trivial example that arrived on interfaces different from I*. A trivial example
of this rule is illustrated in Figure 10, which shows a transit of this rule is illustrated in Figure 10, which shows a transit
router with one sender and one receiver on each interface (and router with one sender and one receiver on each interface (and
assumes one next/previous hop per interface). Interfaces (a) and assumes one next/previous hop per interface). Interfaces (a) and
(c) serve as both outgoing and incoming interfaces for this (c) serve as both outgoing and incoming interfaces for this
session. Both receivers are making wildcard-scope reservations, session. Both receivers are making wildcard-scope reservations,
in which the RESV messages are forwarded to all previous hops for in which the Resv messages are forwarded to all previous hops for
senders in the group, with the exception of the next hop from senders in the group, with the exception of the next hop from
which they came. The result is independent reservations in the which they came. The result is independent reservations in the
two directions. two directions.
There is an additional rule governing the forwarding of RESV There is an additional rule governing the forwarding of Resv
messages: state from RESV messages received from outgoing messages: state from RESV messages received from outgoing
interface Io should be forwarded to incoming interface Ii only if interface Io should be forwarded to incoming interface Ii only if
PATH messages from Ii are forwarded to Io. Path messages from Ii are forwarded to Io.
________________ ________________
a | | c a | | c
( R1, S1 ) <----->| Router |<-----> ( R2, S2 ) ( R1, S1 ) <----->| Router |<-----> ( R2, S2 )
|________________| |________________|
Send | Receive Send | Receive
| |
WF( *{3B}) <-- (a) | (c) <-- WF( *{3B}) WF( *{3B}) <-- (a) | (c) <-- WF( *{3B})
| |
skipping to change at page 24, line 33 skipping to change at page 25, line 33
Figure 10: Independent Reservations Figure 10: Independent Reservations
2.5 Teardown 2.5 Teardown
Upon arrival, RSVP "teardown" messages remove path and reservation Upon arrival, RSVP "teardown" messages remove path and reservation
state immediately. Although it is not necessary to explicitly state immediately. Although it is not necessary to explicitly
tear down an old reservation, we recommend that all end hosts send tear down an old reservation, we recommend that all end hosts send
a teardown request as soon as an application finishes. a teardown request as soon as an application finishes.
There are two types of RSVP teardown message, PTEAR and RTEAR. A There are two types of RSVP teardown message, PathTear and
PTEAR message travels towards all receivers downstream from its ResvTear. A PathTear message travels towards all receivers
point of initiation and deletes path state, as well as all downstream from its point of initiation and deletes path state, as
dependent reservation state, along the way. An RTEAR message well as all dependent reservation state, along the way. An
deletes reservation state and travels towards all senders upstream ResvTear message deletes reservation state and travels towards all
from its point of initiation. A PTEAR (RTEAR) message may be senders upstream from its point of initiation. A PathTear
conceptualized as a reversed-sense Path message (Resv message, (ResvTear) message may be conceptualized as a reversed-sense Path
respectively). message (Resv message, respectively).
A teardown request may be initiated either by an application in an A teardown request may be initiated either by an application in an
end system (sender or receiver), or by a router as the result of end system (sender or receiver), or by a router as the result of
state timeout. Once initiated, a teardown request must be state timeout. Once initiated, a teardown request must be
forwarded hop-by-hop without delay. A teardown message deletes forwarded hop-by-hop without delay. A teardown message deletes
the specified state in the node where it is received. As always, the specified state in the node where it is received. As always,
this state change will be propagated immediately to the next node, this state change will be propagated immediately to the next node,
but only if there will be a net change after merging. As a but only if there will be a net change after merging. As a
result, an RTEAR message will prune the reservation state back result, an ResvTear message will prune the reservation state back
(only) as far as possible. (only) as far as possible.
Like all other RSVP messages, teardown requests are not delivered Like all other RSVP messages, teardown requests are not delivered
reliably. The loss of a teardown request message will not cause a reliably. The loss of a teardown request message will not cause a
protocol failure because the unused state will eventually time out protocol failure because the unused state will eventually time out
even though it is not explicitly deleted. If a teardown message even though it is not explicitly deleted. If a teardown message
is lost, the router that failed to receive that message will time is lost, the router that failed to receive that message will time
out its state and initiate a new teardown message beyond the loss out its state and initiate a new teardown message beyond the loss
point. Assuming that RSVP message loss probability is small, the point. Assuming that RSVP message loss probability is small, the
longest time to delete state will seldom exceed one refresh longest time to delete state will seldom exceed one refresh
timeout period. timeout period.
2.6 Errors 2.6 Errors
There are two RSVP error messages, RERR and PERR. PERR messages There are two RSVP error messages, ResvErr and PathErr. PERR
are very simple. They are simply sent upstream to the sender that messages are very simple. They are simply sent upstream to the
created the error, and they do not change path state in the nodes sender that created the error, and they do not change path state
though which they pass. There are only a few possible causes of in the nodes though which they pass. There are only a few
path errors. possible causes of path errors.
However, there are a number of ways for a syntactically valid However, there are a number of ways for a syntactically valid
reservation request to fail at some node along the path, for reservation request to fail at some node along the path, for
example: example:
1. The effective flowspec that is computed using the new request 1. The effective flowspec that is computed using the new request
may fail admission control. may fail admission control.
2. Administrative policy may prevent the requested reservation. 2. Administrative policy may prevent the requested reservation.
skipping to change at page 25, line 48 skipping to change at page 26, line 48
the use of wildcard fields in the filter spec. the use of wildcard fields in the filter spec.
5. The requested style may be incompatible with the style(s) of 5. The requested style may be incompatible with the style(s) of
existing reservations. The incompatibility may occur among existing reservations. The incompatibility may occur among
reservations for the same session on the same outgoing reservations for the same session on the same outgoing
interface, or among effective reservations on different interface, or among effective reservations on different
outgoing interfaces. outgoing interfaces.
A node may also decide to preempt an established reservation. A node may also decide to preempt an established reservation.
The handling of RERR messages is somewhat complex (Section 3.4). The handling of ResvErr messages is somewhat complex (Section
Since a request that fails may be the result of merging a number 3.4). Since a request that fails may be the result of merging a
of requests, a reservation error must be reported to all of the number of requests, a reservation error must be reported to all of
responsible receivers. In addition, merging heterogeneous the responsible receivers. In addition, merging heterogeneous
requests creates a potential difficulty known as the "killer requests creates a potential difficulty known as the "killer
reservation" problem, in which one request could deny service to reservation" problem, in which one request could deny service to
another. There are actually two killer-reservation problems. another. There are actually two killer-reservation problems.
1. The first killer reservation problem (KR-I) arises when there 1. The first killer reservation problem (KR-I) arises when there
is already a reservation Q0 in place. If another receiver is already a reservation Q0 in place. If another receiver
now makes a larger reservation Q1 > Q0, the result of merging now makes a larger reservation Q1 > Q0, the result of merging
Q0 and Q1 may be rejected by admission control in some Q0 and Q1 may be rejected by admission control in some
upstream node. This must not deny service to Q0. upstream node. This must not deny service to Q0.
The solution to this problem is simple: when admission The solution to this problem is simple: when admission
control fails for a reservation request, any existing control fails for a reservation request, any existing
reservation is left in place. reservation is left in place.
2. The second killer reservation problem (KR-II) is the 2. The second killer reservation problem (KR-II) is the
converse: the receiver making a reservation Q1 is persistent converse: the receiver making a reservation Q1 is persistent
even though Admission Control is failing for Q1 in some node. even though Admission Control is failing for Q1 in some node.
This must not prevent a different receiver from now This must not prevent a different receiver from now
establishing a smaller reservation Q0 that will succeed. establishing a smaller reservation Q0 that will succeed.
To solve this problem, a RERR message establishes additional To solve this problem, a ResvErr message establishes
state, called "blockade state", in each node through which it additional state, called "blockade state", in each node
passes. Blockade state in a node modifies the merging through which it passes. Blockade state in a node modifies
procedure to omit the offending flowspec (Q1 in the example) the merging procedure to omit the offending flowspec (Q1 in
from the merge, allowing a smaller request to be forwarded the example) from the merge, allowing a smaller request to be
and established. The Q1 reservation state is said to be forwarded and established. The Q1 reservation state is said
"blockaded". Detailed rules are presented in Section 3.4. to be "blockaded". Detailed rules are presented in Section
3.4.
A reservation request that fails Admission Control creates A reservation request that fails Admission Control creates
blockade state but is left in place in nodes downstream of the blockade state but is left in place in nodes downstream of the
failure point. It has been suggested that these reservations failure point. It has been suggested that these reservations
downstream from the failure represent "wasted" reservations and downstream from the failure represent "wasted" reservations and
should be timed out if not actively deleted. However, in general should be timed out if not actively deleted. However, in general
the downstream reservations will not be "wasted". the downstream reservations will not be "wasted".
o There are two possible reasons for a receiver persisting in a o There are two possible reasons for a receiver persisting in a
failed reservation: (1) it is polling for resource failed reservation: (1) it is polling for resource
skipping to change at page 27, line 13 skipping to change at page 28, line 15
The blockade state in each downstream router must not remove The blockade state in each downstream router must not remove
the state or prevent its immediate refresh. the state or prevent its immediate refresh.
o If we did not refresh the downstream reservations, they might o If we did not refresh the downstream reservations, they might
time out, to be restored every Td seconds. Such on/off time out, to be restored every Td seconds. Such on/off
behavior might be very distressing for users. behavior might be very distressing for users.
2.7 Confirmation 2.7 Confirmation
To request a confirmation for its reservation request, a receiver To request a confirmation for its reservation request, a receiver
Rj includes in the RESV message a confirmation-request object Rj includes in the Resv message a confirmation-request object
containing Rj's IP address. At each merge point, only the largest containing Rj's IP address. At each merge point, only the largest
flowspec and any accompanying confirmation-request object is flowspec and any accompanying confirmation-request object is
forwarded upstream. If the reservation request from Rj is equal forwarded upstream. If the reservation request from Rj is equal
to or smaller than the reservation in place on a node, its RESV to or smaller than the reservation in place on a node, its Resv
are not forwarded further, and if the RESV included a are not forwarded further, and if the Resv included a
confirmation-request object, a RACK message is sent back to Rj. confirmation-request object, a ResvConf message is sent back to
This mechanism has the following consequences: Rj. This mechanism has the following consequences:
o A new reservation request with a flowspec larger than any in o A new reservation request with a flowspec larger than any in
place for a session will normally result in either a RERR or place for a session will normally result in either a ResvErr
a RACK message back to the receiver from each sender. In or a ResvConf message back to the receiver from each sender.
this case, the RACK 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 RACK gives no guarantees. Assume the first o The receipt of a ResvConf gives no guarantees. Assume the
two reservation requests from receivers R1 and R2 arrive at first two reservation requests from receivers R1 and R2
the node where they are merged. R2, whose reservation was arrive at the node where they are merged. R2, whose
the second to arrive at that node, may receive a RACK from reservation was the second to arrive at that node, may
that node while R1's request has not yet propagated all the receive a ResvConf from that node while R1's request has not
way to a matching sender and may still fail. Thus, R2 may yet propagated all the way to a matching sender and may still
receive a RACK although there is no end-to-end reservation in fail. Thus, R2 may receive a ResvConf although there is no
place; furthermore, R2 may receive a RACK followed by a RERR. end-to-end reservation in place; furthermore, R2 may receive
a ResvConf followed by a ResvErr.
2.8 Policy and Security 2.8 Policy and Security
RSVP-mediated QoS requests will result in particular user(s) RSVP-mediated QoS requests will result in particular user(s)
getting preferential access to network resources. To prevent getting preferential access to network resources. To prevent
abuse, some form of back pressure on users is likely to be abuse, some form of back pressure on users is likely to be
required. This back pressure might take the form of required. This back pressure might take the form of
administrative rules, or of some form of real or virtual billing administrative rules, or of some form of real or virtual billing
for the "cost" of a reservation. The form and contents of such for the "cost" of a reservation. The form and contents of such
back pressure is a matter of administrative policy that may be back pressure is a matter of administrative policy that may be
skipping to change at page 29, line 7 skipping to change at page 30, line 8
It is impossible to deploy RSVP (or any new protocol) at the same It is impossible to deploy RSVP (or any new protocol) at the same
moment throughout the entire Internet. Furthermore, RSVP may moment throughout the entire Internet. Furthermore, RSVP may
never be deployed everywhere. RSVP must therefore provide correct never be deployed everywhere. RSVP must therefore provide correct
protocol operation even when two RSVP-capable routers are joined protocol operation even when two RSVP-capable routers are joined
by an arbitrary "cloud" of non-RSVP routers. Of course, an by an arbitrary "cloud" of non-RSVP routers. Of course, an
intermediate cloud that does not support RSVP is unable to perform intermediate cloud that does not support RSVP is unable to perform
resource reservation. However, if such a cloud has sufficient resource reservation. However, if such a cloud has sufficient
capacity, it may still provide acceptable realtime service. capacity, it may still provide acceptable realtime service.
RSVP automatically tunnels through such a non-RSVP cloud. Both RSVP automatically tunnels through such a non-RSVP cloud. Both
RSVP and non-RSVP routers forward PATH messages towards the RSVP and non-RSVP routers forward Path messages towards the
destination address using their local uni-/multicast routing destination address using their local uni-/multicast routing
table. Therefore, the routing of PATH messages will be unaffected table. Therefore, the routing of Path messages will be unaffected
by non-RSVP routers in the path. When a PATH message traverses a by non-RSVP routers in the path. When a Path message traverses a
non-RSVP cloud, it carries to the next RSVP-capable node the IP non-RSVP cloud, it carries to the next RSVP-capable node the IP
address of the last RSVP-capable router before entering the cloud. address of the last RSVP-capable router before entering the cloud.
This effectively constructs a tunnel through the cloud for RESV This effectively constructs a tunnel through the cloud for Resv
messages, which can then be forwarded directly to the next RSVP- messages, which can then be forwarded directly to the next RSVP-
capable router on the path(s) back towards the source. capable router on the path(s) back towards the source.
Even though RSVP operates correctly through a non-RSVP cloud, the Even though RSVP operates correctly through a non-RSVP cloud, the
non-RSVP-capable nodes will in general perturb the QoS provided to non-RSVP-capable nodes will in general perturb the QoS provided to
a receiver. Therefore, RSVP tries to inform the receiver when a receiver. Therefore, RSVP tries to inform the receiver when
there are non-RSVP-capable hops in the path to a given sender, by there are non-RSVP-capable hops in the path to a given sender, by
means of two flag bits in the SESSION object of a PATH message; means of two flag bits in the SESSION object of a Path message;
see Section 3.7 and Appendix A. see Section 3.7 and Appendix A.
Some topologies of RSVP routers and non-RSVP routers can cause Some topologies of RSVP routers and non-RSVP routers can cause
RESV messages to arrive at the wrong RSVP-capable node, or to Resv messages to arrive at the wrong RSVP-capable node, or to
arrive at the wrong interface of the correct node. An RSVP daemon arrive at the wrong interface of the correct node. An RSVP daemon
must be prepared to handle either situation. If the destination must be prepared to handle either situation. If the destination
address does not match any local interface and the message is not address does not match any local interface and the message is not
a PATH or PTEAR, the message must be forwarded without further a Path or PathTear, the message must be forwarded without further
processing by this node. When a RESV message does arrive at the processing by this node. When a Resv message does arrive at the
addessed node, the IP destination address (or the LIH, defined addessed node, the IP destination address (or the LIH, defined
later) must be used to determine the interface to receive the later) must be used to determine the interface to receive the
reservation. reservation.
2.10 Host Model 2.10 Host Model
Before a session can be created, the session identification, Before a session can be created, the session identification,
comprised of DestAddress and perhaps the generalized destination comprised of DestAddress and perhaps the generalized destination
port, must be assigned and communicated to all the senders and port, must be assigned and communicated to all the senders and
receivers by some out-of-band mechanism. When an RSVP session is receivers by some out-of-band mechanism. When an RSVP session is
being set up, the following events happen at the end systems. being set up, the following events happen at the end systems.
H1 A receiver joins the multicast group specified by H1 A receiver joins the multicast group specified by
DestAddress, using IGMP. DestAddress, using IGMP.
H2 A potential sender starts sending RSVP PATH messages to the H2 A potential sender starts sending RSVP Path messages to the
DestAddress. DestAddress.
H3 A receiver application receives a PATH message. H3 A receiver application receives a Path message.
H4 A receiver starts sending appropriate RESV messages, H4 A receiver starts sending appropriate Resv messages,
specifying the desired flow descriptors. specifying the desired flow descriptors.
H5 A sender application receives a RESV message. H5 A sender application receives a Resv message.
H6 A sender starts sending data packets. H6 A sender starts sending data packets.
There are several synchronization considerations. There are several synchronization considerations.
o H1 and H2 may happen in either order. o H1 and H2 may happen in either order.
o Suppose that a new sender starts sending data (H6) but there o Suppose that a new sender starts sending data (H6) but there
are no multicast routes because no receivers have joined the are no multicast routes because no receivers have joined the
group (H1). Then the data will be dropped at some router group (H1). Then the data will be dropped at some router
node (which node depends upon the routing protocol) until node (which node depends upon the routing protocol) until
receivers(s) appear. receivers(s) appear.
o Suppose that a new sender starts sending PATH messages (H2) o Suppose that a new sender starts sending Path messages (H2)
and data (H6) simultaneously, and there are receivers but no and data (H6) simultaneously, and there are receivers but no
RESV messages have reached the sender yet (e.g., because its Resv messages have reached the sender yet (e.g., because its
PATH messages have not yet propagated to the receiver(s)). Path messages have not yet propagated to the receiver(s)).
Then the initial data may arrive at receivers without the Then the initial data may arrive at receivers without the
desired QoS. The sender could mitigate this problem by desired QoS. The sender could mitigate this problem by
awaiting arrival of the first RESV message (H5); however, awaiting arrival of the first Resv message (H5); however,
receivers that are farther away may not have reservations in receivers that are farther away may not have reservations in
place yet. place yet.
o If a receiver starts sending RESV messages (H4) before o If a receiver starts sending Resv messages (H4) before
receiving any PATH messages (H3), RSVP will return error receiving any Path messages (H3), RSVP will return error
messages to the receiver. messages to the receiver.
The receiver may simply choose to ignore such error messages, The receiver may simply choose to ignore such error messages,
or it may avoid them by waiting for PATH messages before or it may avoid them by waiting for Path messages before
sending RESV messages. sending Resv messages.
A specific application program interface (API) for RSVP is not A specific application program interface (API) for RSVP is not
defined in this protocol spec, as it may be host system dependent. defined in this protocol spec, as it may be host system dependent.
However, Section 3.10.1 discusses the general requirements and However, Section 3.10.1 discusses the general requirements and
outlines a generic interface. outlines a generic interface.
3. RSVP Functional Specification 3. RSVP Functional Specification
3.1 RSVP Message Formats 3.1 RSVP Message Formats
skipping to change at page 32, line 10 skipping to change at page 33, line 10
Protocol version number. This is version 1. Protocol version number. This is version 1.
Flags: 4 bits Flags: 4 bits
0x01 = INTEGRITY object present 0x01 = INTEGRITY object present
This flag indicates that an INTEGRITY object follows This flag indicates that an INTEGRITY object follows
immediately after the common header. The use of the immediately after the common header. The use of the
INTEGRITY object is described in [Baker96]. INTEGRITY object is described in [Baker96].
0x02 = UDP': UDP encapsulation marker flag 0x02-0x80: Reserved
This flag is reserved for use by UDP encapsulation
[Appendix C].
Type: 8 bits Type: 8 bits
1 = PATH 1 = PATH
2 = RESV 2 = RESV
3 = PERR 3 = PERR
4 = RERR 4 = RERR
skipping to change at page 32, line 43 skipping to change at page 33, line 40
The one's complement of the one's complement sum of the The one's complement of the one's complement sum of the
message (fragment), with the checksum field replaced by message (fragment), with the checksum field replaced by
zero for the purpose of computing the checksum. An all- zero for the purpose of computing the checksum. An all-
zero value means that no checksum was transmitted. zero value means that no checksum was transmitted.
RSVP Length: 16 bits RSVP Length: 16 bits
The total length of this RSVP packet in bytes, including The total length of this RSVP packet in bytes, including
the common header and the variable-length objects that the common header and the variable-length objects that
follow. If the MF flag is on or the Fragment Offset field follow. If the MF flag is on or the Fragment Offset field
is non-zero, this is the length of the current fragment of is non-zero, this will generally differ from the length of
a larger message. the current fragment.
Send_TTL: 8 bits Send_TTL: 8 bits
The IP TTL value with which the message was sent. The IP TTL value with which the message was sent.
Message ID: 32 bits Message ID: 32 bits
A label shared by all fragments of one message from a
given next/previous RSVP hop. An RSVP implementation An unique identifying value that is used to identify and
assigns a unique Message ID to each message it sends. reassemble the fragments of a single message. It is
assigned to the RSVP message by the node whose address is
the IP source address of the message (fragment).
MF: More Fragments Flag: 1 bit MF: More Fragments Flag: 1 bit
This flag is the low-order bit of a byte; the seven high- This flag is the low-order bit of a byte; the seven high-
order bits are reserved. It is on for all but the last order bits are reserved. It is on for all but the last
fragment of a message. fragment of a message.
Fragment Offset: 24 bits Fragment Offset: 24 bits
This field gives the byte offset of the current fragment This field gives the byte offset of the current fragment
in the complete message. in the complete message.
For a Path or PathTear message, the Message Id is assigned by
the sender host, and it must be copied at each successive node
into forwarded messages. For other messages, it is assigned at
the most recent RSVP hop to forward the message. When a
message is fragmented, the Messsage Id must be copied into each
fragment. When a fragmented packet is received, it may be
reassembled by RSVP out of fragments carrying the same Message
Id and IP source address.
RSVP messages that exceed the MTU of the interface on which
they are being sent must be split into fragments, each of which
will fit into an MTU.
3.1.2 Object Formats 3.1.2 Object Formats
Every object consists of one or more 32-bit words with a one- Every object consists of one or more 32-bit words with a one-
word header, in the following format: word header, in the following format:
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type | | Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
skipping to change at page 34, line 27 skipping to change at page 35, line 39
Carries the IP address of the RSVP-capable node that Carries the IP address of the RSVP-capable node that
sent this message. This document refers to a sent this message. This document refers to a
RSVP_HOP object as a PHOP ("previous hop") object for RSVP_HOP object as a PHOP ("previous hop") object for
downstream messages or as a NHOP ("next hop") object downstream messages or as a NHOP ("next hop") object
for upstream messages. for upstream messages.
TIME_VALUES TIME_VALUES
Contains the value for the refresh period R used by Contains the value for the refresh period R used by
the creator of the message; see 3.6. Required in the creator of the message; see 3.6. Required in
every PATH and RESV message. every Path and Resv message.
STYLE STYLE
Defines the reservation style plus style-specific Defines the reservation style plus style-specific
information that is not in FLOWSPEC or FILTER_SPEC information that is not in FLOWSPEC or FILTER_SPEC
objects. Required in every RESV message. objects. Required in every Resv message.
FLOWSPEC FLOWSPEC
Defines a desired QoS, in a RESV message. Defines a desired QoS, in a Resv message.
FILTER_SPEC FILTER_SPEC
Defines a subset of session data packets that should Defines a subset of session data packets that should
receive the desired QoS (specified by an FLOWSPEC receive the desired QoS (specified by an FLOWSPEC
object), in a RESV message. object), in a Resv message.
SENDER_TEMPLATE SENDER_TEMPLATE
Contains a sender IP address and perhaps some Contains a sender IP address and perhaps some
additional demultiplexing information to identify a additional demultiplexing information to identify a
sender, in a PATH message. sender, in a Path message.
SENDER_TSPEC SENDER_TSPEC
Defines the traffic characteristics of a sender's Defines the traffic characteristics of a sender's
data stream, in a PATH message. data stream, in a Path message.
ADSPEC ADSPEC
Carries OPWA data, in a PATH message. Carries OPWA data, in a Path message.
ERROR_SPEC ERROR_SPEC
Specifies an error, in a PERR or RERR message. Specifies an error, in a PathErr or ResvErr message.
POLICY_DATA POLICY_DATA
Carries information that will allow a local policy Carries information that will allow a local policy
module to decide whether an associated reservation is module to decide whether an associated reservation is
administratively permitted. May appear in a PATH or administratively permitted. May appear in Path,
RESV message. Resv, PathErr, or ResvErr message.
INTEGRITY INTEGRITY
Contains cryptographic data to authenticate the Contains cryptographic data to authenticate the
originating node and to verify the contents of this originating node and to verify the contents of this
RSVP message. See [Baker96]. RSVP message. See [Baker96].
SCOPE SCOPE
An explicit list of sender hosts towards which to An explicit list of sender hosts towards which to
forward a message. May appear in a RESV, RERR, or forward a message. May appear in a Resv, ResvErr, or
RTEAR message. ResvTear message.
RESV_CONFIRM RESV_CONFIRM
Carries the IP address of a receiver that requested a Carries the IP address of a receiver that requested a
confirmation. May appear in a RESV or RACK message. confirmation. May appear in a Resv or ResvConf
message.
C-Type C-Type
Object type, unique within Class-Num. Values are defined Object type, unique within Class-Num. Values are defined
in Appendix A. in Appendix A.
The maximum object content length is 65528 bytes. The Class- The maximum object content length is 65528 bytes. The Class-
Num and C-Type fields 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.9. Class-Num of an object; see Section 3.9.
3.1.3 Path Messages 3.1.3 Path Messages
Each sender host periodically sends a PATH message containing a Each sender host periodically sends a Path message containing a
description of each data stream it originates. The PATH description of each data stream it originates. The Path
message travels from a sender to receiver(s) along the same message travels from a sender to receiver(s) along the same
path(s) used by the data packets. The IP source address of a path(s) used by the data packets. The IP source address of a
PATH message is an address of the sender it describes, while Path message is an address of the sender it describes, while
the destination address is the DestAddress for the session. the destination address is the DestAddress for the session.
These addresses assure that the message will be correctly These addresses assure that the message will be correctly
routed through a non-RSVP cloud. routed through a non-RSVP cloud.
Each RSVP-capable node along the path(s) captures PATH messages Each RSVP-capable node along the path(s) captures Path messages
and processes them to build local path state. The node then and processes them to build local path state. The node then
forwards the PATH messages towards the receiver(s), replicating forwards the Path messages towards the receiver(s), replicating
it as dictated by multicast routing, while preserving the it as dictated by multicast routing, while preserving the
original IP source address. PATH messages eventually reach the original IP source address. Path messages eventually reach the
applications on all receivers; however, they are not looped applications on all receivers; however, they are not looped
back to a receiver running in the same application process as back to a receiver running in the same application process as
the sender. the sender.
The format of a PATH message is as follows: The format of a Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <POLICY_DATA> ... ]
<sender descriptor> <sender descriptor>
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <POLICY_DATA> ] [ <ADSPEC> ] [ <ADSPEC> ]
If the INTEGRITY object is present, there must be an INTEGRITY If the INTEGRITY object is present, there must be an INTEGRITY
object immediately following the common header in every object immediately following the common header in every
fragment of the message, in this and all other messages. The fragment of the message, in this and all other messages. There
objects included in the sender descriptor must occur after all are no other requirements on transmission order, although the
other objects in the message. above order is recommended. Any number of POLICY_DATA objects
may appear.
The PHOP (i.e., the RSVP_HOP) object of each PATH message The PHOP (i.e., the RSVP_HOP) object of each Path message
contains the address of the interface through which the PATH contains the address of the interface through which the Path
message was most recently sent. The SENDER_TEMPLATE object message was most recently sent. The SENDER_TEMPLATE object
defines the format of data packets from this sender, while the defines the format of data packets from this sender, while the
SENDER_TSPEC object specifies the traffic characteristics of SENDER_TSPEC object specifies the traffic characteristics of
the flow. Optionally, there may be a POLICY_DATA object the flow. Optionally, there may be an ADSPEC object carrying
specifying user credential and accounting information and/or an advertising (OPWA) data.
ADSPEC object carrying advertising (OPWA) data.
A PATH message received at a node is processed to create path A Path message received at a node is processed to create path
state for the sender defined by the SENDER_TEMPLATE and SESSION state for the sender defined by the SENDER_TEMPLATE and SESSION
objects. Any POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are objects. Any POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are
also saved in the path state. If an error is encountered while also saved in the path state. If an error is encountered while
processing a PATH message, a PERR message is sent to the processing a Path message, a PathErr message is sent to the
originating sender of the PATH message. PATH messages must originating sender of the Path message. PATH messages must
satisfy the rules on SrcPort and DstPort in Section 2.2. satisfy the rules on SrcPort and DstPort in Section 2.2.
Periodically, the RSVP daemon at a node scans the path state to Periodically, the RSVP daemon at a node scans the path state to
create new PATH messages to forward downstream. Each message create new Path messages to forward downstream. Each message
contains a sender descriptor defining one sender. The RSVP contains a sender descriptor defining one sender. The RSVP
daemon forwards these messages using routing information it daemon forwards these messages using routing information it
obtains from the appropriate uni-/multicast routing daemon. obtains from the appropriate uni-/multicast routing daemon.
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 none or The routing information generally includes the list of none or
more outgoing interfaces to which the PATH message to be more outgoing interfaces to which the Path message 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, any ADSPEC or contain different PHOP addresses. In addition, ADSPEC objects
POLICY_DATA objects carried in PATH messages will also carried in Path messages will also generally differ for
generally differ for different outgoing interfaces. different outgoing interfaces.
Some IP multicast routing protocols (e.g., DVMRP, PIM, and Some IP multicast routing protocols (e.g., DVMRP, PIM, and
MOSPF) also keep track of the expected incoming interface for MOSPF) also keep track of the expected incoming interface for
each source host to a multicast group. Whenever this each source host to a multicast group. Whenever this
information is available, RSVP should check the incoming information is available, RSVP should check the incoming
interface of each PATH message and immediately discard those interface of each Path message and immediately discard those
messages that have arrived on the wrong interface. messages that have arrived on the wrong interface.
3.1.4 Resv Messages 3.1.4 Resv Messages
RESV messages carry reservation requests hop-by-hop from Resv messages carry reservation requests hop-by-hop from
receivers to senders, along the reverse paths of data flows for receivers to senders, along the reverse paths of data flows for
the session. The IP destination address of a RESV message is the session. The IP destination address of a Resv message is
the unicast address of a previous-hop node, obtained from the the unicast address of a previous-hop node, obtained from the
path state. The IP source address is an address of the node path state. The IP source address is an address of the node
that sent the message. that sent the message.
The RESV message format is as follows: The Resv message format is as follows:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ] <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> [ <S_POLICY_DATA> ] <TIME_VALUES>
[ <POLICY_DATA> ... ]
[ <RESV_CONFIRM> ] [ <SCOPE> ] [ <RESV_CONFIRM> ] [ <SCOPE> ]
<STYLE> <flow descriptor list> <STYLE> <flow descriptor list>
<S_POLICY_DATA> ::= <POLICY_DATA>
<flow descriptor list> ::= <flow descriptor> | <flow descriptor list> ::= <flow descriptor> |
<flow descriptor list> <flow descriptor> <flow descriptor list> <flow descriptor>
The NHOP (i.e., the RSVP_HOP) object contains the IP address of The NHOP (i.e., the RSVP_HOP) object contains the IP address of
the interface through which the RESV message was sent. The the interface through which the Resv message was sent. The
appearance of a RESV_CONFIRM object signals a request for a appearance of a RESV_CONFIRM object signals a request for a
reservation confirmation and carries the IP address of the reservation confirmation and carries the IP address of the
receiver to which the RACK should be sent. The S_POLICY_DATA receiver to which the ResvConf should be sent. Any number of
object is a POLICY_DATA object that is associated with the POLICY_DATA objects may appear.
entire session. There may also be flow-specific F_POLICY_DATA
objects, as described below.
The STYLE object followed by the flow descriptor list must The STYLE object followed by the flow descriptor list must
occur at the end of the message. occur at the end of the message. There are no other
requirements on transmission order, although the above order is
recommended.
The BNF above defines a flow descriptor list as simply a list The BNF above defines a flow descriptor list as simply a list
of flow descriptors. The following style-dependent rules of flow descriptors. The following style-dependent rules
specify in more detail the composition of a valid flow specify in more detail the composition of a valid flow
descriptor list for each of the reservation styles; the order descriptor list for each of the reservation styles; the order
shown must be used. shown must be used.
o WF Style: o WF Style:
<flow descriptor list> ::= <WF flow descriptor> <flow descriptor list> ::= <WF flow descriptor>
<WF flow descriptor> ::= <FLOWSPEC> [ <F_POLICY_DATA> ] <WF flow descriptor> ::= <FLOWSPEC>
<F_POLICY_DATA> ::= <POLICY_DATA>
o FF style: o FF style:
<flow descriptor list> ::= <First FF flow descriptor> | <flow descriptor list> ::=
<flow descriptor list> <FF flow descriptor> <FLOWSPEC> <FILTER_SPEC> |
<First FF flow descriptor> ::= <flow descriptor list> <FF flow descriptor>
<FLOWSPEC> [ <F_POLICY_DATA> ] <FILTER_SPEC>
<FF flow descriptor> ::= <FF flow descriptor> ::=
[ <FLOWSPEC> ] [ <F_POLICY_DATA> ] <FILTER_SPEC> [ <FLOWSPEC> ] <FILTER_SPEC>
Each elementary FF style request is defined by a single Each elementary FF style request is defined by a single
(FLOWSPEC, FILTER_SPEC) pair, and multiple such requests (FLOWSPEC, FILTER_SPEC) pair, and multiple such requests
may be packed into the flow descriptor list of a single may be packed into the flow descriptor list of a single
RESV message. A FLOWSPEC object can be omitted if it is Resv message. A FLOWSPEC object can be omitted if it is
identical to the most recent such object that appeared in identical to the most recent such object that appeared in
the list; the first FF flow descriptor must contain a the list; the first FF flow descriptor must contain a
FLOWSPEC. FLOWSPEC.
Each flow descriptor in the list must be processed Each flow descriptor in the list must be processed
independently, and a separate RERR message must be independently, and a separate ResvErr message must be
generated for each one that is in error. generated for each one that is in error.
o SE style: o SE style:
<flow descriptor list> ::= <SE flow descriptor> <flow descriptor list> ::= <SE flow descriptor>
<SE flow descriptor> ::= <SE flow descriptor> ::=
<FLOWSPEC> [ <F_POLICY_DATA> ] <filter spec list> <FLOWSPEC> <filter spec list>
<filter spec list> ::= <FILTER_SPEC> <filter spec list> ::= <FILTER_SPEC>
| <filter spec list> <FILTER_SPEC> | <filter spec list> <FILTER_SPEC>
The reservation scope, i.e., the set of senders towards which a The reservation scope, i.e., the set of senders towards which a
particular reservation is to be forwarded, is determined as particular reservation is to be forwarded, is determined as
follows: follows:
o Explicit sender selection o Explicit sender selection
skipping to change at page 40, line 7 skipping to change at page 41, line 21
wildcard port), is an error. wildcard port), is an error.
o Wildcard sender selection o Wildcard sender selection
All senders that route to the given outgoing interface All senders that route to the given outgoing interface
match this request. A SCOPE object, if present, contains match this request. A SCOPE object, if present, contains
an explicit list of sender IP addresses. If there is no an explicit list of sender IP addresses. If there is no
SCOPE object, the scope is determined by the relevant set SCOPE object, the scope is determined by the relevant set
of senders in the path state. of senders in the path state.
Whenever a RESV message with wildcard sender selection is Whenever a Resv message with wildcard sender selection is
forwarded to more than one previous hop, a SCOPE object forwarded to more than one previous hop, a SCOPE object
must be included in the message. See Section 3.3 below. must be included in the message. See Section 3.3 below.
3.1.5 Teardown Messages 3.1.5 Teardown Messages
There are two types of RSVP Teardown message, PTEAR and RTEAR. There are two types of RSVP Teardown message, PathTear and
ResvTear.
o A PTEAR message deletes path state (which in turn deletes o A PathTear message deletes path state (which in turn
any reservation state for that sender) and travels towards deletes any reservation state for that sender) and travels
all receivers that are downstream from the initiating towards all receivers that are downstream from the
node. A PTEAR message is routed like a PATH message, and initiating node. A PathTear message is routed like a Path
its IP destination address is DestAddress for the session. message, and its IP destination address is DestAddress for
the session.
o A RTEAR message deletes reservation state and travels o A ResvTear message deletes reservation state and travels
towards all matching senders upstream from the initiating towards all matching senders upstream from the initiating
node. A RTEAR message is routed in the same way as a node. A ResvTear message is routed in the same way as a
corresponding RESV message, and its IP destination address corresponding Resv message, and its IP destination address
is the unicast address of a previous hop. is the unicast address of a previous hop.
<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)
skipping to change at page 40, line 36 skipping to change at page 42, line 4
<PathTear Message> ::= <Common Header> [<INTEGRITY>] <PathTear Message> ::= <Common Header> [<INTEGRITY>]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<sender descriptor> <sender descriptor>
<sender descriptor> ::= (see earlier definition) <sender descriptor> ::= (see earlier definition)
<ResvTear Message> ::= <Common Header> [<INTEGRITY>] <ResvTear Message> ::= <Common Header> [<INTEGRITY>]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
[ <SCOPE> ] <STYLE> [ <SCOPE> ] <STYLE>
<flow descriptor list> <flow descriptor list>
<flow descriptor list> ::= (see earlier definition) <flow descriptor list> ::= (see earlier definition)
FLOWSPEC or POLICY_DATA objects in the flow descriptor list of FLOWSPEC objects in the flow descriptor list of a ResvTear
a RTEAR message will be ignored and may be omitted. The order message will be ignored and may be omitted. The order
requirements for sender descriptor, STYLE object, and flow requirements for sender descriptor, STYLE object, and flow
descriptor list are as given earlier for PATH and RESV descriptor list are as given earlier for Path and Resv
messages. messages.
Note that, unless it is accidentally dropped along the way, a Note that, unless it is accidentally dropped along the way, a
PTEAR message will reach all receivers down stream from its PTEAR message will reach all receivers down stream from its
origination. On the other hand, a RTEAR message will cease to origination. On the other hand, a ResvTear message will cease
be forwarded at the same node where merging suppresses to be forwarded at the same node where merging suppresses
forwarding of the corresponding RESV messages. In each node N forwarding of the corresponding Resv messages. In each node N
along the way, if the RTEAR message causes the removal of all along the way, if the ResvTear message causes the removal of
state for this session, N will create a new teardown message to all state for this session, N will create a new teardown
be propagated further upstream; otherwise, the RTEAR message message to be propagated further upstream; otherwise, the
may result in the immediate forwarding of a modified RESV ResvTear message may result in the immediate forwarding of a
refresh message. modified Resv refresh message.
Deletion of path state as the result of a PTEAR message or a Deletion of path state as the result of a PathTear message or a
timeout must cause any adjustments in related reservation state timeout must cause any adjustments in related reservation state
required to maintain consistency in the local node. The required to maintain consistency in the local node. The
adjustment in reservation state depends upon the style. For adjustment in reservation state depends upon the style. For
example, suppose a PTEAR deletes the path state for a sender S. example, suppose a PathTear deletes the path state for a sender
If the style specifies explicit sender selection (FF or SE), S. If the style specifies explicit sender selection (FF or
any reservation with a filter spec matching S should be SE), any reservation with a filter spec matching S should be
deleted; if the style has wildcard sender selection (WF), the deleted; if the style has wildcard sender selection (WF), the
reservation should be deleted if S is the last sender to the reservation should be deleted if S is the last sender to the
session. These reservation changes should not trigger an session. These reservation changes should not trigger an
immediate RESV refresh message, since the PTEAR message have immediate Resv refresh message, since the PathTear message have
already made the required changes upstream. However, at the already made the required changes upstream. However, at the
node in which a RTEAR message stops, the change of reservation node in which a ResvTear message stops, the change of
state may trigger a RESV refresh starting at that node. reservation state may trigger a Resv refresh starting at that
node.
3.1.6 Error Messages 3.1.6 Error Messages
There are two types of RSVP error messages. There are two types of RSVP error messages.
o PERR messages result from PATH messages and travel o PathErr messages result from Path messages and travel
upstream towards the senders. PERR messages are routed upstream towards the senders. PathErr messages are routed
hop-by-hop using the path state; at each hop, the IP hop-by-hop using the path state; at each hop, the IP
destination address is the unicast address of a previous destination address is the unicast address of a previous
hop. PERR messages do not modify the state of any node hop. PathErr messages do not modify the state of any node
through which they pass; instead, they are only reported through which they pass; instead, they are only reported
to the sender application. to the sender application.
o RERR messages result from RESV messages and travel o ResvErr messages result from Resv messages and travel
downstream towards the appropriate receivers. They are downstream towards the appropriate receivers. They are
routed hop-by-hop using the reservation state; at each routed hop-by-hop using the reservation state; at each
hop, the IP destination address is the unicast address of hop, the IP destination address is the unicast address of
a next-hop node. a next-hop node.
An error encountered while processing an error message must An error encountered while processing an error message must
cause the error message to be discarded without creating cause the error message to be discarded without creating
further error messages; however, logging of such events may be further error messages; however, logging of such events may be
useful. useful.
<PathErr message> ::= <Common Header> [ <INTEGRITY> ] <PathErr message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC> <SESSION> <ERROR_SPEC>
[ <POLICY_DATA> ...]
<sender descriptor> <sender descriptor>
<sender descriptor> ::= (see earlier definition) <sender descriptor> ::= (see earlier definition)
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ] <ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC> <SESSION> <ERROR_SPEC>
[S_POLICY_DATA] [ <SCOPE> ] [ <POLICY_DATA> ...]
[ <SCOPE> ]
<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). POLICY_DATA objects are included in error messages Address). One or more POLICY_DATA objects may be included in
in cases where they may provide relevant information (i.e., an error message to provide relevant information (i.e., when an
when an administrative failure is being reported). The STYLE administrative failure is being reported). The STYLE object is
object is copied from the RESV message in error. The use of copied from the Resv message in error. The use of the SCOPE
the SCOPE object in a RERR message is defined below in Section object in a ResvErr message is defined below in Section 3.3.
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:
<error flow descriptor> ::= <FF flow descriptor> <error flow descriptor> ::= <FF flow descriptor>
o SE style: o SE style:
<error flow descriptor> ::= <SE flow descriptor> <error flow descriptor> ::= <SE flow descriptor>
Note that a RERR 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 RERR messages. (FF style) may create up to N separate ResvErr messages.
Generally speaking, a RERR message should be forwarded towards Generally speaking, a ResvErr message should be forwarded
all receivers that may have caused the error being reported. towards all receivers that may have caused the error being
More specifically: reported. More specifically:
o The node that detects an error in a reservation request o The node that detects an error in a reservation request
sends a RERR message to the next hop from which the sends a RERR message to the next hop from which the
erroneous reservation came. erroneous reservation came.
This message must contain the information required to This message must contain the information required to
define the error and to route the error message in later define the error and to route the error message in later
hops. It therefore includes an ERROR_SPEC object, a copy hops. It therefore includes an ERROR_SPEC object, a copy
of the STYLE object, and the appropriate error flow of the STYLE object, and the appropriate error flow
descriptor. If the error is an admission control failure, descriptor. If the error is an admission control failure,
any reservation already in place will be left in place, any reservation already in place will be left in place,
and the InPlace flag bit must be on in the ERROR_SPEC of and the InPlace flag bit must be on in the ERROR_SPEC of
the RERR message. the ResvErr message.
o Succeeding nodes forward the RERR 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 RERR messages, to avoid loops; see Section 3.3. forwarding ResvErr messages, to avoid loops; see Section
There is also a rule restricting the forwarding of RESV 3.3. There is also a rule restricting the forwarding of
messages for Admission Control failures; see Section 3.4. Resv messages for Admission Control failures; see Section
3.4.
A RERR message that is forwarded should carry the A ResvErr message that is forwarded should carry the
FILTER_SPEC from the corresponding reservation state. FILTER_SPEC from the corresponding reservation state.
o When a RERR message reaches a receiver, the STYLE object, o When a ResvErr message reaches a receiver, the STYLE
flow descriptor list, and ERROR_SPEC object (including its object, flow descriptor list, and ERROR_SPEC object
flags) should be delivered to the receiver application. (including its flags) should be delivered to the receiver
application.
3.1.7 Confirmation Messages 3.1.7 Confirmation Messages
RACK messages are sent to (probabilistically) acknowledge ResvConf messages are sent to (probabilistically) acknowledge
reservation requests. A RACK message is sent as the result of reservation requests. A ResvConf message is sent as the result
the appearance of a RESV_CONFIRM object in a RESV message. of the appearance of a RESV_CONFIRM object in a Resv message.
A RACK 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 RACK message is forwarded to the receiver hop-by- However, a ResvConf message is forwarded to the receiver hop-
hop, to accommodate the hop-by-hop integrity check mechanism. by-hop, to accommodate the hop-by-hop integrity check
mechanism.
<ResvConf Message> ::= <Common Header> <SESSION> <ResvConf Message> ::= <Common Header> <SESSION>
<ERROR_SPEC> <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 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 object order requirements within indicate a confirmation. The flow descriptor list specifies
the flow descriptor list are the same as those given earlier the particular reservations that are being confirmed; it may be
for a RESV message. a subset of flow descriptor list of the Resv that requested the
confirmation.
The object order requirements within the flow descriptor list
are the same as those given earlier for a Resv message.
3.2 Sending RSVP Messages 3.2 Sending RSVP Messages
RSVP messages are sent hop-by-hop between RSVP-capable routers as RSVP messages are sent hop-by-hop between RSVP-capable routers as
"raw" IP packets with protocol number 46. Raw IP packets are "raw" IP packets with protocol number 46. Raw IP packets are
intended to be used between an end system and the first/last hop intended to be used between an end system and the first/last hop
router, although it is also possible to encapsulate RSVP messages router, although it is also possible to encapsulate RSVP messages
as UDP datagrams for end-system communication, as described in as UDP datagrams for end-system communication, as described in
Appendix C. UDP encapsulation is needed for systems that cannot Appendix C. UDP encapsulation is needed for systems that cannot
do raw network I/O. do raw network I/O.
PATH, PTEAR, and RACK messages must be sent with the Router Alert Path, PathTear, and ResvConf messages must be sent with the Router
IP option [Katz95] in their IP headers. This option may be used Alert IP option [Katz95] in their IP headers. This option may be
in the fast forwarding path of a high-speed router to detect used in the fast forwarding path of a high-speed router to detect
datagrams that require special processing. datagrams that require special processing.
Upon the arrival of an RSVP message M that changes the state, a Upon the arrival of an RSVP message M that changes the state, a
node must forward the modified state immediately. However, this node must forward the modified state immediately. However, this
must not trigger sending an message out the interface through must not trigger sending an message out the interface through
which M arrived (as could happen if the implementation simply which M arrived (as could happen if the implementation simply
triggered an immediate refresh of all state for the session). triggered an immediate refresh of all state for the session).
This rule is necessary to prevent packet storms on broadcast LANs. This rule is necessary to prevent packet storms on broadcast LANs.
An RSVP message must be fragmented when necessary to fit into the An RSVP message must be fragmented when necessary to fit into the
skipping to change at page 45, line 27 skipping to change at page 47, line 8
Some multicast routing protocols provide for "multicast tunnels", Some multicast routing protocols provide for "multicast tunnels",
which encapsulate multicast packets for transmission through which encapsulate multicast packets for transmission through
routers that do not have multicast capability. A multicast tunnel routers that do not have multicast capability. A multicast tunnel
looks like a logical outgoing interface that is mapped into some looks like a logical outgoing interface that is mapped into some
physical interface. A multicast routing protocol that supports physical interface. A multicast routing protocol that supports
tunnels will describe a route using a list of logical rather than tunnels will describe a route using a list of logical rather than
physical interfaces. RSVP can run through multicast tunnels in physical interfaces. RSVP can run through multicast tunnels in
the following manner: the following manner:
1. When a node N forwards a PATH message out a logical outgoing 1. When a node N forwards a Path message out a logical outgoing
interface L, it includes in the message some encoding of the interface L, it includes in the message some encoding of the
identity of L, called the "logical interface handle" or LIH. identity of L, called the "logical interface handle" or LIH.
The LIH value is carried in the RSVP_HOP object. The LIH value is carried in the RSVP_HOP object.
2. The next hop node N' stores the LIH value in its path state. 2. The next hop node N' stores the LIH value in its path state.
3. When N' sends a RESV message to N, it includes the LIH value 3. When N' sends a Resv message to N, it includes the LIH value
from the path state (again, in the RSVP_HOP object). from the path state (again, in the RSVP_HOP object).
4. When the RESV message arrives at N, its LIH value provides 4. When the Resv message arrives at N, its LIH value provides
the information necessary to attach the reservation to the the information necessary to attach the reservation to the
appropriate logical interface. Note that N creates and appropriate logical interface. Note that N creates and
interprets the LIH; it is an opaque value to N'. interprets the LIH; it is an opaque value to N'.
3.3 Avoiding RSVP Message Loops 3.3 Avoiding RSVP Message Loops
Forwarding of RSVP messages must avoid looping. In steady state, Forwarding of RSVP messages must avoid looping. In steady state,
PATH and RESV messages are forwarded only once per refresh period Path and Resv messages are forwarded only once per refresh period
on each hop. This avoids looping packets, but there is still the on each hop. This avoids looping packets, but there is still the
possibility of an "auto-refresh" loop, clocked by the refresh possibility of an "auto-refresh" loop, clocked by the refresh
period. Such auto-refresh loops keep state active "forever", even period. Such auto-refresh loops keep state active "forever", even
if the end nodes have ceased refreshing it, until either the if the end nodes have ceased refreshing it, until either the
receivers leave the multicast group and/or the senders stop receivers leave the multicast group and/or the senders stop
sending PATH messages. On the other hand, error and teardown sending Path messages. On the other hand, error and teardown
messages are forwarded immediately and are therefore subject to messages are forwarded immediately and are therefore subject to
looping. looping.
Consider each message type. Consider each message type.
o PATH Messages o Path Messages
PATH messages are forwarded in exactly the same way as IP Path messages are forwarded in exactly the same way as IP
data packets. Therefore there should be no loops of PATH data packets. Therefore there should be no loops of Path
messages, even in a topology with cycles. messages, even in a topology with cycles.
o PTEAR Messages o PathTear Messages
PTEAR messages use the same routing as PATH messages and PathTear messages use the same routing as Path messages and
therefore cannot loop. therefore cannot loop.
o PERR Messages o PathErr Messages
Since PATH messages do not loop, they create path state Since Path messages do not loop, they create path state
defining a loop-free reverse path to each sender. PERR defining a loop-free reverse path to each sender. PathErr
messages are always directed to particular senders and messages are always directed to particular senders and
therefore cannot loop. therefore cannot loop.
o RESV Messages o Resv Messages
RESV messages directed to particular senders (i.e., with Resv messages directed to particular senders (i.e., with
explicit sender selection) cannot loop. However, RESV explicit sender selection) cannot loop. However, Resv
messages with wildcard sender selection (WF style) have a messages with wildcard sender selection (WF style) have a
potential for auto-refresh looping. potential for auto-refresh looping.
o RTEAR Messages o ResvTear Messages
Although RTEAR messages are routed the same as RESV messages, Although ResvTear messages are routed the same as Resv
during the second pass around a loop there will be no state messages, during the second pass around a loop there will be
so any RTEAR message will be dropped. Hence there is no no state so any ResvTear message will be dropped. Hence
looping problem here. there is no looping problem here.
o RERR Messages o ResvErr Messages
RERR messages for WF style reservations may loop for ResvErr messages for WF style reservations may loop for
essentially the same reasons that RESV messages loop. essentially the same reasons that Resv messages loop.
o RACK Messages o ResvConf Messages
RACK messages are forwarded towards a fixed unicast receiver ResvConf messages are forwarded towards a fixed unicast
address and cannot loop. receiver address and cannot loop.
If the topology has no loops, then looping of RESV and RERR If the topology has no loops, then looping of Resv and ResvErr
messages with wildcard sender selection can be avoided by simply messages with wildcard sender selection can be avoided by simply
enforcing the rule given earlier: state that is received through a enforcing the rule given earlier: state that is received through a
particular interface must never be forwarded out the same particular interface must never be forwarded out the same
interface. However, when the topology does have cycles, further interface. However, when the topology does have cycles, further
effort is needed to prevent auto-refresh loops of wildcard RESV effort is needed to prevent auto-refresh loops of wildcard Resv
messages and fast loops of wildcard RERR messages. The solution messages and fast loops of wildcard ResvErr messages. The
to this problem adopted by this protocol specification is for such solution to this problem adopted by this protocol specification is
messages to carry an explicit sender address list in a SCOPE for such messages to carry an explicit sender address list in a
object. SCOPE object.
When a RESV message with WF style is to be forwarded to a When a Resv message with WF style is to be forwarded to a
particular previous hop, a new SCOPE object is computed from the particular previous hop, a new SCOPE object is computed from the
SCOPE objects that were received in matching RESV messages. If SCOPE objects that were received in matching Resv messages. If
the computed SCOPE object is empty, the message is not forwarded the computed SCOPE object is empty, the message is not forwarded
to the previous hop; otherwise, the message is sent containing the to the previous hop; otherwise, the message is sent containing the
new SCOPE object. The rules for computing a new SCOPE object for new SCOPE object. The rules for computing a new SCOPE object for
a RESV message are as follows: a Resv message are as follows:
1. The union is formed of the sets of sender IP addresses listed 1. The union is formed of the sets of sender IP addresses listed
in all SCOPE objects in the reservation state for the given in all SCOPE objects in the reservation state for the given
session. session.
If reservation state from some NHOP does not contain a SCOPE If reservation state from some NHOP does not contain a SCOPE
object, a substitute sender list must be created and included object, a substitute sender list must be created and included
in the union. For a message that arrived on outgoing in the union. For a message that arrived on outgoing
interface OI, the substitute list is the set of senders that interface OI, the substitute list is the set of senders that
route to OI. route to OI.
2. Any local senders (i.e., any sender applications on this 2. Any local senders (i.e., any sender applications on this
node) are removed from this set. node) are removed from this set.
3. If the SCOPE object is to be sent to PHOP, remove from the 3. If the SCOPE object is to be sent to PHOP, remove from the
set any senders that did not come from PHOP. set any senders that did not come from PHOP.
Figure 11 shows an example of wildcard-scoped (WF style) RESV Figure 11 shows an example of wildcard-scoped (WF style) Resv
messages. The address lists within SCOPE objects are shown in messages. The address lists within SCOPE objects are shown in
square brackets. Note that there may be additional connections square brackets. Note that there may be additional connections
among the nodes, creating looping topology that is not shown. among the nodes, creating looping topology that is not shown.
________________ ________________
a | | c a | | c
R4, S4<----->| Router |<-----> R2, S2, S3 R4, S4<----->| Router |<-----> R2, S2, S3
| | | |
b | | b | |
R1, S1<----->| | R1, S1<----->| |
skipping to change at page 48, line 31 skipping to change at page 50, line 4
Receive on (a): | Send on (c): Receive on (a): | Send on (c):
| |
WF( [S1,S2,S3]) --> | WF( [S2, S3]) --> WF( [S1,S2,S3]) --> | WF( [S2, S3]) -->
| |
Receive on (b): | Receive on (b): |
| |
WF( [S2,S3,S4]) --> | WF( [S2,S3,S4]) --> |
| |
Figure 11: SCOPE Objects in Wildcard-Scope Reservations Figure 11: SCOPE Objects in Wildcard-Scope Reservations
SCOPE objects are not necessary if the multicast routing uses SCOPE objects are not necessary if the multicast routing uses
shared trees or if the reservation style has explicit sender shared trees or if the reservation style has explicit sender
selection. Furthermore, attaching a SCOPE object to a reservation selection. Furthermore, attaching a SCOPE object to a reservation
may be deferred to a node which has more than one previous hop may be deferred to a node which has more than one previous hop
upstream. upstream.
The following rules are used for SCOPE objects in RERR 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 RERR message 1. The node that detected the error initiates an ResvErr message
containing a copy of the SCOPE object associated with the containing a copy of the SCOPE object associated with the
reservation state or message in error. reservation state or message in error.
2. Suppose a wildcard-scoped RERR message arrives at a node with 2. Suppose a wildcard-scoped ResvErr message arrives at a node
a SCOPE object containing the sender host address list L. with a SCOPE object containing the sender host address list
The node forwards the RERR message using the rules of Section L. The node forwards the ResvErr message using the rules of
3.1.6. However, the RERR message forwarded out OI must Section 3.1.6. However, the ResvErr message forwarded out OI
contain a SCOPE object derived from L by including only those must contain a SCOPE object derived from L by including only
senders that route to OI. If this SCOPE object is empty, the those senders that route to OI. If this SCOPE object is
RERR message should not be sent out OI. empty, the ResvErr message should not be sent out OI.
3.4 Blockade State 3.4 Blockade State
The basic rule for creating a RESV refresh message is to merge the The basic rule for creating a Resv refresh message is to merge the
flowspecs of the reservation requests in place in the node, by flowspecs of the reservation requests in place in the node, by
computing their LUB. However, this rule is modified by the computing their LUB. However, this rule is modified by the
existence of "blockade state" resulting from RERR messages, to existence of "blockade state" resulting from ResvErr messages, to
solve the KR-II problem (Section 2.6). The blockade state also solve the KR-II problem (Section 2.6). The blockade state also
enters into the routing of RERR messages for Admission Control enters into the routing of ResvErr messages for Admission Control
failure. failure.
When a RERR message for an Admission Control failure is received, When a ResvErr message for an Admission Control failure is
its flowspec Qe is used to create or refresh an element of local received, its flowspec Qe is used to create or refresh an element
blockade state. Each element of blockade state consists of a of local blockade state. Each element of blockade state consists
blockade flowspec Qb taken from the flowspec of the last RERR, and of a blockade flowspec Qb taken from the flowspec of the last
an associated blockade timer Tb. When the blockade timer expires, ResvErr, and an associated blockade timer Tb. When the blockade
the blockade state is deleted. timer expires, the blockade state is deleted.
The granularity of blockade state depends upon the style of the The granularity of blockade state depends upon the style of the
RERR message that created it. For an explicit style, there may be ResvErr message that created it. For an explicit style, there may
a blockade state element (Qb(S),Tb(S)) for each sender S. For a be a blockade state element (Qb(S),Tb(S)) for each sender S. For
wildcard style, blockade state is per previous hop P. a wildcard style, blockade state is per previous hop P.
An element of blockade state with flowspec Qb is said to An element of blockade state with flowspec Qb is said to
"blockade" a reservation with flowspec Qi if Qb is not (strictly) "blockade" a reservation with flowspec Qi if Qb is not (strictly)
greater than Qi. For example, suppose that the LUB of two greater than Qi. For example, suppose that the LUB of two
flowspecs is computed by taking the max of each of their flowspecs is computed by taking the max of each of their
corresponding components. Then Qb blockades Qi if for some corresponding components. Then Qb blockades Qi if for some
component j, Qb[j] <= Qi[j]. component j, Qb[j] <= Qi[j].
Suppose that a node receives a RERR message from previous hop P Suppose that a node receives a ResvErr message from previous hop P
(or, if style is explicit, sender S) as the result of an Admission (or, if style is explicit, sender S) as the result of an Admission
Control failure upstream. Then: Control failure upstream. Then:
1. An element of blockade state is created for P (or S) if it 1. An element of blockade state is created for P (or S) if it
did not exist. did not exist.
2. Qb(P) (or Qb(S)) is set equal to the flowspec Qe from the 2. Qb(P) (or Qb(S)) is set equal to the flowspec Qe from the
RERR message. ResvErr message.
3. A corresponding blockade timer Tb(P) (or Tb(S)) is started or 3. A corresponding blockade timer Tb(P) (or Tb(S)) is started or
restarted for a time Kb*R. Here Kb is a fixed multiplier and restarted for a time Kb*R. Here Kb is a fixed multiplier and
R is the refresh interval for reservation state. Kb should R is the refresh interval for reservation state. Kb should
be configurable. be configurable.
4. If there is some local reservation state that is not 4. If there is some local reservation state that is not
blockaded (see below), an immediate reservation refresh for P blockaded (see below), an immediate reservation refresh for P
(or S) is generated. (or S) is generated.
5. The RERR message is forwarded to next hops in the following 5. The ResvErr message is forwarded to next hops in the
way. If the InPlace bit is off, the RERR message is following way. If the InPlace bit is off, the ResvErr
forwarded to all next hops for which there is reservation message is forwarded to all next hops for which there is
state. If the InPlace bit is on, the RERR message is reservation state. If the InPlace bit is on, the ResvErr
forwarded only to the next hops whose Qi is blockaded by Qb. message is forwarded only to the next hops whose Qi is
blockaded by Qb.
Finally, we present the modified rule for merging flowspecs to Finally, we present the modified rule for merging flowspecs to
create a reservation refresh message. create a reservation refresh message.
o If there are any local reservation requests Qi that are not o If there are any local reservation requests Qi that are not
blockaded, these are merged by computing their LUB. The blockaded, these are merged by computing their LUB. The
blockaded reservations are ignored; this allows forwarding of blockaded reservations are ignored; this allows forwarding of
a smaller reservation that has not failed and may perhaps a smaller reservation that has not failed and may perhaps
succeed, after a larger reservation fails. succeed, after a larger reservation fails.
skipping to change at page 50, line 37 skipping to change at page 52, line 9
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 labelled (a) and (b), and two next hops labelled (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 RERR message that will re- presumably this will fail, sending a ResvErr message that will
establish the blockade state, returning to the situation shown in re-establish the blockade state, returning to the situation shown
the figure. At the same time, the RERR message will be forwarded in the figure. At the same time, the ResvErr message will be
to next hop (c) and to all receivers downstream responsible for forwarded to next hop (c) and to all receivers downstream
the 4B reservations. responsible for the 4B reservations.
Send Blockade| Reserve Receive Send Blockade| Reserve Receive
State| State|
| |
| ________ | ________
(a) <- WF(*{2B}) {4B} | | * {4B} | WF(*{4B}) <- (c) (a) <- WF(*{2B}) {4B} | | * {4B} | WF(*{4B}) <- (c)
| |________| | |________|
| |
---------------------------|------------------------------- ---------------------------|-------------------------------
| |
| ________ | ________
(b) <- WF(*{4B}) (none)| | * {2B} | WF(*{2B}) <- (d) (b) <- WF(*{4B}) (none)| | * {2B} | WF(*{2B}) <- (d)
| |________| | |________|
Figure 12: Blockading with Shared Style Figure 12: Blockading with Shared Style
3.5 Local Repair 3.5 Local Repair
When a route changes, the next PATH or RESV refresh message will When a route changes, the next Path or Resv refresh message will
establish path or reservation state (respectively) along the new establish path or reservation state (respectively) along the new
route. To provide fast adaptation to routing changes without the route. To provide fast adaptation to routing changes without the
overhead of short refresh periods, the local routing protocol overhead of short refresh periods, the local routing protocol
module can notify the RSVP daemon of route changes for particular module can notify the RSVP daemon of route changes for particular
destinations. The RSVP daemon should use this information to destinations. The RSVP daemon should use this information to
trigger a quick refresh of state for these destinations, using the trigger a quick refresh of state for these destinations, using the
new route. new route.
The specific rules are as follows: The specific rules are as follows:
o When routing detects a change of the set of outgoing o When routing detects a change of the set of outgoing
interfaces for destination G, RSVP should wait for a short interfaces for destination G, RSVP should wait for a short
period W, and then send PATH refreshes for all sessions G/* period W, and then send Path refreshes for all sessions G/*
(i.e., for any session with destination G, regardless of (i.e., for any session with destination G, regardless of
destination port). destination port).
The short wait period before sending PATH refreshes is to The short wait period before sending Path refreshes is to
allow the routing protocol getting settled with the new allow the routing protocol getting settled with the new
change(s), and the exact value for W should be chosen change(s), and the exact value for W should be chosen
accordingly. Currently W = 2 sec is suggested; however, this accordingly. Currently W = 2 sec is suggested; however, this
value should be configurable per interface. value should be configurable per interface.
o When a PATH message arrives with a Previous Hop address that o When a Path message arrives with a Previous Hop address that
differs from the one stored in the path state, RSVP should differs from the one stored in the path state, RSVP should
send immediate RESV refreshes for that session. send immediate Resv refreshes for that session.
3.6 Time Parameters 3.6 Time Parameters
There are two time parameters relevant to each element of RSVP There are two time parameters relevant to each element of RSVP
path or reservation state in a node: the refresh period R between path or reservation state in a node: the refresh period R between
generation of successive refreshes for the state by the neighbor generation of successive refreshes for the state by the neighbor
node, and the local state's lifetime L. Each RSVP RESV or PATH node, and the local state's lifetime L. Each RSVP Resv or Path
message may contain a TIME_VALUES object specifying the R value message may contain a TIME_VALUES object specifying the R value
that was used to generate this (refresh) message. This R value is that was used to generate this (refresh) message. This R value is
then used to determine the value for L when the state is received then used to determine the value for L when the state is received
and stored. The values for R and L may vary from hop to hop. and stored. The values for R and L may vary from hop to hop.
In more detail: In more detail:
1. Floyd and Jacobson [FJ94] have shown that periodic messages 1. Floyd and Jacobson [FJ94] have shown that periodic messages
generated by independent network nodes can become generated by independent network nodes can become
synchronized. This can lead to disruption in network synchronized. This can lead to disruption in network
skipping to change at page 52, line 42 skipping to change at page 53, line 52
case, K-1 successive messages may be lost without state being case, K-1 successive messages may be lost without state being
deleted. To compute a lifetime L for a collection of state deleted. To compute a lifetime L for a collection of state
with different R values R0, R1, ..., replace R by max(Ri). with different R values R0, R1, ..., replace R by max(Ri).
Currently K = 3 is suggested as the default. However, it may Currently K = 3 is suggested as the default. However, it may
be necessary to set a larger K value for hops with high loss be necessary to set a larger K value for hops with high loss
rate. K may be set either by manual configuration per rate. K may be set either by manual configuration per
interface, or by some adaptive technique that has not yet interface, or by some adaptive technique that has not yet
been specified. been specified.
3. Each message that creates state (PATH or RESV message) 3. Each Path or Resv message carries a TIME_VALUES object
carries a TIME_VALUES object containing the R used to containing the refresh time R used to generate refreshes.
generate refreshes; the recipient node uses this R to The recipient node uses this R to determine the lifetime L of
determine L of the stored state. the stored state created or refreshed by the message.
4. R is chosen locally by each node. If the node does not 4. The refresh time R is chosen locally by each node. If the
implement local repair of reservations disrupted by route node does not implement local repair of reservations
changes, a smaller R speeds up adaptation to routing changes, disrupted by route changes, a smaller R speeds up adaptation
while increasing the RSVP overhead. With local repair, a to routing changes, while increasing the RSVP overhead. With
router can be more relaxed about R since the periodic refresh local repair, a router can be more relaxed about R since the
becomes only a backstop robustness mechanism. A node may periodic refresh becomes only a backstop robustness
therefore adjust the effective R dynamically to control the mechanism. A node may therefore adjust the effective R
amount of overhead due to refresh messages. dynamically to control the amount of overhead due to refresh
messages.
The current suggested default for R is 30 seconds. However, The current suggested default for R is 30 seconds. However,
the default should be configurable per interface. the default should be configurable per interface.
5. When R is changed dynamically, there is a limit on how fast 5. When R is changed dynamically, there is a limit on how fast
it may increase. Specifically, the ratio of two successive it may increase. Specifically, the ratio of two successive
values R2/R1 must not exceed 1 + Slew.Max. values R2/R1 must not exceed 1 + Slew.Max.
Currently, Slew.Max is 0.30. With K = 3, one packet may be Currently, Slew.Max is 0.30. With K = 3, one packet may be
lost without state timeout while R is increasing 30 percent lost without state timeout while R is increasing 30 percent
skipping to change at page 53, line 28 skipping to change at page 54, line 39
6. To improve robustness, a node may temporarily send refreshes 6. To improve robustness, a node may temporarily send refreshes
more often than R after a state change (including initial more often than R after a state change (including initial
state establishment). state establishment).
7. The values of Rdef, K, and Slew.Max used in an implementation 7. The values of Rdef, K, and Slew.Max used in an implementation
should be easily modifiable per interface, as experience may should be easily modifiable per interface, as experience may
lead to different values. The possibility of dynamically lead to different values. The possibility of dynamically
adapting K and/or Slew.Max in response to measured loss rates adapting K and/or Slew.Max in response to measured loss rates
is for future study. is for future study.
The granularity of state for refresh and timeout is as follows:
o For reservation state, each FLOWSPEC is independently
refreshed and timed out.
o For path state, each sender is independently refreshed and
timed out.
3.7 Traffic Policing and Non-Integrated Service Hops 3.7 Traffic Policing and Non-Integrated Service Hops
Some QoS services may require traffic policing at some or all of Some QoS services may require traffic policing at some or all of
(1) the edge of the network, (2) a merging point for data from (1) the edge of the network, (2) a merging point for data from
multiple senders, and/or (3) a branch point where traffic flow multiple senders, and/or (3) a branch point where traffic flow
from upstream may be greater than the downstream reservation being from upstream may be greater than the downstream reservation being
requested. RSVP knows where such points occur and must so requested. RSVP knows where such points occur and must so
indicate to the traffic control mechanism. On the other hand, indicate to the traffic control mechanism. On the other hand,
RSVP does not interpret the service embodied in the flowspec and RSVP does not interpret the service embodied in the flowspec and
therefore does not know whether policing will actually be applied therefore does not know whether policing will actually be applied
skipping to change at page 54, line 22 skipping to change at page 55, line 41
o B_Police_Flag -- Branch Policing o B_Police_Flag -- Branch Policing
This flag should be set on when the flowspec being installed This flag should be set on when the flowspec being installed
is smaller than, or incomparable to, a FLOWSPEC in place on is smaller than, or incomparable to, a FLOWSPEC in place on
any other interface, for the same FILTER_SPEC and SESSION. any other interface, for the same FILTER_SPEC and SESSION.
RSVP must also detect and report to receivers the presence of RSVP must also detect and report to receivers the presence of
non-RSVP (which implies non-integrated-service compliant) hops in non-RSVP (which implies non-integrated-service compliant) hops in
the path. For this purpose, an RSVP daemon sets the Non_RSVP flag the path. For this purpose, an RSVP daemon sets the Non_RSVP flag
bit in SESSION object of PATH messages. With normal IP bit in SESSION object of Path messages. With normal IP
forwarding, RSVP can detect a non-RSVP hop by comparing the IP TTL forwarding, RSVP can detect a non-RSVP hop by comparing the IP TTL
with which a PATH message is sent to the TTL with which it is with which a Path message is sent to the TTL with which it is
received, and set the Non_RSVP bit on. For this purpose, the received, and set the Non_RSVP bit on. For this purpose, the
transmission TTL is placed in the common header. transmission TTL is placed in the common header.
However, the TTL is not always a reliable indicator of non-RSVP However, the TTL is not always a reliable indicator of non-RSVP
hops, and other means must be used. For example, if the routing hops, and other means must be used. For example, if the routing
protocol uses IP encapsulating tunnels, then the routing protocol protocol uses IP encapsulating tunnels, then the routing protocol
must inform RSVP when non-RSVP hops are included. If no automatic must inform RSVP when non-RSVP hops are included. If no automatic
mechanism will work, manual configuration will be required. mechanism will work, manual configuration will be required.
Finally, there may still be cases where an RSVP cannot reliably Finally, there may still be cases where an RSVP cannot reliably
determine whether or not a non-RSVP hop was used. To report this determine whether or not a non-RSVP hop was used. To report this
to the receiver, the SESSION object carries another flag bit, to the receiver, the SESSION object carries another flag bit,
Maybe_RSVP. Maybe_RSVP.
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 [could ref. section systems) with more than one network interface and routers that are
3.3.4 of RFC-1122], and routers that are supporting local supporting local application programs.
application programs.
An application executing on a multihomed host may explicitly An application executing on a multihomed host may explicitly
specify which interface any given flow will use for sending and/or specify which interface any given flow will use for sending and/or
for receiving data packets, to override the system-specified for receiving data packets, to override the system-specified
default interface. The RSVP daemon must be aware of the default, default interface. The RSVP daemon must be aware of the default,
and if an application sets a specific interface, it must also pass and if an application sets a specific interface, it must also pass
that information to RSVP. that information to RSVP.
o Sending Data o Sending Data
A sender application uses an API call (SENDER in Section A sender application uses an API call (SENDER in Section
3.10.1) to declare to RSVP the characteristics of the data 3.10.1) to declare to RSVP the characteristics of the data
flow it will originate. This call may optionally include the flow it will originate. This call may optionally include the
local IP address of the sender. If it is set by the local IP address of the sender. If it is set by the
application, this parameter must be the interface address for application, this parameter must be the interface address for
sending the data packets; otherwise, the system default sending the data packets; otherwise, the system default
interface is implied. interface is implied.
The RSVP daemon on the host then sends PATH messages for this The RSVP daemon on the host then sends Path messages for this
application out the specified interface (only). application out the specified interface (only).
o Making Reservations o Making Reservations
A receiver application uses an API call (RESERVE in Section A receiver application uses an API call (RESERVE in Section
3.10.1) to request a reservation from RSVP. This call may 3.10.1) to request a reservation from RSVP. This call may
optionally include the local IP address of the receiver, optionally include the local IP address of the receiver,
i.e., the interface address for receiving data packets. In i.e., the interface address for receiving data packets. In
the case of multicast sessions, this is the interface on the case of multicast sessions, this is the interface on
which the group has been joined. If the parameter is which the group has been joined. If the parameter is
omitted, the system default interface is used. omitted, the system default interface is used.
In general, the RSVP daemon should send RESV messages for an In general, the RSVP daemon should send Resv messages for an
application out the specified interface. However, when the application out the specified interface. However, when the
application is executing on a router and the session is application is executing on a router and the session is
multicast, a more complex situation arises. Suppose in this multicast, a more complex situation arises. Suppose in this
case that a receiver application joins the group on an case that a receiver application joins the group on an
interface Iapp that differs from Isp, the shortest-path interface Iapp that differs from Isp, the shortest-path
interface to the sender. Then there are two possible ways interface to the sender. Then there are two possible ways
for multicast routing to deliver data packets to the for multicast routing to deliver data packets to the
application. The RSVP daemon must determine which case holds application. The RSVP daemon must determine which case holds
by examining the path state, to decide which incoming by examining the path state, to decide which incoming
interface to use for sending RESV messages. interface to use for sending Resv messages.
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 Isp and Iapp. The path state on Iapp should only
match a reservation from the local application; it must match a reservation from the local application; it must
be marked "Local_only" by the RSVP daemon. If be marked "Local_only" by the RSVP daemon. If
"Local_only" path state for Iapp exists, the RESV "Local_only" path state for Iapp exists, the Resv
message should be sent out Iapp. 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.9 Future Compatibility 3.9 Future Compatibility
We may expect that in the future new object C-Types will be We may expect that in the future new object C-Types will be
defined for existing object classes, and perhaps new object defined for existing object classes, and perhaps new object
classes will be defined. It will be desirable to employ such new classes will be defined. It will be desirable to employ such new
objects within the Internet using older implementations that do objects within the Internet using older implementations that do
not recognize them. Unfortunately, this is only possible to a not recognize them. Unfortunately, this is only possible to a
limited degree with reasonable complexity. The rules are as limited degree with reasonable complexity. The rules are as
skipping to change at page 56, line 34 skipping to change at page 58, line 4
treat an object with unknown class. This choice is treat an object with unknown class. This choice is
determined by the two high-order bits of the Class-Num octet, determined by the two high-order bits of the Class-Num octet,
as follows. as follows.
o Class-Num = 0bbbbbbb o Class-Num = 0bbbbbbb
The entire message should be rejected and an "Unknown The entire message should be rejected and an "Unknown
Object Class" error returned. Object Class" error returned.
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 the state contained in this message.
For example, suppose that a RESV message that is received For example, suppose that a Resv message that is received
contains an object of unknown class number 11bbbbbb. Such an contains an object of unknown class number 11bbbbbb. Such an
object should be saved in the reservation state without object should be saved in the reservation state without
further examination; however, only the latest object with a further examination; however, only the latest object with a
given (unknown class, C-Type) pair should be saved. When a given (unknown class, C-Type) pair should be saved. When a
RESV message is forwarded, it should include copies of such Resv message is forwarded, it should include copies of such
saved unknown-class objects from all reservations that are saved unknown-class objects from all reservations that are
merged to form the new RESV message. merged to form the new Resv message.
Note that objects with unknown class cannot be merged; Note that objects with unknown class cannot be merged;
however, unmerged objects may be forwarded until they reach a however, unmerged objects may be forwarded until they reach a
node that knows how to merge them. Forwarding objects with node that knows how to merge them. Forwarding objects with
unknown class enables incremental deployment of new objects; unknown class enables incremental deployment of new objects;
however, the scaling limitations of doing so must be however, the scaling limitations of doing so must be
carefully examined before a new object class is deployed with carefully examined before a new object class is deployed with
both high bits on. both high bits on.
These rules should be considered when any new Class-Num is These rules should be considered when any new Class-Num is
skipping to change at page 57, line 25 skipping to change at page 58, line 42
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
generation of an error message (RERR or PERR as appropriate). generation of an error message (ResvErr or PathErr as
The error message will include the Class-Num and C-Type that appropriate). The error message will include the Class-Num
failed (see Appendix B); the end system that originated the and C-Type that failed (see Appendix B); the end system that
failed message may be able to use this information to retry originated the failed message may be able to use this
the request using a different C-Type object, repeating this information to retry the request using a different C-Type
process until it runs out of alternatives or succeeds. object, repeating this process until it runs out of
alternatives or succeeds.
Objects of certain classes (FLOWSPEC, ADSPEC, and Objects of certain classes (FLOWSPEC, ADSPEC, and
POLICY_DATA) are opaque to RSVP, which simply hands them to POLICY_DATA) are opaque to RSVP, which simply hands them to
traffic control or policy modules. Depending upon its traffic control or policy modules. Depending upon its
internal rules, either of the latter modules may reject a C- internal rules, either of the latter modules may reject a C-
Type and inform the RSVP daemon; RSVP should then reject the Type and inform the RSVP daemon; RSVP should then reject the
message and send an error, as described in the previous message and send an error, as described in the previous
paragraph. paragraph.
3.10 RSVP Interfaces 3.10 RSVP Interfaces
skipping to change at page 59, line 7 skipping to change at page 61, line 7
[ , Source_Address ] [ , Source_Port ] [ , Source_Address ] [ , Source_Port ]
[ , Sender_Template ] [ , Sender_Template ]
[ , Sender_Tspec ] [ , Data_TTL ] [ , Sender_Tspec ] [ , Data_TTL ]
[ , Sender_Policy_Data ] ) [ , Sender_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
This is the address of the interface from which the This is the address of the interface from which the
data will be sent. If it is omitted, a default data will be sent. If it is omitted, a default
interface will be used. This parameter is needed on interface will be used. This parameter is needed on
skipping to change at page 60, line 14 skipping to change at page 62, line 14
o Reserve o Reserve
Call: RESERVE( session-id, [ receiver_address , ] Call: RESERVE( session-id, [ receiver_address , ]
[ CONF_flag, ] style, style-dependent-parms ) [ CONF_flag, ] style, style-dependent-parms )
A receiver uses this call to make or to modify a resource A receiver uses this call to make or to modify a resource
reservation for the session registered as `session-id'. reservation for the session registered as `session-id'.
The first RESERVE call will initiate the periodic The first RESERVE call will initiate the periodic
transmission of RESV messages. A later RESERVE call may transmission of Resv messages. A later RESERVE call may
be given to modify the parameters of the earlier call (but be given to modify the parameters of the earlier call (but
note that changing existing reservations may result in note that changing existing reservations may result in
admission control failures). admission control failures).
The optional `receiver_address' parameter may be used by a The optional `receiver_address' parameter may be used by a
receiver on a multihomed host (or router); it is the IP receiver on a multihomed host (or router); it is the IP
address of one of the node's interfaces. The CONF_flag address of one of the node's interfaces. The CONF_flag
should be set on if a reservation confirmation is desired, should be set on if a reservation confirmation is desired,
off otherwise. The `style' parameter indicates the off otherwise. The `style' parameter indicates the
reservation style. The rest of the parameters depend upon reservation style. The rest of the parameters depend upon
skipping to change at page 61, line 14 skipping to change at page 63, line 14
occur asynchronously at any time after a SESSION call and occur asynchronously at any time after a SESSION call and
before a RELEASE call, to indicate an error or an event. before a RELEASE call, to indicate an error or an event.
Currently there are five upcall types, distinguished by Currently there are five upcall types, distinguished by
the Info_type parameter. The selection of information the Info_type parameter. The selection of information
parameters depends upon the type. parameters depends upon the type.
1. Info_type = PATH_EVENT 1. Info_type = PATH_EVENT
A Path Event upcall results from receipt of the first A Path Event upcall results from receipt of the first
PATH message for this session, indicating to a Path message for this session, indicating to a
receiver application that there is at least one receiver application that there is at least one
active sender. active sender.
Upcall: <Upcall_Proc>( ) -> session-id, Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=PATH_EVENT, Info_type=PATH_EVENT,
flags, flags,
Sender_Tspec, Sender_Template, Sender_Tspec, Sender_Template,
[ , Advert ] [ , Policy_data ] [ , Advert ] [ , Policy_data ]
This upcall presents the Sender_Tspec and the This upcall presents the Sender_Tspec and the
Sender_Template from a PATH message; it also passes Sender_Template from a Path message; it also passes
the advertisement and policy data if they are the advertisement and policy data if they are
present. The possible flags correspond to Non_RSVP present. The possible flags correspond to Non_RSVP
and Maybe_RSVP flags of the SESSION object. 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,
Style, Flowspec, Filter_Spec_list, Style, Flowspec, Filter_Spec_list,
[ , Policy_data ] [ , Policy_data ]
Here `Flowspec' will be the effective QoS that has Here `Flowspec' will be the effective QoS that has
been received. Note that an FF-style RESV message been received. Note that an FF-style Resv message
may result in multiple RESV_EVENT upcalls, one for may result in multiple RESV_EVENT upcalls, one for
each flow descriptor. each flow descriptor.
3. Info_type = PATH_ERROR 3. Info_type = PATH_ERROR
An Path Error event indicates an error in sender An Path Error event indicates an error in sender
information that was specified in a SENDER call. information that was specified in a SENDER call.
Upcall: <Upcall_Proc>( ) -> session-id, Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=PATH_ERROR, Info_type=PATH_ERROR,
Error_code , Error_value , Error_code , Error_value ,
Error_Node , Sender_Template, Error_Node , Sender_Template,
[ Policy_data ] [ Policy_data_list ]
The Error_code parameter will define the error, and The Error_code parameter will define the error, and
Error_value may supply some additional (perhaps Error_value may supply some additional (perhaps
system-specific) data about the error. The system-specific) data about the error. The
Error_Node parameter will specify the IP address of Error_Node parameter will specify the IP address of
the node that detected the error. The Policy_data the node that detected the error. The
parameter, if present, will contain the POLICY_DATA Policy_data_list parameter, if present, will contain
object from the failed PATH message. any POLICY_DATA objects from the failed Path message.
4. Info_type = RESV_ERR 4. Info_type = RESV_ERR
An Resv Error event indicates an error in a An Resv Error event indicates an error in a
reservation message to which this application reservation message to which this application
contributed. contributed.
Upcall: <Upcall_Proc>( ) -> session-id, Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=RESV_ERROR, Info_type=RESV_ERROR,
Error_code , Error_value , Error_code , Error_value ,
Error_Node , Error_flags , Error_Node , Error_flags ,
Flowspec, Filter_spec_list, Flowspec, Filter_spec_list,
[ Policy_data ] [ Policy_data_list ]
The Error_code parameter will define the error and The Error_code parameter will define the error and
Error_value may supply some additional (perhaps Error_value may supply some additional (perhaps
system-specific) data. The Error_Node parameter will system-specific) data. The Error_Node parameter will
specify the IP address of the node that detected the specify the IP address of the node that detected the
event being reported. event being reported.
There are two Error_flags: There are two Error_flags:
- InPlace - InPlace
This flag may be on for an Admission Control This flag may be on for an Admission Control
failure, to indicate that there was, and is, a failure, to indicate that there was, and is, a
reservation in place at the failure node. This reservation in place at the failure node. This
flag is set at the failure point and forwarded flag is set at the failure point and forwarded
in RERR messages. in ResvErr messages.
- 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.6). 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 in the RERR message. POLICY_DATA objects from the ResvErr message.
5. Info_type = RESV_CONFIRM 5. Info_type = RESV_CONFIRM
A Confirmation event indicates that a RACK message A Confirmation event indicates that a ResvConf
was received. message was received.
Upcall: <Upcall_Proc>( ) -> session-id, Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=RESV_CONFIRM, Info_type=RESV_CONFIRM,
Style, List_count, Style, List_count,
Flowspec, Filter_spec_list, Flowspec, Filter_spec_list,
[ Policy_data ] [ Policy_data ]
skipping to change at page 66, line 21 skipping to change at page 68, line 21
An RSVP implementation needs the following support from the An RSVP implementation needs the following support from the
packet forwarding and routing mechanisms of the node. packet forwarding and routing mechanisms of the node.
o Promiscuous Receive Mode for RSVP Messages o Promiscuous Receive Mode for RSVP Messages
Packets received for IP protocol 46 but not addressed to Packets received for IP protocol 46 but not addressed to
the node must be diverted to the RSVP program for the node must be diverted to the RSVP program for
processing, without being forwarded. On a router, the processing, without being forwarded. On a router, the
identity of the interface, real or virtual, on which it is identity of the interface, real or virtual, on which it is
received must also be available to the RSVP daemon. received as well as the IP source address and IP TTL with
which it arrived must also be available to the RSVP
daemon.
The RSVP messages to be diverted will carry the Router The RSVP messages to be diverted will carry the Router
Alert IP option, which can be used to pick them out of a Alert IP option, which can be used to pick them out of a
high-speed forwarding path. Alternatively, the node can high-speed forwarding path. Alternatively, the node can
intercept all protocol 46 packets. intercept all protocol 46 packets.
When an RSVP message (fragment) is handed to RSVP, the
actual length received must also be passed.
o Route Query o Route Query
To forward PATH and PTEAR messages, an RSVP daemon must be To forward Path and PathTear messages, an RSVP daemon must
able to query the routing daemon(s) for routes. be able to query the routing daemon(s) for routes.
Ucast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag ) Ucast_Route_Query( [ SrcAddress, ] DestAddress,
-> OutInterface Notify_flag ) -> OutInterface
Mcast_Route_Query( [ SrcAddress, ] DestAddress, Notify_flag ) Mcast_Route_Query( [ SrcAddress, ] DestAddress,
Notify_flag )
-> [ IncInterface, ] OutInterface_list -> [ IncInterface, ] OutInterface_list
Depending upon the routing protocol, the query may or may Depending upon the routing protocol, the query may or may
not depend upon SrcAddress, i.e., upon the sender host IP not depend upon SrcAddress, i.e., upon the sender host IP
address, which is also the IP source address of the address, which is also the IP source address of the
message. Here IncInterface is the interface through which message. Here IncInterface is the interface through which
the packet is expected to arrive; some multicast routing the packet is expected to arrive; some multicast routing
protocols may not provide it. If the Notify_flag is True, protocols may not provide it. If the Notify_flag is True,
routing will save state necessary to issue unsolicited routing will save state necessary to issue unsolicited
route change notification callbacks (see below) whenever route change notification callbacks (see below) whenever
the specified route changes. the specified route changes.
A multicast route query may return an empty A multicast route query may return an empty
OutInterface_list if there are no receivers downstream of OutInterface_list if there are no receivers downstream of
a particular router. A route query may also return a `No a particular router. A route query may also return a `No
such route' error, probably as a result of a transient such route' error, probably as a result of a transient
inconsistency in the routing (since a PATH or PTEAR inconsistency in the routing (since a Path or PathTear
message for the requested route did arrive at this node). message for the requested route did arrive at this node).
In either case, the local state should be updated as In either case, the local state should be updated as
requested by the message, which cannot be forwarded requested by the message, which cannot be forwarded
further. Updating local state will make path state further. Updating local state will make path state
available immediately for a new local receiver, or it will available immediately for a new local receiver, or it will
tear down path state immediately. tear down path state immediately.
o Route Change Notification o Route Change Notification
If requested by a route query with the Notify_flag True, If requested by a route query with the Notify_flag True,
skipping to change at page 67, line 38 skipping to change at page 69, line 44
[ IncInterface, ] OutInterface_list [ IncInterface, ] OutInterface_list
o Outgoing Link Specification o Outgoing Link Specification
RSVP must be able to force a (multicast) datagram to be RSVP must be able to force a (multicast) datagram to be
sent on a specific outgoing virtual link, bypassing the sent on a specific outgoing virtual link, bypassing the
normal routing mechanism. A virtual link may be a real normal routing mechanism. A virtual link may be a real
outgoing link or a multicast tunnel. Outgoing link outgoing link or a multicast tunnel. Outgoing link
specification is necessary to send different versions of specification is necessary to send different versions of
an outgoing PATH message on different interfaces. It is an outgoing Path message on different interfaces. It is
also necessary in some cases to avoid routing loops. also necessary in some cases to avoid routing loops.
o Source Address Specification o Source Address Specification
RSVP must be able to specify the IP source address to be RSVP must be able to specify the IP source address to be
used when sending PATH messages. used when sending Path messages.
o Interface List Discovery o Interface List Discovery
RSVP must be able to learn what real and virtual RSVP must be able to learn what real and virtual
interfaces are active, with their IP addresses. interfaces are active, with their IP addresses.
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.10.4 Service-Dependent Manipulations 3.10.4 Service-Dependent Manipulations
Flowspecs, Tspecs, and Adspecs are opaque objects to RSVP; Flowspecs, Tspecs, and Adspecs are opaque objects to RSVP;
their contents are defined in service specification documents. their contents are defined in service specification documents.
In order to manipulate these objects, RSVP daemon must have In order to manipulate these objects, RSVP daemon must have
available to it the following service-dependent routines. available to it the following service-dependent routines.
o Compare Flowspecs o Compare Flowspecs
Compare_Flowspecs( Flowspec_1, Flowspec_2 ) -> result_code Compare_Flowspecs( Flowspec_1, Flowspec_2 ) ->
result_code
The possible result_codes indicate: flowspecs are equal, The possible result_codes indicate: flowspecs are equal,
Flowspec_1 is greater, Flowspec_2 is greater, flowspecs Flowspec_1 is greater, Flowspec_2 is greater, flowspecs
are incomparable but LUB can be computed, or flowspecs are are incomparable but LUB can be computed, or flowspecs are
incompatible. incompatible.
Note that comparing two flowspecs implicitly compares the Note that comparing two flowspecs implicitly compares the
Tspecs that are contained. Although the RSVP daemon Tspecs that are contained. Although the RSVP daemon
cannot itself parse a flowspec to extract the Tspec, it cannot itself parse a flowspec to extract the Tspec, it
can use the Compare_Flowspecs call to implicitly calculate can use the Compare_Flowspecs call to implicitly calculate
skipping to change at page 70, line 21 skipping to change at page 72, line 21
This section assumes the generic interface calls defined in Section This section assumes the generic interface calls defined in Section
3.10 and the following data structures. An actual implementation may 3.10 and the following data structures. An actual implementation may
use additional or different data structures and interfaces. The data use additional or different data structures and interfaces. The data
structure fields that a shown are required unless they are explicitly structure fields that a shown are required unless they are explicitly
labelled as optional. labelled as optional.
o PSB -- Path State Block o PSB -- Path State Block
Each PSB holds path state for a particular (session, sender) Each PSB holds path state for a particular (session, sender)
pair, defined by SESSION and SENDER_TEMPLATE objects, pair, defined by SESSION and SENDER_TEMPLATE objects,
respectively, received in a PATH message. respectively, received in a Path message.
PSB contents include the following values from a PATH message: PSB contents include the following values from a Path message:
- Session - Session
- Sender_Template - Sender_Template
- 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
skipping to change at page 71, line 5 skipping to change at page 73, line 5
In addition, the PSB contains the following information provided In addition, the PSB contains the following information provided
by routing: OutInterface_list, which is the list of outgoing by routing: OutInterface_list, which is the list of outgoing
interfaces for this (sender, destination), and IncInterface, interfaces for this (sender, destination), and IncInterface,
which is the expected incoming interface. For a unicast which is the expected incoming interface. For a unicast
destination, OutInterface_list contains one entry and destination, OutInterface_list contains one entry and
IncInterface is undefined. IncInterface is undefined.
o RSB -- Reservation State Block o RSB -- Reservation State Block
Each RSB holds a reservation request that arrived in a Each RSB holds a reservation request that arrived in a
particular RESV message, corresponding to the triple: (session, particular Resv message, corresponding to the triple: (session,
next hop, Filter_spec_list). Here "Filter_spec_list" may be a next hop, Filter_spec_list). Here "Filter_spec_list" may be a
list of FILTER_SPECs (for SE style), a single FILTER_SPEC (FF list of FILTER_SPECs (for SE style), a single FILTER_SPEC (FF
style), or empty (WF style). We define a virtual object type style), or empty (WF style). We define a virtual object type
"FILTER_SPEC*" for such a data structure. "FILTER_SPEC*" for such a data structure.
RSB contents include: RSB contents include:
- Session specification - Session specification
- Next hop IP address - Next hop IP address
skipping to change at page 72, line 48 skipping to change at page 74, line 48
The following other variables are also used in this section: Boolean The following other variables are also used in this section: Boolean
flags Path_Refresh_Needed, Resv_Refresh_Needed, Tear_Needed, flags Path_Refresh_Needed, Resv_Refresh_Needed, Tear_Needed,
Need_Scope, B_Merge, and NeworMod, and Refresh_PHOP_list, a Need_Scope, B_Merge, and NeworMod, and Refresh_PHOP_list, a
variable-length list of PHOPs to be refreshed. variable-length list of PHOPs to be refreshed.
MESSAGE ARRIVES MESSAGE ARRIVES
Verify version number and RSVP checksum, and discard message if any Verify version number and RSVP checksum, and discard message if any
mismatch is found. mismatch is found.
If the message type is not PATH or PTEAR and if the IP destination If the message type is not Path or PathTear and if the IP destination
address does not match any of the addresses of the local interfaces, address does not match any of the addresses of the local interfaces,
then forward the message to IP destination address and return. then forward the message to IP destination address and return.
Verify the INTEGRITY object, if any. If the check fails, discard the Verify the INTEGRITY object, if any. If the check fails, discard the
message and return. message and return.
Reassemble fragments of message. Reassemble fragments of message.
Parse the sequence of objects in the message, and discard message if Parse the sequence of objects in the message, and discard message if
any required objects are missing. Verify the length field of the any required objects are missing. Verify the length field of the
common header, and discard message if there is a mismatch. common header, and discard message if there is a mismatch.
Verify the consistent use of port fields. If the DstPort in the Verify the consistent use of port fields. If the DstPort in the
SESSION object is zero but the SrcPort in a SENDER_TEMPLATE or SESSION object is zero but the SrcPort in a SENDER_TEMPLATE or
FILTER_SPEC object is non-zero, the the message has a "conflicting FILTER_SPEC object is non-zero, the the message has a "conflicting
source port" error; discard the message and return. source port" error; discard the message and return.
Further processing depends upon message type. Further processing depends upon message type.
PATH MESSAGE ARRIVES Path MESSAGE ARRIVES
Process the sender descriptor object sequence in the message as Process the sender descriptor object sequence in the message as
follows. The Path_Refresh_Needed and Resv_Refresh_Needed flags follows. The Path_Refresh_Needed and Resv_Refresh_Needed flags
are initially off. are initially off.
o If there is a POLICY_DATA object, verify it; if it is o If there is a POLICY_DATA object, verify it; if it is
unacceptable, build and send a "Administrative Rejection" unacceptable, build and send a "Administrative Rejection"
PERR message, drop the PATH message, and return. PathErr message, drop the Path message, and return.
o Search for a path state block (PSB) whose (session, o Search for a path state block (PSB) whose (session,
sender_template) pair matches the corresponding objects in sender_template) pair matches the corresponding objects in
the message. the message.
o If, during the PSB search, a PSB is found whose session o If, during the PSB search, a PSB is found whose session
matches the DestAddress and Protocol Id fields of the matches the DestAddress and Protocol Id fields of the
received SESSION object, but the DstPorts differ and one is received SESSION object, but the DstPorts differ and one is
zero, then build and send a "Conflicting Dst Port" PERR zero, then build and send a "Conflicting Dst Port" PathErr
message, drop the PATH message, and return. message, drop the Path message, and return.
o If, during the PSB search, a PSB is found with a matching o If, during the PSB search, a PSB is found with a matching
sender host but the SrcPorts differ and one of the SrcPorts sender host but the SrcPorts differ and one of the SrcPorts
is zero, then build and send an "Ambiguous Path" PERR is zero, then build and send an "Ambiguous Path" PathErr
message, drop the PATH message, and return. message, drop the Path message, and return.
o If there was no matching PSB, then: o If there was no matching PSB, then:
1. Create a new PSB. 1. Create a new PSB.
2. Copy contents of the SESSION, SENDER_TEMPLATE, 2. Copy contents of the SESSION, SENDER_TEMPLATE,
SENDER_TSPEC, and PHOP (IP address and LIH) objects SENDER_TSPEC, and PHOP (IP address and LIH) objects
into the PSB. into the PSB.
3. Calculate initial routing information. If the sender 3. Calculate initial routing information. If the sender
skipping to change at page 74, line 32 skipping to change at page 76, line 32
o Otherwise (there is a matching PSB and there is no dest o Otherwise (there is a matching PSB and there is no dest
port conflict): port conflict):
1. If there is no route change notification in place, 1. If there is no route change notification in place,
call the appropriate Route_Query routine using call the appropriate Route_Query routine using
DestAddress from SESSION and (for multicast routing) DestAddress from SESSION and (for multicast routing)
SrcAddress from Sender_Template. SrcAddress from Sender_Template.
- If the OutInterface_list that is returned differs - If the OutInterface_list that is returned differs
from that in the PSB, then execute the PATH LOCAL from that in the PSB, then execute the Path LOCAL
REPAIR event sequence below. REPAIR event sequence below.
- If a multicast message arrived on an interface - If a multicast message arrived on an interface
different from IncInterface, then execute the different from IncInterface, then execute the
RESV REFRESH event sequence below for the Resv REFRESH event sequence below for the
previous hop. previous hop.
2. If the PHOP IP address, the LIH, or Sender_Tspec 2. If the PHOP IP address, the LIH, or Sender_Tspec
differs between the message and the PSB, copy the new differs between the message and the PSB, copy the new
value into the PSB and turn on the Path_Refresh_Needed value into the PSB and turn on the Path_Refresh_Needed
flag. flag.
o If the message contains an ADSPEC object, copy it into the o If the message contains an ADSPEC object, copy it into the
PSB. PSB.
skipping to change at page 75, line 11 skipping to change at page 77, line 11
o Copy E_Police flag from SESSION object into PSB. o Copy E_Police flag from SESSION object into PSB.
o Store the received TTL into the PSB. o Store the received TTL into the PSB.
If the the received TTL differs from Send_TTL in the RSVP If the the received TTL differs from Send_TTL in the RSVP
common header, set the Non_RSVP flag on in the PSB. common header, set the Non_RSVP flag on in the PSB.
o The Path_Refresh_Needed flag is now set if the path state o The Path_Refresh_Needed flag is now set if the path state
is new or modified. If so: is new or modified. If so:
1. If this PATH message came from a network interface and 1. If this Path message came from a network interface and
not from a local application, make a Path Event upcall not from a local application, make a Path Event upcall
for each local application for this session: for each local application for this session:
Call: <Upcall_Proc>( session-id, PATH_EVENT, Call: <Upcall_Proc>( session-id, PATH_EVENT,
flags, sender_tspec, sender_template, flags, sender_tspec, sender_template,
[ADSPEC], [POLICY_DATA] ) [ADSPEC], [POLICY_DATA] )
2. Execute the PATH REFRESH event sequence (below) for 2. Execute the Path REFRESH event sequence (below) for
the sender defined by the PSB. the sender defined by the PSB.
3. If there is no reservation state for this SESSION 3. If there is no reservation state for this SESSION
(i.e., no RSB's exist), then drop the PATH message and (i.e., no RSB's exist), then drop the Path message and
return. return.
4. Otherwise (there is reservation state): 4. Otherwise (there is reservation state):
- Execute the event sequence UPDATE TRAFFIC CONTROL - Execute the event sequence UPDATE TRAFFIC CONTROL
below, to update the local traffic control state below, to update the local traffic control state
if necessary. This will turn on the if necessary. This will turn on the
Resv_Refresh_Needed flag if the traffic control Resv_Refresh_Needed flag if the traffic control
state changes; if so, execute the RESV REFRESH state changes; if so, execute the Resv REFRESH
event sequence (below) for the sender in the PSB. event sequence (below) for the sender in the PSB.
However, if the PATH message came from a local However, if the Path message came from a local
application, then make a RESV_EVENT upcall to application, then make a RESV_EVENT upcall to
that application. that application.
o Drop the PATH message and return. o Drop the Path message and return.
PATH TEAR 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 PTEAR message and return. matching PSB is found, drop the PathTear message and
return.
o Forward a copy of the PTEAR 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., that 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 tear down the RSB, If this RSB matches no other PSB, then tear down the RSB,
as described below under RESV TEAR MESSAGE ARRIVES. as described below under ResvTear MESSAGE ARRIVES.
o Delete the PSB. o Delete the PSB.
o Drop the PTEAR message and return. o Drop the PathTear message and return.
PATH ERROR 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 PERR message and return. matching PSB is found, drop the PathErr message and return.
o If the previous hop address in the PSB is the local API, o If the previous hop address in the PSB is the local API,
make an error upcall to the application: make an error upcall to the application:
Call: <Upcall_Proc>( session-id, PATH_ERROR, Call: <Upcall_Proc>( session-id, PATH_ERROR,
Error_code, Error_value, Error_code, Error_value,
Node_Addr, Sender_Template, Node_Addr, Sender_Template,
[Policy_Data] ) [Policy_Data] )
Any SENDER_TSPEC or ADSPEC object in the message is Any SENDER_TSPEC or ADSPEC object in the message is
ignored. ignored.
Otherwise, send a copy of the PERR message to the PHOP IP Otherwise, send a copy of the PathErr message to the PHOP
address. IP address.
o Drop the PERR message and return. o Drop the PathErr message and return.
RESV MESSAGE ARRIVES Resv MESSAGE ARRIVES
Initially, Refresh_PHOP_list is empty and the Initially, Refresh_PHOP_list is empty and the
Resv_Refresh_Needed and NeworMod flags are off. These variables Resv_Refresh_Needed and NeworMod flags are off. These variables
are used to control immediate reservation refreshes. are used to control immediate reservation refreshes.
o Determine the Outgoing Interface OI o Determine the Outgoing Interface OI
The logical outgoing interface OI is taken from the LIH in The logical outgoing interface OI is taken from the LIH in
the NHOP object. (If the physical interface is not implied the NHOP object. (If the physical interface is not implied
by the LIH, it can be learned from the interface matching by the LIH, it can be learned from the interface matching
the IP destination address). the IP destination address).
o Check the SESSION object. o Check the SESSION object.
If there are no existing PSB's for SESSION then build and If there are no existing PSB's for SESSION then build and
send a RERR message (as described later) specifying "No send a ResvErr message (as described later) specifying "No
path information", drop the RESV message, and return. path information", drop the Resv message, and return.
o Check the S_POLICY_DATA object. o Check the S_POLICY_DATA object.
If there is an S_POLICY_DATA object in the message, check If there is an S_POLICY_DATA object in the message, check
permission to create a reservation for the session. If the permission to create a reservation for the session. If the
check fails, build and send an "Administrative rejection" check fails, build and send an "Administrative rejection"
RERR message, drop the RESV message, and return. ResvErr message, drop the Resv message, and return.
Otherwise, copy the S_POLICY_DATA object into the RSB. Otherwise, copy the S_POLICY_DATA object into the RSB.
o Check for incompatible styles. o Check for incompatible styles.
If any existing RSB for the session has a style that is If any existing RSB for the session has a style that is
incompatible with the style of the message, build and send incompatible with the style of the message, build and send
a RERR message specifying "Conflicting Style", drop the a ResvErr message specifying "Conflicting Style", drop the
RESV message, and return. Resv message, and return.
Process the flow descriptor list to make reservations, as Process the flow descriptor list to make reservations, as
follows, depending upon the style. The following uses a filter follows, depending upon the style. The following uses a filter
spec list struct Filtss, of type FILTER_SPEC* (defined earlier). spec list struct Filtss, of type FILTER_SPEC* (defined earlier).
For FF style: execute the following steps independently for each For FF style: execute the following steps independently for each
flow descriptor in the message, i.e., for each (FLOWSPEC, flow descriptor in the message, i.e., for each (FLOWSPEC,
Filtss) pair. Here the structure Filtss consists of the Filtss) pair. Here the structure Filtss consists of the
FILTER_SPEC from the flow descriptor. FILTER_SPEC from the flow descriptor.
For SE style, execute the following steps once for (FLOWSPEC, For SE style, execute the following steps once for (FLOWSPEC,
Filtss), with Filtss consisting of the list of FILTER_SPEC Filtss), with Filtss consisting of the list of FILTER_SPEC
objects from the flow descriptor. objects from the flow descriptor.
For WF style, execute the following steps once for (FLOWSPEC, For WF style, execute the following steps once for (FLOWSPEC,
Filtss), with Filtss an empty list. Filtss), with Filtss an empty list.
o If the DstPort in the SESSION object is zero but the o If the DstPort in the SESSION object is zero but the
SrcPort in a FILTER_SPEC object (in Filtss) is non-zero, SrcPort in a FILTER_SPEC object (in Filtss) is non-zero,
build nd send a "Conflicting Src Port" RERR message, drop build nd send a "Conflicting Src Port" ResvErr message,
the RESV message, and return. drop the Resv message, and return.
o Check the path state, as follows. o Check the path state, as follows.
1. Locate the set of PSBs (senders) whose 1. Locate the set of PSBs (senders) whose
SENDER_TEMPLATEs match Filtss and whose SENDER_TEMPLATEs match Filtss and whose
OutInterface_list includes OI. OutInterface_list includes OI.
If this set is empty, build and send an error message If this set is empty, build and send an error message
specifying "No sender information", and continue with specifying "No sender information", and continue with
the next flow descriptor in the RESV message. the next flow descriptor in the Resv message.
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 RERR 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. 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 the o Find or create a reservation state block (RSB) for the
triple: (session, NHOP, Filtss). Call this the "active triple: (session, NHOP, Filtss). Call this the "active
RSB". RSB".
o If the active RSB is new: o If the active RSB is new:
skipping to change at page 78, line 45 skipping to change at page 80, line 45
o Start or restart the cleanup timer on the the active RSB. o Start or restart the cleanup timer on the the active RSB.
o If there is a RESV_CONFIRM in the message, turn on o If there is a RESV_CONFIRM in the message, turn on
Resv_Refresh_Needed and save the object in the RSB. Resv_Refresh_Needed and save the object in the RSB.
o If the active RSB is not new, check whether STYLE, FLOWSPEC o If the active RSB is not new, check whether STYLE, FLOWSPEC
or SCOPE objects have changed; if so, copy changed object or SCOPE objects have changed; if so, copy changed object
into RSB and turn on the NeworMod flag. into RSB and turn on the NeworMod flag.
o If NeworMod flag is off, continue with the next flow o If NeworMod flag is off, continue with the next flow
descriptor in the RESV message, if any. descriptor in the Resv message, if any.
o Otherwise (the NeworMod flag is on, i.e., the active RSB is o Otherwise (the NeworMod flag is on, i.e., the active RSB is
new or modified), execute the UPDATE TRAFFIC CONTROL event new or modified), execute the UPDATE TRAFFIC CONTROL event
sequence (below). If the result is to modify the traffic sequence (below). If the result is to modify the traffic
control state, it will turn on the Resv_Refresh_Needed control state, it will turn on the Resv_Refresh_Needed
flag. flag.
o For any local sender, make an RESV_EVENT upcall to the o For any local sender, make an RESV_EVENT upcall to the
application: application:
Call: <Upcall_Proc>( session-id, RESV_EVENT, Call: <Upcall_Proc>( session-id, RESV_EVENT,
style, Flowspec, Filter_spec_list, style, Flowspec, Filter_spec_list,
[POLICY_DATA] ) [POLICY_DATA] )
where the parameters come from the active RSB. where the parameters come from the active RSB.
o Continue with the next flow descriptor. o Continue with the next flow descriptor.
o When all flow descriptors have been processed, check the o When all flow descriptors have been processed, check the
Resv_Refresh_Needed flag. If it is now on, execute the Resv_Refresh_Needed flag. If it is now on, execute the
RESV REFRESH sequence (below) for each PHOP in Resv REFRESH sequence (below) for each PHOP in
Refresh_PHOP_list. Refresh_PHOP_list.
o Drop the RESV message and return. o Drop the Resv message and return.
If processing a RESV message finds an error, a RERR message is If processing a Resv message finds an error, a ResvErr message
created containing flow descriptor and an ERRORS object. The is created containing flow descriptor and an ERRORS object. The
Error Node field of the ERRORS object is set to the IP address Error Node field of the ERRORS object is set to the IP address
of OI, and the message is sent unicast to NHOP. of OI, and the message is sent unicast to NHOP.
RESV TEAR MESSAGE ARRIVES ResvTear MESSAGE ARRIVES
A RTEAR message arrives with an IP destination address matching A ResvTear message arrives with an IP destination address
outgoing interface OI. Flags Tear_Needed and matching outgoing interface OI. Flags Tear_Needed and
Resv_Refresh_Needed are initially off and Refresh_PHOP_list is Resv_Refresh_Needed are initially off and Refresh_PHOP_list is
empty. empty.
o Process the STYLE object and the flow descriptor list in o Process the STYLE object and the flow descriptor list in
the RTEAR message to tear down local reservation state, as the ResvTear message to tear down local reservation state,
follows. as follows. We assume a filter spec list struct Filtss, of
The following uses a filter spec list struct Filtss, of
type FILTER_SPEC* (defined earlier). type FILTER_SPEC* (defined earlier).
For FF style: execute the following steps independently for For FF style: execute the following steps independently for
each flow descriptor in the message, i.e., for each each flow descriptor in the message, i.e., for each
(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.
skipping to change at page 80, line 22 skipping to change at page 82, line 21
3. Execute the event sequence UPDATE TRAFFIC CONTROL 3. Execute the event sequence UPDATE TRAFFIC CONTROL
(below) to update the traffic control state to be (below) to update the traffic control state to be
consistent with the reservation state. consistent with the reservation state.
4. Search for a TCSB remaining for the (session, OI, 4. Search for a TCSB remaining for the (session, OI,
Filtss) triple; if not, set the Tear_Needed flag on. Filtss) triple; if not, set the Tear_Needed flag on.
5. Continue with the next flow descriptor. 5. Continue with the next flow descriptor.
o If Tear_Needed and Resv_Refresh_Needed flags are both off, o If Tear_Needed and Resv_Refresh_Needed flags are both off,
then drop the RTEAR message and return. then drop the ResvTear message and return.
o If Tear_Needed is off but Resv_Refresh_Needed is on, then o If Tear_Needed is off but Resv_Refresh_Needed is on, then
execute the RESV REFRESH sequence for each PHOP in execute the Resv REFRESH sequence for each PHOP in
Refresh_PHOP_list, drop the RTEAR message, and return. Refresh_PHOP_list, drop the ResvTear message, and return.
o Otherwise (Tear_Needed is on), need to forward RTEAR and/or o Otherwise (Tear_Needed is on), need to forward ResvTear
RESV refresh messages. and/or Resv refresh messages.
Do the following for each PSB whose OutInterface_list Do the following for each PSB whose OutInterface_list
includes the outgoing interface OI: includes the outgoing interface OI:
1. Pick each flow descriptor Fj in the RTEAR message 1. Pick each flow descriptor Fj in the ResvTear message
whose FILTER_SPEC matches the PSB, and do the whose FILTER_SPEC matches the PSB, and do the
following. following.
- If there is no RSB whose FILTER_SPEC matches the - If there is no RSB whose FILTER_SPEC matches the
PSB, then add Fj to the new RTEAR message being PSB, then add Fj to the new ResvTear message
built. being built.
- Otherwise (there is a matching RSB), note the PSB - Otherwise (there is a matching RSB), note the PSB
as needing a RESV refresh message and set the as needing a Resv refresh message and set the
Resv_Refresh_Needed flag True. Resv_Refresh_Needed flag True.
2. If the new RTEAR message contains any flow 2. If the new ResvTear message contains any flow
descriptors, send it to PHOP in the PSB. descriptors, send it to PHOP in the PSB.
o If the Resv_Refresh_Needed flag is now on, execute the RESV o If the Resv_Refresh_Needed flag is now on, execute the RESV
REFRESH sequence (below) for each PHOP in REFRESH sequence (below) for each PHOP in
Refresh_PHOP_list. Refresh_PHOP_list.
o Drop the RTEAR message and return. o Drop the ResvTear message and return.
RESV ERROR MESSAGE ARRIVES ResvErr MESSAGE ARRIVES
A RERR message arrives through the (real) incoming interface A ResvErr message arrives through the (real) incoming interface
In_If. In_If.
o If there is no path state for SESSION, drop the RERR o If there is no path state for SESSION, drop the ResvErr
message and return. message and return.
o If the Error Code = 01 (Admission Control failure), do o If the Error Code = 01 (Admission Control failure), do
special processing as follows: special processing as follows:
1. Find or create a Blockade State Block (BSB), in the 1. Find or create a Blockade State Block (BSB), in the
following style-dependent manner. following style-dependent manner.
For WF (wildcard) style, there will be one BSB per For WF (wildcard) style, there will be one BSB per
(session, PHOP) pair. (session, PHOP) pair.
For FF style, there will be one BSB per (session, For FF style, there will be one BSB per (session,
filter_spec) pair. Note that an FF style RERR message filter_spec) pair. Note that an FF style ResvErr
carries only one flow descriptor. message carries only one flow descriptor.
For SE style, there will be one BSB per (session, For SE style, there will be one BSB per (session,
filter_spec), for each filter_spec contained in the filter_spec), for each filter_spec contained in the
filter spec list of the flow descriptor. filter spec list of the flow descriptor.
2. For each BSB in the preceding step, set (or replace) 2. For each BSB in the preceding step, set (or replace)
its FLOWSPEC Qb with FLOWSPEC from the message, and its FLOWSPEC Qb with FLOWSPEC from the message, and
set (or reset) its timer Tb to Kb*R seconds [Section set (or reset) its timer Tb to Kb*R seconds [Section
3.4]. If the BSB is new, set its PHOP value, and set 3.4]. If the BSB is new, set its PHOP value, and set
its Sender_Template equal to the appropriate its Sender_Template equal to the appropriate
filter_spec from the message. filter_spec from the message.
3. Partially execute the RESV REFRESH event sequence 3. Partially execute the Resv REFRESH event sequence
shown below, for the previous hop PHOP. shown below, for the previous hop PHOP.
In particular, execute the refresh sequence with the In particular, execute the refresh sequence with the
B_Merge flag off. If this results in no refresh B_Merge flag off. If this results in no refresh
messages being generated, because all matching messages being generated, because all matching
reservations are blockaded, do not turn B_Merge on but reservations are blockaded, do not turn B_Merge on but
instead exit the refresh sequence and return here. instead exit the refresh sequence and return here.
o For all RERR messages, execute the following for each RSB o For all ResvErr messages, execute the following for each
for this session whose OI differs from In_If and whose RSB for this session whose OI differs from In_If and whose
Filter_spec_list has at least one filter spec in common Filter_spec_list has at least one filter spec in common
with the FILTER_SPEC* in the RERR message. For WF style, with the FILTER_SPEC* in the ResvErr message. For WF
empty FILTER_SPEC* structures are assumed to match. style, empty FILTER_SPEC* structures are assumed to match.
1. If Error_Code = 01 and the InPlace flag is 1 and one 1. If Error_Code = 01 and the InPlace flag is 1 and one
or more of the BSB's found/created above has a Qb that or more of the BSB's found/created above has a Qb that
is strictly greater than Flowspec in the RSB, then is strictly greater than Flowspec in the RSB, then
continue with the next matching RSB, if any. continue with the next matching RSB, if any.
2. If NHOP in the RSB is the local API, then: 2. If NHOP in the RSB is the local API, then:
- If the FLOWSPEC in the RERR message is strictly - If the FLOWSPEC in the ResvErr message is
greater than the RSB Flowspec, then turn on the strictly greater than the RSB Flowspec, then turn
NotGuilty flag in the ERROR_SPEC. on the NotGuilty flag in the ERROR_SPEC.
- Deliver an error upcall to application: - Deliver an error upcall to application:
Call: <Upcall_Proc>( session-id, RESV_ERROR, Call: <Upcall_Proc>( session-id, RESV_ERROR,
Error_code, Error_value, Error_code, Error_value,
Node_Addr, Error_flags, Node_Addr, Error_flags,
Flowspec, Filter_Spec_List, Flowspec, Filter_Spec_List,
[Policy_data] ) [Policy_data] )
and continue with the next RSB. and continue with the next RSB.
3. If the style has wildcard sender selection, use the 3. If the style has wildcard sender selection, use the
SCOPE object SC.In from the RERR message to construct SCOPE object SC.In from the ResvErr message to
a SCOPE object SC.Out to be forwarded. SC.Out should construct a SCOPE object SC.Out to be forwarded.
contain those sender addresses that appeared in SC.In SC.Out should contain those sender addresses that
and that route to OI [LIH?], as determined by scanning appeared in SC.In and that route to OI [LIH?], as
the PSB's. If SC.Out is empty, continue with the next determined by scanning the PSB's. If SC.Out is empty,
RSB. continue with the next RSB.
4. Create a new RERR message containing the error flow 4. Create a new ResvErr message containing the error flow
descriptor and send to the NHOP address specified by descriptor and send to the NHOP address specified by
the RSB. Include SC.Out if the style has wildcard the RSB. Include SC.Out if the style has wildcard
sender selection. sender selection.
5. Continue with the next RSB. 5. Continue with the next RSB.
o Drop the RERR message and return. o Drop the ResvErr message and return.
RESV CONFIRM ARRIVES Resv CONFIRM ARRIVES
o If the (unicast) IP address found in the RESV_CONFIRM o If the (unicast) IP address found in the RESV_CONFIRM
object in the RACK message matches an interface of the object in the ResvConf message matches an interface of the
node, a confirmation upcall is made to the matching node, a confirmation upcall is made to the matching
application: application:
Call: <Upcall_Proc>( session-id, RESV_CONFIRM, Call: <Upcall_Proc>( session-id, RESV_CONFIRM,
Error_code, Error_value, Node_Addr, Error_code, Error_value, Node_Addr,
LUB-Used, nlist, Flowspec, LUB-Used, nlist, Flowspec,
Filter_Spec_List, NULL, NULL ) Filter_Spec_List, NULL, NULL )
o Otherwise, the RACK message is forwarded immediately to the o Otherwise, the ResvConf message is forwarded immediately to
address in the IP address in its RESV_CONFIRM object. the address in the IP address in its RESV_CONFIRM object.
o Drop the RACK message and return. o Drop the ResvConf message and return.
UPDATE TRAFFIC CONTROL UPDATE TRAFFIC CONTROL
The sequence is invoked by the PATH MESSAGE ARRIVES or the RESV The sequence is invoked by the Path MESSAGE ARRIVES or the Resv
MESSAGE ARRIVES sequence, to (re-)calculate and adjust the local MESSAGE ARRIVES sequence, to (re-)calculate and adjust the local
traffic control state in accordance with the current reservation traffic control state in accordance with the current reservation
and path state. If the result is to modify the traffic control and path state. If the result is to modify the traffic control
state, this sequence turns on the Resv_Refresh_Needed flag. state, this sequence turns on the 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 and OI from 1. Consider the set of RSB's matching SESSION and OI from
the message. the message.
skipping to change at page 84, line 32 skipping to change at page 86, line 29
Rhandle = TC_AddFlowspec( OI, TC_Flowspec, Rhandle = TC_AddFlowspec( OI, TC_Flowspec,
Path_Te, police_flags) Path_Te, police_flags)
3. If this call succeeds, record Rhandle in the TCSB and, 3. If this call succeeds, record Rhandle in the TCSB and,
for each filter_spec F in TC_Filter_Spec*, call: for each filter_spec F in TC_Filter_Spec*, call:
Fhandle = TC_AddFilter( OI, Rhandle, Session, F) Fhandle = TC_AddFilter( OI, Rhandle, Session, F)
and record the returned Fhandle in the TCSB. and record the returned Fhandle in the TCSB.
4. Otherwise, build and send a RERR message specifying 4. Otherwise, build and send a ResvErr message specifying
"Admission control failed" and with the InPlace flag "Admission control failed" and with the InPlace flag
off. off.
o If TCSB is not new but the TC_Flowspec, Path_Te, and/or o If TCSB is not new but the TC_Flowspec, Path_Te, and/or
police flags just computed differ from corresponding values police flags just computed differ from corresponding values
in the TCSB, then: in the TCSB, then:
1. Turn the Resv_Refresh_Needed flag on and make the 1. Turn the Resv_Refresh_Needed flag on and make the
traffic control call: traffic control call:
TC_ModFlowspec( OI, Rhandle, TC_Flowspec, TC_ModFlowspec( OI, Rhandle, TC_Flowspec,
Path_Te, police_flags ) Path_Te, police_flags )
2. If this call fails, build and send a RERR message 2. If this call fails, build and send a ResvErr message
specifying "Admission control failed" and with the specifying "Admission control failed" and with the
InPlace bit on. If the call succeeds, update the TCSB InPlace bit on. If the call succeeds, update the TCSB
with the new values. with the new values.
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 differ from the FILTER_SPEC* in the TCSB, then: computed differ 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*.
o Return to the event sequence that invoked this one. o Return to the event sequence that invoked this one.
PATH REFRESH Path REFRESH
This sequence sends a path refresh for a particular sender, This sequence sends a path refresh for a particular sender,
i.e., a PSB. This sequence may be entered by either the i.e., a PSB. This sequence may be entered by either the
expiration of the path refresh timer or directly as the result expiration of the path refresh timer or directly as the result
of the Path_Refresh_Needed flag being turned on during the of the Path_Refresh_Needed flag being turned on during the
processing of a received PATH message. processing of a received Path message.
o Compute the IP TTL for the PATH message as one less than o Compute the IP TTL for the Path message as one less than
the maximum of the TTL values from the senders included in the maximum of the TTL values from the senders included in
the message. However, if the result is zero, return the message. However, if the result is zero, return
without sending the PATH message. without sending the Path message.
o Insert TIME_VALUES and PHOP objects into the PATH message o Insert TIME_VALUES and PHOP objects into the Path message
being built. being built.
o Create a sender descriptor containing the SENDER_TEMPLATE, o Create a sender descriptor containing the SENDER_TEMPLATE,
SENDER_TSPEC, and POLICY_DATA objects, if present in the SENDER_TSPEC, and POLICY_DATA objects, if present in the
PSB, and pack it into the PATH message being built. PSB, and pack it into the Path message being built.
o Pass any ADSPEC and SENDER_TSPEC objects present in the PSB o Pass any ADSPEC and SENDER_TSPEC objects present in the PSB
to the traffic control call TC_Advertise. Insert the to the traffic control call TC_Advertise. Insert the
modified ADSPEC object that is returned into the PATH modified ADSPEC object that is returned into the Path
message being built. message being built.
o If the PSB has the E_Police flag on and if interface OI is o If the PSB has the E_Police flag on and if interface OI is
not capable of policing, turn the E_Police flag on in the not capable of policing, turn the E_Police flag on in the
PATH message being built. Path message being built.
o Send a copy of the PATH message to each interface in o Send a copy of the Path message to each interface in
OutInterfact_list. Before sending each copy, insert into OutInterfact_list. Before sending each copy, insert into
its PHOP object the interface address and the LIH for the its PHOP object the interface address and the LIH for the
interface. interface.
RESV REFRESH Resv REFRESH
This sequence sends a reservation refresh towards a particular This sequence sends a reservation refresh towards a particular
previous hop with IP address PH. This sequence may be entered previous hop with IP address PH. This sequence may be entered
by either the expiration of a reservation refresh timer or by either the expiration of a reservation refresh timer or
directly as a result of the Resv_Refresh_Needed flag being directly as a result of the Resv_Refresh_Needed flag being
turned on by processing a RESV or RTEAR message. turned on by processing a Resv or ResvTear message.
In general, this sequence considers each of the PSB's with PHOP In general, this sequence considers each of the PSB's with PHOP
address PH. For a given PSB, it scans the RSBs for matching address PH. For a given PSB, it scans the RSBs for matching
reservations and merges the styles, FLOWSPECs and reservations and merges the styles, FLOWSPECs and
Filter_spec_list's appropriately. It then builds a RESV message Filter_spec_list's appropriately. It then builds a Resv message
and sends it to PH. The details depend upon the attributes of and sends it to PH. The details depend upon the attributes of
the style(s) included in the reservations. the style(s) included in the reservations.
o Create an output message containing INTEGRITY (if o Create an output message containing INTEGRITY (if
supported), SESSION, RSVP_HOP, and TIME_VALUES objects. supported), SESSION, RSVP_HOP, and TIME_VALUES objects.
o Determine the style for these reservations from the first o Determine the style for these reservations from the first
RSB for the session, and move the STYLE object into the RSB for the session, and move the STYLE object into the
proto-message. (Note that the present set of styles are proto-message. (Note that the present set of styles are
never themselves merged; if future styles can be merged, never themselves merged; if future styles can be merged,
skipping to change at page 87, line 5 skipping to change at page 88, line 49
follows. follows.
- Select BSB's that match this RSB; if any of these - Select BSB's that match this RSB; if any of these
BSB's has a Qb that is not strictly larger than BSB's has a Qb that is not strictly larger than
RSB Flowspec, then continue processing with the RSB Flowspec, then continue processing with the
next RSB. next RSB.
However, if steps 1 and 2 result in finding that all However, if steps 1 and 2 result in finding that all
RSB's matching this PSB are blockaded, then: RSB's matching this PSB are blockaded, then:
- If this RESV REFRESH sequence was invoked from - If this Resv REFRESH sequence was invoked from
RESV ERROR RECEIVED, then return now to the RESV ERROR RECEIVED, then return now to the
latter. latter.
- Otherwise, turn on the B_Merge flag and restart - Otherwise, turn on the B_Merge flag and restart
with this procedure step 1. above. with this procedure step 1. above.
4. Merge the flowspecs, as follows: 4. Merge the flowspecs, as follows:
- If B_Merge flag is off, compute the LUB over the - If B_Merge flag is off, compute the LUB over the
Flowspec objects of this set of RSB's. Flowspec objects of this set of RSB's.
skipping to change at page 87, line 27 skipping to change at page 89, line 23
While computing the LUB, check for a RESV_CONFIRM While computing the LUB, check for a RESV_CONFIRM
object in each RSB. If a RESV_CONFIRM object is object in each RSB. If a RESV_CONFIRM object is
found: found:
- If the FLOWSPEC in that RSB is larger than - If the FLOWSPEC in that RSB is larger than
all other (non-blockaded) flowspecs being all other (non-blockaded) flowspecs being
compared, then save this RESV_CONFIRM object compared, then save this RESV_CONFIRM object
for forwarding. for forwarding.
- Otherwise (the corresponding FLOWSPEC is not - Otherwise (the corresponding FLOWSPEC is not
the largest) then create and send a RACK the largest) then create and send a ResvConf
message containing the RESV_CONFIRM object message containing the RESV_CONFIRM object
to the address in the RESV_CONFIRM object. to the address in the RESV_CONFIRM object.
Include the RESV_CONFIRM object in the RACK Include the RESV_CONFIRM object in the
message. The RACK message should also ResvConf message. The RACK message should
include an ERROR_SPEC object whose also include an ERROR_SPEC object whose
Error_Node parameter is IP address of OI Error_Node parameter is IP address of OI
from the RSB. from the RSB.
- Then delete the RESV_CONFIRM object from the - Then delete the RESV_CONFIRM object from the
RSB. RSB.
- Otherwise (B_Merge flag is on), compute the GLB - Otherwise (B_Merge flag is on), compute the GLB
over the Flowspec objects of this set of RSB's. over the Flowspec objects of this set of RSB's.
While computing the GLB, check for a RESV_CONFIRM While computing the GLB, check for a RESV_CONFIRM
skipping to change at page 88, line 36 skipping to change at page 90, line 32
Using the Sender_Template as the merged Using the Sender_Template as the merged
FILTER_SPEC, form the union of the FILTER_SPECS FILTER_SPEC, form the union of the FILTER_SPECS
obtained from the RSB's. Merge (take the maximum obtained from the RSB's. Merge (take the maximum
of) the merged FLOWSPECS from the RSB's, across of) the merged FLOWSPECS from the RSB's, across
all PSB's for PH. all PSB's for PH.
9. If the Need_Scope flag is on, remove from the merged 9. If the Need_Scope flag is on, remove from the merged
SCOPE object all sender addresses that do not match SCOPE object all sender addresses that do not match
the set of PSB's for PH, and all senders addresses the set of PSB's for PH, and all senders addresses
that are local. If the resulting set is empty, no that are local. If the resulting set is empty, no
RESV should be forwarded to this PHOP; return. Resv should be forwarded to this PHOP; return.
Otherwise (set is not empty), move the new SCOPE Otherwise (set is not empty), move the new SCOPE
object into the message. object into the message.
o (All PSB's have been processed). If a shared reservation o (All PSB's have been processed). If a shared reservation
style is being built, move the final merged FLOWSPEC, style is being built, move the final merged FLOWSPEC,
F_POLICY_DATA, and FILTER_SPEC (if SE) objects into the F_POLICY_DATA, and FILTER_SPEC (if SE) objects into the
message. message.
o If a RESV_CONFIRM object was saved earlier, copy it into o If a RESV_CONFIRM object was saved earlier, copy it into
the new RESV message and delete it from the RSB in which it the new Resv message and delete it from the RSB in which it
was found. was found.
o Set the RSVP_HOP object in the message to contain the o Set the RSVP_HOP object in the message to contain the
IncInterface address through which it will be sent and the IncInterface address through which it will be sent and the
LIH from (one of) the PSB's. LIH from (one of) the PSB's.
o Send the message to the address PH. o Send the message to the address PH.
PATH LOCAL REPAIR Path LOCAL REPAIR
The sequence is entered when RSVP learns from routing that the The sequence is entered when RSVP learns from routing that the
set of outgoing interfaces for some destination (G,DstPort) has set of outgoing interfaces for some destination (G,DstPort) has
changed. changed.
o Wait for a delay time of W seconds [Section 3.5]. o Wait for a delay time of W seconds [Section 3.5].
o For each session that exists for destination IP address G, o For each session that exists for destination IP address G,
execute the PATH REFRESH event sequence above for each execute the Path REFRESH event sequence above for each
sender (PSB) for that session. sender (PSB) for that session.
5. Acknowledgments 5. Acknowledgments
The design of RSVP is based upon research performed in 1992-1993 by a The design of RSVP is based upon research performed in 1992-1993 by a
collaboration including Lixia Zhang (Xerox PARC), Deborah Estrin collaboration including Lixia Zhang (Xerox PARC), Deborah Estrin
(USC/ISI), Scott Shenker (Xerox PARC), Sugih Jamin (USC/Xerox PARC), (USC/ISI), Scott Shenker (Xerox PARC), Sugih Jamin (USC/Xerox PARC),
and Daniel Zappala (USC). Sugih Jamin developed the first prototype and Daniel Zappala (USC). Sugih Jamin developed the first prototype
implementation of RSVP and successfully demonstrated it in May 1993. implementation of RSVP and successfully demonstrated it in May 1993.
Shai Herzog, and later Steve Berson, continued development of RSVP Shai Herzog, and later Steve Berson, continued development of RSVP
skipping to change at page 91, line 9 skipping to change at page 93, line 9
Protocol Id Protocol Id
The IP Protocol Identifier for the data flow. This field The IP Protocol Identifier for the data flow. This field
must be non-zero. must be non-zero.
Flags Flags
0x01 = E_Police flag 0x01 = E_Police flag
The E_Police flag is used in PATH messages to determine The E_Police flag is used in Path messages to determine
the effective "edge" of the network, to control traffic the effective "edge" of the network, to control traffic
policing. If the sender host is not itself capable of policing. If the sender host is not itself capable of
traffic policing, it will set this bit on in PATH traffic policing, it will set this bit on in Path
messages it sends. The first node whose RSVP is capable messages it sends. The first node whose RSVP is capable
of traffic policing will do so (if appropriate to the of traffic policing will do so (if appropriate to the
service) and turn the flag off. service) and turn the flag off.
0x10 = Non_RSVP flag 0x10 = Non_RSVP flag
The Non_RSVP flag is turned on in the SESSION object of The Non_RSVP flag is turned on in the SESSION object of
a PATH message whenever the RSVP daemon detects that the a Path message whenever the RSVP daemon detects that the
previous RSVP hop included one or more non-RSVP-capable previous RSVP hop included one or more non-RSVP-capable
routers. This flag is forwarded hop-by-hop and passed routers. This flag is forwarded hop-by-hop and passed
to a receiver application. If it is on, it indicates to to a receiver application. If it is on, it indicates to
the application that even a successful reservation the application that even a successful reservation
request may not install the requested QoS at every node request may not install the requested QoS at every node
along the path. along the path.
0x20 = Maybe_RSVP flag 0x20 = Maybe_RSVP flag
The Maybe_RSVP flag is turned on in the SESSION object The Maybe_RSVP flag is turned on in the SESSION object
of a PATH message whenever the RSVP daemon is unable to of a Path message whenever the RSVP daemon is unable to
ascertain whether or not the previous hop included one ascertain whether or not the previous hop included one
or more non-RSVP-capable routers. This flag is or more non-RSVP-capable routers. This flag is
forwarded hop-by-hop and passed to a receiver forwarded hop-by-hop and passed to a receiver
application. If it is on and the Non_RSVP flag is off, application. If it is on and the Non_RSVP flag is off,
the application cannot tell whether or not a successful the application cannot tell whether or not a successful
reservation request may not install the requested QoS at reservation request may not install the requested QoS at
every node along the path. every node along the path.
DstPort DstPort
skipping to change at page 94, line 40 skipping to change at page 96, line 40
Error Node Address Error Node Address
The IP address of the node in which the error was detected. The IP address of the node in which the error was detected.
Flags Flags
0x01 = InPlace 0x01 = InPlace
This flag is used only for an ERROR_SPEC object in a This flag is used only for an ERROR_SPEC object in a
RERR message. If it on, this flag indicates that there ResvErr message. If it on, this flag indicates that
was, and still is, a reservation in place at the failure there was, and still is, a reservation in place at the
point. failure point.
0x02 = NotGuilty 0x02 = NotGuilty
This flag is used only for an ERROR_SPEC object in a This flag is used only for an ERROR_SPEC object in a
RERR message, and it is only set in the interface to the ResvErr message, and it is only set in the interface to
receiver application. If it on, this flag indicates the receiver application. If it on, this flag indicates
that the FLOWSPEC that failed was strictly greater than that the FLOWSPEC that failed was strictly greater than
the FLOWSPEC requested by this receiver. the FLOWSPEC requested by this receiver.
Error Code Error Code
A one-octet error description. A one-octet error description.
Error Value Error Value
A two-octet field containing additional information about the A two-octet field containing additional information about the
skipping to change at page 105, line 5 skipping to change at page 107, line 5
group. group.
A.13 POLICY_DATA Class A.13 POLICY_DATA Class
POLICY_DATA class = 14. POLICY_DATA class = 14.
o Type 1 POLICY_DATA object: Class = 14, C-Type = 1 o Type 1 POLICY_DATA object: Class = 14, C-Type = 1
The contents of this object are for further study. The contents of this object are for further study.
A.14 RESV_CONFIRM Class A.14 Resv_CONFIRM Class
RESV_CONFIRM class = 15. RESV_CONFIRM class = 15.
o IPv4 RESV_CONFIRM object: Class = 15, C-Type = 1 o IPv4 RESV_CONFIRM object: Class = 15, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 Receiver Address (4 bytes) | | IPv4 Receiver Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o IP6 RESV_CONFIRM object: Class = 15, C-Type = 2 o IP6 RESV_CONFIRM object: Class = 15, C-Type = 2
skipping to change at page 106, line 9 skipping to change at page 108, line 9
+ IP6 Receiver Address (16 bytes) + + IP6 Receiver Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
APPENDIX B. Error Codes and Values APPENDIX B. Error Codes and Values
The following Error Codes may appear in ERROR_SPEC objects and be The following Error Codes may appear in ERROR_SPEC objects and be
passed to end systems. Except where noted, these Error Codes may passed to end systems. Except where noted, these Error Codes may
appear only in RERR messages. appear only in ResvErr messages.
o Error Code = 00: Confirmation o Error Code = 00: Confirmation
This code is reserved for use in the ERROR_SPEC object of a RACK This code is reserved for use in the ERROR_SPEC object of a
message. The Error Value will also be zero. ResvConf message. The Error Value will also be zero.
o Error Code = 01: Admission Control failure o Error Code = 01: Admission Control failure
Reservation request was rejected by Admission Control due to Reservation request was rejected by Admission Control due to
unavailable resources. unavailable resources.
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 107, line 21 skipping to change at page 109, line 21
- 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
o Error Code = 02: Policy Control failure o Error Code = 02: Policy Control failure
Reservation has been rejected for administrative reasons, for Reservation has been rejected for administrative reasons, for
example, required credentials not submitted, insufficient quota example, required credentials not submitted, insufficient quota
or balance, or administrative preemption. This Error Code may or balance, or administrative preemption. This Error Code may
appear in a PERR or RERR message. 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.
o Error Code = 03: No path information for this Resv message. o Error Code = 03: No path information for this Resv message.
No path state for this session. RESV message cannot be No path state for this session. Resv message cannot be
forwarded. forwarded.
o Error Code = 04: No sender information for this Resv message. o Error Code = 04: No sender information for this Resv message.
There is path state for this session, but it does not include There is path state for this session, but it does not include
the sender matching some flow descriptor contained in the RESV the sender matching some flow descriptor contained in the Resv
message. RESV message cannot be forwarded. message. RESV message cannot be forwarded.
o Error Code = 05: Conflicting reservation style o Error Code = 05: Conflicting reservation style
Reservation style conflicts with style(s) of existing Reservation style conflicts with style(s) of existing
reservation state. The Error Value field contains the low-order reservation state. The Error Value field contains the low-order
16 bits of the Option Vector of the existing style with which 16 bits of the Option Vector of the existing style with which
the conflict occurred. This RESV message cannot be forwarded. the conflict 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 port
Sessions for same destination address and protocol have appeared Sessions for same destination address and protocol have appeared
with both zero and non-zero dest port fields. This Error Code with both zero and non-zero dest port fields. This Error Code
may appear in a PERR or RERR message. may appear in a PathErr or ResvErr message.
o Error Code = 08: Ambiguous path o Error Code = 08: Ambiguous path
Sender port appears both zero and non-zero in same session in a Sender port appears both zero and non-zero in same session in a
PATH message. This Error Code may appear only in a PERR Path message. This Error Code may appear only in a PathErr
message. message.
o Error Code = 09, 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:
skipping to change at page 108, line 34 skipping to change at page 110, line 34
Here the high-order bits ssur are as defined under Error Code Here the high-order bits ssur are as defined under Error Code
01. The following globally-defined sub-codes may appear in the 01. The following globally-defined sub-codes may appear in the
low-order 12 bits when ssur = 0000 are to be defined in the low-order 12 bits when ssur = 0000 are to be defined in the
future. future.
o Error Code = 13: Unknown object class o Error Code = 13: Unknown object class
Error Value contains 16-bit value composed of (Class-Num, C- Error Value contains 16-bit value composed of (Class-Num, C-
Type) of unknown object. This error should be sent only if RSVP Type) of unknown object. This error should be sent only if RSVP
is going to reject the message, as determined by the high-order is going to reject the message, as determined by the high-order
bits of the Class-Num. This Error Code may appear in a PERR or bits of the Class-Num. This Error Code may appear in a PathErr
RERR message. or ResvErr 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- Error Value contains 16-bit value composed of (Class-Num, C-
Type) of object. Type) 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 Error Value field contains an API error code, for an API error
that was detected asynchronously and must be reported via an that was detected asynchronously and must be reported via an
upcall. 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 Reservation request was rejected by Traffic Control due to the
format or contents of the request. This RESV message cannot be format or contents of the request. This Resv message cannot be
forwarded, and continued attempts would be futile. forwarded, and continued attempts 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 ssr = 000: order 12 bits (cccc cccc cccc) when ssr = 000:
skipping to change at page 111, line 27 skipping to change at page 113, line 27
2. The first/last-hop routers are RSVP-capable. 2. The first/last-hop routers are RSVP-capable.
A method of relaxing the second assumption is given later. A method of relaxing the second assumption is given later.
Let Hu be a "UDP-only" host that requires UDP encapsulation, and Hr a Let Hu be a "UDP-only" host that requires UDP encapsulation, and Hr a
host that can do raw network I/O. The UDP encapsulation scheme must host that can do raw network I/O. The UDP encapsulation scheme must
allow RSVP interoperation among an arbitrary topology of Hr hosts, Hu allow RSVP interoperation among an arbitrary topology of Hr hosts, Hu
hosts, and routers. hosts, and routers.
RESV, RERR, RTEAR, and PERR messages are sent to unicast addresses Resv, ResvErr, ResvTear, and PathErr messages are sent to unicast
learned from the path or reservation state in the node. If the node addresses learned from the path or reservation state in the node. If
keeps track of which previous hops and which interfaces need UDP the node keeps track of which previous hops and which interfaces need
encapsulation, these messages can be sent using UDP encapsulation UDP encapsulation, these messages can be sent using UDP encapsulation
when necessary. On the other hand, PATH and PTEAR messages are send when necessary. On the other hand, Path and PathTear messages are
to thedestination address for the session, which may be unicast or send to thedestination address for the session, which may be unicast
multicast. or multicast.
The tables in Figures 13 and 14 show the basic rules for UDP The tables in Figures 13 and 14 show the basic rules for UDP
encapsulation of PATH and PTEAR messages, for unicast DestAddress and encapsulation of Path and PathTear messages, for unicast DestAddress
multicast DestAddress, respectively. Under the `Send' column, the and multicast DestAddress, respectively. Under the `Send' column,
notation is `mode(destaddr, destport)'; destport is omitted for raw the notation is `mode(destaddr, destport)'; destport is omitted for
packets. The `Receive' column shows the group that is joined and, raw packets. The `Receive' column shows the group that is joined
where relevant, the UDP Listen port. and, where relevant, the UDP Listen port.
It is useful to define two flavors of UDP encapsulation, one to be It is useful to define two flavors of UDP encapsulation, one to be
sent by Hu and the other to be sent by Hr and R, to avoid double sent by Hu and the other to be sent by Hr and R, to avoid double
processing by the recipient. In practice, these two flavors are processing by the recipient. In practice, these two flavors are
distinguished by differing UDP port numbers Pu and Pu'. distinguished by differing UDP port numbers Pu and Pu'.
The following symbols are used in the tables. The following symbols are used in the tables.
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.x, i.e., a o G* is a well-known group address of the form 224.0.0.x, i.e., a
group that is limited to the local connected network. [TO BE group that is limited to the local connected network. [TO BE
DEFINED] DEFINED]
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. [TO BE DEFINED] RSVP. [TO BE DEFINED]
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 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
skipping to change at page 113, line 24 skipping to change at page 115, line 24
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 Multicast Encapsulation Rules for 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.
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 listening for UDP-encapsulated Path messages that were sent to either
G* (multicast D) or to the address of interface X (unicast D). There G* (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 is 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 network acts as an RSVP sender, there will be no Path messages to
trigger UDP encapsulation. In this (unlikely) case, it will be trigger UDP encapsulation. In this (unlikely) case, it will be
necessary to explicitly configure UDP encapsulation on the local necessary to explicitly configure UDP encapsulation on the local
network interface of the router. network interface of the router.
When a UDP-encapsulated packet is received, the IP TTL is not When a UDP-encapsulated packet is received, the IP TTL is not
available to the application on most systems. The RSVP daemon that available to the application on most systems. The RSVP daemon that
receives a UDP-encapsulated PATH or PTEAR message should therefore receives a UDP-encapsulated Path or PathTear message should therefore
use the Send_TTL field of the RSVP common header as the effective use the Send_TTL field of the RSVP common header as the effective
receive TTL. This may be overridden by manual configuration. receive TTL. This may be overridden by manual configuration.
We have assumed that the first-hop RSVP-capable router R is on the We have assumed that the first-hop RSVP-capable router R is on the
directly-connected network. There are several possible approaches if directly-connected network. There are several possible approaches if
this is not the case. this is not the case.
1. Hu can send both unicast and multicast sessions to UDP(Ra,Pu) 1. Hu can send both unicast and multicast sessions to UDP(Ra,Pu)
with TTL=Ta with TTL=Ta
Here Ta must be the TTL to exactly reach R. If Ta is too small, Here Ta must be the TTL to exactly reach R. If Ta is too small,
the PATH message will not reach R. If Ta is too large, the Path message will not reach R. If Ta is too large,
multicast routing in R will forward the UDP packet into the multicast routing in R will forward the UDP packet into the
Internet until its hop count expires. This will turn on UDP Internet until its hop count expires. This will turn on UDP
encapsulation between routers within the Internet, perhaps encapsulation between routers within the Internet, perhaps
causing bogus UDP traffic. The host Hu must be explicitly causing bogus UDP traffic. The host Hu must be explicitly
configured with Ra and Ta. configured with Ra and Ta.
2. A particular host on the LAN connected to Hu could be designated 2. A particular host on the LAN connected to Hu could be designated
as an "RSVP relay host". A relay host would listen on (G*,Pu) as an "RSVP relay host". A relay host would listen on (G*,Pu)
and forward any PATH messages directly to R, although it would and forward any Path messages directly to R, although it would
not be in the data path. The relay host would have to be not be in the data path. The relay host would have to be
configured with Ra and Ta. configured with Ra and Ta.
References References
[Baker96] Baker, Fred, "RSVP Cryptographic Authentication", Internet [Baker96] Baker, Fred, "RSVP Cryptographic Authentication", Internet
Draft draft-ietf-rsvp-md5-01.txt, February 1996. Draft draft-ietf-rsvp-md5-01.txt, February 1996.
[ISInt93] Braden, R., Clark, D., and S. Shenker, "Integrated Services [ISInt93] Braden, R., Clark, D., and S. Shenker, "Integrated Services
in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and
 End of changes. 

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