A reservation request that fails Admission Control creates
blockade state but is left in place in nodes downstream of the
failure point. It has been suggested that these reservations
downstream from the failure represent "wasted" reservations and
should be timed out if not actively deleted. However, the
downstream reservations are left in place, for the following
reasons:
o There are two possible reasons for a receiver persisting in a
failed reservation: (1) it is polling for resource
availability along the entire path, or (2) it wants to obtain
the desired QoS along as much of the path as possible.
Certainly in the second case, and perhaps in the first case,
the receiver will want to hold onto the reservations it has
made downstream from the failure.
o If these downstream reservations were not retained, the
responsiveness of RSVP to certain transient failures would be
impaired. For example, suppose a route "flaps" to an
alternate route that is congested, so an existing reservation
suddenly fails, then quickly recovers to the original route.
The blockade state in each downstream router must not remove
the state or prevent its immediate refresh.
o If we did not refresh the downstream reservations, they might
time out, to be restored every Tb seconds (where Tb is the
blockade state timeout interval). Such intermittent behavior
might be very distressing for users.
2.6 Confirmation
To request a confirmation for its reservation request, a receiver
Rj includes in the Resv message a confirmation-request object
containing Rj's IP address. At each merge point, only the largest
flowspec and any accompanying confirmation-request object is
forwarded upstream. If the reservation request from Rj is equal
to or smaller than the reservation in place on a node, its Resv is
not forwarded further, and if the Resv included a confirmation-
request object, a ResvConf message is sent back to Rj. If the
confirmation request is forwarded, it is forwarded immediately,
and no more than once for each request.
This confirmation mechanism has the following consequences:
o A new reservation request with a flowspec larger than any in
place for a session will normally result in either a ResvErr
or a ResvConf message back to the receiver from each sender.
In this case, the ResvConf message will be an end-to-end
confirmation.
o The receipt of a ResvConf gives no guarantees. Assume the
first two reservation requests from receivers R1 and R2
arrive at the node where they are merged. R2, whose
reservation was the second to arrive at that node, may
receive a ResvConf from that node while R1's request has not
yet propagated all the way to a matching sender and may still
fail. Thus, R2 may receive a ResvConf although there is no
end-to-end reservation in place; furthermore, R2 may receive
a ResvConf followed by a ResvErr.
2.7 Policy Control
RSVP-mediated QoS requests allow particular user(s) to obtain
preferential access to network resources. To prevent abuse, some
form of back pressure will generally be required on users who make
reservations. For example, such back pressure may be accomplished
by administrative access policies, or it may depend upon some form
of user feedback such as real or virtual billing for the "cost" of
a reservation. In any case, reliable user identification and
selective admission will generally be needed when a reservation is
requested.
The term "policy control" is used for the mechanisms required to
support access policies and back pressure for RSVP reservations.
When a new reservation is requested, each node must answer two
questions: "Are enough resources available to meet this request?"
and "Is this user allowed to make this reservation?" These two
decisions are termed the "admission control" decision and the
"policy control" decision, respectively, and both must be
favorable in order for RSVP to make a reservation. Different
administrative domains in the Internet may have different
reservation policies.
The input to policy control is referred to as "policy data", which
RSVP carries in POLICY_DATA objects. Policy data may include
credentials identifying users or user classes, account numbers,
limits, quotas, etc. Like flowspecs, policy data is opaque to
RSVP, which simply passes it to policy control when required.
Similarly, merging of policy data must be done by the policy
control mechanism rather than by RSVP itself. Note that the merge
points for policy data are likely to be at the boundaries of
administrative domains. It may therefore be necessary to carry
accumulated and unmerged policy data upstream through multiple
nodes before reaching one of these merge points.
Carrying user-provided policy data in Resv messages presents a
potential scaling problem. When a multicast group has a large
number of receivers, it will be impossible or undesirable to carry
all receivers' policy data upstream. The policy data will have to
be administratively merged at places near the receivers, to avoid
excessive policy data. Further discussion of these issues and an
example of a policy control scheme will be found in [PolArch96].
Specifications for the format of policy data objects and RSVP
processing rules for them are under development.
2.8 Security
RSVP raises the following security issues.
o Message integrity and node authentication
Corrupted or spoofed reservation requests could lead to theft
of service by unauthorized parties or to denial of service
caused by locking up network resources. RSVP protects
against such attacks with a hop-by-hop authentication
mechanism using an encrypted hash function. The mechanism is
supported by INTEGRITY objects that may appear in any RSVP
message. These objects use a keyed cryptographic digest
technique, which assumes that RSVP neighbors share a secret.
Although this mechanism is part of the base RSVP
specification, it is described in a companion document
[Baker96].
Widespread use of the RSVP integrity mechanism will require
the availability of the long-sought key management and
distribution infrastructure for routers. Until that
infrastructure becomes available, manual key management will
be required to secure RSVP message integrity.
o User authentication
Policy control will depend upon positive authentication of
the user responsible for each reservation request. Policy
data may therefore include cryptographically protected user
certificates. Specification of such certificates is a future
issue.
Even without globally-verifiable user certificates, it may be
possible to provide practical user authentication in many
cases by establishing a chain of trust, using the hop-by-hop
INTEGRITY mechanism described earlier.
o Secure data streams
The first two security issues concerned RSVP's operation. A
third security issue concerns resource reservations for
secure data streams. In particular, the use of IPSEC (IP
Security) in the data stream poses a problem for RSVP: if
the transport and higher level headers are encrypted, RSVP's
generalized port numbers cannot be used to define a session
or a sender.
To solve this problem, an RSVP extension has been defined in
which the security association identifier (IPSEC SPI) plays a
role roughly equivalent to the generalized ports [RFC2207].
2.9 Non-RSVP Clouds
It is impossible to deploy RSVP (or any new protocol) at the same
moment throughout the entire Internet. Furthermore, RSVP may
never be deployed everywhere. RSVP must therefore provide correct
protocol operation even when two RSVP-capable routers are joined
by an arbitrary "cloud" of non-RSVP routers. Of course, an
intermediate cloud that does not support RSVP is unable to perform
resource reservation. However, if such a cloud has sufficient
capacity, it may still provide useful realtime service.
RSVP is designed to operate correctly through such a non-RSVP
cloud. Both RSVP and non-RSVP routers forward Path messages
towards the destination address using their local uni-/multicast
routing table. Therefore, the routing of Path messages will be
unaffected by non-RSVP routers in the path. When a Path message
traverses a non-RSVP cloud, it carries to the next RSVP-capable
node the IP address of the last RSVP-capable router before
entering the cloud. An Resv message is then forwarded directly to
the next RSVP-capable router on the path(s) back towards the
source.
Even though RSVP operates correctly through a non-RSVP cloud, the
non-RSVP-capable nodes will in general perturb the QoS provided to
a receiver. Therefore, RSVP passes a `NonRSVP' flag bit to the
local traffic control mechanism when there are non-RSVP-capable
hops in the path to a given sender. Traffic control combines this
flag bit with its own sources of information, and forwards the
composed information on integrated service capability along the
path to receivers using Adspecs [RFC2210].
Some topologies of RSVP routers and non-RSVP routers can cause
Resv messages to arrive at the wrong RSVP-capable node, or to
arrive at the wrong interface of the correct node. An RSVP
process must be prepared to handle either situation. If the
destination address does not match any local interface and the
message is not a Path or PathTear, the message must be forwarded
without further processing by this node. To handle the wrong
interface case, a "Logical Interface Handle" (LIH) is used. The
previous hop information included in a Path message includes not
only the IP address of the previous node but also an LIH defining
the logical outgoing interface; both values are stored in the path
state. A Resv message arriving at the addressed node carries both
the IP address and the LIH of the correct outgoing interface, i.e,
the interface that should receive the requested reservation,
regardless of which interface it arrives on.
The LIH may also be useful when RSVP reservations are made over a
complex link layer, to map between IP layer and link layer flow
entities.
2.10 Host Model
Before a session can be created, the session identification
(DestAddress, ProtocolId [, DstPort]) must be assigned and
communicated to all the senders and receivers by some out-of-band
mechanism. When an RSVP session is being set up, the following
events happen at the end systems.
H1 A receiver joins the multicast group specified by
DestAddress, using IGMP.
H2 A potential sender starts sending RSVP Path messages to the
DestAddress.
H3 A receiver application receives a Path message.
H4 A receiver starts sending appropriate Resv messages,
specifying the desired flow descriptors.
H5 A sender application receives a Resv message.
H6 A sender starts sending data packets.
There are several synchronization considerations.
o H1 and H2 may happen in either order.
o Suppose that a new sender starts sending data (H6) but there
are no multicast routes because no receivers have joined the
group (H1). Then the data will be dropped at some router
node (which node depends upon the routing protocol) until
receivers(s) appear.
o Suppose that a new sender starts sending Path messages (H2)
and data (H6) simultaneously, and there are receivers but no
Resv messages have reached the sender yet (e.g., because its
Path messages have not yet propagated to the receiver(s)).
Then the initial data may arrive at receivers without the
desired QoS. The sender could mitigate this problem by
awaiting arrival of the first Resv message (H5); however,
receivers that are farther away may not have reservations in
place yet.
o If a receiver starts sending Resv messages (H4) before
receiving any Path messages (H3), RSVP will return error
messages to the receiver.
The receiver may simply choose to ignore such error messages,
or it may avoid them by waiting for Path messages before
sending Resv messages.
A specific application program interface (API) for RSVP is not
defined in this protocol spec, as it may be host system dependent.
However, Section 3.11.1 discusses the general requirements and
outlines a generic interface.
3. RSVP Functional Specification
3.1 RSVP Message Formats
An RSVP message consists of a common header, followed by a body
consisting of a variable number of variable-length, typed
"objects". The following subsections define the formats of the
common header, the standard object header, and each of the RSVP
message types.
For each RSVP message type, there is a set of rules for the
permissible choice of object types. These rules are specified
using Backus-Naur Form (BNF) augmented with square brackets
surrounding optional sub-sequences. The BNF implies an order for
the objects in a message. However, in many (but not all) cases,
object order makes no logical difference. An implementation
should create messages with the objects in the order shown here,
but accept the objects in any permissible order.
3.1.1 Common Header
0 1 2 3
+-------------+-------------+-------------+-------------+
| Vers | Flags| Msg Type | RSVP Checksum |
+-------------+-------------+-------------+-------------+
| Send_TTL | (Reserved) | RSVP Length |
+-------------+-------------+-------------+-------------+
The fields in the common header are as follows:
Vers: 4 bits
Protocol version number. This is version 1.
Flags: 4 bits
0x01-0x08: Reserved
No flag bits are defined yet.
Msg Type: 8 bits
1 = Path
2 = Resv
3 = PathErr
4 = ResvErr
5 = PathTear
6 = ResvTear
7 = ResvConf
RSVP Checksum: 16 bits
The one's complement of the one's complement sum of the
message, with the checksum field replaced by zero for the
purpose of computing the checksum. An all-zero value
means that no checksum was transmitted.
Send_TTL: 8 bits
The IP TTL value with which the message was sent. See
Section 3.8.
RSVP Length: 16 bits
The total length of this RSVP message in bytes, including
the common header and the variable-length objects that
follow.
3.1.2 Object Formats
Every object consists of one or more 32-bit words with a one-
word header, with the following format:
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| |
// (Object contents) //
| |
+-------------+-------------+-------------+-------------+
An object header has the following fields:
Length
A 16-bit field containing the total object length in
bytes. Must always be a multiple of 4, and at least 4.
Class-Num
Identifies the object class; values of this field are
defined in Appendix A. Each object class has a name,
which is always capitalized in this document. An RSVP
implementation must recognize the following classes:
NULL
A NULL object has a Class-Num of zero, and its C-Type
is ignored. Its length must be at least 4, but can
be any multiple of 4. A NULL object may appear
anywhere in a sequence of objects, and its contents
will be ignored by the receiver.
SESSION
Contains the IP destination address (DestAddress),
the IP protocol id, and some form of generalized
destination port, to define a specific session for
the other objects that follow. Required in every
RSVP message.
RSVP_HOP
Carries the IP address of the RSVP-capable node that
sent this message and a logical outgoing interface
handle (LIH; see Section 3.3). This document refers
to a RSVP_HOP object as a PHOP ("previous hop")
object for downstream messages or as a NHOP (" next
hop") object for upstream messages.
TIME_VALUES
Contains the value for the refresh period R used by
the creator of the message; see Section 3.7.
Required in every Path and Resv message.
STYLE
Defines the reservation style plus style-specific
information that is not in FLOWSPEC or FILTER_SPEC
objects. Required in every Resv message.
FLOWSPEC
Defines a desired QoS, in a Resv message.
FILTER_SPEC
Defines a subset of session data packets that should
receive the desired QoS (specified by a FLOWSPEC
object), in a Resv message.
SENDER_TEMPLATE
Contains a sender IP address and perhaps some
additional demultiplexing information to identify a
sender. Required in a Path message.
SENDER_TSPEC
Defines the traffic characteristics of a sender's
data flow. Required in a Path message.
ADSPEC
Carries OPWA data, in a Path message.
ERROR_SPEC
Specifies an error in a PathErr, ResvErr, or a
confirmation in a ResvConf message.
POLICY_DATA
Carries information that will allow a local policy
module to decide whether an associated reservation is
administratively permitted. May appear in Path,
Resv, PathErr, or ResvErr message.
The use of POLICY_DATA objects is not fully specified
at this time; a future document will fill this gap.
INTEGRITY
Carries cryptographic data to authenticate the
originating node and to verify the contents of this
RSVP message. The use of the INTEGRITY object is
described in [Baker96].
SCOPE
Carries an explicit list of sender hosts towards
which the information in the message is to be
forwarded. May appear in a Resv, ResvErr, or
ResvTear message. See Section 3.4.
RESV_CONFIRM
Carries the IP address of a receiver that requested a
confirmation. May appear in a Resv or ResvConf
message.
C-Type
Object type, unique within Class-Num. Values are defined
in Appendix A.
The maximum object content length is 65528 bytes. The Class-
Num and C-Type fields may be used together as a 16-bit number
to define a unique type for each object.
The high-order two bits of the Class-Num is used to determine
what action a node should take if it does not recognize the
Class-Num of an object; see Section 3.10.
3.1.3 Path Messages
Each sender host periodically sends a Path message for each
data flow it originates. It contains a SENDER_TEMPLATE object
defining the format of the data packets and a SENDER_TSPEC
object specifying the traffic characteristics of the flow.
Optionally, it may contain may be an ADSPEC object carrying
advertising (OPWA) data for the flow.
A Path message travels from a sender to receiver(s) along the
same path(s) used by the data packets. The IP source address
of a Path message must be an address of the sender it
describes, while the destination address must be the
DestAddress for the session. These addresses assure that the
message will be correctly routed through a non-RSVP cloud.
The format of a Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
If the INTEGRITY object is present, it must immediately follow
the common header. There are no other requirements on
transmission order, although the above order is recommended.
Any number of POLICY_DATA objects may appear.
The PHOP (i.e., RSVP_HOP) object of each Path message contains
the previous hop address, i.e., the IP address of the interface
through which the Path message was most recently sent. It also
carries a logical interface handle (LIH).
Each RSVP-capable node along the path(s) captures a Path
message and processes it to create path state for the sender
defined by the SENDER_TEMPLATE and SESSION objects. Any
POLICY_DATA, SENDER_TSPEC, and ADSPEC objects are also saved in
the path state. If an error is encountered while processing a
Path message, a PathErr message is sent to the originating
sender of the Path message. Path messages must satisfy the
rules on SrcPort and DstPort in Section 3.2.
Periodically, the RSVP process at a node scans the path state
to create new Path messages to forward towards the receiver(s).
Each message contains a sender descriptor defining one sender,
and carries the original sender's IP address as its IP source
address. Path messages eventually reach the applications on
all receivers; however, they are not looped back to a receiver
running in the same application process as the sender.
The RSVP process forwards Path messages and replicates them as
required by multicast sessions, using routing information it
obtains from the appropriate uni-/multicast routing process.
The route depends upon the session DestAddress, and for some
routing protocols also upon the source (sender's IP) address.
The routing information generally includes the list of zero or
more outgoing interfaces to which the Path message is to be
forwarded. Because each outgoing interface has a different IP
address, the Path messages sent out different interfaces
contain different PHOP addresses. In addition, ADSPEC objects
carried in Path messages will also generally differ for
different outgoing interfaces.
Path state for a given session and sender may not necessarily
have a unique PHOP or unique incoming interface. There are two
cases, corresponding to multicast and unicast sessions.
o Multicast Sessions
Multicast routing allows a stable distribution tree in
which Path messages from the same sender arrive from more
than one PHOP, and RSVP must be prepared to maintain all
such path state. The RSVP rules for handling this
situation are contained in Section 3.9. RSVP must not
forward (according to the rules of Section 3.9) Path
messages that arrive on an incoming interface different
from that provided by routing.
o Unicast Sessions
For a short period following a unicast route change
upstream, a node may receive Path messages from multiple
PHOPs for a given (session, sender) pair. The node cannot
reliably determine which is the right PHOP, although the
node will receive data from only one of the PHOPs at a
time. One implementation choice for RSVP is to ignore
PHOP in matching unicast past state, and allow the PHOP to
flip among the candidates. Another implementation choice
is to maintain path state for each PHOP and to send Resv
messages upstream towards all such PHOPs. In either case,
the situation is a transient; the unused path state will
time out or be torn down (because upstream path state
timed out).
3.1.4 Resv Messages
Resv messages carry reservation requests hop-by-hop from
receivers to senders, along the reverse paths of data flows for
the session. The IP destination address of a Resv message is
the unicast address of a previous-hop node, obtained from the
path state. The IP source address is an address of the node
that sent the message.
The Resv message format is as follows:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <empty> |
<flow descriptor list> <flow descriptor>
If the INTEGRITY object is present, it must immediately follow
the common header. The STYLE object followed by the flow
descriptor list must occur at the end of the message, and
objects within the flow descriptor list must follow the BNF
given below. There are no other requirements on transmission
order, although the above order is recommended.
The NHOP (i.e., the RSVP_HOP) object contains the IP address of
the interface through which the Resv message was sent and the
LIH for the logical interface on which the reservation is
required.
The appearance of a RESV_CONFIRM object signals a request for a
reservation confirmation and carries the IP address of the
receiver to which the ResvConf should be sent. Any number of
POLICY_DATA objects may appear.
The BNF above defines a flow descriptor list as simply a list
of flow descriptors. The following style-dependent rules
specify in more detail the composition of a valid flow
descriptor list for each of the reservation styles.
o WF Style:
<flow descriptor list> ::= <WF flow descriptor>
<WF flow descriptor> ::= <FLOWSPEC>
o FF style:
<flow descriptor list> ::=
<FLOWSPEC> <FILTER_SPEC> |
<flow descriptor list> <FF flow descriptor>
<FF flow descriptor> ::=
[ <FLOWSPEC> ] <FILTER_SPEC>
Each elementary FF style request is defined by a single
(FLOWSPEC, FILTER_SPEC) pair, and multiple such requests
may be packed into the flow descriptor list of a single
Resv message. A FLOWSPEC object can be omitted if it is
identical to the most recent such object that appeared in
the list; the first FF flow descriptor must contain a
FLOWSPEC.
o SE style:
<flow descriptor list> ::= <SE flow descriptor>
<SE flow descriptor> ::=
<FLOWSPEC> <filter spec list>
<filter spec list> ::= <FILTER_SPEC>
| <filter spec list> <FILTER_SPEC>
The reservation scope, i.e., the set of senders towards which a
particular reservation is to be forwarded (after merging), is
determined as follows:
o Explicit sender selection
The reservation is forwarded to all senders whose
SENDER_TEMPLATE objects recorded in the path state match a
FILTER_SPEC object in the reservation. This match must
follow the rules of Section 3.2.
o Wildcard sender selection
A request with wildcard sender selection will match all
senders that route to the given outgoing interface.
Whenever a Resv message with wildcard sender selection is
forwarded to more than one previous hop, a SCOPE object
must be included in the message (see Section 3.4 below);
in this case, the scope for forwarding the reservation is
constrained to just the sender IP addresses explicitly
listed in the SCOPE object.
A Resv message that is forwarded by a node is generally
the result of merging a set of incoming Resv messages
(that are not blockaded; see Section 3.5). If one of
these merged messages contains a RESV_CONFIRM object and
has a FLOWSPEC larger than the FLOWSPECs of the other
merged reservation requests, then this RESV_CONFIRM object
is forwarded in the outgoing Resv message. A RESV_CONFIRM
object in one of the other merged requests (whose
flowspecs are equal to, smaller than, or incomparable to,
the merged flowspec, and which is not blockaded) will
trigger the generation of an ResvConf message containing
the RESV_CONFIRM. A RESV_CONFIRM object in a request that
is blockaded will be neither forwarded nor returned; it
will be dropped in the current node.
3.1.5 Path Teardown Messages
Receipt of a PathTear (path teardown) message deletes matching
path state. Matching state must have match the SESSION,
SENDER_TEMPLATE, and PHOP objects. In addition, a PathTear
message for a multicast session can only match path state for
the incoming interface on which the PathTear arrived. If there
is no matching path state, a PathTear message should be
discarded and not forwarded.
PathTear messages are initiated explicitly by senders or by
path state timeout in any node, and they travel downstream
towards all receivers. A unicast PathTear must not be
forwarded if there is path state for the same (session, sender)
pair but a different PHOP. Forwarding of multicast PathTear
messages is governed by the rules of Section 3.9.
A PathTear message must be routed exactly like the
corresponding Path message. Therefore, its IP destination
address must be the session DestAddress, and its IP source
address must be the sender address from the path state being
torn down.
<PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
[ <sender descriptor> ]
<sender descriptor> ::= (see earlier definition)
A PathTear message may include a SENDER_TSPEC or ADSPEC object
in its sender descriptor, but these must be ignored. The order
requirements are as given earlier for a Path message, but the
above order is recommended.
Deletion of path state as the result of a PathTear message or a
timeout must also adjust related reservation state as required
to maintain consistency in the local node. The adjustment
depends upon the reservation style. For example, suppose a
PathTear deletes the path state for a sender S. If the style
specifies explicit sender selection (FF or SE), any reservation
with a filter spec matching S should be deleted; if the style
has wildcard sender selection (WF), the reservation should be
deleted if S is the last sender to the session. These
reservation changes should not trigger an immediate Resv
refresh message, since the PathTear message has already made
the required changes upstream. They should not trigger a
ResvErr message, since the result could be to generate a shower
of such messages.
3.1.6 Resv Teardown Messages
Receipt of a ResvTear (reservation teardown) message deletes
matching reservation state. Matching reservation state must
match the SESSION, STYLE, and FILTER_SPEC objects as well as
the LIH in the RSVP_HOP object. If there is no matching
reservation state, a ResvTear message should be discarded. A
ResvTear message may tear down any subset of the filter specs
in FF-style or SE-style reservation state.
ResvTear messages are initiated explicitly by receivers or by
any node in which reservation state has timed out, and they
travel upstream towards all matching senders.
A ResvTear message must be routed like the corresponding Resv
message, and its IP destination address will be the unicast
address of a previous hop.
<ResvTear Message> ::= <Common Header> [<INTEGRITY>]
<SESSION> <RSVP_HOP>
[ <SCOPE> ] <STYLE>
<flow descriptor list>
<flow descriptor list> ::= (see earlier definition)
FLOWSPEC objects in the flow descriptor list of a ResvTear
message will be ignored and may be omitted. The order
requirements for INTEGRITY object, sender descriptor, STYLE
object, and flow descriptor list are as given earlier for a
Resv message, but the above order is recommended. A ResvTear
message may include a SCOPE object, but it must be ignored.
A ResvTear message will cease to be forwarded at the node where
merging would have suppressed forwarding of the corresponding
Resv message. Depending upon the resulting state change in a
node, receipt of a ResvTear message may cause a ResvTear
message to be forwarded, a modified Resv message to be
forwarded, or no message to be forwarded. These three cases
can be illustrated in the case of the FF-style reservations
shown in Figure 6.
o If receiver R2 sends a ResvTear message for its
reservation S3{B}, the corresponding reservation is
removed from interface (d) and a ResvTear for S3{B} is
forwarded out (b).
o If receiver R1 sends a ResvTear for its reservation
S1{4B}, the corresponding reservation is removed from
interface (c) and a modified Resv message FF( S1{3B} ) is
immediately forwarded out (a).
o If receiver R3 sends a ResvTear message for S1{B}, there
is no change in the effective reservation S1{3B} on (d)
and no message is forwarded.
3.1.7 Path Error Messages
PathErr (path error) messages report errors in processing Path
messages. They are travel upstream towards senders and are
routed hop-by-hop using the path state. At each hop, the IP
destination address is the unicast address of a previous hop.
PathErr messages do not modify the state of any node through
which they pass; they are only reported to the sender
application.
<PathErr message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC>
[ <POLICY_DATA> ...]
[ <sender descriptor> ]
<sender descriptor> ::= (see earlier definition)
The ERROR_SPEC object specifies the error and includes the IP
address of the node that detected the error (Error Node
Address). One or more POLICY_DATA objects may be included
message to provide relevant information. The sender descriptor
is copied from the message in error. The object order
requirements are as given earlier for a Path message, but the
above order is recommended.
3.1.8 Resv Error Messages
ResvErr (reservation error) messages report errors in
processing Resv messages, or they may report the spontaneous
disruption of a reservation, e.g., by administrative
preemption.
ResvErr messages travel downstream towards the appropriate
receivers, routed hop-by-hop using the reservation state. At
each hop, the IP destination address is the unicast address of
a next-hop node.
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ]
[ <POLICY_DATA> ...]
<STYLE> [ <error flow descriptor> ]
The ERROR_SPEC object specifies the error and includes the IP
address of the node that detected the error (Error Node
Address). One or more POLICY_DATA objects may be included in
an error message to provide relevant information (e.g.,, when a
policy control error is being reported). The RSVP_HOP object
contains the previous hop address, and the STYLE object is
copied from the Resv message in error. The use of the SCOPE
object in a ResvErr message is defined below in Section 3.4.
The object order requirements are as given for Resv messages,
but the above order is recommended.
The following style-dependent rules define the composition of a
valid error flow descriptor; the object order requirements are
as given earlier for flow descriptor.
o WF Style:
<error flow descriptor> ::= <WF flow descriptor>
o FF style:
<error flow descriptor> ::= <FF flow descriptor>
Each flow descriptor in a FF-style Resv message must be
processed independently, and a separate ResvErr message
must be generated for each one that is in error.
o SE style:
<error flow descriptor> ::= <SE flow descriptor>
An SE-style ResvErr message may list the subset of the
filter specs in the corresponding Resv message to which
the error applies.
Note that a ResvErr message contains only one flow descriptor.
Therefore, a Resv message that contains N > 1 flow descriptors
(FF style) may create up to N separate ResvErr messages.
Generally speaking, a ResvErr message should be forwarded
towards all receivers that may have caused the error being
reported. More specifically:
o The node that detects an error in a reservation request
sends a ResvErr message to the next hop node from which
the erroneous reservation came.
This ResvErr message must contain the information required
to define the error and to route the error message in
later hops. It therefore includes an ERROR_SPEC object, a
copy of the STYLE object, and the appropriate error flow
descriptor. If the error is an admission control failure
while attempting to increase an existing reservation, then
the existing reservation must be left in place and the
InPlace flag bit must be on in the ERROR_SPEC of the
ResvErr message.
o Succeeding nodes forward the ResvErr message to next hops
that have local reservation state. For reservations with
wildcard scope, there is an additional limitation on
forwarding ResvErr messages, to avoid loops; see Section
3.4. There is also a rule restricting the forwarding of a
Resv message after an Admission Control failure; see
Section 3.5.
A ResvErr message that is forwarded should carry the
FILTER_SPEC(s) from the corresponding reservation state.
o When a ResvErr message reaches a receiver, the STYLE
object, flow descriptor list, and ERROR_SPEC object
(including its flags) should be delivered to the receiver
application.
3.1.9 Confirmation Messages
ResvConf messages are sent to (probabilistically) acknowledge
reservation requests. A ResvConf message is sent as the result
of the appearance of a RESV_CONFIRM object in a Resv message.
A ResvConf message is sent to the unicast address of a receiver
host; the address is obtained from the RESV_CONFIRM object.
However, a ResvConf message is forwarded to the receiver hop-
by-hop, to accommodate the hop-by-hop integrity check
mechanism.
<ResvConf message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC>
<RESV_CONFIRM>
<STYLE> <flow descriptor list>
<flow descriptor list> ::= (see earlier definition)
The object order requirements are the same as those given
earlier for a Resv message, but the above order is recommended.
The RESV_CONFIRM object is a copy of that object in the Resv
message that triggered the confirmation. The ERROR_SPEC is
used only to carry the IP address of the originating node, in
the Error Node Address; the Error Code and Value are zero to
indicate a confirmation. The flow descriptor list specifies
the particular reservations that are being confirmed; it may be
a subset of flow descriptor list of the Resv that requested the
confirmation.
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 [RFC2113] 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