+-------------+-------------+-------------+-------------+
SrcAddress
The IP source address for a sender host. Must be non-zero.
SrcPort
The UDP/TCP source port for a sender, or zero to indicate
`none'.
Flow Label
A 24-bit Flow Label, defined in IPv6. This value may be used
by the packet classifier to efficiently identify the packets
belonging to a particular (sender->destination) data flow.
A.10 SENDER_TEMPLATE Class
SENDER_TEMPLATE class = 11.
o IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 1
Definition same as IPv4/UDP FILTER_SPEC object.
o IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 2
Definition same as IPv6/UDP FILTER_SPEC object.
o IPv6 Flow-label SENDER_TEMPLATE object: Class = 11, C-Type =
3
A.11 SENDER_TSPEC Class
SENDER_TSPEC class = 12.
o Intserv SENDER_TSPEC object: Class = 12, C-Type = 2
The contents and encoding rules for this object are specified
in documents prepared by the int-serv working group.
A.12 ADSPEC Class
ADSPEC class = 13.
o Intserv ADSPEC object: Class = 13, C-Type = 2
The contents and format for this object are specified in
documents prepared by the int-serv working group.
A.13 POLICY_DATA Class
POLICY_DATA class = 14.
o Type 1 POLICY_DATA object: Class = 14, C-Type = 1
The contents of this object are for further study.
A.14 Resv_CONFIRM Class
RESV_CONFIRM class = 15.
o IPv4 RESV_CONFIRM object: Class = 15, C-Type = 1
+-------------+-------------+-------------+-------------+
| IPv4 Receiver Address (4 bytes) |
+-------------+-------------+-------------+-------------+
o IPv6 RESV_CONFIRM object: Class = 15, C-Type = 2
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Receiver Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
APPENDIX B. Error Codes and Values
The following Error Codes may appear in ERROR_SPEC objects and be
passed to end systems. Except where noted, these Error Codes may
appear only in ResvErr messages.
o Error Code = 00: Confirmation
This code is reserved for use in the ERROR_SPEC object of a
ResvConf message. The Error Value will also be zero.
o Error Code = 01: Admission Control failure
Reservation request was rejected by Admission Control due to
unavailable resources.
For this Error Code, the 16 bits of the Error Value field are:
ssur cccc cccc cccc
where the bits are:
ss = 00: Low order 12 bits contain a globally-defined sub-code
(values listed below).
ss = 10: Low order 12 bits contain a organization-specific sub-
code. RSVP is not expected to be able to interpret this
except as a numeric value.
ss = 11: Low order 12 bits contain a service-specific sub-code.
RSVP is not expected to be able to interpret this except as
a numeric value.
Since the traffic control mechanism might substitute a
different service, this encoding may include some
representation of the service in use.
u = 0: RSVP rejects the message without updating local
state.
u = 1: RSVP may use message to update local state and forward
the message. This means that the message is informational.
r: Reserved bit, should be zero.
cccc cccc cccc: 12 bit code.
The following globally-defined sub-codes may appear in the low-
order 12 bits when ssur = 0000:
- Sub-code = 1: Delay bound cannot be met
- Sub-code = 2: Requested bandwidth unavailable
- Sub-code = 3: MTU in flowspec larger than interface MTU.
o Error Code = 02: Policy Control failure
Reservation or path message has been rejected for administrative
reasons, for example, required credentials not submitted,
insufficient quota or balance, or administrative preemption.
This Error Code may appear in a PathErr or ResvErr message.
Contents of the Error Value field are to be determined in the
future.
o Error Code = 03: No path information for this Resv message.
No path state for this session. Resv message cannot be
forwarded.
o Error Code = 04: No sender information for this Resv message.
There is path state for this session, but it does not include
the sender matching some flow descriptor contained in the Resv
message. Resv message cannot be forwarded.
o Error Code = 05: Conflicting reservation style
Reservation style conflicts with style(s) of existing
reservation state. The Error Value field contains the low-order
16 bits of the Option Vector of the existing style with which
the conflict occurred. This Resv message cannot be forwarded.
o Error Code = 06: Unknown reservation style
Reservation style is unknown. This Resv message cannot be
forwarded.
o Error Code = 07: Conflicting dest ports
Sessions for same destination address and protocol have appeared
with both zero and non-zero dest port fields. This Error Code
may appear in a PathErr or ResvErr message.
o Error Code = 08: Conflicting sender ports
Sender port is both zero and non-zero in Path messages for the
same session. This Error Code may appear only in a PathErr
message.
o Error Code = 09, 10, 11: (reserved)
o Error Code = 12: Service preempted
The service request defined by the STYLE object and the flow
descriptor has been administratively preempted.
For this Error Code, the 16 bits of the Error Value field are:
ssur cccc cccc cccc
Here the high-order bits ssur are as defined under Error Code
01. The globally-defined sub-codes that may appear in the low-
order 12 bits when ssur = 0000 are to be defined in the future.
o Error Code = 13: Unknown object class
Error Value contains 16-bit value composed of (Class-Num, C-
Type) of unknown object. This error should be sent only if RSVP
is going to reject the message, as determined by the high-order
bits of the Class-Num. This Error Code may appear in a PathErr
or ResvErr message.
o Error Code = 14: Unknown object C-Type
Error Value contains 16-bit value composed of (Class-Num, C-
Type) of object.
o Error Code = 15-19: (reserved)
o Error Code = 20: Reserved for API
Error Value field contains an API error code, for an API error
that was detected asynchronously and must be reported via an
upcall.
o Error Code = 21: Traffic Control Error
Traffic Control call failed due to the format or contents of the
parameters to the request. The Resv or Path message that caused
the call cannot be forwarded, and repeating the call would be
futile.
For this Error Code, the 16 bits of the Error Value field are:
ss00 cccc cccc cccc
Here the high-order bits ss are as defined under Error Code 01.
The following globally-defined sub-codes may appear in the low
order 12 bits (cccc cccc cccc) when ss = 00:
- Sub-code = 01: Service conflict
Trying to merge two incompatible service requests.
- Sub-code = 02: Service unsupported
Traffic control can provide neither the requested service
nor an acceptable replacement.
- Sub-code = 03: Bad Flowspec value
Malformed or unreasonable request.
- Sub-code = 04: Bad Tspec value
Malformed or unreasonable request.
- Sub-code = 05: Bad Adspec value
Malformed or unreasonable request.
o Error Code = 22: Traffic Control System error
A system error was detected and reported by the traffic control
modules. The Error Value will contain a system-specific value
giving more information about the error. RSVP is not expected
to be able to interpret this value.
o Error Code = 23: RSVP System error
The Error Value field will provide implementation-dependent
information on the error. RSVP is not expected to be able to
interpret this value.
In general, every RSVP message is rebuilt at each hop, and the node
that creates an RSVP message is responsible for its correct
construction. Similarly, each node is required to verify the correct
construction of each RSVP message it receives. Should a programming
error allow an RSVP to create a malformed message, the error is not
generally reported to end systems in an ERROR_SPEC object; instead,
the error is simply logged locally, and perhaps reported through
network management mechanisms.
The only message formatting errors that are reported to end systems
are those that may reflect version mismatches, and which the end
system might be able to circumvent, e.g., by falling back to a
previous CType for an object; see code 13 and 14 above.
The choice of message formatting errors that an RSVP may detect and
log locally is implementation-specific, but it will typically include
the following:
o Wrong-length message: RSVP Length field does not match message
length.
o Unknown or unsupported RSVP version.
o Bad RSVP checksum
o INTEGRITY failure
o Illegal RSVP message Type
o Illegal object length: not a multiple of 4, or less than 4.
o Next hop/Previous hop address in HOP object is illegal.
o Bad source port: Source port is non-zero in a filter spec or
sender template for a session with destination port zero.
o Required object class (specify) missing
o Illegal object class (specify) in this message type.
o Violation of required object order
o Flow descriptor count wrong for style or message type
o Logical Interface Handle invalid
o Unknown object Class-Num.
o Destination address of ResvConf message does not match Receiver
Address in the RESV_CONFIRM object it contains.
APPENDIX C. UDP Encapsulation
An RSVP implementation will generally require the ability to perform
"raw" network I/O, i.e., to send and receive IP datagrams using
protocol 46. However, some important classes of host systems may not
support raw network I/O. To use RSVP, such hosts must encapsulate
RSVP messages in UDP.
The basic UDP encapsulation scheme makes two assumptions:
1. All hosts are capable of sending and receiving multicast packets
if multicast destinations are to be supported.
2. The first/last-hop routers are RSVP-capable.
A method of relaxing the second assumption is given later.
Let Hu be a "UDP-only" host that requires UDP encapsulation, and Hr a
host that can do raw network I/O. The UDP encapsulation scheme must
allow RSVP interoperation among an arbitrary topology of Hr hosts, Hu
hosts, and routers.
Resv, ResvErr, ResvTear, and PathErr messages are sent to unicast
addresses learned from the path or reservation state in the node. If
the node keeps track of which previous hops and which interfaces need
UDP encapsulation, these messages can be sent using UDP encapsulation
when necessary. On the other hand, Path and PathTear messages are
sent to the destination address for the session, which may be unicast
or multicast.
The tables in Figures 13 and 14 show the basic rules for UDP
encapsulation of Path and PathTear messages, for unicast DestAddress
and multicast DestAddress, respectively. The other message types,
which are sent unicast, should follow the unicast rules in Figure 13.
Under the `RSVP Send' columns in these figures, the notation is
`mode(destaddr, destport)'; destport is omitted for raw packets. The
`Receive' columns show the group that is joined and, where relevant,
the UDP Listen port.
It is useful to define two flavors of UDP encapsulation, one to be
sent by Hu and the other to be sent by Hr and R, to avoid double
processing by the recipient. In practice, these two flavors are
distinguished by differing UDP port numbers Pu and Pu'.
The following symbols are used in the tables.
o D is the DestAddress for the particular session.
o G* is a well-known group address of the form 224.0.0.14, i.e., a
group that is limited to the local connected network.
o Pu and Pu' are two well-known UDP ports for UDP encapsulation of
RSVP, with values 1698 and 1699.
o Ra is the IP address of the router interface `a'.
o Router interface `a' is on the local network connected to Hu and
Hr.
o
The following notes apply to these figures:
[Note 1] Hu sends a unicast Path message either to the destination
address D, if D is local, or to the address Ra of the first-hop
router. Ra is presumably known to the host.
[Note 2] Here D is the address of the local interface through
which the message arrived.
[Note 3] This assumes that the application has joined the group D.
UNICAST DESTINATION D:
RSVP RSVP
Node Send Receive
___ _____________ _______________
Hu UDP(D/Ra,Pu) UDP(D,Pu)
[Note 1] and UDP(D,Pu')
[Note 2]
Hr Raw(D) Raw()
and if (UDP) and UDP(D, Pu)
then UDP(D,Pu') [Note 2]
(Ignore Pu')
R (Interface a):
Raw(D) Raw()
and if (UDP) and UDP(Ra, Pu)
then UDP(D,Pu') (Ignore Pu')
Figure 13: UDP Encapsulation Rules for Unicast Path and Resv Messages
MULTICAST DESTINATION D:
RSVP RSVP
Node Send Receive
___ _____________ _________________
Hu UDP(G*,Pu) UDP(D,Pu')
[Note 3]
and UDP(G*,Pu)
Hr Raw(D,Tr) Raw()
and if (UDP) and UDP(G*,Pu)
then UDP(D,Pu') (Ignore Pu')
R (Interface a):
Raw(D,Tr) Raw()
and if (UDP) and UDP(G*,Pu)
then UDP(D,Pu') (Ignore Pu')
Figure 14: UDP Encapsulation Rules for Multicast Path Messages
A router may determine if its interface X needs UDP encapsulation by
listening for UDP-encapsulated Path messages that were sent to either
G* (multicast D) or to the address of interface X (unicast D). There
is one failure mode for this scheme: if no host on the connected
network acts as an RSVP sender, there will be no Path messages to
trigger UDP encapsulation. In this (unlikely) case, it will be
necessary to explicitly configure UDP encapsulation on the local
network interface of the router.
When a UDP-encapsulated packet is received, the IP TTL is not
available to the application on most systems. The RSVP process that
receives a UDP-encapsulated Path or PathTear message should therefore
use the Send_TTL field of the RSVP common header as the effective
receive TTL. This may be overridden by manual configuration.
We have assumed that the first-hop RSVP-capable router R is on the
directly-connected network. There are several possible approaches if
this is not the case.
1. Hu can send both unicast and multicast sessions to UDP(Ra,Pu)
with TTL=Ta
Here Ta must be the TTL to exactly reach R. If Ta is too small,
the Path message will not reach R. If Ta is too large, R and
succeeding routers may forward the UDP packet until its hop
count expires. This will turn on UDP encapsulation between
routers within the Internet, perhaps causing bogus UDP traffic.
The host Hu must be explicitly configured with Ra and Ta.
2. A particular host on the LAN connected to Hu could be designated
as an "RSVP relay host". A relay host would listen on (G*,Pu)
and forward any Path messages directly to R, although it would
not be in the data path. The relay host would have to be
configured with Ra and Ta.
APPENDIX D. Glossary
o Admission control
A traffic control function that decides whether the packet
scheduler in the node can supply the requested QoS while
continuing to provide the QoS requested by previously-admitted
requests. See also "policy control" and "traffic control".
o Adspec
An Adspec is a data element (object) in a Path message that
carries a package of OPWA advertising information. See "OPWA".
o Auto-refresh loop
An auto-refresh loop is an error condition that occurs when a
topological loop of routers continues to refresh existing
reservation state even though all receivers have stopped
requesting these reservations. See section 3.4 for more
information.
o Blockade state
Blockade state helps to solve a "killer reservation" problem.
See sections 2.5 and 3.5, and "killer reservation".
o Branch policing
Traffic policing at a multicast branching point on an outgoing
interface that has "less" resources reserved than another
outgoing interface for the same flow. See "traffic policing".
o C-Type
The class type of an object; unique within class-name. See
"class-name".
o Class-name
The class of an object. See "object".
o DestAddress
The IP destination address; part of session identification. See
"session".
o Distinct style
A (reservation) style attribute; separate resources are reserved
for each different sender. See also "shared style".
o Downstream
Towards the data receiver(s).
o DstPort
The IP (generalized) destination port used as part of a session.
See "generalized destination port".
o Entry policing
Traffic policing done at the first RSVP- (and policing-) capable
router on a data path.
o ERROR_SPEC
Object that carries the error report in a PathErr or ResvErr
message.
o Explicit sender selection
A (reservation) style attribute; all reserved senders are to be
listed explicitly in the reservation message. See also
"wildcard sender selection".
o FF style
Fixed Filter reservation style, which has explicit sender
selection and distinct attributes.
o FilterSpec
Together with the session information, defines the set of data
packets to receive the QoS specified in a flowspec. The
filterspec is used to set parameters in the packet classifier
function. A filterspec may be carried in a FILTER_SPEC or
SENDER_TEMPLATE object.
o Flow descriptor
The combination of a flowspec and a filterspec.
o Flowspec
Defines the QoS to be provided for a flow. The flowspec is used
to set parameters in the packet scheduling function to provide
the requested quality of service. A flowspec is carried in a
FLOWSPEC object. The flowspec format is opaque to RSVP and is
defined by the Integrated Services Working Group.
o Generalized destination port
The component of a session definition that provides further
transport or application protocol layer demultiplexing beyond
DestAddress. See "session".
o Generalized source port
The component of a filter spec that provides further transport
or application protocol layer demultiplexing beyond the sender
address.
o GLB
Greatest Lower Bound
o Incoming interface
The interface on which data packets are expected to arrive, and
on which Resv messages are sent.
o INTEGRITY
Object of an RSVP control message that contains cryptographic
data to authenticate the originating node and to verify the
contents of an RSVP message.
o Killer reservation problem
The killer reservation problem describes a case where a receiver
attempting and failing to make a large QoS reservation prevents
smaller QoS reservations from being established. See Sections
2.5 and 3.5 for more information.
o LIH
The LIH (Logical Interface Handle) is used to help deal with
non-RSVP clouds. See Section 2.9 for more information.
o Local repair
Allows RSVP to rapidly adapt its reservations to changes in
routing. See Section 3.6 for more information.
o LPM
Local Policy Module. the function that exerts policy control.
o LUB
Least Upper Bound.
o Merge policing
Traffic policing that takes place at data merge point of a
shared reservation.
o Merging
The process of taking the maximum (or more generally the least
upper bound) of the reservations arriving on outgoing
interfaces, and forwarding this maximum on the incoming
interface. See Section 2.2 for more information.
o MTU
Maximum Transmission Unit.
o Next hop
The next router in the direction of traffic flow.
o NHOP
An object that carries the Next Hop information in RSVP control
messages.
o Node
A router or host system.
o Non-RSVP clouds
Groups of hosts and routers that do not run RSVP. Dealing with
nodes that do not support RSVP is important for backwards
compatibility. See section 2.9.
o Object
An element of an RSVP control message; a type, length, value
triplet.
o OPWA
Abbreviation for "One Pass With Advertising". Describes a
reservation setup model in which (Path) messages sent downstream
gather information that the receiver(s) can use to predict the
end-to-end service. The information that is gathered is called
an advertisement. See also "Adspec".
o Outgoing interface
Interface through which data packets and Path messages are
forwarded.
o Packet classifier
Traffic control function in the primary data packet forwarding
path that selects a service class for each packet, in accordance
with the reservation state set up by RSVP. The packet
classifier may be combined with the routing function. See also
"traffic control".
o Packet scheduler
Traffic control function in the primary data packet forwarding
path that implements QoS for each flow, using one of the service
models defined by the Integrated Services Working Group. See
also " traffic control".
o Path state
Information kept in routers and hosts about all RSVP senders.
o PathErr
Path Error RSVP control message.
o PathTear
Path Teardown RSVP control message.
o PHOP
An object that carries the Previous Hop information in RSVP
control messages.
o Police
See traffic policing.
o Policy control
A function that determines whether a new request for quality of
service has administrative permission to make the requested
reservation. Policy control may also perform accounting (usage
feedback) for a reservation.
o Policy data
Data carried in a Path or Resv message and used as input to
policy control to determine authorization and/or usage feedback
for the given flow.
o Previous hop
The previous router in the direction of traffic flow. Resv
messages flow towards previous hops.
o ProtocolId
The component of session identification that specifies the IP
protocol number used by the data stream.
o QoS
Quality of Service.
o Reservation state
Information kept in RSVP-capable nodes about successful RSVP
reservation requests.
o Reservation style
Describes a set of attributes for a reservation, including the
sharing attributes and sender selection attributes. See Section
1.3 for details.
o Resv message
Reservation request RSVP control message.
o ResvConf
Reservation Confirmation RSVP control message, confirms
successful installation of a reservation at some upstream node.
o ResvErr
Reservation Error control message, indicates that a reservation
request has failed or an active reservation has been preempted.
o ResvTear
Reservation Teardown RSVP control message, deletes reservation
state.
o Rspec
The component of a flowspec that defines a desired QoS. The
Rspec format is opaque to RSVP and is defined by the Integrated
Services Working Group of the IETF.
o RSVP_HOP
Object of an RSVP control message that carries the PHOP or NHOP
address of the source of the message.
o Scope
The set of sender hosts to which a given reservation request is
to be propagated.
o SE style
Shared Explicit reservation style, which has explicit sender
selection and shared attributes.
o Semantic fragmentation
A method of fragmenting a large RSVP message using information
about the structure and contents of the message, so that each
fragment is a logically complete RSVP message.
o Sender template
Parameter in a Path message that defines a sender; carried in a
SENDER_TEMPLATE object. It has the form of a filter spec that
can be used to select this sender's packets from other packets
in the same session on the same link.
o Sender Tspec
Parameter in a Path message, a Tspec that characterizes the
traffic parameters for the data flow from the corresponding
sender. It is carried in a SENDER_TSPEC object.
o Session
An RSVP session defines one simplex unicast or multicast data
flow for which reservations are required. A session is
identified by the destination address, transport-layer protocol,
and an optional (generalized) destination port.
o Shared style
A (reservation) style attribute: all reserved senders share the
same reserved resources. See also "distinct style".
o Soft state
Control state in hosts and routers that will expire if not
refreshed within a specified amount of time.
o STYLE
Object of an RSVP message that specifies the desired reservation
style.
o Style
See "reservation style"
o TIME_VALUES
Object in an RSVP control message that specifies the time period
timer used for refreshing the state in this message.
o Traffic control
The entire set of machinery in the node that supplies requested
QoS to data streams. Traffic control includes packet
classifier, packet scheduler, and admission control functions.
o Traffic policing
The function, performed by traffic control, of forcing a given
data flow into compliance with the traffic parameters implied by
the reservation. It may involve dropping non-compliant packets
or sending them with lower priority, for example.
o TSpec
A traffic parameter set that describes a flow. The format of a
Tspec is opaque to RSVP and is defined by the Integrated Service
Working Group.
o UDP encapsulation
A way for hosts that cannot use raw sockets to participate in
RSVP by encapsulating the RSVP protocol (raw) packets in
ordinary UDP packets. See Section APPENDIX C for more
information.
o Upstream
Towards the traffic source. RSVP Resv messages flow upstream.
o WF style
Wildcard Filter reservation style, which has wildcard sender
selection and shared attributes.
o Wildcard sender selection
A (reservation) style attribute: traffic from any sender to a
specific session receives the same QoS. See also "explicit
sender selection".
References
[Baker96] Baker, F., "RSVP Cryptographic Authentication", Work in
Progress.
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services
in the Internet Architecture: an Overview", RFC1633, ISI, MIT, and
PARC, June 1994.
[FJ94] Floyd, S. and V. Jacobson, "Synchronization of Periodic Routing
Messages", IEEE/ACM Transactions on Networking, Vol. 2, No. 2,
April, 1994.
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
Flows", RFC2207, September 1997.
[RFC2113] Katz, D., "IP Router Alert Option", RFC2113, cisco Systems,
February 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with Integrated Services",
RFC2210, September 1997.
[PolArch96] Herzog, S., "Policy Control for RSVP: Architectural
Overview". Work in Progress.
[OPWA95] Shenker, S. and L. Breslau, "Two Issues in Reservation
Establishment", Proc. ACM SIGCOMM '95, Cambridge, MA, August 1995.
[RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D.
Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network,
September 1993.
Security Considerations
See Section 2.8.
Authors' Addresses
Bob Braden
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: (310) 822-1511
EMail: Braden@ISI.EDU
Lixia Zhang
UCLA Computer Science Department
4531G Boelter Hall
Los Angeles, CA 90095-1596 USA
Phone: 310-825-2695
EMail: lixia@cs.ucla.edu
Steve Berson
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: (310) 822-1511
EMail: Berson@ISI.EDU
Shai Herzog
IBM T. J. Watson Research Center
P.O Box 704
Yorktown Heights, NY 10598
Phone: (914) 784-6059
EMail: Herzog@WATSON.IBM.COM
Sugih Jamin
University of Michigan
CSE/EECS
1301 Beal Ave.
Ann Arbor, MI 48109-2122
Phone: (313) 763-1583
EMail: jamin@EECS.UMICH.EDU