RFC 2205
Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
Pages: 112
Proposed Standard
→ Errata
Updated by: 2750 3936 4495 5946 6437 6780
Proposed Standard
→ Errata
Updated by: 2750 3936 4495 5946 6437 6780
Part 3 of 4 – Pages 47 to 76
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 Ports" 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 "Bad
Src Ports" 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 a
"Conflicting Sender Port" error.
Note that RSVP has no "wildcard" ports, i.e., a zero port cannot
match a non-zero port.
3.3 Sending RSVP Messages
RSVP messages are sent hop-by-hop between RSVP-capable routers as
"raw" IP datagrams with protocol number 46. Raw IP datagrams are
also intended to be used between an end system and the first/last
hop router, although it is also possible to encapsulate RSVP
messages as UDP datagrams for end-system communication, as
described in Appendix C. UDP encapsulation is needed for systems
that cannot do raw network I/O.
Path, PathTear, and ResvConf messages must be sent with the Router
Alert IP option [RFC 2113] in their IP headers. This option may
be used in the fast forwarding path of a high-speed router to
detect datagrams that require special processing.
Upon the arrival of an RSVP message M that changes the state, a
node must forward the state modification immediately. However,
this must not trigger sending a message out the interface through
which M arrived (which could happen if the implementation simply
triggered an immediate refresh of all state for the session).
This rule is necessary to prevent packet storms on broadcast LANs.
In this version of the spec, each RSVP message must occupy exactly
one IP datagram. If it exceeds the MTU, such a datagram will be
fragmented by IP and reassembled at the recipient node. This has
several consequences:
o A single RSVP message may not exceed the maximum IP datagram
size, approximately 64K bytes.
o A congested non-RSVP cloud could lose individual message
fragments, and any lost fragment will lose the entire
message.
Future versions of the protocol will provide solutions for these
problems if they prove burdensome. The most likely direction will
be to perform "semantic fragmentation", i.e., break the path or
reservation state being transmitted into multiple self-contained
messages, each of an acceptable size.
RSVP uses its periodic refresh mechanisms to recover from
occasional packet losses. Under network overload, however,
substantial losses of RSVP messages could cause a failure of
resource reservations. To control the queuing delay and dropping
of RSVP packets, routers should be configured to offer them a
preferred class of service. If RSVP packets experience noticeable
losses when crossing a congested non-RSVP cloud, a larger value
can be used for the timeout factor K (see section 3.7).
Some multicast routing protocols provide for "multicast tunnels",
which do IP encapsulation of multicast packets for transmission
through routers that do not have multicast capability. A
multicast tunnel looks like a logical outgoing interface that is
mapped into some physical interface. A multicast routing protocol
that supports tunnels will describe a route using a list of
logical rather than physical interfaces. RSVP can operate across
such multicast tunnels in the following manner:
1. When a node N forwards a Path message out a logical outgoing
interface L, it includes in the message some encoding of the
identity of L, called the "logical interface handle" or LIH.
The LIH value is carried in the RSVP_HOP object.
2. The next hop node N' stores the LIH value in its path state.
3. When N' sends a Resv message to N, it includes the LIH value
from the path state (again, in the RSVP_HOP object).
4. When the Resv message arrives at N, its LIH value provides
the information necessary to attach the reservation to the
appropriate logical interface. Note that N creates and
interprets the LIH; it is an opaque value to N'.
Note that this only solves the routing problem posed by tunnels.
The tunnel appears to RSVP as a non-RSVP cloud. To establish RSVP
reservations within the tunnel, additional machinery will be
required, to be defined in the future.
3.4 Avoiding RSVP Message Loops
Forwarding of RSVP messages must avoid looping. In steady state,
Path and Resv messages are forwarded on each hop only once per
refresh period. This avoids looping packets, but there is still
the possibility of an "auto-refresh" loop, clocked by the refresh
period. Such auto-refresh loops keep state active "forever", even
if the end nodes have ceased refreshing it, until the receivers
leave the multicast group and/or the senders stop sending Path
messages. On the other hand, error and teardown messages are
forwarded immediately and are therefore subject to direct looping.
Consider each message type.
o Path Messages
Path messages are forwarded in exactly the same way as IP
data packets. Therefore there should be no loops of Path
messages (except perhaps for transient routing loops, which
we ignore here), even in a topology with cycles.
o PathTear Messages
PathTear messages use the same routing as Path messages and
therefore cannot loop.
o PathErr Messages
Since Path messages do not loop, they create path state
defining a loop-free reverse path to each sender. PathErr
messages are always directed to particular senders and
therefore cannot loop.
o Resv Messages
Resv messages directed to particular senders (i.e., with
explicit sender selection) cannot loop. However, Resv
messages with wildcard sender selection (WF style) have a
potential for auto-refresh looping.
o ResvTear Messages
Although ResvTear messages are routed the same as Resv
messages, during the second pass around a loop there will be
no state so any ResvTear message will be dropped. Hence
there is no looping problem here.
o ResvErr Messages
ResvErr messages for WF style reservations may loop for
essentially the same reasons that Resv messages loop.
o ResvConf Messages
ResvConf messages are forwarded towards a fixed unicast
receiver address and cannot loop.
If the topology has no loops, then looping of Resv and ResvErr
messages with wildcard sender selection can be avoided by simply
enforcing the rule given earlier: state that is received through a
particular interface must never be forwarded out the same
interface. However, when the topology does have cycles, further
effort is needed to prevent auto-refresh loops of wildcard Resv
messages and fast loops of wildcard ResvErr messages. The
solution to this problem adopted by this protocol specification is
for such messages to carry an explicit sender address list in a
SCOPE object.
When a Resv message with WF style is to be forwarded to a
particular previous hop, a new SCOPE object is computed from the
SCOPE objects that were received in matching Resv messages. If
the computed SCOPE object is empty, the message is not forwarded
to the previous hop; otherwise, the message is sent containing the
new SCOPE object. The rules for computing a new SCOPE object for
a Resv message are as follows:
1. The union is formed of the sets of sender IP addresses listed
in all SCOPE objects in the reservation state for the given
session.
If reservation state from some NHOP does not contain a SCOPE
object, a substitute sender list must be created and included
in the union. For a message that arrived on outgoing
interface OI, the substitute list is the set of senders that
route to OI.
2. Any local senders (i.e., any sender applications on this
node) are removed from this set.
3. If the SCOPE object is to be sent to PHOP, remove from the
set any senders that did not come from PHOP.
Figure 11 shows an example of wildcard-scoped (WF style) Resv
messages. The address lists within SCOPE objects are shown in
square brackets. Note that there may be additional connections
among the nodes, creating looping topology that is not shown.
________________
a | | c
R4, S4<----->| Router |<-----> R2, S2, S3
| |
b | |
R1, S1<----->| |
|________________|
Send on (a): | Receive on (c):
|
<-- WF( [S4] ) | <-- WF( [S4, S1])
|
Send on (b): |
|
<-- WF( [S1] ) |
|
Receive on (a): | Send on (c):
|
WF( [S1,S2,S3]) --> | WF( [S2, S3]) -->
|
Receive on (b): |
|
WF( [S2,S3,S4]) --> |
|
Figure 11: SCOPE Objects in Wildcard-Scope Reservations
SCOPE objects are not necessary if the multicast routing uses
shared trees or if the reservation style has explicit sender
selection. Furthermore, attaching a SCOPE object to a reservation
should be deferred to a node which has more than one previous hop
for the reservation state.
The following rules are used for SCOPE objects in ResvErr messages
with WF style:
1. The node that detected the error initiates an ResvErr message
containing a copy of the SCOPE object associated with the
reservation state or message in error.
2. Suppose a wildcard-style ResvErr message arrives at a node
with a SCOPE object containing the sender host address list
L. The node forwards the ResvErr message using the rules of
Section 3.1.8. However,
the ResvErr message forwarded out OI must contain a SCOPE
object derived from L by including only those senders that
route to OI. If this SCOPE object is empty, the ResvErr
message should not be sent out OI.
3.5 Blockade State
The basic rule for creating a Resv refresh message is to merge the
flowspecs of the reservation requests in place in the node, by
computing their LUB. However, this rule is modified by the
existence of "blockade state" resulting from ResvErr messages, to
solve the KR-II problem (see Section 2.5). The blockade state
also enters into the routing of ResvErr messages for Admission
Control failure.
When a ResvErr message for an Admission Control failure is
received, its flowspec Qe is used to create or refresh an element
of local blockade state. Each element of blockade state consists
of a blockade flowspec Qb taken from the flowspec of the ResvErr
message, and an associated blockade timer Tb. When a blockade
timer expires, the corresponding blockade state is deleted.
The granularity of blockade state depends upon the style of the
ResvErr message that created it. For an explicit style, there may
be a blockade state element (Qb(S),Tb(S)) for each sender S. For
a wildcard style, blockade state is per previous hop P.
An element of blockade state with flowspec Qb is said to
"blockade" a reservation with flowspec Qi if Qb is not (strictly)
greater than Qi. For example, suppose that the LUB of two
flowspecs is computed by taking the max of each of their
corresponding components. Then Qb blockades Qi if for some
component j, Qb[j] <= Qi[j].
Suppose that a node receives a ResvErr message from previous hop P
(or, if style is explicit, sender S) as the result of an Admission
Control failure upstream. Then:
1. An element of blockade state is created for P (or S) if it
did not exist.
2. Qb(P) (or Qb(S)) is set equal to the flowspec Qe from the
ResvErr message.
3. A corresponding blockade timer Tb(P) (or Tb(S)) is started or
restarted for a time Kb*R. Here Kb is a fixed multiplier and
R is the refresh interval for reservation state. Kb should
be configurable.
4. If there is some local reservation state that is not
blockaded (see below), an immediate reservation refresh for P
(or S) is generated.
5. The ResvErr message is forwarded to next hops in the
following way. If the InPlace bit is off, the ResvErr
message is forwarded to all next hops for which there is
reservation state. If the InPlace bit is on, the ResvErr
message is forwarded only to the next hops whose Qi is
blockaded by Qb.
Finally, we present the modified rule for merging flowspecs to
create a reservation refresh message.
o If there are any local reservation requests Qi that are not
blockaded, these are merged by computing their LUB. The
blockaded reservations are ignored; this allows forwarding of
a smaller reservation that has not failed and may perhaps
succeed, after a larger reservation fails.
o Otherwise (all local requests Qi are blockaded), they are
merged by taking the GLB (Greatest Lower Bound) of the Qi's.
(The use of some definition of "minimum" improves performance
by bracketing the failure level between the largest that
succeeds and the smallest that fails. The choice of GLB in
particular was made because it is simple to define and
implement, and no reason is known for using a different
definition of "minimum" here).
This refresh merging algorithm is applied separately to each flow
(each sender or PHOP) contributing to a shared reservation (WF or
SE style).
Figure 12 shows an example of the the application of blockade
state for a shared reservation (WF style). There are two previous
hops labeled (a) and (b), and two next hops labeled (c) and (d).
The larger reservation 4B arrived from (c) first, but it failed
somewhere upstream via PHOP (a), but not via PHOP (b). The
figures show the final "steady state" after the smaller
reservation 2B subsequently arrived from (d). This steady state
is perturbed roughly every Kb*R seconds, when the blockade state
times out. The next refresh then sends 4B to previous hop (a);
presumably this will fail, sending a ResvErr message that will
re-establish the blockade state, returning to the situation shown
in the figure. At the same time, the ResvErr message will be
forwarded to next hop (c) and to all receivers downstream
responsible for the 4B reservations.
Send Blockade | Reserve Receive
State {Qb}|
| ________
(a) <- WF(*{2B}) {4B} | | * {4B} | WF(*{4B}) <- (c)
| |________|
|
---------------------------|-------------------------------
|
| ________
(b) <- WF(*{4B}) (none)| | * {2B} | WF(*{2B}) <- (d)
| |________|
Figure 12: Blockading with Shared Style
3.6 Local Repair
When a route changes, the next Path or Resv refresh message will
establish path or reservation state (respectively) along the new
route. To provide fast adaptation to routing changes without the
overhead of short refresh periods, the local routing protocol
module can notify the RSVP process of route changes for particular
destinations. The RSVP process should use this information to
trigger a quick refresh of state for these destinations, using the
new route.
The specific rules are as follows:
o When routing detects a change of the set of outgoing
interfaces for destination G, RSVP should update the path
state, wait for a short period W, and then send Path
refreshes for all sessions G/* (i.e., for any session with
destination G, regardless of destination port).
The short wait period before sending Path refreshes is to
allow the routing protocol to settle, and the value for W
should be chosen accordingly. Currently W = 2 sec is
suggested; however, this value should be configurable per
interface.
o When a Path message arrives with a Previous Hop address that
differs from the one stored in the path state, RSVP should
send immediate Resv refreshes to that PHOP.
3.7 Time Parameters There are two time parameters relevant to each element of RSVP path or reservation state in a node: the refresh period R between generation of successive refreshes for the state by the neighbor node, and the local state's lifetime L. Each RSVP Resv or Path message may contain a TIME_VALUES object specifying the R value 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 and stored. The values for R and L may vary from hop to hop. In more detail: 1. Floyd and Jacobson [FJ94] have shown that periodic messages generated by independent network nodes can become synchronized. This can lead to disruption in network services as the periodic messages contend with other network traffic for link and forwarding resources. Since RSVP sends periodic refresh messages, it must avoid message synchronization and ensure that any synchronization that may occur is not stable. For this reason, the refresh timer should be randomly set to a value in the range [0.5R, 1.5R]. 2. To avoid premature loss of state, L must satisfy L >= (K + 0.5)*1.5*R, where K is a small integer. Then in the worst case, K-1 successive messages may be lost without state being deleted. To compute a lifetime L for a collection of state with different R values R0, R1, ..., replace R by max(Ri). Currently K = 3 is suggested as the default. However, it may be necessary to set a larger K value for hops with high loss rate. K may be set either by manual configuration per interface, or by some adaptive technique that has not yet been specified. 3. Each Path or Resv message carries a TIME_VALUES object containing the refresh time R used to generate refreshes. The recipient node uses this R to determine the lifetime L of the stored state created or refreshed by the message. 4. The refresh time R is chosen locally by each node. If the node does not implement local repair of reservations disrupted by route changes, a smaller R speeds up adaptation to routing changes, while increasing the RSVP overhead. With local repair, a router can be more relaxed about R since the periodic refresh becomes only a backstop robustness
mechanism. A node may therefore adjust the effective R
dynamically to control the amount of overhead due to refresh
messages.
The current suggested default for R is 30 seconds. However,
the default value Rdef should be configurable per interface.
5. When R is changed dynamically, there is a limit on how fast
it may increase. Specifically, the ratio of two successive
values R2/R1 must not exceed 1 + Slew.Max.
Currently, Slew.Max is 0.30. With K = 3, one packet may be
lost without state timeout while R is increasing 30 percent
per refresh cycle.
6. To improve robustness, a node may temporarily send refreshes
more often than R after a state change (including initial
state establishment).
7. The values of Rdef, K, and Slew.Max used in an implementation
should be easily modifiable per interface, as experience may
lead to different values. The possibility of dynamically
adapting K and/or Slew.Max in response to measured loss rates
is for future study.
3.8 Traffic Policing and Non-Integrated Service Hops
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
multiple senders, and/or (3) a branch point where traffic flow
from upstream may be greater than the downstream reservation being
requested. RSVP knows where such points occur and must so
indicate to the traffic control mechanism. On the other hand,
RSVP does not interpret the service embodied in the flowspec and
therefore does not know whether policing will actually be applied
in any particular case.
The RSVP process passes to traffic control a separate policing
flag for each of these three situations.
o E_Police_Flag -- Entry Policing
This flag is set in the first-hop RSVP node that implements
traffic control (and is therefore capable of policing).
For example, sender hosts must implement RSVP but currently
many of them do not implement traffic control. In this case,
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
control is reached. This is controlled by the E_Police flag
in SESSION objects.
o M_Police_Flag -- Merge Policing
This flag should be set on for a reservation using a shared
style (WF or SE) when flows from more than one sender are
being merged.
o B_Police_Flag -- Branch Policing
This flag should be set on when the flowspec being installed
is smaller than, or incomparable to, a FLOWSPEC in place on
any other interface, for the same FILTER_SPEC and SESSION.
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
that the RSVP process supplies and from its own local knowledge,
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
the receivers in Adspecs [RFC 2210].
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
with which it is received; for this purpose, the transmission TTL
is placed in the common header. However, the TTL is not always a
reliable indicator of non-RSVP hops, and other means must
sometimes be used. For example, if the routing protocol uses IP
encapsulating tunnels, then the routing protocol must inform RSVP
when non-RSVP hops are included. If no automatic mechanism will
work, manual configuration will be required.
3.9 Multihomed Hosts
Accommodating multihomed hosts requires some special rules in
RSVP. We use the term `multihomed host' to cover both hosts (end
systems) with more than one network interface and routers that are
supporting local application programs.
An application executing on a multihomed host may explicitly
specify which interface any given flow will use for sending and/or
for receiving data packets, to override the system-specified
default interface. The RSVP process must be aware of the default,
and if an application sets a specific interface, it must also pass
that information to RSVP.
o Sending Data
A sender application uses an API call (SENDER in Section
3.11.1) to declare to RSVP the characteristics of the data
flow it will originate. This call may optionally include the
local IP address of the sender. If it is set by the
application, this parameter must be the interface address for
sending the data packets; otherwise, the system default
interface is implied.
The RSVP process on the host then sends Path messages for
this application out the specified interface (only).
o Making Reservations
A receiver application uses an API call (RESERVE in Section
3.11.1) to request a reservation from RSVP. This call may
optionally include the local IP address of the receiver,
i.e., the interface address for receiving data packets. In
the case of multicast sessions, this is the interface on
which the group has been joined. If the parameter is
omitted, the system default interface is used.
In general, the RSVP process should send Resv messages for an
application out the specified interface. However, when the
application is executing on a router and the session is
multicast, a more complex situation arises. Suppose in this
case that a receiver application joins the group on an
interface Iapp that differs from Isp, the shortest-path
interface to the sender. Then there are two possible ways
for multicast routing to deliver data packets to the
application. The RSVP process must determine which case
holds by examining the path state, to decide which incoming
interface to use for sending Resv messages.
1. The multicast routing protocol may create a separate
branch of the multicast distribution `tree' to deliver
to Iapp. In this case, there will be path state for
both interfaces Isp and Iapp. The path state on Iapp
should only match a reservation from the local
application; it must be marked "Local_only" by the RSVP
process. If "Local_only" path state for Iapp exists,
the Resv message should be sent out Iapp.
Note that it is possible for the path state blocks for
Isp and Iapp to have the same next hop, if there is an
intervening non-RSVP cloud.
2. The multicast routing protocol may forward data within
the router from Isp to Iapp. In this case, Iapp will
appear in the list of outgoing interfaces of the path
state for Isp, and the Resv message should be sent out
Isp.
3. When Path and PathTear messages are forwarded, path
state marked "Local_Only" must be ignored.
3.10 Future Compatibility
We may expect that in the future new object C-Types will be
defined for existing object classes, and perhaps new object
classes will be defined. It will be desirable to employ such new
objects within the Internet using older implementations that do
not recognize them. Unfortunately, this is only possible to a
limited degree with reasonable complexity. The rules are as
follows (`b' represents a bit).
1. Unknown Class
There are three possible ways that an RSVP implementation can
treat an object with unknown class. This choice is
determined by the two high-order bits of the Class-Num octet,
as follows.
o Class-Num = 0bbbbbbb
The entire message should be rejected and an "Unknown
Object Class" error returned.
o Class-Num = 10bbbbbb
The node should ignore the object, neither forwarding it
nor sending an error message.
o Class-Num = 11bbbbbb
The node should ignore the object but forward it,
unexamined and unmodified, in all messages resulting
from this message.
The following more detailed rules hold for unknown-class
objects with a Class-Num of the form 11bbbbbb:
1. Such unknown-class objects received in PathTear,
ResvTear, PathErr, or ResvErr messages should be
forwarded immediately in the same messages.
2. Such unknown-class objects received in Path or Resv
messages should be saved with the corresponding state
and forwarded in any refresh message resulting from that
state.
3. When a Resv refresh is generated by merging multiple
reservation requests, the refresh message should include
the union of unknown-class objects from the component
requests. Only one copy of each unique unknown-class
object should be included in this union.
4. The original order of such unknown-class objects need
not be retained; however, the message that is forwarded
must obey the general order requirements for its message
type.
Although objects with unknown class cannot be merged, these
rules will forward such objects until they reach a node that
knows how to merge them. Forwarding objects with unknown
class enables incremental deployment of new objects; however,
the scaling limitations of doing so must be carefully
examined before a new object class is deployed with both high
bits on.
2. Unknown C-Type for Known Class
One might expect the known Class-Num to provide information
that could allow intelligent handling of such an object.
However, in practice such class-dependent handling is
complex, and in many cases it is not useful.
Generally, the appearance of an object with unknown C-Type
should result in rejection of the entire message and
generation of an error message (ResvErr or PathErr as
appropriate). The error message will include the Class-Num
and C-Type that failed (see Appendix B); the end system that
originated the failed message may be able to use this
information to retry the request using a different C-Type
object, repeating this process until it runs out of
alternatives or succeeds.
Objects of certain classes (FLOWSPEC, ADSPEC, and
POLICY_DATA) are opaque to RSVP, which simply hands them to
traffic control or policy modules. Depending upon its
internal rules, either of the latter modules may reject a C-
Type and inform the RSVP process; RSVP should then reject the
message and send an error, as described in the previous
paragraph.
3.11 RSVP Interfaces 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 also an interface to traffic control (if it exists on the host). 3.11.1 Application/RSVP Interface This section describes a generic interface between an application and an RSVP control process. The details of a real interface may be operating-system dependent; the following can only suggest the basic functions to be performed. Some of these calls cause information to be returned asynchronously. o Register Session Call: SESSION( DestAddress , ProtocolId, DstPort [ , SESSION_object ] [ , Upcall_Proc_addr ] ) -> Session-id This call initiates RSVP processing for a session, defined by DestAddress together with ProtocolId and possibly a port number DstPort. If successful, the SESSION call returns immediately with a local session identifier Session-id, which may be used in subsequent calls. The Upcall_Proc_addr parameter defines the address of an upcall procedure to receive asynchronous error or event notification; see below. The SESSION_object parameter is included as an escape mechanism to support some more general definition of the session ("generalized destination port"), should that be necessary in the future. Normally SESSION_object will be omitted. o Define Sender Call: SENDER( Session-id [ , Source_Address ] [ , Source_Port ] [ , Sender_Template ] [ , Sender_Tspec ] [ , Adspec ] [ , Data_TTL ] [ , Policy_data ] )
A sender uses this call to define, or to modify the
definition of, the attributes of the data flow. The first
SENDER call for the session registered as `Session-id'
will cause RSVP to begin sending Path messages for this
session; later calls will modify the path information.
The SENDER parameters are interpreted as follows:
- Source_Address
This is the address of the interface from which the
data will be sent. If it is omitted, a default
interface will be used. This parameter is needed
only on a multihomed sender host.
- Source_Port
This is the UDP/TCP port from which the data will be
sent.
- Sender_Template
This parameter is included as an escape mechanism to
support a more general definition of the sender
("generalized source port"). Normally this parameter
may be omitted.
- Sender_Tspec
This parameter describes the traffic flow to be sent;
see [RFC 2210].
- Adspec
This parameter may be specified to initialize the
computation of QoS properties along the path; see
[RFC 2210].
- Data_TTL
This is the (non-default) IP Time-To-Live parameter
that is being supplied on the data packets. It is
needed to ensure that Path messages do not have a
scope larger than multicast data packets.
- Policy_data
This optional parameter passes policy data for the
sender. This data may be supplied by a system
service, with the application treating it as opaque.
o Reserve
Call: RESERVE( session-id, [ receiver_address , ]
[ CONF_flag, ] [ Policy_data, ]
style, style-dependent-parms )
A receiver uses this call to make or to modify a resource
reservation for the session registered as `session-id'.
The first RESERVE call will initiate the periodic
transmission of Resv messages. A later RESERVE call may
be given to modify the parameters of the earlier call (but
note that changing existing reservations may result in
admission control failures).
The optional `receiver_address' parameter may be used by a
receiver on a multihomed host (or router); it is the IP
address of one of the node's interfaces. The CONF_flag
should be set on if a reservation confirmation is desired,
off otherwise. The `Policy_data' parameter specifies
policy data for the receiver, while the `style' parameter
indicates the reservation style. The rest of the
parameters depend upon the style; generally these will be
appropriate flowspecs and filter specs.
The RESERVE call returns immediately. Following a RESERVE
call, an asynchronous ERROR/EVENT upcall may occur at any
time.
o Release
Call: RELEASE( session-id )
This call removes RSVP state for the session specified by
session-id. The node then sends appropriate teardown
messages and ceases sending refreshes for this session-id.
o Error/Event Upcalls
The general form of a upcall is as follows:
Upcall: <Upcall_Proc>( ) -> session-id, Info_type,
information_parameters
Here "Upcall_Proc" represents the upcall procedure whose
address was supplied in the SESSION call. This upcall may
occur asynchronously at any time after a SESSION call and
before a RELEASE call, to indicate an error or an event.
Currently there are five upcall types, distinguished by
the Info_type parameter. The selection of information
parameters depends upon the type.
1. Info_type = PATH_EVENT
A Path Event upcall results from receipt of the first
Path message for this session, indicating to a
receiver application that there is at least one
active sender, or if the path state changes.
Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=PATH_EVENT,
Sender_Tspec, Sender_Template
[ , Adspec ] [ , Policy_data ]
This upcall presents the Sender_Tspec, the
Sender_Template, the Adspec, and any policy data from
a Path message.
2. Info_type = RESV_EVENT
A Resv Event upcall is triggered by the receipt of
the first RESV message, or by modification of a
previous reservation state, for this session.
Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=RESV_EVENT,
Style, Flowspec, Filter_Spec_list
[ , Policy_data ]
Here `Flowspec' will be the effective QoS that has
been received. Note that an FF-style Resv message
may result in multiple RESV_EVENT upcalls, one for
each flow descriptor.
3. Info_type = PATH_ERROR
An Path Error event indicates an error in sender
information that was specified in a SENDER call.
Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=PATH_ERROR,
Error_code , Error_value ,
Error_Node , Sender_Template
[ , Policy_data_list ]
The Error_code parameter will define the error, and
Error_value may supply some additional (perhaps
system-specific) data about the error. The
Error_Node parameter will specify the IP address of
the node that detected the error. The
Policy_data_list parameter, if present, will contain
any POLICY_DATA objects from the failed Path message.
4. Info_type = RESV_ERR
An Resv Error event indicates an error in a
reservation message to which this application
contributed.
Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=RESV_ERROR,
Error_code , Error_value ,
Error_Node , Error_flags ,
Flowspec, Filter_spec_list
[ , Policy_data_list ]
The Error_code parameter will define the error and
Error_value may supply some additional (perhaps
system-specific) data. The Error_Node parameter will
specify the IP address of the node that detected the
event being reported.
There are two Error_flags:
- InPlace
This flag may be on for an Admission Control
failure, to indicate that there was, and is, a
reservation in place at the failure node. This
flag is set at the failure point and forwarded
in ResvErr messages.
- NotGuilty
This flag may be on for an Admission Control
failure, to indicate that the flowspec requested
by this receiver was strictly less than the
flowspec that got the error. This flag is set
at the receiver API.
Filter_spec_list and Flowspec will contain the
corresponding objects from the error flow descriptor
(see Section 3.1.8). List_count will specify the
number of FILTER_SPECS in Filter_spec_list. The
Policy_data_list parameter will contain any
POLICY_DATA objects from the ResvErr message.
5. Info_type = RESV_CONFIRM
A Confirmation event indicates that a ResvConf
message was received.
Upcall: <Upcall_Proc>( ) -> session-id,
Info_type=RESV_CONFIRM,
Style, List_count,
Flowspec, Filter_spec_list
[ , Policy_data ]
The parameters are interpreted as in the Resv Error
upcall.
Although RSVP messages indicating path or resv events may
be received periodically, the API should make the
corresponding asynchronous upcall to the application only
on the first occurrence or when the information to be
reported changes. All error and confirmation events
should be reported to the application.
3.11.2 RSVP/Traffic Control Interface
It is difficult to present a generic interface to traffic
control, because the details of establishing a reservation
depend strongly upon the particular link layer technology in
use on an interface.
Merging of RSVP reservations is required because of multicast
data delivery, which replicates data packets for delivery to
different next-hop nodes. At each such replication point, RSVP
must merge reservation requests from the corresponding next
hops by computing the "maximum" of their flowspecs. At a given
router or host, one or more of the following three replication
locations may be in use.
1. IP layer
IP multicast forwarding performs replication in the IP
layer. In this case, RSVP must merge the reservations
that are in place on the corresponding outgoing interfaces
in order to forward a request upstream.
2. "The network"
Replication might take place downstream from the node,
e.g., in a broadcast LAN, in link-layer switches, or in a
mesh of non-RSVP-capable routers (see Section 2.8). In
these cases, RSVP must merge the reservations from the
different next hops in order to make the reservation on
the single outgoing interface. It must also merge
reservations requests from all outgoing interfaces in
order to forward a request upstream.
3. Link-layer driver
For a multi-access technology, replication may occur in
the link layer driver or interface card. For example,
this case might arise when there is a separate ATM point-
to-point VC towards each next hop. RSVP may need to apply
traffic control independently to each VC, without merging
requests from different next hops.
In general, these complexities do not impact the protocol
processing that is required by RSVP, except to determine
exactly what reservation requests need to be merged. It may be
desirable to organize an RSVP implementation into two parts: a
core that performs link-layer-independent processing, and a
link-layer-dependent adaptation layer. However, we present
here a generic interface that assumes that replication can
occur only at the IP layer or in "the network".
o Make a Reservation
Call: TC_AddFlowspec( Interface, TC_Flowspec,
TC_Tspec, TC_Adspec, Police_Flags )
-> RHandle [, Fwd_Flowspec]
The TC_Flowspec parameter defines the desired effective
QoS to admission control; its value is computed as the
maximum over the flowspecs of different next hops (see the
Compare_Flowspecs call below). The TC_Tspec parameter
defines the effective sender Tspec Path_Te (see Section
2.2). The TC_Adspec parameter defines the effective
Adspec. The Police_Flags parameter carries the three
flags E_Police_Flag, M_Police_Flag, and B_Police_Flag; see
Section 3.8.
If this call is successful, it establishes a new
reservation channel corresponding to RHandle; otherwise,
it returns an error code. The opaque number RHandle is
used by the caller for subsequent references to this
reservation. If the traffic control service updates the
flowspec, the call will also return the updated object as
Fwd_Flowspec.
o Modify Reservation
Call: TC_ModFlowspec( Interface, RHandle, TC_Flowspec,
TC_Tspec, TC_Adspec, Police_flags )
[ -> Fwd_Flowspec ]
This call is used to modify an existing reservation.
TC_Flowspec is passed to Admission Control; if it is
rejected, the current flowspec is left in force. The
corresponding filter specs, if any, are not affected. The
other parameters are defined as in TC_AddFlowspec. If the
service updates the flowspec, the call will also return
the updated object as Fwd_Flowspec.
o Delete Flowspec
Call: TC_DelFlowspec( Interface, RHandle )
This call will delete an existing reservation, including
the flowspec and all associated filter specs.
o Add Filter Spec
Call: TC_AddFilter( Interface, RHandle,
Session , FilterSpec ) -> FHandle
This call is used to associate an additional filter spec
with the reservation specified by the given RHandle,
following a successful TC_AddFlowspec call. This call
returns a filter handle FHandle.
o Delete Filter Spec
Call: TC_DelFilter( Interface, FHandle )
This call is used to remove a specific filter, specified
by FHandle.
o OPWA Update
Call: TC_Advertise( Interface, Adspec,
Non_RSVP_Hop_flag ) -> New_Adspec
This call is used for OPWA to compute the outgoing
advertisement New_Adspec for a specified interface. The
flag bit Non_RSVP_Hop_flag should be set whenever the RSVP
daemon detects that the previous RSVP hop included one or
more non-RSVP-capable routers. TC_Advertise will insert
this information into New_Adspec to indicate that a non-
integrated-service hop was found; see Section 3.8.
o Preemption Upcall
Upcall: TC_Preempt() -> RHandle, Reason_code
In order to grant a new reservation request, the admission
control and/or policy control modules may preempt one or
more existing reservations. This will trigger a
TC_Preempt() upcall to RSVP for each preempted
reservation, passing the RHandle of the reservation and a
sub-code indicating the reason.
3.11.3 RSVP/Policy Control Interface
This interface will be specified in a future document.
3.11.4 RSVP/Routing Interface
An RSVP implementation needs the following support from the
routing mechanisms of the node.
o Route Query
To forward Path and PathTear messages, an RSVP process
must be able to query the routing process(s) for routes.
Ucast_Route_Query( [ SrcAddress, ] DestAddress,
Notify_flag ) -> OutInterface
Mcast_Route_Query( [ SrcAddress, ] DestAddress,
Notify_flag )
-> [ IncInterface, ] OutInterface_list
Depending upon the routing protocol, the query may or may
not depend upon SrcAddress, i.e., upon the sender host IP
address, which is also the IP source address of the
message. Here IncInterface is the interface through which
the packet is expected to arrive; some multicast routing
protocols may not provide it. If the Notify_flag is True,
routing will save state necessary to issue unsolicited
route change notification callbacks (see below) whenever
the specified route changes.
A multicast route query may return an empty
OutInterface_list if there are no receivers downstream of
a particular router. A route query may also return a `No
such route' error, probably as a result of a transient
inconsistency in the routing (since a Path or PathTear
message for the requested route did arrive at this node).
In either case, the local state should be updated as
requested by the message, which cannot be forwarded
further. Updating local state will make path state
available immediately for a new local receiver, or it will
tear down path state immediately.
o Route Change Notification
If requested by a route query with the Notify_flag True,
the routing process may provide an asynchronous callback
to the RSVP process that a specified route has changed.
Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
OutInterface
Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
[ IncInterface, ] OutInterface_list
o Interface List Discovery
RSVP must be able to learn what real and virtual
interfaces are active, with their IP addresses.
It should be possible to logically disable an interface
for RSVP. When an interface is disabled for RSVP, a Path
message should never be forwarded out that interface, and
if an RSVP message is received on that interface, the
message should be silently discarded (perhaps with local
logging).
3.11.5 RSVP/Packet I/O Interface
An RSVP implementation needs the following support from the
packet I/O and forwarding mechanisms of the node.
o Promiscuous Receive Mode for RSVP Messages
Packets received for IP protocol 46 but not addressed to
the node must be diverted to the RSVP program for
processing, without being forwarded. The RSVP messages to
be diverted in this manner will include Path, PathTear,
and ResvConf messages. These message types carry the
Router Alert IP option, which can be used to pick them out
of a high-speed forwarding path. Alternatively, the node
can intercept all protocol 46 packets.
On a router or multi-homed host, the identity of the
interface (real or virtual) on which a diverted message is
received, as well as the IP source address and IP TTL with
which it arrived, must also be available to the RSVP
process.
o Outgoing Link Specification
RSVP must be able to force a (multicast) datagram to be
sent on a specific outgoing real or virtual link,
bypassing the normal routing mechanism. A virtual link
might be a multicast tunnel, for example. Outgoing link
specification is necessary to send different versions of
an outgoing Path message on different interfaces, and to
avoid routing loops in some cases.
o Source Address and TTL Specification
RSVP must be able to specify the IP source address and IP
TTL to be used when sending Path messages.
o Router Alert
RSVP must be able to cause Path, PathTear, and ResvConf
message to be sent with the Router Alert IP option.
3.11.6 Service-Dependent Manipulations Flowspecs, Tspecs, and Adspecs are opaque objects to RSVP; their contents are defined in service specification documents. In order to manipulate these objects, RSVP process must have available to it the following service-dependent routines. o Compare Flowspecs Compare_Flowspecs( Flowspec_1, Flowspec_2 ) -> result_code The possible result_codes indicate: flowspecs are equal, Flowspec_1 is greater, Flowspec_2 is greater, flowspecs are incomparable but LUB can be computed, or flowspecs are incompatible. Note that comparing two flowspecs implicitly compares the Tspecs that are contained. Although the RSVP process cannot itself parse a flowspec to extract the Tspec, it can use the Compare_Flowspecs call to implicitly calculate Resv_Te (see Section 2.2). o Compute LUB of Flowspecs LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) -> Flowspec_LUB o Compute GLB of Flowspecs GLB_of_Flowspecs( Flowspec_1, Flowspec_2 ) -> Flowspec_GLB o Compare Tspecs Compare_Tspecs( Tspec_1, Tspec_2 ) -> result_code
The possible result_codes indicate: Tspecs are equal, or
Tspecs are unequal.
o Sum Tspecs
Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum
This call is used to compute Path_Te (see Section 2.2).
4. Acknowledgments
The design of RSVP is based upon research performed in 1992-1993 by a
collaboration including Lixia Zhang (UCLA), 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, Daniel Zappala, and Lixia Zhang. In addition, a
number of host and router vendors have made valuable contributions to
the RSVP documents, 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), as
well as many others.
(next page on part 4)