draft-ietf-rsvp-spec-13.txt   draft-ietf-rsvp-spec-14.txt 
Internet Draft R. Braden, Ed. Internet Draft R. Braden, Ed.
Expiration: February 1997 ISI Expiration: May 1997 ISI
File: draft-ietf-rsvp-spec-13.txt L. Zhang File: draft-ietf-rsvp-spec-14.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
August 12, 1996 November 5, 1996
Status of Memo Status of Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction ........................................................3 1. Introduction ........................................................3
1.1 Data Flows ......................................................6 1.1 Data Flows ......................................................6
1.2 Reservation Model ...............................................7 1.2 Reservation Model ...............................................7
1.3 Reservation Styles ..............................................10 1.3 Reservation Styles ..............................................10
1.4 Examples of Styles ..............................................12 1.4 Examples of Styles ..............................................12
2. RSVP Protocol Mechanisms ............................................17 2. RSVP Protocol Mechanisms ............................................17
2.1 RSVP Messages ...................................................17 2.1 RSVP Messages ...................................................17
2.2 Port Usage ......................................................19 2.2 Merging Flowspecs ...............................................19
2.3 Merging Flowspecs ...............................................20 2.3 Soft State ......................................................20
2.4 Soft State ......................................................21 2.4 Teardown ........................................................22
2.5 Teardown ........................................................23 2.5 Errors ..........................................................23
2.6 Errors ..........................................................24 2.6 Confirmation ....................................................25
2.7 Confirmation ....................................................26 2.7 Policy and Security .............................................25
2.8 Policy and Security .............................................26 2.8 Non-RSVP Clouds .................................................26
2.9 Non-RSVP Clouds .................................................27 2.9 Host Model ......................................................27
2.10 Host Model .....................................................28 3. RSVP Functional Specification .......................................29
3. RSVP Functional Specification .......................................30 3.1 RSVP Message Formats ............................................29
3.1 RSVP Message Formats ............................................30 3.2 Port Usage ......................................................42
3.2 Sending RSVP Messages ...........................................43 3.3 Sending RSVP Messages ...........................................43
3.3 Avoiding RSVP Message Loops .....................................45 3.4 Avoiding RSVP Message Loops .....................................45
3.4 Blockade State ..................................................48 3.5 Blockade State ..................................................48
3.5 Local Repair ....................................................50 3.6 Local Repair ....................................................50
3.6 Time Parameters .................................................51 3.7 Time Parameters .................................................51
3.7 Traffic Policing and Non-Integrated Service Hops ................52 3.8 Traffic Policing and Non-Integrated Service Hops ................52
3.8 Multihomed Hosts ................................................53 3.9 Multihomed Hosts ................................................53
3.9 Future Compatibility ............................................55 3.10 Future Compatibility ...........................................55
3.10 RSVP Interfaces ................................................57 3.11 RSVP Interfaces ................................................57
4. Message Processing Rules ............................................69 APPENDIX A. Object Definitions .........................................69
5. Acknowledgments .....................................................91 APPENDIX B. Error Codes and Values .....................................84
APPENDIX A. Object Definitions .........................................93 APPENDIX C. UDP Encapsulation ..........................................89
APPENDIX B. Error Codes and Values .....................................108 APPENDIX D. Glossary ...................................................93
APPENDIX C. UDP Encapsulation ..........................................114
1. Introduction 1. Introduction
This document defines RSVP, a resource reservation setup protocol This document defines RSVP, a resource reservation setup protocol
designed for an integrated services Internet [RSVP93,ISInt93]. designed for an integrated services Internet [RSVP93,ISInt93].
The RSVP protocol is used by a host, on behalf of an application data The RSVP protocol is used by a host, on behalf of an application data
stream, to request a specific quality of service (QoS) from the stream, to request a specific quality of service (QoS) from the
network. The RSVP protocol is also used by routers to deliver QoS network for particular data streams or flows. The RSVP protocol is
control requests to all nodes along the path(s) of the data stream also used by routers to deliver QoS control requests to all nodes
and to establish and maintain state to provide the requested service. along the path(s) of the flows and to establish and maintain state to
RSVP requests will generally, although not necessarily, result in provide the requested service. RSVP requests will generally,
resources being reserved in each node along the data path. although not necessarily, result in resources being reserved in each
node along the data path.
RSVP requests resources for simplex data streams, i.e., it requests RSVP requests resources for simplex flows, i.e., it requests
resources in only one direction. Therefore, RSVP treats a sender as resources in only one direction. Therefore, RSVP treats a sender as
logically distinct from a receiver, although the same application logically distinct from a receiver, although the same application
process may act as both a sender and a receiver at the same time. process may act as both a sender and a receiver at the same time.
RSVP operates on top of IP (either IPv4 or IPv6), occupying the place RSVP operates on top of IP (either IPv4 or IPv6), occupying the place
of a transport protocol in the protocol stack. However, RSVP does of a transport protocol in the protocol stack. However, RSVP does
not transport application data but is rather an Internet control not transport application data but is rather an Internet control
protocol, like ICMP, IGMP, or routing protocols. Like the protocol, like ICMP, IGMP, or routing protocols. Like the
implementations of routing and management protocols, an implementations of routing and management protocols, an
implementation of RSVP will typically execute in the background, not implementation of RSVP will typically execute in the background, not
in the data forwarding path, as shown in Figure 1. in the data forwarding path, as shown in Figure 1.
RSVP is not itself a routing protocol; RSVP is designed to operate RSVP is not itself a routing protocol; RSVP is designed to operate
with current and future unicast and multicast routing protocols. An with current and future unicast and multicast routing protocols. An
RSVP daemon consults the local routing database(s) to obtain routes. RSVP process consults the local routing database(s) to obtain routes.
In the multicast case, for example, a host sends IGMP messages to In the multicast case, for example, a host sends IGMP messages to
join a multicast group and then sends RSVP messages to reserve join a multicast group and then sends RSVP messages to reserve
resources along the delivery path(s) of that group. Routing resources along the delivery path(s) of that group. Routing
protocols determine where packets get forwarded; RSVP is only protocols determine where packets get forwarded; RSVP is only
concerned with the QoS of those packets that are forwarded in concerned with the QoS of those packets that are forwarded in
accordance with routing. accordance with routing.
In order to efficiently accommodate large groups, dynamic group In order to efficiently accommodate large groups, dynamic group
membership, and heterogeneous receiver requirements, RSVP makes membership, and heterogeneous receiver requirements, RSVP makes
receivers responsible for requesting QoS control [RSVP93]. A QoS receivers responsible for requesting QoS control [RSVP93]. A QoS
control request from a receiver host application is passed to the control request from a receiver host application is passed to the
local RSVP implementation, shown as a daemon process in Figure 1. local RSVP process. The RSVP protocol then carries the request to
The RSVP protocol then carries the request to all the nodes (routers all the nodes (routers and hosts) along the reverse data path(s) to
and hosts) along the reverse data path(s) to the data source(s). the data source(s).
HOST ROUTER
HOST ROUTER HOST ROUTER
_____________________________ ____________________________ _____________________________ ____________________________
| | .-----------. | | _______ | | |
| _______ ______ | / | ________ . ______ | | | | _______ | | _______ |
| | | | | | RSVP || | . | | | RSVP | |Appli- | | | |RSVP | | | |
| |Applic-| | RSVP <---------/ ||Routing | -> RSVP <----------> | | cation| | RSVP <---------------------------> RSVP <---------->
| | ation<--->daemon| _____ | ||Protocol| |daemon| _____ | | | <--> | | | _______ | | |
| |_._____| | >|Polcy|| || daemon <---> >|Polcy|| | | | |process| _____ | ||Routing| |process| _____ |
| | |__.__.||Cntrl|| ||__._____| |__.__.||Cntrl|| | |_._____| | -->Polcy|| || <--> -->Polcy||
| |data | .|_____|| | | | .|_____|| | | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl||
|===|============|====.======| |===|============|====.======| | |data | | |_____|| ||__.____| | | |_____||
| | ..........| .____ | | | ..........| .____ | |===|===========|==|==========| |===|==========|==|==========|
| _V__V_ ____V___ |Admis|| | _V__V_ ____V___ |Admis|| | | --------| | _____ | | | --------| | _____ |
| |Class-| | ||Cntrl|| | |Class-| | ||Cntrl|| | | | | ---->Admis|| | | | | ---->Admis||
| | ifier|==> Packet ||_____|| .===> ifier|==> Packet ||_____|| | _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl||
| |______| |Schedulr|===========/ | |______| |Schedulr|===========> | | | | | |_____|| | | | | ||_____||
| |________| | data | |________| | data | |Class-| | Packet | | | |Class-| | Packet | |
|____________________________| |____________________________| | | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>
| |______| |________| |data | |______| |________| |data
| | | |
|_____________________________| |____________________________|
Figure 1: RSVP in Hosts and Routers Figure 1: RSVP in Hosts and Routers
Each node that is capable of QoS control passes incoming data packets Each node that is capable of QoS control passes incoming data packets
through a "packet classifier", which determines the route and the QoS through a "packet classifier", which determines the route and the QoS
class for each packet. On each outgoing interface, a "packet class for each packet. On each outgoing interface, a "packet
scheduler" then makes forwarding decisions for every packet, to scheduler" then makes forwarding decisions for every packet, to
achieve the promised QoS on the particular link-layer medium used by achieve the promised QoS on the particular link-layer medium used by
that interface. that interface.
At each node, an RSVP QoS control request is passed to two local At each node, an RSVP QoS control request is passed to two local
decision modules, "admission control" and "policy control". decision modules, "admission control" and "policy control".
Admission control determines whether the node has sufficient Admission control determines whether the node has sufficient
available resources to supply the requested QoS. Policy control available resources to supply the requested QoS. Policy control
determines whether the user has administrative permission to make the determines whether the user has administrative permission to make the
reservation. If both checks succeed, parameters are set in the reservation. If both checks succeed, parameters are set in the
packet classifier and in the scheduler, to obtain the desired QoS. packet classifier and in the scheduler, to obtain the desired QoS.
If either check fails, the RSVP program returns an error notification If either check fails, the RSVP program returns an error notification
to the application process that originated the request. We refer to to the application process that originated the request. We refer to
the packet classifier, packet scheduler, and admission control the packet classifier, packet scheduler, and admission control
components as "traffic control". The packet schedular and admission components as "traffic control". The packet scheduler and admission
control components implement QoS service models defined by the control components implement QoS service models defined by the
Integrated Services Working Group. Integrated Services Working Group.
RSVP protocol mechanisms provide a general facility for creating and RSVP protocol mechanisms provide a general facility for creating and
maintaining distributed reservation state across a mesh of multicast maintaining distributed reservation state across a mesh of multicast
or unicast delivery paths. RSVP itself transfers and manipulates QoS or unicast delivery paths. RSVP itself transfers and manipulates QoS
control parameters as opaque data, passing them to the appropriate control parameters as opaque data, passing them to the appropriate
traffic control modules for interpretation. The structure and traffic control modules for interpretation. The structure and
contents of the QoS parameters are documented in specifications contents of the QoS parameters are documented in specifications
developed by the Integrated Services Working Group. In particular, developed by the Integrated Services Working Group. In particular,
skipping to change at page 8, line 31 skipping to change at page 8, line 31
hierarchically-encoded signal by selecting on fields in an hierarchically-encoded signal by selecting on fields in an
application-layer header. In the interest of simplicity (and to application-layer header. In the interest of simplicity (and to
minimize layer violation), the present RSVP version uses a much minimize layer violation), the present RSVP version uses a much
more restricted form of filter spec, consisting of sender IP more restricted form of filter spec, consisting of sender IP
address and optionally the UDP/TCP port number SrcPort. address and optionally the UDP/TCP port number SrcPort.
Because the UDP/TCP port numbers are used for packet Because the UDP/TCP port numbers are used for packet
classification, each router must be able to examine these fields. classification, each router must be able to examine these fields.
This raises three potential problems. This raises three potential problems.
1. It is necessary to avoid IP fragmentation of a data stream 1. It is necessary to avoid IP fragmentation of a data flow for
for which a resource reservation is desired. which a resource reservation is desired.
Document [ISrsvp96] specifies a procedure for applications Document [ISrsvp96] specifies a procedure for applications
using RSVP facilities to compute the minimum MTU over a using RSVP facilities to compute the minimum MTU over a
multicast tree and return the result to the senders. multicast tree and return the result to the senders.
2. IPv6 inserts a variable number of variable-length Internet- 2. IPv6 inserts a variable number of variable-length Internet-
layer headers before the transport header, increasing the layer headers before the transport header, increasing the
difficulty and cost of packet classification for QoS. difficulty and cost of packet classification for QoS.
Efficient classification of IPv6 data packets could be Efficient classification of IPv6 data packets could be
skipping to change at page 9, line 46 skipping to change at page 9, line 46
request a confirmation message to indicate that its request was request a confirmation message to indicate that its request was
(probably) installed in the network. A successful reservation (probably) installed in the network. A successful reservation
request propagates upstream along the multicast tree until it request propagates upstream along the multicast tree until it
reaches a point where an existing reservation is equal or greater reaches a point where an existing reservation is equal or greater
than that being requested. At that point, the arriving request is than that being requested. At that point, the arriving request is
merged with the reservation in place and need not be forwarded merged with the reservation in place and need not be forwarded
further; the node may then send a reservation confirmation message further; the node may then send a reservation confirmation message
back to the receiver. Note that the receipt of a confirmation is back to the receiver. Note that the receipt of a confirmation is
only a high-probability indication, not a guarantee, that the only a high-probability indication, not a guarantee, that the
requested service is in place all the way to the sender(s), as requested service is in place all the way to the sender(s), as
explained in Section 2.7. explained in Section 2.6.
The basic RSVP reservation model is "one pass": a receiver sends a The basic RSVP reservation model is "one pass": a receiver sends a
reservation request upstream, and each node in the path either reservation request upstream, and each node in the path either
accepts or rejects the request. This scheme provides no easy way accepts or rejects the request. This scheme provides no easy way
for a receiver to find out the resulting end-to-end service. for a receiver to find out the resulting end-to-end service.
Therefore, RSVP supports an enhancement to one-pass service known Therefore, RSVP supports an enhancement to one-pass service known
as "One Pass With Advertising" (OPWA) [OPWA95]. With OPWA, RSVP as "One Pass With Advertising" (OPWA) [OPWA95]. With OPWA, RSVP
control packets are sent downstream, following the data paths, to control packets are sent downstream, following the data paths, to
gather information that may be used to predict the end-to-end QoS. gather information that may be used to predict the end-to-end QoS.
The results ("advertisements") are delivered by RSVP to the The results ("advertisements") are delivered by RSVP to the
skipping to change at page 12, line 32 skipping to change at page 12, line 32
The RSVP rules disallow merging of shared reservations with The RSVP rules disallow merging of shared reservations with
distinct reservations, since these modes are fundamentally distinct reservations, since these modes are fundamentally
incompatible. They also disallow merging explicit sender incompatible. They also disallow merging explicit sender
selection with wildcard sender selection, since this might produce selection with wildcard sender selection, since this might produce
an unexpected service for a receiver that specified explicit an unexpected service for a receiver that specified explicit
selection. As a result of these prohibitions, WF, SE, and FF selection. As a result of these prohibitions, WF, SE, and FF
styles are all mutually incompatible. styles are all mutually incompatible.
It would seem possible to simulate the effect of a WF reservation It would seem possible to simulate the effect of a WF reservation
using the SE style. When an application asked for WF, the RSVP using the SE style. When an application asked for WF, the RSVP
daemon on the receiver host could use local state to create an process on the receiver host could use local state to create an
equivalent SE reservation that explicitly listed all senders. equivalent SE reservation that explicitly listed all senders.
However, an SE reservation forces the packet classifier in each However, an SE reservation forces the packet classifier in each
node to explicitly select each sender in the list, while a WF node to explicitly select each sender in the list, while a WF
allows the packet classifier to simply "wild card" the sender allows the packet classifier to simply "wild card" the sender
address and port. When there is a large list of senders, a WF address and port. When there is a large list of senders, a WF
style reservation can therefore result in considerably less style reservation can therefore result in considerably less
overhead than an equivalent SE style reservation. For this overhead than an equivalent SE style reservation. For this
reason, both SE and WF are included in the protocol. reason, both SE and WF are included in the protocol.
Other reservation options and styles may be defined in the future. Other reservation options and styles may be defined in the future.
1.4 Examples of Styles 1.4 Examples of Styles
This section presents examples of each of the reservation styles This section presents examples of each of the reservation styles
and shows the effects of merging. and shows the effects of merging.
Figure 4 illustrates a router with two incoming interfaces, Figure 4 illustrates a router with two incoming interfaces,
labeled (a) and (b), through which data streams will arrive, and labeled (a) and (b), through which flows will arrive, and two
two outgoing interfaces, labeled (c) and (d), through which data outgoing interfaces, labeled (c) and (d), through which data will
will be forwarded. This topology will be assumed in the examples be forwarded. This topology will be assumed in the examples that
that follow. There are three upstream senders; packets from follow. There are three upstream senders; packets from sender S1
sender S1 (S2 and S3) arrive through previous hop (a) ((b), (S2 and S3) arrive through previous hop (a) ((b), respectively).
respectively). There are also three downstream receivers; packets There are also three downstream receivers; packets bound for R1
bound for R1 (R2 and R3) are routed via outgoing interface (c) (R2 and R3) are routed via outgoing interface (c) ((d),
((d), respectively). We furthermore assume that outgoing respectively). We furthermore assume that outgoing interface (d)
interface (d) is connected to a broadcast LAN, and that R2 and R3 is connected to a broadcast LAN, and that R2 and R3 are reached
are reached via different next hop routers (not shown). via different next hop routers (not shown).
We must also specify the multicast routes within the node of We must also specify the multicast routes within the node of
Figure 4. Assume first that data packets from each Si shown in Figure 4. Assume first that data packets from each Si shown in
Figure 4 are routed to both outgoing interfaces. Under this Figure 4 are routed to both outgoing interfaces. Under this
assumption, Figures 5, 6, and 7 illustrate Wildcard-Filter, assumption, Figures 5, 6, and 7 illustrate Wildcard-Filter,
Fixed-Filter, and Shared-Explicit reservations, respectively. Fixed-Filter, and Shared-Explicit reservations, respectively.
________________ ________________
(a)| | (c) (a)| | (c)
( S1 ) ---------->| |----------> ( R1 ) ( S1 ) ---------->| |----------> ( R1 )
skipping to change at page 17, line 30 skipping to change at page 17, line 30
|_____| |--------| b d |-----------| |_____| |--------| b d |-----------|
| Path-->| | Path --> | _____ | Path-->| | Path --> | _____
_____ | <--Resv|_____________________| <-- Resv | | | _____ | <--Resv|_____________________| <-- Resv | | |
| | | |--| D' | | | | |--| D' |
| B' |--| | |_____| | B' |--| | |_____|
|_____| | | |_____| | |
Figure 9: Router Using RSVP Figure 9: Router Using RSVP
Figure 9 illustrates RSVP's model of a router node. Each data Figure 9 illustrates RSVP's model of a router node. Each data
stream arrives from a "previous hop" through a corresponding flow arrives from a "previous hop" through a corresponding
"incoming interface" and departs through one or more "outgoing "incoming interface" and departs through one or more "outgoing
interface"(s). The same physical interface may act in both the interface"(s). The same 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). routers in the path to the next RSVP hop (see Section 2.8).
There are two fundamental RSVP message types: Resv and Path. There are two fundamental RSVP message types: Resv and Path.
Each receiver host sends RSVP reservation request (Resv) messages Each receiver host sends RSVP reservation request (Resv) messages
upstream towards the senders. These messages must follow exactly upstream towards the senders. These messages must follow exactly
the reverse of the path(s) the data packets will use, upstream to the reverse of the path(s) the data packets will use, upstream to
all the sender hosts included in the sender selection. They all the sender hosts included in the sender selection. They
create and maintain "reservation state" in each node along the create and maintain "reservation state" in each node along the
path(s). Resv messages must finally be delivered to the sender path(s). Resv messages must finally be delivered to the sender
hosts themselves, so that the hosts can set up appropriate traffic hosts themselves, so that the hosts can set up appropriate traffic
skipping to change at page 18, line 35 skipping to change at page 18, line 35
Sender Templates have exactly the same expressive power and Sender Templates have exactly the same expressive power and
format as filter specs that appear in Resv messages. format as filter specs that appear in Resv messages.
Therefore a Sender Template may specify only the sender IP Therefore a Sender Template may specify only the sender IP
address and optionally the UDP/TCP sender port, and it address and optionally the UDP/TCP sender port, and it
assumes the protocol Id specified for the session. assumes the protocol Id specified for the session.
o Sender Tspec o Sender Tspec
A Path message is required to carry a Sender Tspec, which A Path message is required to carry a Sender Tspec, which
defines the traffic characteristics of the data stream that defines the traffic characteristics of the data flow that the
the sender will generate. This Tspec is used by traffic sender will generate. This Tspec is used by traffic control
control to prevent over-reservation, and perhaps unnecessary to prevent over-reservation, and perhaps unnecessary
Admission Control failures. Admission Control failures.
o Adspec o Adspec
A Path message may carry a package of OPWA advertising A Path message may carry a package of OPWA advertising
information, known as an "Adspec". An Adspec received in a information, known as an "Adspec". An Adspec received in a
Path message is passed to the local traffic control, which Path message is passed to the local traffic control, which
returns an updated Adspec; the updated version is then returns an updated Adspec; the updated version is then
forwarded in Path messages sent downstream. forwarded in Path messages sent downstream.
Path messages are sent with the same source and destination Path messages are sent with the same source and destination
addresses as the data, so that they will be routed correctly addresses as the data, so that they will be routed correctly
through non-RSVP clouds (see Section 2.9). On the other hand, through non-RSVP clouds (see Section 2.8). 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 Merging Flowspecs
An RSVP session is normally defined by the triple: (DestAddress,
ProtocolId, DstPort). Here DstPort is a UDP/TCP destination port
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
ProtocolId specifies a protocol that does not have a destination
port field in the format used by UDP and TCP.
RSVP allows any value for ProtocolId. However, end-system
implementations of RSVP may know about certain values for this
field, and in particular the values for UDP and TCP (17 and 6,
respectively). An end system may give an error to an application
that either:
o specifies a non-zero DstPort for a protocol that does not
have UDP/TCP-like ports, or
o specifies a zero DstPort for a protocol that does have
UDP/TCP-like ports.
Filter specs and sender templates specify the pair: (SrcAddress,
SrcPort), where SrcPort is a UDP/TCP source port field (i.e., a
16-bit quantity carried at octet offset +0 in the transport
header). SrcPort may be omitted (set to zero) in certain cases.
The following rules hold for the use of zero DstPort and/or
SrcPort fields in RSVP.
1. Destination ports must be consistent.
Path state and reservation state for the same DestAddress and
ProtocolId must each have DstPort values that are all zero or
all non-zero. Violation of this condition in a node is a
"Conflicting Dest Port" error.
2. Destination ports rule.
If DstPort in a session definition is zero, all SrcPort
fields used for that session must also be zero. The
assumption here is that the protocol does not have UDP/TCP-
like ports. Violation of this condition in a node is a
"Conflicting Src Port" error.
3. Source Ports must be consistent.
A sender host must not send path state both with and without
a zero SrcPort. Violation of this condition is an "Ambiguous
Path" error.
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 both represent flowspec largest, see Section 3.5). These cases both represent flowspec
merging. merging.
Flowspec merging requires calculation of the "largest" of a set of Flowspec merging requires calculation of the "largest" of a set of
flowspecs. However, since flowspecs are generally multi- flowspecs. However, flowspecs are opaque to RSVP, so the actual
dimensional vectors (they may contain both Tspec and Rspec rules for comparing flowspecs must be defined and implemented
components, each of which may itself be multi-dimensional), it may outside RSVP proper. The comparison rules are defined in the
not be possible to strictly order two flowspecs. For example, if appropriate integrated service specification document; see
one request calls for a higher bandwidth and another calls for a [ISrsvp96]. An RSVP implementation will need to call service-
tighter delay bound, one is not "larger" than the other. In such specific routines to perform flowspec merging.
a case, instead of taking the larger, RSVP must compute and use a
third flowspec that is at least as large as each. Mathematically, Note that flowspecs are generally multi-dimensional vectors; they
RSVP merges flowspecs using the "least upper bound" (LUB) instead may contain both Tspec and Rspec components, each of which may
of the maximum. Typically, the LUB is calculated by creating a itself be multi-dimensional. Therefore, it may not be possible to
new flowspec whose components are individually either the max or strictly order two flowspecs. For example, if one request calls
the min of corresponding components of the flowspecs being merged. for a higher bandwidth and another calls for a tighter delay
For example, the LUB of Tspecs defined by token bucket parameters bound, one is not "larger" than the other. In such a case,
is computed by taking the maximums of the bucket size and the rate instead of taking the larger, the service-specific merging
parameters. In some cases, the GLB (Greatest Lower Bound) is routines must be able to return a third flowspec that is at least
required instead of the LUB; this simply interchanges max and min as large as each; mathematically, this is the "least upper bound"
operations. (LUB). In some cases, a flowspec at least as small is needed;
this is the "greatest lower bound" (GLB) GLB (Greatest Lower
Bound).
The following steps are used to calculate the effective flowspec The following steps are used to calculate the effective flowspec
(Te, Re) to be installed on an interface. Here Te is the (Te, Re) to be installed on an interface [ISrsvp96]. Here Te is
effective Tspec and Re is the effective Rspec. As an example, the effective Tspec and Re is the effective Rspec. As an example,
consider interface (d) in Figure 9. consider interface (d) in Figure 9.
1. RSVP calculates the LUB of the flowspecs that arrived in Resv 1. A service-specific calculation of the LUB of the flowspecs
messages from different next hops (e.g., D and D') but the that arrived in Resv messages from different next hops (e.g.,
same outgoing interface (d). D and D') but the same outgoing interface (d) is performed.
This calculation yields a flowspec that is opaque to RSVP but The result is a flowspec that is opaque to RSVP but actually
actually consists of the pair (Re, Resv_Te), where Re is the consists of the pair (Re, Resv_Te), where Re is the LUB of
LUB of the Rspecs and Resv_Te is the LUB of the Tspecs from the Rspecs and Resv_Te is the LUB of the Tspecs from the Resv
the Resv messages. messages.
2. RSVP calculates Path_Te, the sum of all Tspecs that were 2. A service-specific calculation of Path_Te, the sum of all
supplied in Path messages from different previous hops (e.g., Tspecs that were supplied in Path messages from different
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), is performed.
3. RSVP passes these two results, (Re, Resv_Te) and Path_Te, to 3. RSVP passes these two results, (Re, Resv_Te) and Path_Te, to
traffic control. Traffic control will compute the "minimum" traffic control. Traffic control will compute the "minimum"
of Path_Te and Resv_Te in an appropriate, perhaps service- of Path_Te and Resv_Te in a service-dependent manner, to be
dependent, manner. the effective flowspec.
The definition and implementation of the rules for comparing A generic set of service-specific calls to compare flowspecs and
flowspecs, calculating LUBs and GLBs, and summing Tspecs are compute the LUB and GLB of flowspecs, and to compare and sum
outside the definition of RSVP. Section 3.10.5 shows generic Tspecs, is defined in Section 3.11.5.
calls that an RSVP daemon could use for these functions.
2.4 Soft State 2.3 Soft State
RSVP takes a "soft state" approach to managing the reservation RSVP takes a "soft state" approach to managing the reservation
state in routers and hosts. RSVP soft state is created and state in routers and hosts. RSVP soft state is created and
periodically refreshed by Path and Resv messages. The state is periodically refreshed by Path and Resv messages. The state is
deleted if no matching refresh messages arrive before the deleted if no matching refresh messages arrive before the
expiration of a "cleanup timeout" interval. State may also be expiration of a "cleanup timeout" interval. State may also be
deleted by an explicit "teardown" message, described in the next deleted by an explicit "teardown" message, described in the next
section. At the expiration of each "refresh timeout" period and section. At the expiration of each "refresh timeout" period and
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.
skipping to change at page 23, line 26 skipping to change at page 22, line 26
WF( *{4B}) --> (a) | (c) --> WF( *{4B}) WF( *{4B}) --> (a) | (c) --> WF( *{4B})
| |
Reserve on (a) | Reserve on (c) Reserve on (a) | Reserve on (c)
__________ | __________ __________ | __________
| * {4B} | | | * {3B} | | * {4B} | | | * {3B} |
|__________| | |__________| |__________| | |__________|
| |
Figure 10: Independent Reservations Figure 10: Independent Reservations
2.5 Teardown 2.4 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, PathTear and There are two types of RSVP teardown message, PathTear and
ResvTear. A PathTear message travels towards all receivers ResvTear. A PathTear message travels towards all receivers
downstream from its point of initiation and deletes path state, as downstream from its point of initiation and deletes path state, as
well as all dependent reservation state, along the way. An well as all dependent reservation state, along the way. An
skipping to change at page 24, line 26 skipping to change at page 23, line 26
state. For path state, the granularity for teardown is a single state. For path state, the granularity for teardown is a single
sender. For reservation state, the granularity is an individual sender. For reservation state, the granularity is an individual
filter spec. For example, refer to Figure 7. Receiver R1 could filter spec. For example, refer to Figure 7. Receiver R1 could
send a ResvTear message for sender S2 only (or for any subset of send a ResvTear message for sender S2 only (or for any subset of
the filter spec list), leaving S1 in place. the filter spec list), leaving S1 in place.
A ResvTear message specifies the style and filters; any flowspec A ResvTear message specifies the style and filters; any flowspec
is ignored. Whatever flowspec is in place will be removed if all is ignored. Whatever flowspec is in place will be removed if all
its filter specs are torn down. its filter specs are torn down.
2.6 Errors 2.5 Errors
There are two RSVP error messages, ResvErr and PathErr. PathErr There are two RSVP error messages, ResvErr and PathErr. PathErr
messages are very simple; they are simply sent upstream to the messages are very simple; they are simply sent upstream to the
sender that created the error, and they do not change path state sender that created the error, and they do not change path state
in the nodes though which they pass. There are only a few in the nodes though which they pass. There are only a few
possible causes of path errors. possible causes of path errors.
However, there are a number of ways for a syntactically valid However, there are a number of ways for a syntactically valid
reservation request to fail at some node along the path. A node reservation request to fail at some node along the path. A node
may also decide to preempt an established reservation. The may also decide to preempt an established reservation. The
handling of ResvErr messages is somewhat complex (Section 3.4). handling of ResvErr messages is somewhat complex (Section 3.5).
Since a request that fails may be the result of merging a number Since a request that fails may be the result of merging a number
of requests, a reservation error must be reported to all of the of requests, a reservation error must be reported to all of the
responsible receivers. In addition, merging heterogeneous 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
skipping to change at page 25, line 20 skipping to change at page 24, line 20
establishing a smaller reservation Q0 that would succeed if establishing a smaller reservation Q0 that would succeed if
not merged with Q1. not merged with Q1.
To solve this problem, a ResvErr message establishes To solve this problem, a ResvErr message establishes
additional state, called "blockade state", in each node additional state, called "blockade state", in each node
through which it passes. Blockade state in a node modifies through which it passes. Blockade state in a node modifies
the merging procedure to omit the offending flowspec (Q1 in the merging procedure to omit the offending flowspec (Q1 in
the example) from the merge, allowing a smaller request to be the example) from the merge, allowing a smaller request to be
forwarded and established. The Q1 reservation state is said forwarded and established. The Q1 reservation state is said
to be "blockaded". Detailed rules are presented in Section to be "blockaded". Detailed rules are presented in Section
3.4. 3.5.
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, the should be timed out if not actively deleted. However, the
downstream reservations are left in place, for the following downstream reservations are left in place, for the following
reasons: reasons:
o There are two possible reasons for a receiver persisting in a o There are two possible reasons for a receiver persisting in a
skipping to change at page 26, line 5 skipping to change at page 25, line 5
alternate route that is congested, so an existing reservation alternate route that is congested, so an existing reservation
suddenly fails, then quickly recovers to the original route. suddenly fails, then quickly recovers to the original route.
The blockade state in each downstream router must not remove The blockade state in each downstream router must not remove
the state or prevent its immediate refresh. the state or prevent its immediate refresh.
o If we did not refresh the downstream reservations, they might o If we did not refresh the downstream reservations, they might
time out, to be restored every Tb seconds (where Tb is the time out, to be restored every Tb seconds (where Tb is the
blockade state timeout interval). Such intermittent behavior blockade state timeout interval). Such intermittent behavior
might be very distressing for users. might be very distressing for users.
2.7 Confirmation 2.6 Confirmation
To request a confirmation for its reservation request, a receiver To request a confirmation for its reservation request, a receiver
Rj includes in the Resv message a confirmation-request object Rj includes in the Resv message a confirmation-request object
containing Rj's IP address. At each merge point, only the largest containing Rj's IP address. At each merge point, only the largest
flowspec and any accompanying confirmation-request object is flowspec and any accompanying confirmation-request object is
forwarded upstream. If the reservation request from Rj is equal forwarded upstream. If the reservation request from Rj is equal
to or smaller than the reservation in place on a node, its Resv to or smaller than the reservation in place on a node, its Resv
are not forwarded further, and if the Resv included a are not forwarded further, and if the Resv included a
confirmation-request object, a ResvConf message is sent back to confirmation-request object, a ResvConf message is sent back to
Rj. If the confirmation request is forwarded, it is forwarded Rj. If the confirmation request is forwarded, it is forwarded
skipping to change at page 26, line 36 skipping to change at page 25, line 36
o The receipt of a ResvConf gives no guarantees. Assume the o The receipt of a ResvConf gives no guarantees. Assume the
first two reservation requests from receivers R1 and R2 first two reservation requests from receivers R1 and R2
arrive at the node where they are merged. R2, whose arrive at the node where they are merged. R2, whose
reservation was the second to arrive at that node, may reservation was the second to arrive at that node, may
receive a ResvConf from that node while R1's request has not receive a ResvConf from that node while R1's request has not
yet propagated all the way to a matching sender and may still yet propagated all the way to a matching sender and may still
fail. Thus, R2 may receive a ResvConf although there is no fail. Thus, R2 may receive a ResvConf although there is no
end-to-end reservation in place; furthermore, R2 may receive end-to-end reservation in place; furthermore, R2 may receive
a ResvConf followed by a ResvErr. a ResvConf followed by a ResvErr.
2.8 Policy and Security 2.7 Policy and Security
RSVP-mediated QoS requests will result in particular user(s) RSVP-mediated QoS requests will result in particular user(s)
getting preferential access to network resources. To prevent getting preferential access to network resources. To prevent
abuse, some form of back pressure on users is likely to be abuse, some form of back pressure on users is likely to be
required. This back pressure might take the form of required. This back pressure might take the form of
administrative rules, or of some form of real or virtual billing administrative rules, or of some form of real or virtual billing
for the "cost" of a reservation. The form and contents of such for the "cost" of a reservation. The form and contents of such
back pressure is a matter of administrative policy that may be back pressure is a matter of administrative policy that may be
determined independently by each administrative domain in the determined independently by each administrative domain in the
Internet. Internet.
skipping to change at page 27, line 39 skipping to change at page 26, line 39
with each reservation to the network as needed. Note that the with each reservation to the network as needed. Note that the
merge points for policy data are likely to be at the boundaries of merge points for policy data are likely to be at the boundaries of
administrative domains. It may be necessary to carry accumulated administrative domains. It may be necessary to carry accumulated
and unmerged policy data upstream through multiple nodes before and unmerged policy data upstream through multiple nodes before
reaching one of these merge points. reaching one of these merge points.
This document does not specify the contents of policy data, the This document does not specify the contents of policy data, the
structure of an LPM, or any generic policy models. These will be structure of an LPM, or any generic policy models. These will be
defined in the future. defined in the future.
2.9 Non-RSVP Clouds 2.8 Non-RSVP Clouds
It is impossible to deploy RSVP (or any new protocol) at the same It is impossible to deploy RSVP (or any new protocol) at the same
moment throughout the entire Internet. Furthermore, RSVP may moment throughout the entire Internet. Furthermore, RSVP may
never be deployed everywhere. RSVP must therefore provide correct never be deployed everywhere. RSVP must therefore provide correct
protocol operation even when two RSVP-capable routers are joined protocol operation even when two RSVP-capable routers are joined
by an arbitrary "cloud" of non-RSVP routers. Of course, an by an arbitrary "cloud" of non-RSVP routers. Of course, an
intermediate cloud that does not support RSVP is unable to perform intermediate cloud that does not support RSVP is unable to perform
resource reservation. However, if such a cloud has sufficient resource reservation. However, if such a cloud has sufficient
capacity, it may still provide useful realtime service. capacity, it may still provide useful realtime service.
skipping to change at page 28, line 24 skipping to change at page 27, line 24
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 passes a `NonRSVP' flag bit to the a receiver. Therefore, RSVP passes a `NonRSVP' flag bit to the
local traffic control mechanism when there are non-RSVP-capable local traffic control mechanism when there are non-RSVP-capable
hops in the path to a given sender. Traffic control combines this hops in the path to a given sender. Traffic control combines this
flag bit with its own sources of information, and forwards the flag bit with its own sources of information, and forwards the
composed information on integrated service capability along the composed information on integrated service capability along the
path to receivers using Adspecs [ISrsvp96]. path to receivers using Adspecs [ISrsvp96].
Some topologies of RSVP routers and non-RSVP routers can cause Some topologies of RSVP routers and non-RSVP routers can cause
Resv messages to arrive at the wrong RSVP-capable node, or to Resv messages to arrive at the wrong RSVP-capable node, or to
arrive at the wrong interface of the correct node. An RSVP daemon arrive at the wrong interface of the correct node. An RSVP
must be prepared to handle either situation. If the destination process must be prepared to handle either situation. If the
address does not match any local interface and the message is not destination address does not match any local interface and the
a Path or PathTear, the message must be forwarded without further message is not a Path or PathTear, the message must be forwarded
processing by this node. To handle the wrong interface case, a without further processing by this node. To handle the wrong
"Logical Interface Handle" (LIH) is used. The previous hop interface case, a "Logical Interface Handle" (LIH) is used. The
information included in a Path message includes not only the IP previous hop information included in a Path message includes not
address of the previous node but also an LIH defining the logical only the IP address of the previous node but also an LIH defining
outgoing interface; both values are stored in the path state. A the logical outgoing interface; both values are stored in the path
Resv message arriving at the addressed node carries both the IP state. A Resv message arriving at the addressed node carries both
address and the LIH of the correct outgoing interface, i.e, the the IP address and the LIH of the correct outgoing interface, i.e,
interface that should receive the requested reservation, the interface that should receive the requested reservation,
regardless of which interface it arrives on. regardless of which interface it arrives on.
The LIH may also be useful when RSVP reservations are made over a The LIH may also be useful when RSVP reservations are made over a
complex link layer, to map between IP layer and link layer flow complex link layer, to map between IP layer and link layer flow
entities. entities.
2.10 Host Model 2.9 Host Model
Before a session can be created, the session identification, Before a session can be created, the session identification,
comprised of DestAddress, ProtocolId, and perhaps the generalized comprised of DestAddress, ProtocolId, and perhaps the generalized
destination port, must be assigned and communicated to all the destination port, must be assigned and communicated to all the
senders and receivers by some out-of-band mechanism. When an RSVP senders and receivers by some out-of-band mechanism. When an RSVP
session is being set up, the following events happen at the end session is being set up, the following events happen at the end
systems. systems.
H1 A receiver joins the multicast group specified by H1 A receiver joins the multicast group specified by
DestAddress, using IGMP. DestAddress, using IGMP.
skipping to change at page 29, line 48 skipping to change at page 28, line 48
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.11.1 discusses the general requirements and
outlines a generic interface. outlines a generic interface.
3. RSVP Functional Specification 3. RSVP Functional Specification
3.1 RSVP Message Formats 3.1 RSVP Message Formats
An RSVP message consists of a common header, followed by a body An RSVP message consists of a common header, followed by a body
consisting of a variable number of variable-length, typed consisting of a variable number of variable-length, typed
"objects". The following subsections define the formats of the "objects". The following subsections define the formats of the
common header, the standard object header, and each of the RSVP common header, the standard object header, and each of the RSVP
skipping to change at page 31, line 24 skipping to change at page 30, line 24
RSVP Checksum: 16 bits RSVP Checksum: 16 bits
The one's complement of the one's complement sum of the The one's complement of the one's complement sum of the
message, with the checksum field replaced by zero for the message, with the checksum field replaced by zero for the
purpose of computing the checksum. An all-zero value purpose of computing the checksum. An all-zero value
means that no checksum was transmitted. means that no checksum was transmitted.
Send_TTL: 8 bits Send_TTL: 8 bits
The IP TTL value with which the message was sent. See The IP TTL value with which the message was sent. See
Section 3.7. Section 3.8.
RSVP Length: 16 bits RSVP Length: 16 bits
The total length of this RSVP message in bytes, including The total length of this RSVP message in bytes, including
the common header and the variable-length objects that the common header and the variable-length objects that
follow. follow.
3.1.2 Object Formats 3.1.2 Object Formats
Every object consists of one or more 32-bit words with a one- Every object consists of one or more 32-bit words with a one-
word header, in the following format: word header, with the following format:
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type | | Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
// (Object contents) // // (Object contents) //
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 32, line 33 skipping to change at page 31, line 33
Contains the IP destination address (DestAddress), Contains the IP destination address (DestAddress),
the IP protocol id, and some form of generalized the IP protocol id, and some form of generalized
destination port, to define a specific session for destination port, to define a specific session for
the other objects that follow. Required in every the other objects that follow. Required in every
RSVP message. RSVP message.
RSVP_HOP RSVP_HOP
Carries the IP address of the RSVP-capable node that Carries the IP address of the RSVP-capable node that
sent this message and a logical outgoing interface sent this message and a logical outgoing interface
handle (LIH; see Section 3.2). This document refers handle (LIH; see Section 3.3). This document refers
to a RSVP_HOP object as a PHOP ("previous hop") to a RSVP_HOP object as a PHOP ("previous hop")
object for downstream messages or as a NHOP (" next object for downstream messages or as a NHOP (" next
hop") object for upstream messages. hop") object for upstream messages.
TIME_VALUES TIME_VALUES
Contains the value for the refresh period R used by Contains the value for the refresh period R used by
the creator of the message; see Section 3.6. the creator of the message; see Section 3.7.
Required in every Path and Resv message. Required in 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.
skipping to change at page 33, line 21 skipping to change at page 32, line 21
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. Required in a Path message. sender. Required in a Path message.
SENDER_TSPEC SENDER_TSPEC
Defines the traffic characteristics of a sender's Defines the traffic characteristics of a sender's
data stream. Required in a Path message. data flow. Required in a Path message.
ADSPEC ADSPEC
Carries OPWA data, in a Path message. Carries OPWA data, in a Path message.
ERROR_SPEC ERROR_SPEC
Specifies an error in a PathErr, ResvErr, or a Specifies an error in a PathErr, ResvErr, or a
confirmation in a ResvConf message. confirmation in a ResvConf message.
skipping to change at page 34, line 6 skipping to change at page 33, line 6
Carries cryptographic data to authenticate the Carries cryptographic data to authenticate the
originating node and to verify the contents of this originating node and to verify the contents of this
RSVP message. The use of the INTEGRITY object is RSVP message. The use of the INTEGRITY object is
described in [Baker96]. described in [Baker96].
SCOPE SCOPE
Carries an explicit list of sender hosts towards Carries an explicit list of sender hosts towards
which the information in the message is to be which the information in the message is to be
forwarded. May appear in a Resv, ResvErr, or forwarded. May appear in a Resv, ResvErr, or
ResvTear message. See Section 3.3. ResvTear message. See Section 3.4.
RESV_CONFIRM RESV_CONFIRM
Carries the IP address of a receiver that requested a Carries the IP address of a receiver that requested a
confirmation. May appear in a Resv or ResvConf confirmation. May appear in a Resv or ResvConf
message. message.
C-Type C-Type
Object type, unique within Class-Num. Values are defined Object type, unique within Class-Num. Values are defined
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.10.
3.1.3 Path Messages 3.1.3 Path Messages
Each sender host periodically sends a Path message for each
data stream it originates. The Path message travels from a
sender to receiver(s) along the same path(s) used by the data
packets. The IP source address of a Path message is an address
of the sender it describes, while the destination address is
the DestAddress for the session. These addresses assure that
the message will be correctly routed through a non-RSVP cloud.
The format of a Path message is as follows: The format of a Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<sender descriptor> [ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ] [ <ADSPEC> ]
If the INTEGRITY object is present, it must immediately follow If the INTEGRITY object is present, it must immediately follow
the common header. There are no other requirements on the common header. There are no other requirements on
transmission order, although the above order is recommended. transmission order, although the above order is recommended.
Any number of POLICY_DATA objects may appear. Any number of POLICY_DATA objects may appear.
The PHOP (i.e., the RSVP_HOP) object of each Path message The PHOP (i.e., the RSVP_HOP) object of each Path message
contains the previous hop address, i.e., the IP address of the contains the previous hop address, i.e., the IP address of the
interface through which the Path message was most recently interface through which the Path message was most recently
sent. It also carries a logical interface handle (LIH). sent. It also carries a logical interface handle (LIH).
skipping to change at page 35, line 14 skipping to change at page 34, line 8
If the INTEGRITY object is present, it must immediately follow If the INTEGRITY object is present, it must immediately follow
the common header. There are no other requirements on the common header. There are no other requirements on
transmission order, although the above order is recommended. transmission order, although the above order is recommended.
Any number of POLICY_DATA objects may appear. Any number of POLICY_DATA objects may appear.
The PHOP (i.e., the RSVP_HOP) object of each Path message The PHOP (i.e., the RSVP_HOP) object of each Path message
contains the previous hop address, i.e., the IP address of the contains the previous hop address, i.e., the IP address of the
interface through which the Path message was most recently interface through which the Path message was most recently
sent. It also carries a logical interface handle (LIH). sent. It also carries a logical interface handle (LIH).
The SENDER_TEMPLATE object defines the format of data packets Each sender host periodically sends a Path message for each
from this sender, while the SENDER_TSPEC object specifies the data flow it originates. The SENDER_TEMPLATE object defines
traffic characteristics of the flow. Optionally, there may be the format of the data packets, while the SENDER_TSPEC object
an ADSPEC object carrying advertising (OPWA) data. specifies the traffic characteristics of the flow. Optionally,
there may be an ADSPEC object carrying advertising (OPWA) data
for the flow.
The Path message travels from a sender to receiver(s) along the
same path(s) used by the data packets. The IP source address
of a Path message is an address of the sender it describes,
while the destination address is the DestAddress for the
session. These addresses assure that the message will be
correctly routed through a non-RSVP cloud.
Each RSVP-capable node along the path(s) captures a Path Each RSVP-capable node along the path(s) captures a Path
message and processes it to create path state for the sender message and processes it to create path state for the sender
defined by the SENDER_TEMPLATE and SESSION objects. Any defined by the SENDER_TEMPLATE and SESSION objects. Any
POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in
the path state. If an error is encountered while processing a the path state. If an error is encountered while processing a
Path message, a PathErr message is sent to the originating Path message, a PathErr message is sent to the originating
sender of the Path message. Path messages must satisfy the sender of the Path message. Path messages must satisfy the
rules on SrcPort and DstPort in Section 2.2. rules on SrcPort and DstPort in Section 3.2.
Periodically, the RSVP daemon at a node scans the path state to Periodically, the RSVP process at a node scans the path state
create new Path messages to forward towards the receiver(s). to create new Path messages to forward towards the receiver(s).
Each message contains a sender descriptor defining one sender, Each message contains a sender descriptor defining one sender,
and carries the original sender's IP address as its IP source and carries the original sender's IP address as its IP source
address. Path messages eventually reach the applications on address. Path messages eventually reach the applications on
all receivers; however, they are not looped back to a receiver all receivers; however, they are not looped back to a receiver
running in the same application process as the sender. running in the same application process as the sender.
The RSVP daemon forwards Path messages, and replicates them as The RSVP process forwards Path messages and replicates them as
required, using routing information it obtains from the required by multicast sessions, using routing information it
appropriate uni-/multicast routing daemon. The route depends obtains from the appropriate uni-/multicast routing process.
upon the session DestAddress, and for some routing protocols The route depends upon the session DestAddress, and for some
also upon the source (sender's IP) address. The routing routing protocols also upon the source (sender's IP) address.
information generally includes the list of zero or more The routing information generally includes the list of zero or
outgoing interfaces to which the Path message is to be more outgoing interfaces to which the Path message is to be
forwarded. Because each outgoing interface has a different IP forwarded. Because each outgoing interface has a different IP
address, the Path messages sent out different interfaces address, the Path messages sent out different interfaces
contain different PHOP addresses. In addition, ADSPEC objects contain different PHOP addresses. In addition, ADSPEC objects
carried in Path messages will also generally differ for carried in Path messages will also generally differ for
different outgoing interfaces. different outgoing interfaces.
Some IP multicast routing protocols (e.g., DVMRP, PIM, and 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 do special handling of those interface of each Path message and do special handling of those
messages Path messages that have arrived on the wrong messages Path messages that have arrived on the wrong
interface; see Section 3.8. interface; see Section 3.9.
3.1.4 Resv Messages 3.1.4 Resv Messages
Resv messages carry reservation requests hop-by-hop from Resv messages carry reservation requests hop-by-hop from
receivers to senders, along the reverse paths of data flows for receivers to senders, along the reverse paths of data flows for
the session. The IP destination address of a Resv message is the session. The IP destination address of a Resv message is
the unicast address of a previous-hop node, obtained from the the unicast address of a previous-hop node, obtained from the
path state. The IP source address is an address of the node path state. The IP source address is an address of the node
that sent the message. that sent the message.
skipping to change at page 36, line 32 skipping to change at page 35, line 36
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ] [ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list> <STYLE> <flow descriptor list>
<flow descriptor list> ::= <flow descriptor> | <flow descriptor list> ::= <empty> |
<flow descriptor list> <flow descriptor> <flow descriptor list> <flow descriptor>
If the INTEGRITY object is present, it must immediately follow If the INTEGRITY object is present, it must immediately follow
the common header. The STYLE object followed by the flow the common header. The STYLE object followed by the flow
descriptor list must occur at the end of the message, and descriptor list must occur at the end of the message, and
objects within the flow descriptor list must follow the BNF objects within the flow descriptor list must follow the BNF
given below. There are no other requirements on transmission given below. There are no other requirements on transmission
order, although the above order is recommended. order, although the above order is recommended.
skipping to change at page 37, line 46 skipping to change at page 37, line 4
o SE style: o SE style:
<flow descriptor list> ::= <SE flow descriptor> <flow descriptor list> ::= <SE flow descriptor>
<SE flow descriptor> ::= <SE flow descriptor> ::=
<FLOWSPEC> <filter spec list> <FLOWSPEC> <filter spec list>
<filter spec list> ::= <FILTER_SPEC> <filter spec list> ::= <FILTER_SPEC>
| <filter spec list> <FILTER_SPEC> | <filter spec list> <FILTER_SPEC>
The reservation scope, i.e., the set of senders towards which a The reservation scope, i.e., the set of senders towards which a
particular reservation is to be forwarded (after merging), is particular reservation is to be forwarded (after merging), is
determined as follows: determined as follows:
o Explicit sender selection o Explicit sender selection
The reservation is forwarded to all senders whose The reservation is forwarded to all senders whose
SENDER_TEMPLATE objects recorded in the path state match a SENDER_TEMPLATE objects recorded in the path state match a
FILTER_SPEC object in the reservation. This match must FILTER_SPEC object in the reservation. This match must
follow the rules of Section 2.2. follow the rules of Section 3.2.
o Wildcard sender selection o Wildcard sender selection
A request with wildcard sender selection will match all A request with wildcard sender selection will match all
senders that route to the given outgoing interface. senders that route to the given outgoing interface.
Whenever a Resv message with wildcard sender selection is Whenever a Resv message with wildcard sender selection is
forwarded to more than one previous hop, a SCOPE object forwarded to more than one previous hop, a SCOPE object
must be included in the message (see Section 3.3 below); must be included in the message (see Section 3.4 below);
in this case, the scope for forwarding the reservation is in this case, the scope for forwarding the reservation is
constrained to just the sender IP addresses explicitly constrained to just the sender IP addresses explicitly
listed in the SCOPE object. listed in the SCOPE object.
3.1.5 Teardown Messages 3.1.5 Teardown Messages
There are two types of RSVP teardown message, PathTear and There are two types of RSVP teardown message, PathTear and
ResvTear. ResvTear.
o A PathTear message deletes path state (which in turn o A PathTear message deletes path state (which in turn
deletes any reservation state for that sender), traveling deletes any reservation state for that sender), traveling
towards all receivers that are downstream from the towards all receivers that are downstream from the
initiating node. A PathTear message must be routed initiating node. A PathTear message must be routed
exactly like the corresponding Path message. Therefore, exactly like the corresponding Path message. Therefore,
its IP destination address must be the session its IP destination address must be the session
DestAddress, and its IP source address must be the address DestAddress, and its IP source address must be the address
of the sender being torn down. of the sender being torn down.
o A ResvTear message deletes reservation state, travelling o A ResvTear message deletes reservation state, traveling
towards all matching senders upstream from the initiating towards all matching senders upstream from the initiating
node. A ResvTear message must be routed like the node. A ResvTear message must be routed like the
corresponding Resv message, and its IP destination address corresponding Resv message, and its IP destination address
will be the unicast address of a previous hop. A ResvTear will be the unicast address of a previous hop. A ResvTear
message will be initiated by a receiver, by a node in message will be initiated by a receiver, by a node in
which reservation state has timed out, or by a node in which reservation state has timed out, or by a node in
which a reservation has been preempted. which a reservation has been preempted.
<PathTear Message> ::= <Common Header> [ <INTEGRITY> ] <PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<sender descriptor> [ <sender descriptor> ]
<sender descriptor> ::= (see earlier definition) <sender descriptor> ::= (see earlier definition)
<ResvTear Message> ::= <Common Header> [<INTEGRITY>] <ResvTear Message> ::= <Common Header> [<INTEGRITY>]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
[ <SCOPE> ] <STYLE> [ <SCOPE> ] <STYLE>
<flow descriptor list> <flow descriptor list>
<flow descriptor list> ::= (see earlier definition) <flow descriptor list> ::= (see earlier definition)
FLOWSPEC objects in the flow descriptor list of a ResvTear FLOWSPEC objects in the flow descriptor list of a ResvTear
message will be ignored and may be omitted. The order message will be ignored and may be omitted. The order
requirements for INTEGRITY object, sender descriptor, STYLE requirements for INTEGRITY object, sender descriptor, STYLE
object, and flow descriptor list are as given earlier for Path object, and flow descriptor list are as given earlier for Path
and Resv messages. A ResvTear message may specify any subset and Resv messages. A ResvTear message may specify any subset
of the filter specs in FF- or SE-style reservation state. of the filter specs in FF-style or SE-style reservation state.
Note that, unless it is accidentally dropped along the way, a Note that, unless it is accidentally dropped along the way, a
PathTear message will reach all receivers downstream from the PathTear message will reach all receivers downstream from the
originating node. On the other hand, a ResvTear message will originating node. On the other hand, a ResvTear message will
cease to be forwarded at the node where merging would have cease to be forwarded at the node where merging would have
suppressed forwarding of the corresponding Resv message. suppressed forwarding of the corresponding Resv message.
Depending upon the resulting state change in a node, receipt of Depending upon the resulting state change in a node, receipt of
a ResvTear message may cause a ResvTear message to be a ResvTear message may cause a ResvTear message to be
forwarded, a modified Resv message to be forwarded, or no forwarded, a modified Resv message to be forwarded, or no
message to be forwarded. message to be forwarded.
skipping to change at page 40, line 47 skipping to change at page 39, line 49
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.
<PathErr message> ::= <Common Header> [ <INTEGRITY> ] <PathErr message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC> <SESSION> <ERROR_SPEC>
[ <POLICY_DATA> ...] [ <POLICY_DATA> ...]
<sender descriptor> [ <sender descriptor> ]
<sender descriptor> ::= (see earlier definition) <sender descriptor> ::= (see earlier definition)
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ] <ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ] <ERROR_SPEC> [ <SCOPE> ]
[ <POLICY_DATA> ...] [ <POLICY_DATA> ...]
<STYLE> <error flow descriptor> <STYLE> [ <error flow descriptor> ]
The ERROR_SPEC object specifies the error and includes the IP The ERROR_SPEC object specifies the error and includes the IP
address of the node that detected the error (Error Node address of the node that detected the error (Error Node
Address). One or more POLICY_DATA objects may be included in Address). One or more POLICY_DATA objects may be included in
an error message to provide relevant information (i.e., when an an error message to provide relevant information (i.e., when an
administrative failure is being reported). In a ResvErr administrative failure is being reported). In a ResvErr
message, the RSVP_HOP object contains the previous hop address, message, the RSVP_HOP object contains the previous hop address,
and the STYLE object is copied from the Resv message in error. and the STYLE object is copied from the Resv message in error.
The use of the SCOPE object in a ResvErr message is defined The use of the SCOPE object in a ResvErr message is defined
below in Section 3.3. below in Section 3.4.
The following style-dependent rules define the composition of a The following style-dependent rules define the composition of a
valid error flow descriptor; the object order requirements are valid error flow descriptor; the object order requirements are
as given earlier for a Resv message. as given earlier for a Resv message.
o WF Style: o WF Style:
<error flow descriptor> ::= <WF flow descriptor> <error flow descriptor> ::= <WF flow descriptor>
o FF style: o FF style:
skipping to change at page 42, line 29 skipping to change at page 41, line 29
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 must be left in place, any reservation already in place must be left in place,
and the InPlace flag bit must be on in the ERROR_SPEC of and the InPlace flag bit must be on in the ERROR_SPEC of
the ResvErr message. the ResvErr message.
o Succeeding nodes forward the ResvErr message to next hops o Succeeding nodes forward the ResvErr message to next hops
that have local reservation state. For reservations with that have local reservation state. For reservations with
wildcard scope, there is an additional limitation on wildcard scope, there is an additional limitation on
forwarding ResvErr messages, to avoid loops; see Section forwarding ResvErr messages, to avoid loops; see Section
3.3. There is also a rule restricting the forwarding of a 3.4. There is also a rule restricting the forwarding of a
Resv message after an Admission Control failure; see Resv message after an Admission Control failure; see
Section 3.4. Section 3.5.
A ResvErr message that is forwarded should carry the A ResvErr message that is forwarded should carry the
FILTER_SPEC from the corresponding reservation state. FILTER_SPEC from the corresponding reservation state.
o When a ResvErr message reaches a receiver, the STYLE o When a ResvErr message reaches a receiver, the STYLE
object, flow descriptor list, and ERROR_SPEC object object, flow descriptor list, and ERROR_SPEC object
(including its flags) should be delivered to the receiver (including its flags) should be delivered to the receiver
application. application.
An error encountered while processing an error message must An error encountered while processing an error message must
skipping to change at page 43, line 31 skipping to change at page 42, line 31
The RESV_CONFIRM object is a copy of that object in the Resv The RESV_CONFIRM object is a copy of that object in the Resv
message that triggered the confirmation. The ERROR_SPEC is message that triggered the confirmation. The ERROR_SPEC is
used only to carry the IP address of the originating node, in used only to carry the IP address of the originating node, in
the Error Node Address; the Error Code and Value are zero to the Error Node Address; the Error Code and Value are zero to
indicate a confirmation. The flow descriptor list specifies indicate a confirmation. The flow descriptor list specifies
the particular reservations that are being confirmed; it may be the particular reservations that are being confirmed; it may be
a subset of flow descriptor list of the Resv that requested the a subset of flow descriptor list of the Resv that requested the
confirmation. confirmation.
3.2 Sending RSVP Messages 3.2 Port Usage
An RSVP session is normally defined by the triple: (DestAddress,
ProtocolId, DstPort). Here DstPort is a UDP/TCP destination port
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
ProtocolId specifies a protocol that does not have a destination
port field in the format used by UDP and TCP.
RSVP allows any value for ProtocolId. However, end-system
implementations of RSVP may know about certain values for this
field, and in particular the values for UDP and TCP (17 and 6,
respectively). An end system may give an error to an application
that either:
o specifies a non-zero DstPort for a protocol that does not
have UDP/TCP-like ports, or
o specifies a zero DstPort for a protocol that does have
UDP/TCP-like ports.
Filter specs and sender templates specify the pair: (SrcAddress,
SrcPort), where SrcPort is a UDP/TCP source port field (i.e., a
16-bit quantity carried at octet offset +0 in the transport
header). SrcPort may be omitted (set to zero) in certain cases.
The following rules hold for the use of zero DstPort and/or
SrcPort fields in RSVP.
1. Destination ports must be consistent.
Path state and reservation state for the same DestAddress and
ProtocolId must each have DstPort values that are all zero or
all non-zero. Violation of this condition in a node is a
"Conflicting Dest Port" error.
2. Destination ports rule.
If DstPort in a session definition is zero, all SrcPort
fields used for that session must also be zero. The
assumption here is that the protocol does not have UDP/TCP-
like ports. Violation of this condition in a node is a
"Conflicting Src Port" error.
3. Source Ports must be consistent.
A sender host must not send path state both with and without
a zero SrcPort. Violation of this condition is an "Ambiguous
Path" error.
3.3 Sending RSVP Messages
RSVP messages are sent hop-by-hop between RSVP-capable routers as RSVP messages are sent hop-by-hop between RSVP-capable routers as
"raw" IP datagrams with protocol number 46. Raw IP datagrams are "raw" IP datagrams with protocol number 46. Raw IP datagrams are
also intended to be used between an end system and the first/last also intended to be used between an end system and the first/last
hop router, although it is also possible to encapsulate RSVP hop router, although it is also possible to encapsulate RSVP
messages as UDP datagrams for end-system communication, as messages as UDP datagrams for end-system communication, as
described in Appendix C. UDP encapsulation is needed for systems described in Appendix C. UDP encapsulation is needed for systems
that cannot do raw network I/O. that cannot do raw network I/O.
Path, PathTear, and ResvConf messages must be sent with the Router Path, PathTear, and ResvConf messages must be sent with the Router
skipping to change at page 44, line 32 skipping to change at page 44, line 32
reservation state being transmitted into multiple self-contained reservation state being transmitted into multiple self-contained
messages, each of an acceptable size. messages, each of an acceptable size.
RSVP uses its periodic refresh mechanisms to recover from RSVP uses its periodic refresh mechanisms to recover from
occasional packet losses. Under network overload, however, occasional packet losses. Under network overload, however,
substantial losses of RSVP messages could cause a failure of substantial losses of RSVP messages could cause a failure of
resource reservations. To control the queueing delay and dropping resource reservations. To control the queueing delay and dropping
of RSVP packets, routers should be configured to offer them a of RSVP packets, routers should be configured to offer them a
preferred class of service. If RSVP packets experience noticeable preferred class of service. If RSVP packets experience noticeable
losses when crossing a congested non-RSVP cloud, a larger value losses when crossing a congested non-RSVP cloud, a larger value
can be used for the timeout factor K (see section 3.6). can be used for the timeout factor K (see section 3.7).
Some multicast routing protocols provide for "multicast tunnels", Some multicast routing protocols provide for "multicast tunnels",
which do IP encapsulation of multicast packets for transmission which do IP encapsulation of multicast packets for transmission
through routers that do not have multicast capability. A through routers that do not have multicast capability. A
multicast tunnel looks like a logical outgoing interface that is multicast tunnel looks like a logical outgoing interface that is
mapped into some physical interface. A multicast routing protocol mapped into some physical interface. A multicast routing protocol
that supports tunnels will describe a route using a list of that supports tunnels will describe a route using a list of
logical rather than physical interfaces. RSVP can operate across logical rather than physical interfaces. RSVP can operate across
such multicast tunnels in the following manner: such multicast tunnels in the following manner:
skipping to change at page 45, line 15 skipping to change at page 45, line 15
4. When the Resv message arrives at N, its LIH value provides 4. When the Resv message arrives at N, its LIH value provides
the information necessary to attach the reservation to the the information necessary to attach the reservation to the
appropriate logical interface. Note that N creates and appropriate logical interface. Note that N creates and
interprets the LIH; it is an opaque value to N'. interprets the LIH; it is an opaque value to N'.
Note that this only solves the routing problem posed by tunnels. Note that this only solves the routing problem posed by tunnels.
The tunnel appears to RSVP as a non-RSVP cloud. To establish RSVP The tunnel appears to RSVP as a non-RSVP cloud. To establish RSVP
reservations within the tunnel, additional machinery will be reservations within the tunnel, additional machinery will be
required, to be defined in the future. required, to be defined in the future.
3.3 Avoiding RSVP Message Loops 3.4 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 on each hop only once per Path and Resv messages are forwarded on each hop only once per
refresh period. This avoids looping packets, but there is still refresh period. This avoids looping packets, but there is still
the possibility of an "auto-refresh" loop, clocked by the refresh the possibility of an "auto-refresh" loop, clocked by the refresh
period. Such auto-refresh loops keep state active "forever", even period. Such auto-refresh loops keep state active "forever", even
if the end nodes have ceased refreshing it, until either the if the end nodes have ceased refreshing it, until the receivers
receivers leave the multicast group and/or the senders stop leave the multicast group and/or the senders stop sending Path
sending Path messages. On the other hand, error and teardown messages. On the other hand, error and teardown messages are
messages are forwarded immediately and are therefore subject to forwarded immediately and are therefore subject to direct looping.
direct looping.
Consider each message type. Consider each message type.
o Path Messages o Path Messages
Path messages are forwarded in exactly the same way as IP Path messages are forwarded in exactly the same way as IP
data packets. Therefore there should be no loops of Path data packets. Therefore there should be no loops of Path
messages (except perhaps for transient routing loops, which messages (except perhaps for transient routing loops, which
we ignore here), even in a topology with cycles. we ignore here), even in a topology with cycles.
skipping to change at page 48, line 17 skipping to change at page 48, line 17
reservation state or message in error. reservation state or message in error.
2. Suppose a wildcard-style ResvErr message arrives at a node 2. Suppose a wildcard-style ResvErr message arrives at a node
with a SCOPE object containing the sender host address list with a SCOPE object containing the sender host address list
L. The node forwards the ResvErr message using the rules of L. The node forwards the ResvErr message using the rules of
Section 3.1.6. However, the ResvErr message forwarded out OI Section 3.1.6. However, the ResvErr message forwarded out OI
must contain a SCOPE object derived from L by including only must contain a SCOPE object derived from L by including only
those senders that route to OI. If this SCOPE object is those senders that route to OI. If this SCOPE object is
empty, the ResvErr message should not be sent out OI. empty, the ResvErr message should not be sent out OI.
3.4 Blockade State 3.5 Blockade State
The basic rule for creating a Resv refresh message is to merge the The basic rule for creating a Resv refresh message is to merge the
flowspecs of the reservation requests in place in the node, by flowspecs of the reservation requests in place in the node, by
computing their LUB. However, this rule is modified by the computing their LUB. However, this rule is modified by the
existence of "blockade state" resulting from ResvErr messages, to existence of "blockade state" resulting from ResvErr messages, to
solve the KR-II problem (see Section 2.6). The blockade state solve the KR-II problem (see Section 2.5). The blockade state
also enters into the routing of ResvErr messages for Admission also enters into the routing of ResvErr messages for Admission
Control failure. Control failure.
When a ResvErr message for an Admission Control failure is When a ResvErr message for an Admission Control failure is
received, its flowspec Qe is used to create or refresh an element received, its flowspec Qe is used to create or refresh an element
of local blockade state. Each element of blockade state consists of local blockade state. Each element of blockade state consists
of a blockade flowspec Qb taken from the flowspec of the ResvErr of a blockade flowspec Qb taken from the flowspec of the ResvErr
message, and an associated blockade timer Tb. When a blockade message, and an associated blockade timer Tb. When a blockade
timer expires, the corresponding blockade state is deleted. timer expires, the corresponding blockade state is deleted.
skipping to change at page 50, line 27 skipping to change at page 50, line 27
| |________| | |________|
| |
---------------------------|------------------------------- ---------------------------|-------------------------------
| |
| ________ | ________
(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.6 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 process of route changes for particular
destinations. The RSVP daemon should use this information to destinations. The RSVP process 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 update the path interfaces for destination G, RSVP should update the path
state, wait for a short period W, and then send Path state, wait for a short period W, and then send Path
refreshes for all sessions G/* (i.e., for any session with refreshes for all sessions G/* (i.e., for any session with
destination G, regardless of destination port). destination G, regardless of destination port).
skipping to change at page 51, line 12 skipping to change at page 51, line 12
The short wait period before sending Path refreshes is to The short wait period before sending Path refreshes is to
allow the routing protocol to settle, and the value for W allow the routing protocol to settle, and the value for W
should be chosen accordingly. Currently W = 2 sec is should be chosen accordingly. Currently W = 2 sec is
suggested; however, this value should be configurable per suggested; however, this value should be configurable per
interface. 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 to that PHOP. send immediate Resv refreshes to that PHOP.
3.6 Time Parameters 3.7 Time Parameters
There are two time parameters relevant to each element of RSVP There are two time parameters relevant to each element of RSVP
path or reservation state in a node: the refresh period R between path or reservation state in a node: the refresh period R between
generation of successive refreshes for the state by the neighbor generation of successive refreshes for the state by the neighbor
node, and the local state's lifetime L. Each RSVP Resv or Path node, and the local state's lifetime L. Each RSVP Resv or Path
message may contain a TIME_VALUES object specifying the R value message may contain a TIME_VALUES object specifying the R value
that was used to generate this (refresh) message. This R value is that was used to generate this (refresh) message. This R value is
then used to determine the value for L when the state is received then used to determine the value for L when the state is received
and stored. The values for R and L may vary from hop to hop. and stored. The values for R and L may vary from hop to hop.
skipping to change at page 52, line 37 skipping to change at page 52, line 37
6. To improve robustness, a node may temporarily send refreshes 6. To improve robustness, a node may temporarily send refreshes
more often than R after a state change (including initial more often than R after a state change (including initial
state establishment). state establishment).
7. The values of Rdef, K, and Slew.Max used in an implementation 7. The values of Rdef, K, and Slew.Max used in an implementation
should be easily modifiable per interface, as experience may should be easily modifiable per interface, as experience may
lead to different values. The possibility of dynamically lead to different values. The possibility of dynamically
adapting K and/or Slew.Max in response to measured loss rates adapting K and/or Slew.Max in response to measured loss rates
is for future study. is for future study.
3.7 Traffic Policing and Non-Integrated Service Hops 3.8 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
in any particular case. in any particular case.
The RSVP daemon passes to traffic control a separate policing flag The RSVP process passes to traffic control a separate policing
for each of these three situations. flag for each of these three situations.
o E_Police_Flag -- Entry Policing o E_Police_Flag -- Entry Policing
This flag is set in the first-hop RSVP node that implements This flag is set in the first-hop RSVP node that implements
traffic control (and is therefore capable of policing). traffic control (and is therefore capable of policing).
For example, sender hosts must implement RSVP but currently For example, sender hosts must implement RSVP but currently
many of them do not implement traffic control. In this case, many of them do not implement traffic control. In this case,
the E_Police_Flag should be off in the sender host, and it the E_Police_Flag should be off in the sender host, and it
should only be set on when the first node capable of traffic should only be set on when the first node capable of traffic
skipping to change at page 53, line 31 skipping to change at page 53, line 31
being merged. being merged.
o B_Police_Flag -- Branch Policing o B_Police_Flag -- Branch Policing
This flag should be set on when the flowspec being installed This flag should be set on when the flowspec being installed
is smaller than, or incomparable to, a FLOWSPEC in place on is smaller than, or incomparable to, a FLOWSPEC in place on
any other interface, for the same FILTER_SPEC and SESSION. any other interface, for the same FILTER_SPEC and SESSION.
RSVP must also test for the presence of non-RSVP hops in the path RSVP must also test for the presence of non-RSVP hops in the path
and pass this information to traffic control. From this flag bit and pass this information to traffic control. From this flag bit
that the RSVP daemon supplies and from its own local knowledge, that the RSVP process supplies and from its own local knowledge,
traffic control can detect the presence of a hop in the path that traffic control can detect the presence of a hop in the path that
is not capable of QoS control, and it passes this information to is not capable of QoS control, and it passes this information to
the receivers in Adspecs [ISrsvp96]. the receivers in Adspecs [ISrsvp96].
With normal IP forwarding, RSVP can detect a non-RSVP hop by With normal IP forwarding, RSVP can detect a non-RSVP hop by
comparing the IP TTL with which a Path message is sent to the TTL comparing the IP TTL with which a Path message is sent to the TTL
with which it is received; for this purpose, the transmission TTL with which it is received; for this purpose, the transmission TTL
is placed in the common header. However, the TTL is not always a is placed in the common header. However, the TTL is not always a
reliable indicator of non-RSVP hops, and other means must reliable indicator of non-RSVP hops, and other means must
sometimes be used. For example, if the routing protocol uses IP sometimes be used. For example, if the routing protocol uses IP
encapsulating tunnels, then the routing protocol must inform RSVP encapsulating tunnels, then the routing protocol must inform RSVP
when non-RSVP hops are included. If no automatic mechanism will when non-RSVP hops are included. If no automatic mechanism will
work, manual configuration will be required. work, manual configuration will be required.
3.8 Multihomed Hosts 3.9 Multihomed Hosts
Accommodating multihomed hosts requires some special rules in Accommodating multihomed hosts requires some special rules in
RSVP. We use the term `multihomed host' to cover both hosts (end RSVP. We use the term `multihomed host' to cover both hosts (end
systems) with more than one network interface and routers that are systems) with more than one network interface and routers that are
supporting local application programs. supporting local application programs.
An application executing on a multihomed host may explicitly An application executing on a multihomed host may explicitly
specify which interface any given flow will use for sending and/or specify which interface any given flow will use for sending and/or
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 process 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.11.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 process on the host then sends Path messages for
application out the specified interface (only). this 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.11.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 process 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 process must determine which case
by examining the path state, to decide which incoming holds by examining the path state, to decide which incoming
interface to use for sending Resv messages. interface to use for sending Resv messages.
1. The multicast routing protocol may create a separate 1. The multicast routing protocol may create a separate
branch of the multicast distribution `tree' to deliver branch of the multicast distribution `tree' to deliver
to Iapp. In this case, there will be path state for to Iapp. In this case, there will be path state for
both Isp and Iapp. The path state on Iapp should only both 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 process. 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.10 Future Compatibility
We may expect that in the future new object C-Types will be We may expect that in the future new object C-Types will be
defined for existing object classes, and perhaps new object defined for existing object classes, and perhaps new object
classes will be defined. It will be desirable to employ such new classes will be defined. It will be desirable to employ such new
objects within the Internet using older implementations that do objects within the Internet using older implementations that do
not recognize them. Unfortunately, this is only possible to a not recognize them. Unfortunately, this is only possible to a
limited degree with reasonable complexity. The rules are as limited degree with reasonable complexity. The rules are as
follows (`b' represents a bit). follows (`b' represents a bit).
1. Unknown Class 1. Unknown Class
skipping to change at page 56, line 43 skipping to change at page 56, line 43
and C-Type that failed (see Appendix B); the end system that and C-Type that failed (see Appendix B); the end system that
originated the failed message may be able to use this originated the failed message may be able to use this
information to retry the request using a different C-Type information to retry the request using a different C-Type
object, repeating this process until it runs out of object, repeating this process until it runs out of
alternatives or succeeds. 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 process; 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.11 RSVP Interfaces
RSVP on a router has interfaces to routing and to traffic control. RSVP on a router has interfaces to routing and to traffic control.
RSVP on a host has an interface to applications (i.e, an API) and RSVP on a host has an interface to applications (i.e, an API) and
also an interface to traffic control (if it exists on the host). also an interface to traffic control (if it exists on the host).
3.10.1 Application/RSVP Interface 3.11.1 Application/RSVP Interface
This section describes a generic interface between an This section describes a generic interface between an
application and an RSVP control process. The details of a real application and an RSVP control process. The details of a real
interface may be operating-system dependent; the following can interface may be operating-system dependent; the following can
only suggest the basic functions to be performed. Some of only suggest the basic functions to be performed. Some of
these calls cause information to be returned asynchronously. these calls cause information to be returned asynchronously.
o Register Session o Register Session
Call: SESSION( DestAddress , ProtocolId, DstPort Call: SESSION( DestAddress , ProtocolId, DstPort
skipping to change at page 58, line 5 skipping to change at page 58, line 5
Call: SENDER( Session-id Call: SENDER( Session-id
[ , Source_Address ] [ , Source_Port ] [ , Source_Address ] [ , Source_Port ]
[ , Sender_Template ] [ , Sender_Template ]
[ , Sender_Tspec ] [ , Adspec ] [ , Sender_Tspec ] [ , Adspec ]
[ , Data_TTL ] [ , Policy_data ] ) [ , Data_TTL ] [ , Policy_data ] )
A sender uses this call to define, or to modify the A sender uses this call to define, or to modify the
definition of, the attributes of the data stream. The definition of, the attributes of the data flow. The first
first SENDER call for the session registered as `Session- SENDER call for the session registered as `Session-id'
id' will cause RSVP to begin sending Path messages for will cause RSVP to begin sending Path messages for this
this session; later calls will modify the path 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 interface will be used. This parameter is needed
only on a multihomed sender host. only on a multihomed sender host.
skipping to change at page 63, line 12 skipping to change at page 63, line 12
The parameters are interpreted as in the Resv Error The parameters are interpreted as in the Resv Error
upcall. upcall.
Although RSVP messages indicating path or resv events may Although RSVP messages indicating path or resv events may
be received periodically, the API should make the be received periodically, the API should make the
corresponding asynchronous upcall to the application only corresponding asynchronous upcall to the application only
on the first occurrence or when the information to be on the first occurrence or when the information to be
reported changes. All error and confirmation events reported changes. All error and confirmation events
should be reported to the application. should be reported to the application.
3.10.2 RSVP/Traffic Control Interface 3.11.2 RSVP/Traffic Control Interface
In an RSVP-capable node, enhanced QoS is achieved by a group of In an RSVP-capable node, enhanced QoS is achieved by a group of
inter-related traffic control functions: a packet classifier, inter-related traffic control functions: a packet classifier,
an admission control module, and a packet scheduler. This an admission control module, and a packet scheduler. This
section describes a generic RSVP interface to traffic control. section describes a generic RSVP interface to traffic control.
o Make a Reservation o Make a Reservation
Call: TC_AddFlowspec( Interface, TC_Flowspec, Call: TC_AddFlowspec( Interface, TC_Flowspec,
TC_Tspec, Police_Flags ) TC_Tspec, Police_Flags )
-> RHandle [, Fwd_Flowspec] -> RHandle [, Fwd_Flowspec]
The TC_Flowspec parameter defines the desired effective The TC_Flowspec parameter defines the desired effective
QoS to admission control; its value is computed as the QoS to admission control; its value is computed as the
maximum over the flowspecs of different next hops (see the maximum over the flowspecs of different next hops (see the
Compare_Flowspecs call below). The TC_Tspec parameter Compare_Flowspecs call below). The TC_Tspec parameter
defines the effective sender Tspec Path_Te (see Section defines the effective sender Tspec Path_Te (see Section
2.3). The Police_Flags parameter carries the three flags 2.2). The Police_Flags parameter carries the three flags
E_Police_Flag, M_Police_Flag, and B_Police_Flag; see E_Police_Flag, M_Police_Flag, and B_Police_Flag; see
Section 3.7. Section 3.8.
If this call is successful, it establishes a new If this call is successful, it establishes a new
reservation channel corresponding to RHandle; otherwise, reservation channel corresponding to RHandle; otherwise,
it returns an error code. The opaque number RHandle is it returns an error code. The opaque number RHandle is
used by the caller for subsequent references to this used by the caller for subsequent references to this
reservation. If the traffic control service updates the reservation. If the traffic control service updates the
flowspec, the call will also return the updated object as flowspec, the call will also return the updated object as
Fwd_Flowspec. Fwd_Flowspec.
o Modify Reservation o Modify Reservation
skipping to change at page 64, line 46 skipping to change at page 64, line 46
o OPWA Update o OPWA Update
Call: TC_Advertise( Interface, Adspec, Call: TC_Advertise( Interface, Adspec,
Non_RSVP_Hop_flag ) -> New_Adspec Non_RSVP_Hop_flag ) -> New_Adspec
This call is used for OPWA to compute the outgoing This call is used for OPWA to compute the outgoing
advertisement New_Adspec for a specified interface. The advertisement New_Adspec for a specified interface. The
flag bit Non_RSVP_Hop_flag should be set whenever the RSVP flag bit Non_RSVP_Hop_flag should be set whenever the RSVP
daemon detects that the previous RSVP hop included one or process detects that the previous RSVP hop included one or
more non-RSVP-capable routers. TC_Advertise will insert more non-RSVP-capable routers. TC_Advertise will insert
this information into New_Adspec to indicate that a non- this information into New_Adspec to indicate that a non-
integrated-service hop was found; see Section 3.7. integrated-service hop was found; see Section 3.8.
o Preemption Upcall o Preemption Upcall
Upcall: TC_Preempt() -> RHandle, Reason_code Upcall: TC_Preempt() -> RHandle, Reason_code
In order to grant a new reservation request, the admission In order to grant a new reservation request, the admission
control and/or policy control modules may preempt one or control and/or policy control modules may preempt one or
more existing reservations. This will trigger a more existing reservations. This will trigger a
TC_Preempt() upcall to RSVP for each preempted TC_Preempt() upcall to RSVP for each preempted
reservation, passing the RHandle of the reservation and a reservation, passing the RHandle of the reservation and a
sub-code indicating the reason. sub-code indicating the reason.
3.10.3 RSVP/Policy Control Interface 3.11.3 RSVP/Policy Control Interface
This interface will be specified in a future document. This interface will be specified in a future document.
3.10.4 RSVP/Routing Interface 3.11.4 RSVP/Routing Interface
An RSVP implementation needs the following support from the An RSVP implementation needs the following support from the
packet forwarding and routing mechanisms of the node. 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 as well as the IP source address and IP TTL with received as well as the IP source address and IP TTL with
which it arrived must also be available to the RSVP which it arrived must also be available to the RSVP
daemon. process.
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.
o Route Query o Route Query
To forward Path and PathTear messages, an RSVP daemon must To forward Path and PathTear messages, an RSVP process
be able to query the routing daemon(s) for routes. must be able to query the routing process(s) for routes.
Ucast_Route_Query( [ SrcAddress, ] DestAddress, Ucast_Route_Query( [ SrcAddress, ] DestAddress,
Notify_flag ) -> OutInterface Notify_flag ) -> OutInterface
Mcast_Route_Query( [ SrcAddress, ] DestAddress, Mcast_Route_Query( [ SrcAddress, ] DestAddress,
Notify_flag ) Notify_flag )
-> [ IncInterface, ] OutInterface_list -> [ IncInterface, ] OutInterface_list
skipping to change at page 66, line 35 skipping to change at page 66, line 35
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,
the routing daemon may provide an asynchronous callback to the routing process may provide an asynchronous callback
the RSVP daemon that a specified route has changed. to the RSVP process that a specified route has changed.
Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress, Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
OutInterface OutInterface
Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress, Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
[ IncInterface, ] OutInterface_list [ IncInterface, ] OutInterface_list
o Outgoing Link Specification o Outgoing Link Specification
skipping to change at page 67, line 27 skipping to change at page 67, line 27
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.5 Service-Dependent Manipulations 3.11.5 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 process must have
available to it the following service-dependent routines. available to it the following service-dependent routines.
o Compare Flowspecs o Compare Flowspecs
Compare_Flowspecs( Flowspec_1, Flowspec_2 ) -> Compare_Flowspecs( Flowspec_1, Flowspec_2 ) ->
result_code 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 process
cannot itself parse a flowspec to extract the Tspec, it cannot itself parse a flowspec to extract the Tspec, it
can use the Compare_Flowspecs call to implicitly calculate can use the Compare_Flowspecs call to implicitly calculate
Resv_Te (see Section 2.3). Resv_Te (see Section 2.2).
o Compute LUB of Flowspecs o Compute LUB of Flowspecs
LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) -> LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
Flowspec_LUB Flowspec_LUB
o Compute GLB of Flowspecs o Compute GLB of Flowspecs
GLB_of_Flowspecs( Flowspec_1, Flowspec_2 ) -> GLB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
skipping to change at page 68, line 28 skipping to change at page 68, line 28
Compare_Tspecs( Tspec_1, Tspec_2 ) -> result_code Compare_Tspecs( Tspec_1, Tspec_2 ) -> result_code
The possible result_codes indicate: Tspecs are equal, or The possible result_codes indicate: Tspecs are equal, or
Tspecs are unequal. Tspecs are unequal.
o Sum Tspecs o Sum Tspecs
Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum
This call is used to compute Path_Te (see Section 2.3). This call is used to compute Path_Te (see Section 2.2).
4. Message Processing Rules
This section provides a generic description of the rules for RSVP
operation. It is intended to outline a set of algorithms that will
accomplish the needed function, omitting some details.
This section assumes the generic interface calls defined in Section
3.10 and the following data structures. An actual implementation may
use additional or different data structures and interfaces. The data
structure fields that are shown are required unless they are
explicitly labelled as optional.
o PSB -- Path State Block
Each PSB holds path state for a particular (session, sender)
pair, defined by SESSION and SENDER_TEMPLATE objects,
respectively, received in a Path message.
PSB contents include the following values from a Path message:
- Session
- Sender_Template
- Sender_Tspec
- The previous hop IP address and the Logical Interface
Handle (LIH) from a PHOP object
- The remaining IP TTL
- POLICY_DATA and/or ADSPEC objects (optional)
- Non_RSVP flag (Section 3.7).
- E_Police flag (Section 3.7)
- Local_Only flag (Section 3.8)
In addition, the PSB contains the following information provided
by routing: OutInterface_list, which is the list of outgoing
interfaces for this (sender, destination), and IncInterface,
which is the expected incoming interface. For a unicast
destination, OutInterface_list contains one entry and
IncInterface is undefined.
Note that there may be more than one PSB for the same (session,
sender) pair but different incoming interfaces (see Section
3.8). At most one of these, which will have the Local_Only flag
off, will be the PSB used for forwarding Path messages
downstream; we will refer to it as the "forwarding PSB" in the
following. The other PSB's will have the Local_Only flag on and
an empty OutInterface_list. The Local_Only flag is needed to
correctly match PSB's against RSB's, by the rules of Section
3.8.
o RSB -- Reservation State Block
Each RSB holds a reservation request that arrived in a
particular Resv message, corresponding to the triple: (session,
next hop, Filter_spec_list). Here "Filter_spec_list" may be a
list of FILTER_SPECs (for SE style), a single FILTER_SPEC (FF
style), or empty (WF style). We define the virtual object type
"FILTER_SPEC*" for such a data structure.
RSB contents include:
- Session specification
- Next hop IP address
- Filter_spec_list
- The outgoing (logical) interface OI on which the
reservation is to be made or has been made.
- Style
- Flowspec
- A SCOPE object (optional, depending upon style)
- RESV_CONFIRM object that was received (optional)
o TCSB -- Traffic Control State Block
Each TCSB holds the reservation specification that has been
handed to traffic control for a specific outgoing interface. In
general, TCSB information is derived from RSB's for the same
outgoing interface. Each TCSB defines a single reservation for
a particular triple: (session, OI, Filter_spec_list). TCSB
contents include:
- Session
- OI (Outgoing Interface)
- Filter_spec_list
- TC_Flowspec, the effective flowspec, i.e., the LUB over the
corresponding FLOWSPEC values from matching RSB's.
TC_Flowspec is passed to traffic control to make the actual
reservation.
- Fwd_Flowspec, the updated object to be forwarded after
merging.
- TC_Tspec, equal to Path_Te, the effective sender Tspec.
- Police Flags
The flags E_Police_Flag, M_Police_Flag, and B_Police_Flag
are defined in Section 3.7.
- Rhandle, F_Handle_list
Handles returned by the traffic control interface,
corresponding to a flowspec and perhaps a list of filter
specs.
- A RESV_CONFIRM object to be forwarded.
o BSB -- Blockade State Block
Each BSB contains an element of blockade state. Depending upon
the reservation style in use, the BSB's may be per (session,
sender_template) pair or per (session, PHOP) pair. In practice,
an implementation might embed a BSB within a PSB; however, for
clarity we describe BSB's independently.
The contents of a BSB include:
- Session
- Sender_Template (which is also a filter spec)
- PHOP
- FLOWSPEC Qb
- Blockade timer Tb
The following Boolean Flag variables are used in this section:
Path_Refresh_Needed, Resv_Refresh_Needed, Tear_Needed, Need_Scope,
B_Merge, and NeworMod. Refresh_PHOP_list is a variable-length list
of PHOPs to be refreshed.
MESSAGE ARRIVES
Verify version number and RSVP checksum, and discard message if any
mismatch is found.
If the message type is not Path or PathTear or ResvConf and if the IP
destination address does not match any of the addresses of the local
interfaces, then forward the message to IP destination address and
return.
Parse the sequence of objects in the message. If any required
objects are missing or the length field of the common header does not
match an object boundary, discard the message and return.
Verify the INTEGRITY object, if any. If the check fails, discard the
message and return.
Verify the consistent use of port fields. If the DstPort in the
SESSION object is zero but the SrcPort in a SENDER_TEMPLATE or
FILTER_SPEC object is non-zero, then the message has a "conflicting
source port" error; silently discard the message and return.
Processing of POLICY_DATA objects will be specified in the future.
Further processing depends upon message type.
Path MESSAGE ARRIVES
Assume the Path message arrives on interface InIf.
Process the sender descriptor object sequence in the message as
follows. The Path_Refresh_Needed and Resv_Refresh_Needed flags
are initially off.
o Search for a path state block (PSB) whose (session,
sender_template) pair matches the corresponding objects in
the message, and whose IncInterface matches InIf.
During this search:
1. If a PSB is found whose session matches the
DestAddress and Protocol Id fields of the received
SESSION object, but the DstPorts differ and one is
zero, then build and send a "Conflicting Dst Port"
PathErr message, drop the Path message, and return.
2. If a PSB is found with a matching sender host but the
SrcPorts differ and one of the SrcPorts is zero, then
build and send an "Ambiguous Path" PathErr message,
drop the Path message, and return.
3. If a forwarding PSB is found, i.e., a PSB that matches
the (session, sender_template) pair and whose
Local_Only flag is off, save a pointer to it in the
variable fPSB. If none is found, set fPSB to NULL.
o If there was no matching PSB, then:
1. Create a new PSB.
2. Copy contents of the SESSION, SENDER_TEMPLATE,
SENDER_TSPEC, and PHOP (IP address and LIH) objects
into the PSB.
3. If the sender is from the local API, set
OutInterface_List to the single interface whose
address matches the sender address, and make
IncInterface undefined. Otherwise, turn on the
Local_Only flag.
4. Turn on the Path_Refresh_Needed flag.
o Otherwise (there is a matching PSB):
- If the PHOP IP address, the LIH, or Sender_Tspec
differs between the message and the PSB, copy the new
value into the PSB and turn on the Path_Refresh_Needed
flag. If the PHOP IP address or the LIH differ, also
turn on the Resv_Refresh_Needed flag.
o Call the resulting PSB the "current PSB" (cPSB). Update
the cPSB, as follows:
- Start or Restart the cleanup timer for the PSB.
- If the message contains an ADSPEC object, copy it into
the PSB.
- Copy E_Police flag from SESSION object into PSB.
- Store the received TTL into the PSB.
If the received TTL differs from Send_TTL in the RSVP
common header, set the Non_RSVP flag on in the PSB.
o If the PSB is new or if there is no route change
notification in place, then perform the following routing
manipulations, but not if the cPSB is from the local API.
1. Invoke the appropriate Route_Query routine using
DestAddress from SESSION and (for multicast routing)
SrcAddress from Sender_Template.
Call the results (Rt_OutL, Rt_InIf).
2. If the destination is multicast and Rt_InIf differs
from IncInterface in the cPSB, but fPSB points to the
cPSB, then do the following.
- Turn on the Local_Only flag and clear the
OutInterface_list of the fPSB. Set the fPSB
pointer to NULL.
- Search for a PSB for the same (session,
sender_template) pair whose IncInterface matches
Rt_InIf. If one is found, set fPSB to point to
it.
3. If the destination is multicast and Rt_InIf is the
same as IncInterface in the cPSB, but fPSB does not
point to the cPSB, then do the following.
- Copy into the cPSB the OutInterface_list from the
PSB, if any, pointed to by fPSB. Clear
OutInterface_list and turn on the Local_Only flag
in the PSB pointed to by fPSB, if any.
- Turn off the Local_Only flag in the cPSB and set
fPSB to point to cPSB.
4. If Rt_OutL differs from OutInterface_list of the PSB
pointed to by fPSB, then:
- Update the OutInterface_list of the PSB from
Rt_OutL, and then execute the Path LOCAL REPAIR
event sequence below.
o If the Path_Refresh_Needed flag is now off, drop the Path
message and return.
Otherwise (the path state is new or modified), do
refreshes, upcalls, and state updates as follows.
1. If this Path message came from a network interface and
not from a local application, make a Path Event upcall
for each local application for this session:
Call: <Upcall_Proc>( session-id, PATH_EVENT,
flags, sender_tspec, sender_template
[ , ADSPEC] [ , POLICY_DATA] )
2. If OutInterface_list is not empty, execute the Path
REFRESH event sequence (below) for the sender defined
by the PSB.
3. Search for any matching reservation state, i.e., an
RSB whose Filter_spec_list includes a FILTER_SPEC
matching the SENDER_TEMPLATE and whose OI appears in
the OutInterface_list, and make this the `active RSB'.
If none is found, drop the Path message and return.
4. Execute the Resv REFRESH sequence (below) for the PHOP
in the PSB.
5. Execute the event sequence UPDATE TRAFFIC CONTROL to
update the local traffic control state if necessary.
This sequence will turn on the Resv_Refresh_Needed
flag if the traffic control state has been modified in
a manner that should trigger a reservation refresh.
If so, execute the Resv REFRESH sequence for the PHOP
in the PSB.
o Drop the Path message and return.
PathTear MESSAGE ARRIVES
o Search for a PSB whose (Session, Sender_Template) pair
matches the corresponding objects in the message. If no
matching PSB is found, drop the PathTear message and
return.
o Forward a copy of the PathTear message to each outgoing
interface listed in OutInterface_list of the PSB.
o Find each RSB that matches this PSB, i.e., whose
Filter_spec_list matches Sender_Template in the PSB and
whose OI is included in OutInterface_list.
1. If the RSB style is explicit, then:
- Delete from Filter_spec_list the FILTER_SPEC that
matches the PSB.
- if Filter_spec_list is now empty, delete the RSB.
2. Otherwise (RSB style is wildcard) then:
- If this RSB matches no other PSB, then delete the
RSB.
3. If an RSB was found, execute the event sequence UPDATE
TRAFFIC CONTROL (below) to update the traffic control
state to be consistent with the current reservation
and path state.
o Delete the PSB.
o Drop the PathTear message and return.
PathErr MESSAGE ARRIVES
o Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair
matches the corresponding objects in the message. If no
matching PSB is found, drop the PathErr message and return.
o If the previous hop address in the PSB is the local API,
make an error upcall to the application:
Call: <Upcall_Proc>( session-id, PATH_ERROR,
Error_code, Error_value,
Node_Addr, Sender_Template
[ , Policy_Data] )
Any SENDER_TSPEC or ADSPEC object in the message is
ignored.
Otherwise, send a copy of the PathErr message to the PHOP
IP address.
o Drop the PathErr message and return.
Resv MESSAGE ARRIVES
Initially, Refresh_PHOP_list is empty and the
Resv_Refresh_Needed and NeworMod flags are off. These variables
are used to control immediate reservation refreshes.
o Determine the Outgoing Interface OI
The logical outgoing interface OI is taken from the LIH in
the NHOP object. (If the physical interface is not implied
by the LIH, it can be learned from the interface matching
the IP destination address).
o Check the path state
1. If there are no existing PSB's for SESSION then build
and send a ResvErr message (as described later)
specifying "No path information", drop the Resv
message, and return.
2. If a PSB is found with a matching sender host but the
SrcPorts differ and one of the SrcPorts is zero, then
build and send an "Ambiguous Path" PathErr message,
drop the Resv message, and return.
o Check for incompatible styles.
If any existing RSB for the session has a style that is
incompatible with the style of the message, build and send
a ResvErr message specifying "Conflicting Style", drop the
Resv message, and return.
Process the flow descriptor list to make reservations, as
follows, depending upon the style. The following uses a filter
spec list struct Filtss of type FILTER_SPEC* (defined earlier).
For FF style: execute the following steps independently for each
flow descriptor in the message, i.e., for each (FLOWSPEC,
Filtss) pair. Here the structure Filtss consists of the
FILTER_SPEC from the flow descriptor.
For SE style, execute the following steps once for (FLOWSPEC,
Filtss), with Filtss consisting of the list of FILTER_SPEC
objects from the flow descriptor.
For WF style, execute the following steps once for (FLOWSPEC,
Filtss), with Filtss an empty list.
o Check the path state, as follows.
1. Locate the set of PSBs (senders) that route to OI and
whose SENDER_TEMPLATEs match a FILTER_SPEC in Filtss.
If this set is empty, build and send an error message
specifying "No sender information", and continue with
the next flow descriptor in the Resv message.
2. If the style has explicit sender selection (e.g., FF
or SE) and if any FILTER_SPEC included in Filtss
matches more than one PSB, build and send a ResvErr
message specifying "Ambiguous filter spec" and
continue with the next flow descriptor in the Resv
message.
3. If the style is SE and if some FILTER_SPEC included in
Filtss matches no PSB, delete that FILTER_SPEC from
Filtss.
4. Add the PHOP from the PSB to Refresh_PHOP_list, if the
PHOP is not already on the list.
o Find or create a reservation state block (RSB) for
(SESSION, NHOP). If the style is distinct, Filtss is also
used in the selection. Call this the "active RSB".
o If the active RSB is new:
1. Set the session, NHOP, OI and style of the RSB from
the message.
2. Copy Filtss into the Filter_spec_list of the RSB.
3. Copy the FLOWSPEC and any SCOPE object from the
message into the RSB.
4. Set NeworMod flag on.
o If the active RSB is not new, check whether Filtss from the
message contains FILTER_SPECs that are not in the RSB; if
so, add the new FILTER_SPECs and turn on the NeworMod flag.
o Start or restart the cleanup timer on the active RSB, or,
in the case of SE style, on each FILTER_SPEC of the RSB
that also appears in Filtss.
o If the active RSB is not new, check whether STYLE, FLOWSPEC
or SCOPE objects have changed; if so, copy changed object
into RSB and turn on the NeworMod flag.
o If the message contained a RESV_CONFIRM object, copy it
into the RSB and turn on NeworMod flag.
o If the NeworMod flag is off, continue with the next flow
descriptor in the Resv message, if any.
o Otherwise (the NeworMod flag is on, i.e., the active RSB is
new or modified), execute the UPDATE TRAFFIC CONTROL event
sequence (below). If the result is to modify the traffic
control state, this sequence will turn on the
Resv_Refresh_Needed flag and make a RESV_EVENT upcall to
any local application.
If the UPDATE TRAFFIC CONTROL sequence fails with an error,
then delete a new RSB but restore the original reservation
in an old RSB.
o Continue with the next flow descriptor.
o When all flow descriptors have been processed, check the
Resv_Refresh_Needed flag. If it is now on, execute the
Resv REFRESH sequence (below) for each PHOP in
Refresh_PHOP_list.
o Drop the Resv message and return.
If processing a Resv message finds an error, a ResvErr message
is created containing flow descriptor and an ERRORS object. The
Error Node field of the ERRORS object is set to the IP address
of OI, and the message is sent unicast to NHOP.
ResvTear MESSAGE ARRIVES
Processing of a ResvTear message roughly parallels the
processing of the corresponding Resv message
A ResvTear message arrives with an IP destination address
matching outgoing interface OI. Flag Resv_Refresh_Needed is
initially off and Refresh_PHOP_list is empty.
o Determine the Outgoing Interface OI
The logical outgoing interface OI is taken from the LIH in
the NHOP object. (If the physical interface is not implied
by the LIH, it can be learned from the interface matching
the IP destination address).
o Process the flow descriptor list in the ResvTear message to
tear down local reservation state, as follows, depending
upon the style. The following uses a filter spec list
struct Filtss of type FILTER_SPEC* (defined earlier).
For FF style: execute the following steps independently for
each flow descriptor in the message, i.e., for each
(FLOWSPEC, Filtss) pair. Here the structure Filtss
consists of the FILTER_SPEC from the flow descriptor.
For SE style, execute the following steps once for
(FLOWSPEC, Filtss), with Filtss consisting of the list of
FILTER_SPEC objects from the flow descriptor.
For WF style, execute the following steps once for
(FLOWSPEC, Filtss), with Filtss an empty list.
1. Find an RSB matching (SESSION, NHOP). If the style is
distinct, Filtss is also used in the selection. Call
this the "active RSB". If no active RSB is found,
continue with next flow descriptor.
2. Check the style
If the active RSB has a style that is incompatible
with the style of the message, drop the ResvTear
message and return.
3. Delete from the active RSB each FILTER_SPEC that
matches a FILTER_SPEC in Filtss.
4. If all FILTER_SPECs have now been deleted from the
active RSB, delete the active RSB.
5. Execute the UPDATE TRAFFIC CONTROL event sequence
(below) to update the traffic control state to be
consistent with the reservation state. If the result
is to modify the traffic control state, the
Resv_Refresh_Needed flag will be turned on and a
RESV_EVENT upcall will be made to any local
application.
6. Continue with the next flow descriptor.
o All flow descriptors have been processed.
Build and send any ResvTear messages to be forwarded, in
the following manner.
1. Select each PSB that routes to the outgoing interface
OI, and, for distinct style, that has a
SENDER_TEMPLATE matching Filtss.
2. Select a flow descriptor (Qj,Fj) (where Fj may be a
list) in the ResvTear message whose FILTER_SPEC
matches the SENDER_TEMPLATE in the PSB. If not match
is found, return for next PSB.
- Search for an RSB (for any outgoing interface) to
which the PSB routes and whose Filter_spec_list
includes the SENDER_TEMPLATE from the PSB.
- If an RSB is found, add the PHOP of the PSB to
the Refresh_PHOP_list.
- Otherwise (no RSB is found), add the flow
descriptor (Qj,Fj) to the new ResvTear message
being built, in a manner appropriate to the
style.
- Continue with the next PSB.
3. If the next PSB is for a different PHOP or the last
PSB has been processed, forward any ResvTear message
that has been built.
o If any PSB's were found in the preceding step, and if the
Resv_Refresh_Needed flag is now on, execute the Resv
REFRESH sequence (below) for each PHOP in
Refresh_PHOP_list.
o Drop the ResvTear message and return.
ResvErr MESSAGE ARRIVES
A ResvErr message arrives through the (real) incoming interface
In_If.
o If there is no path state for SESSION, drop the ResvErr
message and return.
o If the Error Code = 01 (Admission Control failure), do
special processing as follows:
1. Find or create a Blockade State Block (BSB), in the
following style-dependent manner.
For WF (wildcard) style, there will be one BSB per
(session, PHOP) pair.
For FF style, there will be one BSB per (session,
filter_spec) pair. Note that an FF style ResvErr
message carries only one flow descriptor.
For SE style, there will be one BSB per (session,
filter_spec), for each filter_spec contained in the
filter spec list of the flow descriptor.
2. For each BSB in the preceding step, set (or replace)
its FLOWSPEC Qb with FLOWSPEC from the message, and
set (or reset) its timer Tb to Kb*R seconds [Section
3.4]. If the BSB is new, set its PHOP value, and set
its Sender_Template equal to the appropriate
filter_spec from the message.
3. Execute the Resv REFRESH event sequence (shown below)
for the previous hop PHOP, but only with the B_Merge
flag off. That is, if processing in the Resv REFRESH
sequence reaches the point of turning the B_Merge flag
on (because all matching reservations are blockaded),
do not turn it on but instead exit the REFRESH
sequence and return here.
o Execute the following for each RSB for this session whose
OI differs from In_If and whose Filter_spec_list has at
least one filter spec in common with the FILTER_SPEC* in
the ResvErr message. For WF style, empty FILTER_SPEC*
structures are assumed to match.
1. If Error_Code = 01 and the InPlace flag in the
ERROR_SPEC is 1 and one or more of the BSB's
found/created above has a Qb that is strictly greater
than Flowspec in the RSB, then continue with the next
matching RSB, if any.
2. If NHOP in the RSB is the local API, then:
- If the FLOWSPEC in the ResvErr message is
strictly greater than the RSB Flowspec, then turn
on the NotGuilty flag in the ERROR_SPEC.
- Deliver an error upcall to application:
Call: <Upcall_Proc>( session-id, RESV_ERROR,
Error_code, Error_value,
Node_Addr, Error_flags,
Flowspec, Filter_Spec_List
[ , Policy_data] )
and continue with the next RSB.
3. If the style has wildcard sender selection, use the
SCOPE object SC.In from the ResvErr message to
construct a SCOPE object SC.Out to be forwarded.
SC.Out should contain those sender addresses that
appeared in SC.In and that route to OI, as determined
by scanning the PSB's. If SC.Out is empty, continue
with the next RSB.
4. Create a new ResvErr message containing the error flow
descriptor and send to the NHOP address specified by
the RSB. Include SC.Out if the style has wildcard
sender selection.
5. Continue with the next RSB.
o Drop the ResvErr message and return.
Resv CONFIRM ARRIVES
o If the (unicast) IP address found in the RESV_CONFIRM
object in the ResvConf message matches an interface of the
node, a confirmation upcall is made to the matching
application:
Call: <Upcall_Proc>( session-id, RESV_CONFIRM,
Error_code, Error_value, Node_Addr,
LUB-Used, nlist, Flowspec,
Filter_Spec_List, NULL, NULL )
o Otherwise, forward the ResvConf message to the IP address
in its RESV_CONFIRM object.
o Drop the ResvConf message and return.
UPDATE TRAFFIC CONTROL
The sequence is invoked by many of the message arrival sequences
to set or adjust the local traffic control state in accordance
with the current reservation and path state. An implicit
parameter of this sequence is the `active' RSB.
If the result is to modify the traffic control state, this
sequence notifies any matching local applications with a
RESV_EVENT upcall. If the state change is such that it should
trigger immediate Resv refresh messages, it also turns on the
Resv_Refresh_Needed flag.
o Compute the traffic control parameters using the following
steps.
1. Initially the local flag Is_Biggest is off.
2. Consider the set of RSB's matching SESSION and OI from
the active RSB. If the style of the active RSB is
distinct, then the Filter_spec_list must also be
matched.
- Compute the effective kernel flowspec,
TC_Flowspec, as the LUB of the FLOWSPEC values in
these RSB's.
- Compute the effective traffic control filter spec
(list) TC_Filter_Spec* as the union of the
Filter_spec_lists from these RSB's.
- If the active RSB has a FLOWSPEC larger than all
the others, turn on the Is_Biggest flag.
3. Scan all RSB's matching session and Filtss, for all
OI. Set TC_B_Police_flag on if TC_Flowspec is smaller
than, or incomparable to, any FLOWSPEC in those RSB's.
4. Locate the set of PSBs (senders) whose
SENDER_TEMPLATEs match Filter_spec_list in the active
RSB and whose OutInterface_list includes OI.
5. Set TC_E_Police_flag on if any of these PSBs have
their E_Police flag on. Set TC_M_Police_flag on if it
is a shared style and there is more than one PSB in
the set.
6. Compute Path_Te as the sum of the SENDER_TSPEC objects
in this set of PSBs.
o Search for a TCSB matching SESSION and OI; for distinct
style (FF), it must also match Filter_spec_list.
If none is found, create a new TCSB.
o If TCSB is new:
1. Store TC_Flowspec, TC_Filter_Spec*, Path_Te, and the
police flags into TCSB.
2. Turn the Resv_Refresh_Needed flag on and make the
traffic control call:
TC_AddFlowspec( OI, TC_Flowspec,
Path_Te, police_flags)
-> Rhandle, Fwd_Flowspec
3. If this call fails, build and send a ResvErr message
specifying "Admission control failed" and with the
InPlace flag off. Delete the TCSB, delete any
RESV_CONFIRM object from the active RSB, and return.
4. Otherwise (call succeeds), record Rhandle and
Fwd_Flowspec in the TCSB. For each filter_spec F in
TC_Filter_Spec*, call:
TC_AddFilter( OI, Rhandle, Session, F)
-> Fhandle
and record the returned Fhandle in the TCSB.
o Otherwise, if TCSB is not new but no effective kernel
flowspec TC_Flowspec was computed earlier, then:
1. Turn on the Resv_Refresh_Needed flag.
2. Call traffic control to delete the reservation:
TC_DelFlowspec( OI, Rhandle )
3. Delete the TCSB and return.
o Otherwise, if TCSB is not new but the TC_Flowspec, Path_Te,
and/or police flags just computed differ from corresponding
values in the TCSB, then:
1. If the TC_Flowspec and/or Path_Te values differ, turn
the Resv_Refresh_Needed flag on.
2. Call traffic control to modify the reservation:
TC_ModFlowspec( OI, Rhandle, TC_Flowspec,
Path_Te, police_flags )
-> Fwd_Flowspec
3. If this call fails, build and send a ResvErr message
specifying "Admission control failed" and with the
InPlace bit on. Delete any RESV_CONFIRM object from
the active RSB and return.
4. Otherwise (the call succeeds), update the TCSB with
the new values and save Fwd_Flowspec in the TCSB.
o If the TCSB is not new but the TC_Filter_Spec* just
computed differs from the FILTER_SPEC* in the TCSB, then:
1. Make an appropriate set of TC_DelFilter and
TC_AddFilter calls to transform the Filter_spec_list
in the TCSB into the new TC_Filter_Spec*.
2. Turn on the Resv_Refresh_Needed flag.
o If the active RSB contains a RESV_CONFIRM object, then:
1. If the Is_Biggest flag is on, move the RESV_CONFIRM
object into the TCSB and turn on the
Resv_Refresh_Needed flag. (This will later cause the
Resv REFRESH sequence to be invoked, which will either
forward or return the RESV_CONFIRM object, deleting it
from the TCSB in either case).
2. Otherwise, create and send a ResvConf message to the
address in the RESV_CONFIRM object. Include the
RESV_CONFIRM object in the ResvConf message. The
ResvConf message should also include an ERROR_SPEC
object whose Error_Node parameter is IP address of OI
from the TCSB and that specifies "No Error".
o If the Resv_Refresh_Needed flag is on and the RSB is not
from the API, make a RESV_EVENT upcall to any matching
application:
Call: <Upcall_Proc>( session-id, RESV_EVENT,
style, Flowspec, Filter_spec_list
[ , POLICY_DATA] )
where Flowspec and Filter_spec_list come from the TCSB and
the style comes from the active RSB.
o Return to the event sequence that invoked this one.
Path REFRESH
This sequence sends a path refresh for a particular sender,
i.e., a PSB. This sequence may be entered by either the
expiration of a refresh timer or directly as the result of the
Path_Refresh_Needed flag being turned on during the processing
of a received Path message.
o Insert TIME_VALUES object into the Path message being
built. Compute the IP TTL for the Path message as one less
than the TTL value received in the message. However, if
the result is zero, return without sending the Path
message.
o Create a sender descriptor containing the SENDER_TEMPLATE,
SENDER_TSPEC, and POLICY_DATA objects, if present in the
PSB, and pack it into the Path message being built.
o Send a copy of the Path message to each interface OI in
OutInterface_list. Before sending each copy:
1. 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 Path message being built.
2. Pass the ADSPEC object and Non_RSVP flag present in
the PSB to the traffic control call TC_Advertise.
Insert the modified ADSPEC object that is returned
into the Path message being built.
3. Insert into its PHOP object the interface address and
the LIH for the interface.
Resv REFRESH
This sequence sends a reservation refresh towards a particular
previous hop with IP address PH. This sequence may be entered
by the expiration of a refresh timer, or invoked from the Path
MESSAGE ARRIVES, Resv MESSAGE ARRIVES, ResvTear MESSAGE ARRIVES,
or ResvErr MESSAGE ARRIVES sequence.
In general, this sequence considers each of the PSB's with PHOP
address PH. For a given PSB, it scans the TCSBs for matching
reservations and merges the styles, FLOWSPECs and
Filter_spec_list's appropriately. It then builds a Resv message
and sends it to PH. The details depend upon the attributes of
the style(s) included in the reservations.
Initially the Need_Scope flag is off and the new_SCOPE object is
empty.
o Create an output message containing INTEGRITY (if
configured), SESSION, RSVP_HOP, and TIME_VALUES objects.
o Determine the style for these reservations from the first
RSB for the session, and move the STYLE object into the
proto-message. (Note that the present set of styles are
never themselves merged; if future styles can be merged,
these rules will become more complex).
o If style is wildcard and if there are PSB's from more than
one PHOP and if the multicast routing protocol does not use
shared trees, set the Need_Scope flag on.
o Select each sender PSB whose PHOP has address PH. Set the
local flag B_Merge off and execute the following steps.
1. Select all TCSB's whose Filter_spec_list's match the
SENDER_TEMPLATE object in the PSB and whose OI appears
in the OutInterface_list of the PSB.
2. If the PSB is from the API, then:
- If TCSB contains a CONFIRM object, then create
and send a ResvConf message containing the object
and delete the CONFIRM object from the TCSB.
- Continue with next PSB.
3. If B_Merge flag is off then ignore a blockaded TCSB,
as follows.
- Select BSB's that match this TCSB. If a selected
BSB is expired, delete it. If any of the
unexpired BSB's has a Qb that is not strictly
larger than TC_Flowspec, then continue processing
with the next TCSB.
However, if steps 1 and 2 result in finding that all
TCSB's matching this PSB are blockaded, then:
- If this Resv REFRESH sequence was invoked from
Resv ERROR RECEIVED, then return to the latter.
- Otherwise, turn on the B_Merge flag and restart
at step 1, immediately above.
4. Merge the flowspecs from this set of TCSB's, as
follows:
- If B_Merge flag is off, compute the LUB over the
flowspec objects. From each TCSB, use the
Fwd_Flowspec object if present, else use the
normal Flowspec object.
While computing the LUB, check for a RESV_CONFIRM
object in each TCSB. If a RESV_CONFIRM object is
found:
- If the flowspec (Fwd_Flowspec or Flowspec)
in that TCSB is larger than all other (non-
blockaded) flowspecs being compared, then
save this RESV_CONFIRM object for forwarding
and delete from the TCSB.
- Otherwise (the corresponding flowspec is not
the largest), create and send a ResvConf
message to the address in the RESV_CONFIRM
object. Include the RESV_CONFIRM object in
the ResvConf message. The ResvConf message
should also include an ERROR_SPEC object
whose Error_Node parameter is IP address of
OI from the TCSB and specifying "No Error".
- Delete the RESV_CONFIRM object from the
TCSB.
- Otherwise (B_Merge flag is on), compute the GLB
over the Flowspec objects of this set of TCSB's.
While computing the GLB, delete any RESV_CONFIRM
object object in any of these TCSB's.
5. (All matching TCSB's have been processed). The next
step depends upon the style attributes.
Distinct reservation (FF) style
Use the Sender_Template as the merged
FILTER_SPEC. Pack the merged (FLOWSPEC,
FILTER_SPEC, F_POLICY_DATA) triplet into the
message as a flow descriptor.
Shared wildcard reservation (WF) style
There is no merged FILTER_SPEC. Merge (compute
the LUB of) the merged FLOWSPECS from the TCSB's,
across all PSB's for PH.
Shared distinct reservation (SE) style
Using the Sender_Template as the merged
FILTER_SPEC, form the union of the FILTER_SPECS
obtained from the TCSB's. Merge (compute the LUB
of) the merged FLOWSPECS from the TCSB's, across
all PSB's for PH.
6. If the Need_Scope flag is on and the sender specified
by the PSB is not the local API:
- Find each RSB that matches this PSB, i.e., whose
Filter_spec_list matches Sender_Template in the
PSB and whose OI is included in
OutInterface_list.
- If the RSB either has no SCOPE list or its SCOPE
list includes the sender IP address from the PSB,
insert the sender IP address into new_SCOPE.
o (All PSB's for PH have been processed). Finish the Resv
message.
1. If Need_Scope flag is on but new_SCOPE is empty, no
RESV message should be sent; return. Otherwise, if
Need_Scope is on, move new_SCOPE into the message.
2. If a shared reservation style is being built, move the
final merged FLOWSPEC object and filter spec list into
the message.
3. If a RESV_CONFIRM object was saved earlier, move it
into the new Resv message.
4. Set the RSVP_HOP object in the message to contain the
IncInterface address through which it will be sent and
the LIH from (one of) the PSB's.
o Send the message to the address PH.
ROUTE CHANGE NOTIFICATION
This sequence is triggered when routing sends a route change
notification to RSVP.
o Each PSB is located whose SESSION matches the destination
address and whose SENDER_TEMPLATE matches the source
address (for multicast).
1. If the OutInterface_list from the notification differs
from that in the PSB, execute the Path LOCAL REPAIR
sequence.
2. If the IncInterface from the notification differs from
that in the PSB, update the PSB.
Path LOCAL REPAIR
The sequence is entered to effect local repair after a route
change for a given PSB.
o Wait for a delay time of W seconds [Section 3.5].
o Execute the Path REFRESH event sequence (above) for the
PSB.
5. Acknowledgments
The design of RSVP is based upon research performed in 1992-1993 by a
collaboration including Lixia Zhang (Xerox PARC), Deborah Estrin
(USC/ISI), Scott Shenker (Xerox PARC), Sugih Jamin (USC/Xerox PARC),
and Daniel Zappala (USC). Sugih Jamin developed the first prototype
implementation of RSVP and successfully demonstrated it in May 1993.
Shai Herzog, and later Steve Berson, continued development of RSVP
prototypes.
Since 1993, many members of the Internet research community have
contributed to the design and development of RSVP; these include (in
alphabetical order) Steve Berson, Bob Braden, Lee Breslau, Dave
Clark, Deborah Estrin, Shai Herzog, Craig Partridge, Scott Shenker,
John Wroclawski, and Daniel Zappala. In addition, a number of host
and router vendors have made valuable contributions, particularly
Fred Baker (Cisco), Mark Baugher (Intel), Lou Berger (Fore Systems),
Don Hoffman (Sun), Steve Jakowski (NetManage), John Krawczyk (Bay
Networks), and Bill Nowicki (SGI). Ron Frederick, Bobby Minnear, Eve
Schooler, and Garrett Wollman did early interfacing of multicast
applications to RSVP. Steve Deering, Bill Fenner, and Ajit
Thyagarajan helped with the interface between RSVP and multicast
routing.
APPENDIX A. Object Definitions APPENDIX A. Object Definitions
C-Types are defined for the two Internet address families IPv4 and C-Types are defined for the two Internet address families IPv4 and IPv6.
IPv6. To accommodate other address families, additional C-Types To accommodate other address families, additional C-Types could easily
could easily be defined. These definitions are contained as an be defined. These definitions are contained as an Appendix, to ease
Appendix, to ease updating. updating.
All unused fields should be sent as zero and ignored on receipt. All unused fields should be sent as zero and ignored on receipt.
A.1 SESSION Class A.1 SESSION Class
SESSION Class = 1. SESSION Class = 1.
o IPv4/UDP SESSION object: Class = 1, C-Type = 1 o IPv4/UDP SESSION object: Class = 1, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 93, line 42 skipping to change at page 69, line 42
+ IPv6 DestAddress (16 bytes) + + IPv6 DestAddress (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort | | Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
DestAddress DestAddress
The IP unicast or multicast destination address of the The IP unicast or multicast destination address of the session.
session. This field must be non-zero. This field must be non-zero.
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
must be non-zero. 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
the effective "edge" of the network, to control traffic 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
messages it sends. The first node whose RSVP is capable it sends. The first node whose RSVP is capable of traffic
of traffic policing will do so (if appropriate to the policing will do so (if appropriate to the service) and
service) and turn the flag off. turn the flag off.
DstPort DstPort
The UDP/TCP destination port for the session. Zero may be The UDP/TCP destination port for the session. Zero may be used
used to indicate `none'. to indicate `none'.
Other SESSION C-Types could be defined in the future to Other SESSION C-Types could be defined in the future to support
support other demultiplexing conventions in the transport- other demultiplexing conventions in the transport-layer or
layer or application layer. application layer.
A.2 RSVP_HOP Class A.2 RSVP_HOP Class
RSVP_HOP class = 3. RSVP_HOP class = 3.
o IPv4 RSVP_HOP object: Class = 3, C-Type = 1 o IPv4 RSVP_HOP object: Class = 3, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 Next/Previous Hop Address | | IPv4 Next/Previous Hop Address |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 95, line 32 skipping to change at page 71, line 32
| | | |
+ IPv6 Next/Previous Hop Address + + IPv6 Next/Previous Hop Address +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Logical Interface Handle | | Logical Interface Handle |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
This object provides the IP address of the interface through which This object provides the IP address of the interface through which
the last RSVP-knowledgeable hop forwarded this message. The the last RSVP-knowledgeable hop forwarded this message. The Logical
Logical Interface Handle is a 32-bit number which may be used to Interface Handle is a 32-bit number which may be used to distinguish
distinguish logical outgoing interfaces as described in Section logical outgoing interfaces as described in Section 3.3; it should be
3.2; it should be identically zero if there is no logical identically zero if there is no logical interface handle.
interface handle.
A.3 INTEGRITY Class A.3 INTEGRITY Class
INTEGRITY class = 4. INTEGRITY class = 4.
See [Baker96]. See [Baker96].
A.4 TIME_VALUES Class A.4 TIME_VALUES Class
TIME_VALUES class = 5. TIME_VALUES class = 5.
o TIME_VALUES Object: Class = 5, C-Type = 1 o TIME_VALUES Object: Class = 5, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Refresh Period R | | Refresh Period R |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
Refresh Period Refresh Period
The refresh timeout period R used to generate this message; The refresh timeout period R used to generate this message; in
in milliseconds. milliseconds.
A.5 ERROR_SPEC Class A.5 ERROR_SPEC Class
ERROR_SPEC class = 6. ERROR_SPEC class = 6.
o IPv4 ERROR_SPEC object: Class = 6, C-Type = 1 o IPv4 ERROR_SPEC object: Class = 6, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 Error Node Address (4 bytes) | | IPv4 Error Node Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 97, line 40 skipping to change at page 73, 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
ResvErr message. If it on, this flag indicates that ResvErr message. If it on, this flag indicates that there
there was, and still is, a reservation in place at the was, and still is, a reservation in place at the failure
failure point. 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
ResvErr message, and it is only set in the interface to ResvErr message, and it is only set in the interface to the
the receiver application. If it on, this flag indicates receiver application. If it on, this flag indicates that
that the FLOWSPEC that failed was strictly greater than the FLOWSPEC that failed was strictly greater than the
the FLOWSPEC requested by this receiver. FLOWSPEC requested by this receiver.
Error Code Error Code
A one-octet error description. A one-octet error description.
Error Value Error Value
A two-octet field containing additional information about the A two-octet field containing additional information about the
error. Its contents depend upon the Error Type. error. Its contents depend upon the Error Type.
The values for Error Code and Error Value are defined in Appendix The values for Error Code and Error Value are defined in Appendix B.
B.
A.6 SCOPE Class A.6 SCOPE Class
SCOPE class = 7. SCOPE class = 7.
This object contains a list of IP addresses, used for routing This object contains a list of IP addresses, used for routing
messages with wildcard scope without loops. The addresses must be messages with wildcard scope without loops. The addresses must be
listed in ascending numerical order. listed in ascending numerical order.
o IPv4 SCOPE List object: Class = 7, C-Type = 1 o IPv4 SCOPE List object: Class = 7, C-Type = 1
skipping to change at page 100, line 20 skipping to change at page 76, line 21
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Flags | Option Vector | | Flags | Option Vector |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
Flags: 8 bits Flags: 8 bits
(None assigned yet) (None assigned yet)
Option Vector: 24 bits Option Vector: 24 bits
A set of bit fields giving values for the reservation A set of bit fields giving values for the reservation options.
options. If new options are added in the future, If new options are added in the future, corresponding fields in
corresponding fields in the option vector will be assigned the option vector will be assigned from the least-significant
from the least-significant end. If a node does not recognize end. If a node does not recognize a style ID, it may interpret
a style ID, it may interpret as much of the option vector as as much of the option vector as it can, ignoring new fields that
it can, ignoring new fields that may have been defined. may have been defined.
The option vector bits are assigned (from the left) as The option vector bits are assigned (from the left) as follows:
follows:
19 bits: Reserved 19 bits: Reserved
2 bits: Sharing control 2 bits: Sharing control
00b: Reserved 00b: Reserved
01b: Distinct reservations 01b: Distinct reservations
10b: Shared reservations 10b: Shared reservations
11b: Reserved 11b: Reserved
3 bits: Sender selection control 3 bits: Sender selection control
000b: Reserved 000b: Reserved
001b: Wildcard 001b: Wildcard
010b: Explicit 010b: Explicit
011b - 111b: Reserved
The low order bits of the option vector are determined by the 011b - 111b: Reserved
style, as follows: The low order bits of the option vector are determined by the style,
as follows:
WF 10001b WF 10001b
FF 01010b FF 01010b
SE 10010b SE 10010b
A.8 FLOWSPEC Class A.8 FLOWSPEC Class
FLOWSPEC class = 9. FLOWSPEC class = 9.
o Reserved (obsolete) flowspec object: Class = 9, C-Type = 1
o Inv-serv Flowspec object: Class = 9, C-Type = 2 o Inv-serv Flowspec object: Class = 9, C-Type = 2
The contents and encoding rules for this object are specified The contents and encoding rules for this object are specified in
in documents prepared by the int-serv working group. documents prepared by the int-serv working group [ISrsvp96].
A.9 FILTER_SPEC Class A.9 FILTER_SPEC Class
FILTER_SPEC class = 10. FILTER_SPEC class = 10.
o IPv4 FILTER_SPEC object: Class = 10, C-Type = 1 o IPv4 FILTER_SPEC object: Class = 10, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 SrcAddress (4 bytes) | | IPv4 SrcAddress (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 104, line 12 skipping to change at page 80, line 12
The IP source address for a sender host. Must be non-zero. The IP source address for a sender host. Must be non-zero.
SrcPort SrcPort
The UDP/TCP source port for a sender, or zero to indicate The UDP/TCP source port for a sender, or zero to indicate
`none'. `none'.
Flow Label Flow Label
A 24-bit Flow Label, defined in IPv6. This value may be used A 24-bit Flow Label, defined in IPv6. This value may be used by
by the packet classifier to efficiently identify the packets the packet classifier to efficiently identify the packets
belonging to a particular (sender->destination) data flow. belonging to a particular (sender->destination) data flow.
A.10 SENDER_TEMPLATE Class A.10 SENDER_TEMPLATE Class
SENDER_TEMPLATE class = 11. SENDER_TEMPLATE class = 11.
o IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 1 o IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 1
Definition same as IPv4/UDP FILTER_SPEC object. Definition same as IPv4/UDP FILTER_SPEC object.
o IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 2 o IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 2
Definition same as IPv6/UDP FILTER_SPEC object. Definition same as IPv6/UDP FILTER_SPEC object.
o IPv6 Flow-label SENDER_TEMPLATE object: Class = 11, C-Type = o IPv6 Flow-label SENDER_TEMPLATE object: Class = 11, C-Type = 3
3
A.11 SENDER_TSPEC Class A.11 SENDER_TSPEC Class
SENDER_TSPEC class = 12. SENDER_TSPEC class = 12.
o Intserv SENDER_TSPEC object: Class = 12, C-Type = 2 o Intserv SENDER_TSPEC object: Class = 12, C-Type = 2
The contents and encoding rules for this object are specified The contents and encoding rules for this object are specified in
in documents prepared by the int-serv working group. documents prepared by the int-serv working group.
A.12 ADSPEC Class A.12 ADSPEC Class
ADSPEC class = 13. ADSPEC class = 13.
o Intserv ADSPEC object: Class = 13, C-Type = 2 o Intserv ADSPEC object: Class = 13, C-Type = 2
The contents and format for this object are specified in The contents and format for this object are specified in
documents prepared by the int-serv working group. documents prepared by the int-serv working group.
skipping to change at page 108, line 7 skipping to change at page 84, line 7
+ + + +
| | | |
+ IPv6 Receiver Address (16 bytes) + + IPv6 Receiver Address (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
APPENDIX B. Error Codes and Values APPENDIX B. Error Codes and Values
The following Error Codes may appear in ERROR_SPEC objects and be The following Error Codes may appear in ERROR_SPEC objects and be passed
passed to end systems. Except where noted, these Error Codes may to end systems. Except where noted, these Error Codes may appear only
appear only in ResvErr messages. 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 This code is reserved for use in the ERROR_SPEC object of a
ResvConf 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.
skipping to change at page 108, line 35 skipping to change at page 84, line 35
where the bits are: where the bits are:
ss = 00: Low order 12 bits contain a globally-defined sub-code ss = 00: Low order 12 bits contain a globally-defined sub-code
(values listed below). (values listed below).
ss = 10: Low order 12 bits contain a organization-specific sub- ss = 10: Low order 12 bits contain a organization-specific sub-
code. RSVP is not expected to be able to interpret this code. RSVP is not expected to be able to interpret this
except as a numeric value. except as a numeric value.
ss = 11: Low order 12 bits contain a service-specific sub-code. ss = 11: Low order 12 bits contain a service-specific sub-code.
RSVP is not expected to be able to interpret this except as RSVP is not expected to be able to interpret this except as a
a numeric value. numeric value.
Since the traffic control mechanism might substitute a Since the traffic control mechanism might substitute a
different service, this encoding may include some different service, this encoding may include some
representation of the service in use. representation of the service in use.
u = 0: RSVP rejects the message without updating local u = 0: RSVP rejects the message without updating local state.
state.
u = 1: RSVP may use message to update local state and forward u = 1: RSVP may use message to update local state and forward the
the message. This means that the message is informational. message. This means that the message is informational.
r: Reserved bit, should be zero. r: Reserved bit, should be zero.
cccc cccc cccc: 12 bit code. cccc cccc cccc: 12 bit code.
The following globally-defined sub-codes may appear in the low- The following globally-defined sub-codes may appear in the low-
order 12 bits when ssur = 0000: order 12 bits when ssur = 0000:
- Sub-code = 1: Delay bound cannot be met - Sub-code = 1: Delay bound cannot be met
- Sub-code = 2: Requested bandwidth unavailable - Sub-code = 2: Requested bandwidth unavailable
- Sub-code = 3: MTU in flowspec larger than interface MTU. - Sub-code = 3: MTU in flowspec larger than interface MTU.
o Error Code = 02: Policy Control failure o Error Code = 02: Policy Control failure
Reservation or path message has been rejected for administrative Reservation or path message has been rejected for administrative
reasons, for example, required credentials not submitted, reasons, for example, required credentials not submitted,
insufficient quota or balance, or administrative preemption. insufficient quota or balance, or administrative preemption. This
This Error Code may appear in a PathErr or ResvErr message. Error Code may appear in a PathErr or ResvErr message.
Contents of the Error Value field are to be determined in the Contents of the Error Value field are to be determined in the
future. future.
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
the sender matching some flow descriptor contained in the Resv sender matching some flow descriptor contained in the Resv message.
message. Resv message cannot be forwarded. 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
reservation state. The Error Value field contains the low-order state. The Error Value field contains the low-order 16 bits of the
16 bits of the Option Vector of the existing style with which Option Vector of the existing style with which the conflict
the conflict occurred. This Resv message cannot be forwarded. occurred. This Resv message cannot be forwarded.
o Error Code = 06: Unknown reservation style o Error Code = 06: Unknown reservation style
Reservation style is unknown. This Resv message cannot be Reservation style is unknown. This Resv message cannot be
forwarded. forwarded.
o Error Code = 07: Conflicting dest port o Error Code = 07: Conflicting dest 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
may appear in a PathErr or ResvErr message. appear in a PathErr or ResvErr message.
o Error Code = 08: Ambiguous path o Error Code = 08: Ambiguous path
Sender port appears both zero and non-zero in same session in a Sender port appears both zero and non-zero in same session in a
Path message. This Error Code may appear only in a PathErr Path message. This Error Code may appear only in a PathErr
message. message.
o Error Code = 09: Ambiguous Filter Spec o Error Code = 09: Ambiguous Filter Spec
Message contains a filter spec that matches more than one Message contains a filter spec that matches more than one sender,
sender, but an explicit style that requires an exact match. but an explicit style that requires an exact match.
o Error Code = 10, 11: (reserved) o Error Code = 10, 11: (reserved)
o Error Code = 12: Service preempted o Error Code = 12: Service preempted
The service request defined by the STYLE object and the flow The service request defined by the STYLE object and the flow
descriptor has been administratively preempted. descriptor has been administratively preempted.
For this Error Code, the 16 bits of the Error Value field are: For this Error Code, the 16 bits of the Error Value field are:
ssur cccc cccc cccc ssur cccc cccc cccc
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.
01. The globally-defined sub-codes that may appear in the low- The globally-defined sub-codes that may appear in the low-order 12
order 12 bits when ssur = 0000 are to be defined in the future. bits when ssur = 0000 are to be defined in the 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)
Type) of unknown object. This error should be sent only if RSVP of unknown object. This error should be sent only if RSVP is going
is going to reject the message, as determined by the high-order to reject the message, as determined by the high-order bits of the
bits of the Class-Num. This Error Code may appear in a PathErr Class-Num. This Error Code may appear in a PathErr or ResvErr
or ResvErr message. message.
o Error Code = 14: Unknown object C-Type o Error Code = 14: Unknown object C-Type
Error Value contains 16-bit value composed of (Class-Num, C- Error Value contains 16-bit value composed of (Class-Num, C-Type)
Type) of object. of object.
o Error Code = 15-19: (reserved) o Error Code = 15-19: (reserved)
o Error Code = 20: Reserved for API o Error Code = 20: Reserved for API
Error Value field contains an API error code, for an API error Error Value field contains an API error code, for an API error that
that was detected asynchronously and must be reported via an 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
skipping to change at page 111, line 29 skipping to change at page 87, line 28
The following globally-defined sub-codes may appear in the low The following globally-defined sub-codes may appear in the low
order 12 bits (cccc cccc cccc) when ss = 00: order 12 bits (cccc cccc cccc) when ss = 00:
- Sub-code = 01: Service conflict - Sub-code = 01: Service conflict
Trying to merge two incompatible service requests. Trying to merge two incompatible service requests.
- Sub-code = 02: Service unsupported - Sub-code = 02: Service unsupported
Traffic control can provide neither the requested service Traffic control can provide neither the requested service nor
nor an acceptable replacement. an acceptable replacement.
- Sub-code = 03: Bad Flowspec value - Sub-code = 03: Bad Flowspec value
Mal-formed or unreasonable request. Malformed or unreasonable request.
- Sub-code = 04: Bad Tspec value - Sub-code = 04: Bad Tspec value
Malformed or unreasonable request. Malformed or unreasonable request.
o Error Code = 22: Traffic Control System error o Error Code = 22: Traffic Control System error
A system error was detected and reported by the traffic control A system error was detected and reported by the traffic control
modules. The Error Value will contain a system-specific value modules. The Error Value will contain a system-specific value
giving more information about the error. RSVP is not expected giving more information about the error. RSVP is not expected to
to be able to interpret this value. be able to interpret this value.
o Error Code = 23: RSVP System error o Error Code = 23: RSVP System error
The Error Value field will provide implementation-dependent The Error Value field will provide implementation-dependent
information on the error. RSVP is not expected to be able to information on the error. RSVP is not expected to be able to
interpret this value. interpret this value.
In general, every RSVP message is rebuilt at each hop, and the node In general, every RSVP message is rebuilt at each hop, and the node that
that creates an RSVP message is responsible for its correct creates an RSVP message is responsible for its correct construction.
construction. Similarly, each node is required to verify the correct Similarly, each node is required to verify the correct construction of
construction of each RSVP message it receives. Should a programming each RSVP message it receives. Should a programming error allow an RSVP
error allow an RSVP to create a malformed message, the error is not to create a malformed message, the error is not generally reported to
generally reported to end systems in an ERROR_SPEC object; instead, end systems in an ERROR_SPEC object; instead, the error is simply logged
the error is simply logged locally, and perhaps reported through locally, and perhaps reported through network management mechanisms.
network management mechanisms.
The only message formatting errors that are reported to end systems The only message formatting errors that are reported to end systems are
are those that may reflect version mismatches, and which the end those that may reflect version mismatches, and which the end system
system might be able to circumvent, e.g., by falling back to a might be able to circumvent, e.g., by falling back to a previous CType
previous CType for an object; see code 13 and 14 above. for an object; see code 13 and 14 above.
The choice of message formatting errors that an RSVP may detect and The choice of message formatting errors that an RSVP may detect and log
log locally is implementation-specific, but it will typically include locally is implementation-specific, but it will typically include the
the following: following:
o Wrong-length message: RSVP Length field does not match message o Wrong-length message: RSVP Length field does not match message
length. length.
o Unknown or unsupported RSVP version. o Unknown or unsupported RSVP version.
o Bad RSVP checksum o Bad RSVP checksum
o INTEGRITY failure o INTEGRITY failure
o Illegal RSVP message Type o Illegal RSVP message Type
o Illegal object length: not a multiple of 4, or less than 4. o Illegal object length: not a multiple of 4, or less than 4.
o Next hop/Previous hop address in HOP object is illegal. o Next hop/Previous hop address in HOP object is illegal.
o Conflicting source port: Source port is non-zero in a filter o Conflicting source port: Source port is non-zero in a filter spec
spec or sender template for a session with destination port or sender template for a session with destination port zero.
zero.
o Required object class (specify) missing o Required object class (specify) missing
o Illegal object class (specify) in this message type. o Illegal object class (specify) in this message type.
o Violation of required object order o Violation of required object order
o Flow descriptor count wrong for style o Flow descriptor count wrong for style
o Logical Interface Handle invalid o Logical Interface Handle invalid
skipping to change at page 113, line 4 skipping to change at page 88, line 49
o Required object class (specify) missing o Required object class (specify) missing
o Illegal object class (specify) in this message type. o Illegal object class (specify) in this message type.
o Violation of required object order o Violation of required object order
o Flow descriptor count wrong for style o Flow descriptor count wrong for style
o Logical Interface Handle invalid o Logical Interface Handle invalid
o Unknown object Class-Num. o Unknown object Class-Num.
o Destination address of ResvConf message does not match Receiver o Destination address of ResvConf message does not match Receiver
Address in the RESV_CONFIRM object it contains. Address in the RESV_CONFIRM object it contains.
APPENDIX C. UDP Encapsulation APPENDIX C. UDP Encapsulation
An RSVP implementation will generally require the ability to perform An RSVP implementation will generally require the ability to perform
"raw" network I/O, i.e., to send and receive IP datagrams using "raw" network I/O, i.e., to send and receive IP datagrams using protocol
protocol 46. However, some important classes of host systems may not 46. However, some important classes of host systems may not support raw
support raw network I/O. To use RSVP, such hosts must encapsulate network I/O. To use RSVP, such hosts must encapsulate RSVP messages in
RSVP messages in UDP. UDP.
The basic UDP encapsulation scheme makes two assumptions: The basic UDP encapsulation scheme makes two assumptions:
1. All hosts are capable of sending and receiving multicast packets 1. All hosts are capable of sending and receiving multicast packets if
if multicast destinations are to be supported. multicast destinations are to be supported.
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, ResvErr, ResvTear, and PathErr messages are sent to unicast Resv, ResvErr, ResvTear, and PathErr messages are sent to unicast
addresses learned from the path or reservation state in the node. If addresses learned from the path or reservation state in the node. If
the node keeps track of which previous hops and which interfaces need the node keeps track of which previous hops and which interfaces need
UDP 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 PathTear messages are when necessary. On the other hand, Path and PathTear messages are sent
send to the destination address for the session, which may be unicast to the destination address for the session, which may be unicast or
or multicast. 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 PathTear messages, for unicast DestAddress encapsulation of Path and PathTear messages, for unicast DestAddress and
and multicast DestAddress, respectively. Under the `Send' column, multicast DestAddress, respectively. The other message types, which are
the notation is `mode(destaddr, destport)'; destport is omitted for sent unicast, should follow the unicast rules in Figure 13. Under the
raw packets. The `Receive' column shows the group that is joined `RSVP Send' columns in these figures, the notation is `mode(destaddr,
and, where relevant, the UDP Listen port. destport)'; destport is omitted for raw packets. The `Receive' columns
show the group that is joined 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
sent by Hu and the other to be sent by Hr and R, to avoid double by Hu and the other to be sent by Hr and R, to avoid double processing
processing by the recipient. In practice, these two flavors are by the recipient. In practice, these two flavors are distinguished by
distinguished by differing UDP port numbers Pu and Pu'. 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.14, i.e., a o G* is a well-known group address of the form 224.0.0.14, i.e., a
group that is limited to the local connected network. group that is limited to the local connected network.
o Pu and Pu' are two well-known UDP ports for UDP encapsulation of o Pu and Pu' are two well-known UDP ports for UDP encapsulation of
RSVP, with values 1698 and 1699. RSVP, with values 1698 and 1699.
o Ra is the IP address of the router interface `a'. o Ra is the IP address of the router interface `a'.
o 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.
The following notes apply to these figures:
[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
router. Ra is presumably known to the host.
[Note 2] Here D is the address of the local interface through which
the message arrived.
[Note 3] This assumes that the application has joined the group D.
UNICAST DESTINATION D: UNICAST DESTINATION D:
RSVP RSVP RSVP RSVP
Node Send Receive Node Send Receive
___ _____________ _______________ ___ _____________ _______________
Hu UDP(D/Ra,Pu) UDP(D,Pu) Hu UDP(D/Ra,Pu) UDP(D,Pu)
[Note 1] and UDP(D,Pu') [Note 1] and UDP(D,Pu')
[Note 2] [Note 2]
Hr Raw(D)[RA] Raw() Hr Raw(D)[RA] Raw()
skipping to change at page 116, line 24 skipping to change at page 92, line 25
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 Encapsulation Rules for Multicast Path Messages Figure 14: UDP Encapsulation Rules for Multicast Path Messages
[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
router. Ra is presumably known to the host.
[Note 2] Here D is the address of the local interface through which
the message arrived.
[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*
G* (multicast D) or to the address of interface X (unicast D). There (multicast D) or to the address of interface X (unicast D). There is
is one failure mode for this scheme: if no host on the connected one failure mode for this scheme: if no host on the connected network
network acts as an RSVP sender, there will be no Path messages to acts as an RSVP sender, there will be no Path messages to trigger UDP
trigger UDP encapsulation. In this (unlikely) case, it will be encapsulation. In this (unlikely) case, it will be necessary to
necessary to explicitly configure UDP encapsulation on the local explicitly configure UDP encapsulation on the local network interface of
network interface of the router. 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
available to the application on most systems. The RSVP daemon that to the application on most systems. The RSVP process that receives a
receives a UDP-encapsulated Path or PathTear message should therefore UDP-encapsulated Path or PathTear message should therefore use the
use the Send_TTL field of the RSVP common header as the effective Send_TTL field of the RSVP common header as the effective receive TTL.
receive TTL. This may be overridden by manual configuration. 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
with TTL=Ta 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, R and the Path message will not reach R. If Ta is too large, R and
succeeding routers may forward the UDP packet until its hop succeeding routers may forward the UDP packet until its hop count
count expires. This will turn on UDP encapsulation between expires. This will turn on UDP encapsulation between routers
routers within the Internet, perhaps causing bogus UDP traffic. within the Internet, perhaps causing bogus UDP traffic. The host
The host Hu must be explicitly configured with Ra and Ta. Hu must be explicitly 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
as an "RSVP relay host". A relay host would listen on (G*,Pu) an "RSVP relay host". A relay host would listen on (G*,Pu) and
and forward any Path messages directly to R, although it would forward any Path messages directly to R, although it would not be
not be in the data path. The relay host would have to be in the data path. The relay host would have to be configured with
configured with Ra and Ta. Ra and Ta.
APPENDIX D. Glossary
o Admission control
A traffic control function that decides whether the packet
scheduler in the node can supply the requested QoS while continuing
to provide the QoS requested by previously-admitted requests. See
also "policy control" and "traffic control".
o Adspec
An Adspec is a data element (object) in a Path message that carries
a package of OPWA advertising information. See "OPWA".
o Auto-refresh loop
An auto-refresh loop is an error condition that occurs when a
topological loop of routers continues to refresh existing
reservation state even though all receivers have stopped requesting
these reservations. See section 3.4 for more information.
o Blockade state
Blockade state helps to solve a "killer reservation" problem. See
sections 2.5 and 3.5, and "killer reservation".
o Branch policing
Traffic policing at a multicast branching point on an outgoing
interface that has "less" resources reserved than another outgoing
interface for the same flow. See "traffic policing".
o C-Type
The class type of an object; unique within class-name. See
"class-name".
o Class-name
The class of an object. See "object".
o DestAddress
The IP destination address; part of session identification. See
"session".
o Distinct style
A (reservation) style attribute; separate resources are reserved
for each different sender. See also "shared style".
o Downstream
Towards the data receiver(s).
o DstPort
The IP (generalized) destination port used as part of a session.
See "generalized destination port".
o Entry policing
Traffic policing done at the first RSVP- (and policing-) capable
router on a data path.
o ERROR_SPEC
Object that carries the error report in a PathErr or ResvErr
message.
o Explicit sender selection
A (reservation) style attribute; all reserved senders are to be
listed explicitly in the reservation message. See also "wildcard
sender selection".
o FF style
Fixed Filter reservation style, which has explicit sender selection
and distinct attributes.
o FilterSpec
Together with the session information, defines the set of data
packets to receive the QoS specified in a flowspec. The filterspec
is used to set parameters in the packet classifier function. A
filterspec may be carried in a FILTER_SPEC or SENDER_TEMPLATE
object.
o Flow descriptor
The combination of a flowspec and a filterspec.
o Flowspec
Defines the QoS to be provided for a flow. The flowspec is used to
set parameters in the packet scheduling function to provide the
requested quality of service. A flowspec is carried in a FLOWSPEC
object. The flowspec format is opaque to RSVP, and is defined by
the Integrated Services Working Group.
o Generalized destination port
The component of a session definition that provides further
transport or application protocol layer demultiplexing beyond
DestAddress. See "session".
o Generalized source port
The component of a filter spec that provides further transport or
application protocol layer demultiplexing beyond the sender
address.
o GLB
Greatest Lower Bound
o Incoming interface
The interface on which data packets are expected to arrive, and on
which Resv messages are sent.
o INTEGRITY
Object of an RSVP control message that contains cryptographic data
to authenticate the originating node and to verify the contents of
an RSVP message.
o Killer reservation problem
The killer reservation problem describes a case where a receiver
attempting and failing to make a large QoS reservation prevents
smaller QoS reservations from being established. See Sections 2.5
and 3.5 for more information.
o LIH
The LIH (Logical Interface Handle) is used to help deal with non-
RSVP clouds. See Section 2.8 for more information.
o Local repair
Allows RSVP to rapidly adapt its reservations to changes in
routing. See Section 3.6 for more information.
o LPM
Local Policy Module. the function that exerts policy control.
o LUB
Least Upper Bound.
o Merge policing
Traffic policing that takes place at data merge point of a shared
reservation.
o Merging
The process of taking the maximum (or more generally the least
upper bound) of the reservations arriving on outgoing interfaces,
and forwarding this maximum on the incoming interface. See Section
2.2 for more information.
o MTU
Maximum Transmission Unit.
o Next hop
The next router in the direction of traffic flow.
o NHOP
An object that carries the Next Hop information in RSVP control
messages.
o Node
A router or host system.
o Non-RSVP clouds
Groups of hosts and routers that do not run RSVP. Dealing with
nodes that do not support RSVP is important for backwards
compatibility. See section 2.8.
o Object
An element of an RSVP control message; a type, length, value
triplet.
o OPWA
Abbreviation for "One Pass With Advertising". Describes a
reservation setup model in which (Path) messages sent downstream
gather information that the receiver(s) can use to predict the
end-to-end service. The information that is gathered is called an
advertisement. See also "Adspec".
o Outgoing interface
Interface through which data packets and Path messages are
forwarded.
o Packet classifier
Traffic control function in the primary data packet forwarding path
that selects a service class for each packet, in accordance with
the reservation state set up by RSVP. The packet classifier may be
combined with the routing function. See also "traffic control".
o Packet scheduler
Traffic control function in the primary data packet forwarding path
that implements QoS for each flow, using one of the service models
defined by the Integrated Services Working Group. See also "
traffic control".
o Path state
Information kept in routers and hosts about all RSVP senders.
o PathErr
Path Error RSVP control message.
o PathTear
Path Teardown RSVP control message.
o PHOP
An object that carries the Previous Hop information in RSVP control
messages.
o Police
See traffic policing.
o Policy control
A function that determines whether a new request for quality of
service has administrative permission to make the requested
reservation. Policy control may also perform accounting (usage
feedback) for a reservation.
o Policy data
Data carried in a Path or Resv message and used as input to policy
control to determine authorization and/or usage feedback for the
given flow.
o Previous hop
The previous router in the direction of traffic flow. Resv
messages flow towards previous hops.
o ProtocolId
The component of session identification that specifies the IP
protocol number used by the data stream.
o QoS
Quality of Service.
o Reservation state
Information kept in RSVP-capable nodes about successful RSVP
reservation requests.
o Reservation style
Describes a set of attributes for a reservation, including the
sharing attributes and sender selection attributes. See Section
1.3 for details.
o Resv message
Reservation request RSVP control message.
o ResvConf
Reservation Confirmation RSVP control message, confirms successful
installation of a reservation at some upstream node.
o ResvErr
Reservation Error control message, indicates that a reservation
request has failed or an active reservation has been preempted.
o ResvTear
Reservation Teardown RSVP control message, deletes reservation
state.
o Rspec
The component of a flowspec that defines a desired QoS. The Rspec
format is opaque to RSVP, and is defined by the Integrated Services
Working Group of the IETF.
o RSVP_HOP
Object of an RSVP control message that carries the PHOP or NHOP
address of the source of the message.
o Scope
The set of sender hosts to which a given reservation request is to
be propagated.
o SE style
Shared Explicit reservation style, which has explicit sender
selection and shared attributes.
o Semantic fragmentation
A method of fragmenting a large RSVP message using information
about the structure and contents of the message, so that each
fragment is a logically complete RSVP message.
o Sender template
Parameter in a Path message that defines a sender; carried in a
SENDER_TEMPLATE object. It has the form of a filter spec that can
be used to select this sender's packets from other packets in the
same session on the same link.
o Sender Tspec
Parameter in a Path message, a Tspec that characterizes the traffic
parameters for the data flow from the corresponding sender. It is
carried in a SENDER_TSPEC object.
o Session
An RSVP session defines one simplex unicast or multicast data flow
for which reservations are required. A session is identified by
the destination address, transport-layer protocol, and an optional
(generalized) destination port.
o Shared style
A (reservation) style attribute: all reserved senders share the
same reserved resources. See also "distinct style".
o Soft state
Control state in hosts and routers that will expire if not
refreshed within a specified amount of time.
o STYLE
Object of an RSVP message that specifies the desired reservation
style.
o Style
See "reservation style"
o TIME_VALUES
Object in an RSVP control message that specifies the time period
timer used for refreshing the state in this message.
o Traffic control
The entire set of machinery in the node that supplies requested QoS
to data streams. Traffic control includes packet classifier,
packet scheduler, and admission control functions.
o Traffic policing
The function, performed by traffic control, of forcing a given data
flow into compliance with the traffic parameters implied by the
reservation. It may involve dropping non-compliant packets or
sending them with lower priority, for example.
o TSpec
A traffic parameter set that describes a flow. The format of a
Tspec is opaque to RSVP and is defined by the Integrated Service
Working Group.
o UDP encapsulation
A way for hosts that cannot use raw sockets to participate in RSVP
by encapsulating the RSVP protocol (raw) packets in ordinary UDP
packets. See Section APPENDIX C for more information.
o Upstream
Towards the traffic source. RSVP Resv messages flow upstream.
o WF style
Wildcard Filter reservation style, which has wildcard sender
selection and shared attributes.
o Wildcard sender selection
A (reservation) style attribute: traffic from any sender to a
specific session receives the same QoS. See also "explicit sender
selection".
References References
[Baker96] Baker, F., "RSVP Cryptographic Authentication", Work in [Baker96] Baker, F., "RSVP Cryptographic Authentication", Work in
Progress, February 1996. Progress, February 1996.
[ISInt93] Braden, R., Clark, D., and S. Shenker, "Integrated Services [ISInt93] Braden, R., Clark, D., and S. Shenker, "Integrated Services
in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and
PARC, June 1994. PARC, June 1994.
[FJ94] Floyd, S. and V. Jacobson, "Synchronization of Periodic Routing [FJ94] Floyd, S. and V. Jacobson, "Synchronization of Periodic Routing
Messages", IEEE/ACM Transactions on Networking, Vol. 2, No. 2, Messages", IEEE/ACM Transactions on Networking, Vol. 2, No. 2,
April, 1994. April, 1994.
[IPSEC96] Berger, L., O'Malley, T., and R. Atkinson, "RSVP Extensions [IPSEC96] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC IPv4
for IPSEC IPv4 Data Flows", Internet Draft, <draft-ietf-rsvp-ext- Data Flows", Internet Draft, <draft-ietf-rsvp-ext-04.txt>,
04.txt>, Integrated Services Working Group, June 1996. Integrated Services Working Group, June 1996.
[Katz95] Katz, D., "IP Router Alert Option", Work in Progress, November [Katz95] Katz, D., "IP Router Alert Option", Work in Progress, November
1995. 1995.
[ISdata96] Wroclawski, J., "Data Element Naming and Encoding for [ISdata96] Wroclawski, J., "Data Element Naming and Encoding for
Integrated Services Messages", <draft-ietf-intserv-data-encoding- Integrated Services Messages", <draft-ietf-intserv-data-encoding-
02.txt>, Integrated Services Working Group, July 1996. 02.txt>, Integrated Services Working Group, July 1996.
[ISrsvp] Wroclawski, J., "The Use of RSVP with Integrated Services", [ISrsvp96] Wroclawski, J., "The Use of RSVP with Integrated Services",
<draft-ietf-intserv-rsvp-use.00.txt>, Integrated Services Working <draft-ietf-intserv-rsvp-use.00.txt>, Integrated Services Working
Group, July 1996. Group, July 1996.
[ISTempl96] Shenker, S. and J. Wroclawski, "Network Element QoS Control [ISTempl96] Shenker, S. and J. Wroclawski, "Network Element QoS Control
Service Specification Template", <draft-ietf-intserv-serv-template- Service Specification Template", <draft-ietf-intserv-serv-template-
03.txt>, Integrated Services Working Group, July 1996. 03.txt>, Integrated Services Working Group, July 1996.
[OPWA95] Shenker, S. and L. Breslau, "Two Issues in Reservation [OPWA95] Shenker, S. and L. Breslau, "Two Issues in Reservation
Establishment", Proc. ACM SIGCOMM '95, Cambridge, MA, August 1995. Establishment", Proc. ACM SIGCOMM '95, Cambridge, MA, August 1995.
[RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. [RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D.
Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network, Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network,
September 1993. September 1993.
Security Considerations Security Considerations
See Section 2.8. See Section 2.7.
Authors' Addresses Authors' Addresses
Bob Braden Bob Braden
USC Information Sciences Institute USC Information Sciences Institute
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292 Marina del Rey, CA 90292
Phone: (310) 822-1511 Phone: (310) 822-1511
EMail: Braden@ISI.EDU EMail: Braden@ISI.EDU
 End of changes. 

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