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 [RFC2210].
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 [RFC2210].
- Adspec
This parameter may be specified to initialize the
computation of QoS properties along the path; see
[RFC2210].
- 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.
APPENDIX A. Object Definitions
C-Types are defined for the two Internet address families IPv4 and
IPv6. To accommodate other address families, additional C-Types
could easily be defined. These definitions are contained as an
Appendix, to ease updating.
All unused fields should be sent as zero and ignored on receipt.
A.1 SESSION Class
SESSION Class = 1.
o IPv4/UDP SESSION object: Class = 1, C-Type = 1
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+
o IPv6/UDP SESSION object: Class = 1, C-Type = 2
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+
DestAddress
The IP unicast or multicast destination address of the
session. This field must be non-zero.
Protocol Id
The IP Protocol Identifier for the data flow. This field
must be non-zero.
Flags
0x01 = E_Police flag
The E_Police flag is used in Path messages to determine
the effective "edge" of the network, to control traffic
policing. If the sender host is not itself capable of
traffic policing, it will set this bit on in Path
messages it sends. The first node whose RSVP is capable
of traffic policing will do so (if appropriate to the
service) and turn the flag off.
DstPort
The UDP/TCP destination port for the session. Zero may be
used to indicate `none'.
Other SESSION C-Types could be defined in the future to
support other demultiplexing conventions in the transport-
layer or application layer.
A.2 RSVP_HOP Class
RSVP_HOP class = 3.
o IPv4 RSVP_HOP object: Class = 3, C-Type = 1
+-------------+-------------+-------------+-------------+
| IPv4 Next/Previous Hop Address |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
o IPv6 RSVP_HOP object: Class = 3, C-Type = 2
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Next/Previous Hop Address +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
This object carries the IP address of the interface through which
the last RSVP-knowledgeable hop forwarded this message. The
Logical Interface Handle (LIH) is used to distinguish logical
outgoing interfaces, as discussed in Sections 3.3 and 3.9. A node
receiving an LIH in a Path message saves its value and returns it
in the HOP objects of subsequent Resv messages sent to the node
that originated the LIH. The LIH should be identically zero if
there is no logical interface handle.
A.3 INTEGRITY Class
INTEGRITY class = 4.
See [Baker96].
A.4 TIME_VALUES Class
TIME_VALUES class = 5.
o TIME_VALUES Object: Class = 5, C-Type = 1
+-------------+-------------+-------------+-------------+
| Refresh Period R |
+-------------+-------------+-------------+-------------+
Refresh Period
The refresh timeout period R used to generate this message;
in milliseconds.
A.5 ERROR_SPEC Class
ERROR_SPEC class = 6.
o IPv4 ERROR_SPEC object: Class = 6, C-Type = 1
+-------------+-------------+-------------+-------------+
| IPv4 Error Node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
o IPv6 ERROR_SPEC object: Class = 6, C-Type = 2
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Error Node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
Error Node Address
The IP address of the node in which the error was detected.
Flags
0x01 = InPlace
This flag is used only for an ERROR_SPEC object in a
ResvErr message. If it on, this flag indicates that
there was, and still is, a reservation in place at the
failure point.
0x02 = NotGuilty
This flag is used only for an ERROR_SPEC object in a
ResvErr message, and it is only set in the interface to
the receiver application. If it on, this flag indicates
that the FLOWSPEC that failed was strictly greater than
the FLOWSPEC requested by this receiver.
Error Code
A one-octet error description.
Error Value
A two-octet field containing additional information about the
error. Its contents depend upon the Error Type.
The values for Error Code and Error Value are defined in Appendix
B.
A.6 SCOPE Class
SCOPE class = 7.
This object contains a list of IP addresses, used for routing
messages with wildcard scope without loops. The addresses must be
listed in ascending numerical order.
o IPv4 SCOPE List object: Class = 7, C-Type = 1
+-------------+-------------+-------------+-------------+
| IPv4 Src Address (4 bytes) |
+-------------+-------------+-------------+-------------+
// //
+-------------+-------------+-------------+-------------+
| IPv4 Src Address (4 bytes) |
+-------------+-------------+-------------+-------------+
o IPv6 SCOPE list object: Class = 7, C-Type = 2
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Src Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
// //
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Src Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
A.7 STYLE Class
STYLE class = 8.
o STYLE object: Class = 8, C-Type = 1
+-------------+-------------+-------------+-------------+
| Flags | Option Vector |
+-------------+-------------+-------------+-------------+
Flags: 8 bits
(None assigned yet)
Option Vector: 24 bits
A set of bit fields giving values for the reservation
options. If new options are added in the future,
corresponding fields in the option vector will be assigned
from the least-significant end. If a node does not recognize
a style ID, it may interpret as much of the option vector as
it can, ignoring new fields that may have been defined.
The option vector bits are assigned (from the left) as
follows:
19 bits: Reserved
2 bits: Sharing control
00b: Reserved
01b: Distinct reservations
10b: Shared reservations
11b: Reserved
3 bits: Sender selection control
000b: Reserved
001b: Wildcard
010b: Explicit
011b - 111b: Reserved
The low order bits of the option vector are determined by the
style, as follows:
WF 10001b
FF 01010b
SE 10010b
A.8 FLOWSPEC Class
FLOWSPEC class = 9.
o Reserved (obsolete) flowspec object: Class = 9, C-Type = 1
o Inv-serv Flowspec object: Class = 9, C-Type = 2
The contents and encoding rules for this object are specified
in documents prepared by the int-serv working group [RFC
2210].
A.9 FILTER_SPEC Class
FILTER_SPEC class = 10.
o IPv4 FILTER_SPEC object: Class = 10, C-Type = 1
+-------------+-------------+-------------+-------------+
| IPv4 SrcAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| ////// | ////// | SrcPort |
+-------------+-------------+-------------+-------------+
o IPv6 FILTER_SPEC object: Class = 10, C-Type = 2
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 SrcAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| ////// | ////// | SrcPort |
+-------------+-------------+-------------+-------------+
o IPv6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 SrcAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| /////// | Flow Label (24 bits) |