RFC 2205
Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
Pages: 112
Proposed Standard
→ Errata
Updated by: 2750 3936 4495 5946 6437 6780
Proposed Standard
→ Errata
Updated by: 2750 3936 4495 5946 6437 6780
Part 4 of 4 – Pages 77 to 112
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) | +-------------+-------------+-------------+-------------+ 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. [RFC 1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, 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. [RFC 2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997. [RFC 2113] Katz, D., "IP Router Alert Option", RFC 2113, cisco Systems, February 1997. [RFC 2210] Wroclawski, J., "The Use of RSVP with Integrated Services", RFC 2210, 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