draft-ietf-rsvp-spec-15.txt   rfc2205.txt 
Internet Draft R. Braden, Ed. Network Working Group R. Braden, Ed.
Expiration: November 1997 ISI Request for Comments: 2205 ISI
File: draft-ietf-rsvp-spec-15.txt L. Zhang Category: Standards Track L. Zhang
PARC UCLA
S. Berson S. Berson
ISI ISI
S. Herzog S. Herzog
IBM Research IBM Research
S. Jamin S. Jamin
Univ. of Michigan Univ. of Michigan
September 1997
Resource ReSerVation Protocol (RSVP) -- Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification Version 1 Functional Specification
May 27, 1997 Status of this Memo
Status of Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the This document specifies an Internet standards track protocol for the
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Internet community, and requests discussion and suggestions for
Directories on ds.internic.net (US East Coast), nic.nordu.net improvements. Please refer to the current edition of the "Internet
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Official Protocol Standards" (STD 1) for the standardization state
Rim). and status of this protocol. Distribution of this memo is unlimited.
Abstract Abstract
This memo describes version 1 of RSVP, a resource reservation setup This memo describes version 1 of RSVP, a resource reservation setup
protocol designed for an integrated services Internet. RSVP provides protocol designed for an integrated services Internet. RSVP provides
receiver-initiated setup of resource reservations for multicast or receiver-initiated setup of resource reservations for multicast or
unicast data flows, with good scaling and robustness properties. unicast data flows, with good scaling and robustness properties.
Table of Contents Table of Contents
1. Introduction ........................................................4 1. Introduction ................................................... 4
1.1 Data Flows ......................................................7 1.1 Data Flows ................................................. 7
1.2 Reservation Model ...............................................8 1.2 Reservation Model .......................................... 8
1.3 Reservation Styles ..............................................11 1.3 Reservation Styles .........................................11
1.4 Examples of Styles ..............................................14 1.4 Examples of Styles .........................................14
2. RSVP Protocol Mechanisms ............................................19 2. RSVP Protocol Mechanisms .......................................19
2.1 RSVP Messages ...................................................19 2.1 RSVP Messages ..............................................19
2.2 Merging Flowspecs ...............................................21 2.2 Merging Flowspecs ..........................................21
2.3 Soft State ......................................................22 2.3 Soft State .................................................22
2.4 Teardown ........................................................24 2.4 Teardown ...................................................24
2.5 Errors ..........................................................25 2.5 Errors .....................................................25
2.6 Confirmation ....................................................27 2.6 Confirmation ...............................................27
2.7 Policy Control ..................................................27 2.7 Policy Control .............................................27
2.8 Security ........................................................28 2.8 Security ...................................................28
2.9 Non-RSVP Clouds .................................................29 2.9 Non-RSVP Clouds ............................................29
2.10 Host Model .....................................................30 2.10 Host Model ................................................30
3. RSVP Functional Specification .......................................32 3. RSVP Functional Specification ..................................32
3.1 RSVP Message Formats ............................................32 3.1 RSVP Message Formats .......................................32
3.2 Port Usage ......................................................46 3.2 Port Usage .................................................47
3.3 Sending RSVP Messages ...........................................47 3.3 Sending RSVP Messages ......................................48
3.4 Avoiding RSVP Message Loops .....................................49 3.4 Avoiding RSVP Message Loops ................................50
3.5 Blockade State ..................................................53 3.5 Blockade State .............................................54
3.6 Local Repair ....................................................55 3.6 Local Repair ...............................................56
3.7 Time Parameters .................................................56 3.7 Time Parameters ............................................57
3.8 Traffic Policing and Non-Integrated Service Hops ................57 3.8 Traffic Policing and Non-Integrated Service Hops ...........58
3.9 Multihomed Hosts ................................................58 3.9 Multihomed Hosts ...........................................59
3.10 Future Compatibility ...........................................60 3.10 Future Compatibility ......................................61
3.11 RSVP Interfaces ................................................62 3.11 RSVP Interfaces ...........................................63
APPENDIX A. Object Definitions .........................................75 4. Acknowledgments ................................................76
APPENDIX B. Error Codes and Values .....................................90 APPENDIX A. Object Definitions ....................................77
APPENDIX C. UDP Encapsulation ..........................................95 APPENDIX B. Error Codes and Values ................................92
APPENDIX D. Glossary ...................................................99 APPENDIX C. UDP Encapsulation .....................................98
APPENDIX D. Glossary .............................................102
REFERENCES .......................................................111
SECURITY CONSIDERATIONS ..........................................111
AUTHORS' ADDRESSES ...............................................112
What's Changed What's Changed
This revision contains the following very minor changes from the ID14 This revision contains the following very minor changes from the ID14
version. version.
o For clarity, each message type is now defined separately in o For clarity, each message type is now defined separately in
Section 3.1. Section 3.1.
o We added more precise and complete rules for accepting Path o We added more precise and complete rules for accepting Path
messages for unicast and multicast destinations (Section messages for unicast and multicast destinations (Section
skipping to change at page 4, line 8 skipping to change at page 4, line 8
o Section 2.7 on Policy and Security was split into two o Section 2.7 on Policy and Security was split into two
sections, and some additional discussion of security was sections, and some additional discussion of security was
included. included.
o There were some minor editorial improvements. o There were some minor editorial improvements.
1. Introduction 1. Introduction
This document defines RSVP, a resource reservation setup protocol This document defines RSVP, a resource reservation setup protocol
designed for an integrated services Internet [RSVP93,ISInt93]. The designed for an integrated services Internet [RSVP93, RFC 1633]. The
RSVP protocol is used by a host to request specific qualities of RSVP protocol is used by a host to request specific qualities of
service from the network for particular application data streams or service from the network for particular application data streams or
flows. RSVP is also used by routers to deliver quality-of-service flows. RSVP is also used by routers to deliver quality-of-service
(QoS) requests to all nodes along the path(s) of the flows and to (QoS) requests to all nodes along the path(s) of the flows and to
establish and maintain state to provide the requested service. RSVP establish and maintain state to provide the requested service. RSVP
requests will generally result in resources being reserved in each requests will generally result in resources being reserved in each
node along the data path. node along the data path.
RSVP requests resources for simplex flows, i.e., it requests RSVP requests resources for simplex flows, i.e., it requests
resources in only one direction. Therefore, RSVP treats a sender as resources in only one direction. Therefore, RSVP treats a sender as
skipping to change at page 6, line 13 skipping to change at page 6, line 18
the RSVP program returns an error notification to the application the RSVP program returns an error notification to the application
process that originated the request. process that originated the request.
RSVP protocol mechanisms provide a general facility for creating and RSVP protocol mechanisms provide a general facility for creating and
maintaining distributed reservation state across a mesh of multicast maintaining distributed reservation state across a mesh of multicast
or unicast delivery paths. RSVP itself transfers and manipulates QoS or unicast delivery paths. RSVP itself transfers and manipulates QoS
and policy control parameters as opaque data, passing them to the and policy control parameters as opaque data, passing them to the
appropriate traffic control and policy control modules for appropriate traffic control and policy control modules for
interpretation. The structure and contents of the QoS parameters are interpretation. The structure and contents of the QoS parameters are
documented in specifications developed by the Integrated Services documented in specifications developed by the Integrated Services
Working Group; see [ISrsvp96]. The structure and contents of the Working Group; see [RFC 2210]. The structure and contents of the
policy parameters are under development. policy parameters are under development.
Since the membership of a large multicast group and the resulting Since the membership of a large multicast group and the resulting
multicast tree topology are likely to change with time, the RSVP multicast tree topology are likely to change with time, the RSVP
design assumes that state for RSVP and traffic control state is to be design assumes that state for RSVP and traffic control state is to be
built and destroyed incrementally in routers and hosts. For this built and destroyed incrementally in routers and hosts. For this
purpose, RSVP establishes "soft" state; that is, RSVP sends periodic purpose, RSVP establishes "soft" state; that is, RSVP sends periodic
refresh messages to maintain the state along the reserved path(s). refresh messages to maintain the state along the reserved path(s).
In the absence of refresh messages, the state automatically times out In the absence of refresh messages, the state automatically times out
and is deleted. and is deleted.
skipping to change at page 7, line 9 skipping to change at page 7, line 14
o RSVP provides several reservation models or "styles" (defined o RSVP provides several reservation models or "styles" (defined
below) to fit a variety of applications. below) to fit a variety of applications.
o RSVP provides transparent operation through routers that do not o RSVP provides transparent operation through routers that do not
support it. support it.
o RSVP supports both IPv4 and IPv6. o RSVP supports both IPv4 and IPv6.
Further discussion on the objectives and general justification for Further discussion on the objectives and general justification for
RSVP design are presented in [RSVP93] and [ISInt93]. RSVP design are presented in [RSVP93] and [RFC 1633].
The remainder of this section describes the RSVP reservation The remainder of this section describes the RSVP reservation
services. Section 2 presents an overview of the RSVP protocol services. Section 2 presents an overview of the RSVP protocol
mechanisms. Section 3 contains the functional specification of RSVP, mechanisms. Section 3 contains the functional specification of RSVP,
while Section 4 presents explicit message processing rules. Appendix while Section 4 presents explicit message processing rules. Appendix
A defines the variable-length typed data objects used in the RSVP A defines the variable-length typed data objects used in the RSVP
protocol. Appendix B defines error codes and values. Appendix C protocol. Appendix B defines error codes and values. Appendix C
defines a UDP encapsulation of RSVP messages, for hosts whose defines a UDP encapsulation of RSVP messages, for hosts whose
operating systems provide inadequate raw network I/O support. operating systems provide inadequate raw network I/O support.
skipping to change at page 8, line 43 skipping to change at page 8, line 50
spec is used to set parameters in the packet classifier. Data spec is used to set parameters in the packet classifier. Data
packets that are addressed to a particular session but do not packets that are addressed to a particular session but do not
match any of the filter specs for that session are handled as match any of the filter specs for that session are handled as
best-effort traffic. best-effort traffic.
The flowspec in a reservation request will generally include a The flowspec in a reservation request will generally include a
service class and two sets of numeric parameters: (1) an "Rspec" service class and two sets of numeric parameters: (1) an "Rspec"
(R for `reserve') that defines the desired QoS, and (2) a "Tspec" (R for `reserve') that defines the desired QoS, and (2) a "Tspec"
(T for `traffic') that describes the data flow. The formats and (T for `traffic') that describes the data flow. The formats and
contents of Tspecs and Rspecs are determined by the integrated contents of Tspecs and Rspecs are determined by the integrated
service models [ISrsvp96] and are generally opaque to RSVP. service models [RFC 2210] and are generally opaque to RSVP.
The exact format of a filter spec depends upon whether IPv4 or The exact format of a filter spec depends upon whether IPv4 or
IPv6 is in use; see Appendix A. In the most general approach IPv6 is in use; see Appendix A. In the most general approach
[RSVP93], filter specs may select arbitrary subsets of the packets [RSVP93], filter specs may select arbitrary subsets of the packets
in a given session. Such subsets might be defined in terms of in a given session. Such subsets might be defined in terms of
senders (i.e., sender IP address and generalized source port), in senders (i.e., sender IP address and generalized source port), in
terms of a higher-level protocol, or generally in terms of any terms of a higher-level protocol, or generally in terms of any
fields in any protocol headers in the packet. For example, filter fields in any protocol headers in the packet. For example, filter
specs might be used to select different subflows of a specs might be used to select different subflows of a
hierarchically-encoded video stream by selecting on fields in an hierarchically-encoded video stream by selecting on fields in an
skipping to change at page 9, line 20 skipping to change at page 9, line 26
the present RSVP specification has a very restricted form: sender the present RSVP specification has a very restricted form: sender
IP address and optionally the UDP/TCP port number SrcPort. IP address and optionally the UDP/TCP port number SrcPort.
Because the UDP/TCP port numbers are used for packet Because the UDP/TCP port numbers are used for packet
classification, each router must be able to examine these fields. classification, each router must be able to examine these fields.
This raises three potential problems. This raises three potential problems.
1. It is necessary to avoid IP fragmentation of a data flow for 1. It is necessary to avoid IP fragmentation of a data flow for
which a resource reservation is desired. which a resource reservation is desired.
Document [ISrsvp96] specifies a procedure for applications Document [RFC 2210] specifies a procedure for applications
using RSVP facilities to compute the minimum MTU over a using RSVP facilities to compute the minimum MTU over a
multicast tree and return the result to the senders. multicast tree and return the result to the senders.
2. IPv6 inserts a variable number of variable-length Internet- 2. IPv6 inserts a variable number of variable-length Internet-
layer headers before the transport header, increasing the layer headers before the transport header, increasing the
difficulty and cost of packet classification for QoS. difficulty and cost of packet classification for QoS.
Efficient classification of IPv6 data packets could be Efficient classification of IPv6 data packets could be
obtained using the Flow Label field of the IPv6 header. The obtained using the Flow Label field of the IPv6 header. The
details will be provided in the future. details will be provided in the future.
3. IP-level Security, under either IPv4 or IPv6, may encrypt the 3. IP-level Security, under either IPv4 or IPv6, may encrypt the
entire transport header, hiding the port numbers of data entire transport header, hiding the port numbers of data
packets from intermediate routers. packets from intermediate routers.
A small extension to RSVP for IP Security under IPv4 and IPv6 A small extension to RSVP for IP Security under IPv4 and IPv6
is described separately in [IPSEC96]. is described separately in [RFC 2207].
RSVP messages carrying reservation requests originate at receivers RSVP messages carrying reservation requests originate at receivers
and are passed upstream towards the sender(s). Note: in this and are passed upstream towards the sender(s). Note: in this
document, we define the directional terms "upstream" vs. document, we define the directional terms "upstream" vs.
"downstream", "previous hop" vs. "next hop", and "incoming "downstream", "previous hop" vs. "next hop", and "incoming
interface" vs "outgoing interface" with respect to the direction interface" vs "outgoing interface" with respect to the direction
of data flow. of data flow.
At each intermediate node, a reservation request triggers two At each intermediate node, a reservation request triggers two
general actions, as follows: general actions, as follows:
skipping to change at page 21, line 40 skipping to change at page 21, line 46
for a higher bandwidth and another calls for a tighter delay for a higher bandwidth and another calls for a tighter delay
bound, one is not "larger" than the other. In such a case, bound, one is not "larger" than the other. In such a case,
instead of taking the larger, the service-specific merging instead of taking the larger, the service-specific merging
routines must be able to return a third flowspec that is at least routines must be able to return a third flowspec that is at least
as large as each; mathematically, this is the "least upper bound" as large as each; mathematically, this is the "least upper bound"
(LUB). In some cases, a flowspec at least as small is needed; (LUB). In some cases, a flowspec at least as small is needed;
this is the "greatest lower bound" (GLB) GLB (Greatest Lower this is the "greatest lower bound" (GLB) GLB (Greatest Lower
Bound). Bound).
The following steps are used to calculate the effective flowspec The following steps are used to calculate the effective flowspec
(Re, Te) to be installed on an interface [ISrsvp96]. Here Te is (Re, Te) to be installed on an interface [RFC 2210]. Here Te is
the effective Tspec and Re is the effective Rspec. the effective Tspec and Re is the effective Rspec.
1. An effective flowspec is determined for the outgoing 1. An effective flowspec is determined for the outgoing
interface. Depending upon the link-layer technology, this interface. Depending upon the link-layer technology, this
may require merging flowspecs from different next hops; this may require merging flowspecs from different next hops; this
means computing the effective flowspec as the LUB of the means computing the effective flowspec as the LUB of the
flowspecs. Note that what flowspecs to merge is determined flowspecs. Note that what flowspecs to merge is determined
by the link layer medium (see Section 3.11.2), while how to by the link layer medium (see Section 3.11.2), while how to
merge them is determined by the service model in use merge them is determined by the service model in use [RFC
[ISrsvp96]. 2210].
The result is a flowspec that is opaque to RSVP but actually The result is a flowspec that is opaque to RSVP but actually
consists of the pair (Re, Resv_Te), where is Re is the consists of the pair (Re, Resv_Te), where is Re is the
effective Rspec and Resv_Te is the effective Tspec. effective Rspec and Resv_Te is the effective Tspec.
2. A service-specific calculation of Path_Te, the sum of all 2. A service-specific calculation of Path_Te, the sum of all
Tspecs that were supplied in Path messages from different Tspecs that were supplied in Path messages from different
previous hops (e.g., some or all of A, B, and B' in Figure previous hops (e.g., some or all of A, B, and B' in Figure
9), is performed. 9), is performed.
skipping to change at page 29, line 34 skipping to change at page 29, line 36
The first two security issues concerned RSVP's operation. A The first two security issues concerned RSVP's operation. A
third security issue concerns resource reservations for third security issue concerns resource reservations for
secure data streams. In particular, the use of IPSEC (IP secure data streams. In particular, the use of IPSEC (IP
Security) in the data stream poses a problem for RSVP: if Security) in the data stream poses a problem for RSVP: if
the transport and higher level headers are encrypted, RSVP's the transport and higher level headers are encrypted, RSVP's
generalized port numbers cannot be used to define a session generalized port numbers cannot be used to define a session
or a sender. or a sender.
To solve this problem, an RSVP extension has been defined in To solve this problem, an RSVP extension has been defined in
which the security association identifier (IPSEC SPI) plays a which the security association identifier (IPSEC SPI) plays a
role roughly equivalent to the generalized ports [IPSEC97]. role roughly equivalent to the generalized ports [RFC 2207].
2.9 Non-RSVP Clouds 2.9 Non-RSVP Clouds
It is impossible to deploy RSVP (or any new protocol) at the same It is impossible to deploy RSVP (or any new protocol) at the same
moment throughout the entire Internet. Furthermore, RSVP may moment throughout the entire Internet. Furthermore, RSVP may
never be deployed everywhere. RSVP must therefore provide correct never be deployed everywhere. RSVP must therefore provide correct
protocol operation even when two RSVP-capable routers are joined protocol operation even when two RSVP-capable routers are joined
by an arbitrary "cloud" of non-RSVP routers. Of course, an by an arbitrary "cloud" of non-RSVP routers. Of course, an
intermediate cloud that does not support RSVP is unable to perform intermediate cloud that does not support RSVP is unable to perform
resource reservation. However, if such a cloud has sufficient resource reservation. However, if such a cloud has sufficient
skipping to change at page 30, line 17 skipping to change at page 30, line 18
the next RSVP-capable router on the path(s) back towards the the next RSVP-capable router on the path(s) back towards the
source. source.
Even though RSVP operates correctly through a non-RSVP cloud, the Even though RSVP operates correctly through a non-RSVP cloud, the
non-RSVP-capable nodes will in general perturb the QoS provided to non-RSVP-capable nodes will in general perturb the QoS provided to
a receiver. Therefore, RSVP passes a `NonRSVP' flag bit to the a receiver. Therefore, RSVP passes a `NonRSVP' flag bit to the
local traffic control mechanism when there are non-RSVP-capable local traffic control mechanism when there are non-RSVP-capable
hops in the path to a given sender. Traffic control combines this hops in the path to a given sender. Traffic control combines this
flag bit with its own sources of information, and forwards the flag bit with its own sources of information, and forwards the
composed information on integrated service capability along the composed information on integrated service capability along the
path to receivers using Adspecs [ISrsvp96]. path to receivers using Adspecs [RFC 2210].
Some topologies of RSVP routers and non-RSVP routers can cause Some topologies of RSVP routers and non-RSVP routers can cause
Resv messages to arrive at the wrong RSVP-capable node, or to Resv messages to arrive at the wrong RSVP-capable node, or to
arrive at the wrong interface of the correct node. An RSVP arrive at the wrong interface of the correct node. An RSVP
process must be prepared to handle either situation. If the process must be prepared to handle either situation. If the
destination address does not match any local interface and the destination address does not match any local interface and the
message is not a Path or PathTear, the message must be forwarded message is not a Path or PathTear, the message must be forwarded
without further processing by this node. To handle the wrong without further processing by this node. To handle the wrong
interface case, a "Logical Interface Handle" (LIH) is used. The interface case, a "Logical Interface Handle" (LIH) is used. The
previous hop information included in a Path message includes not previous hop information included in a Path message includes not
skipping to change at page 48, line 20 skipping to change at page 49, line 6
RSVP messages are sent hop-by-hop between RSVP-capable routers as RSVP messages are sent hop-by-hop between RSVP-capable routers as
"raw" IP datagrams with protocol number 46. Raw IP datagrams are "raw" IP datagrams with protocol number 46. Raw IP datagrams are
also intended to be used between an end system and the first/last also intended to be used between an end system and the first/last
hop router, although it is also possible to encapsulate RSVP hop router, although it is also possible to encapsulate RSVP
messages as UDP datagrams for end-system communication, as messages as UDP datagrams for end-system communication, as
described in Appendix C. UDP encapsulation is needed for systems described in Appendix C. UDP encapsulation is needed for systems
that cannot do raw network I/O. that cannot do raw network I/O.
Path, PathTear, and ResvConf messages must be sent with the Router Path, PathTear, and ResvConf messages must be sent with the Router
Alert IP option [Katz97] in their IP headers. This option may be Alert IP option [RFC 2113] in their IP headers. This option may
used in the fast forwarding path of a high-speed router to detect be used in the fast forwarding path of a high-speed router to
datagrams that require special processing. detect datagrams that require special processing.
Upon the arrival of an RSVP message M that changes the state, a Upon the arrival of an RSVP message M that changes the state, a
node must forward the state modification immediately. However, node must forward the state modification immediately. However,
this must not trigger sending a message out the interface through this must not trigger sending a message out the interface through
which M arrived (which could happen if the implementation simply which M arrived (which could happen if the implementation simply
triggered an immediate refresh of all state for the session). triggered an immediate refresh of all state for the session).
This rule is necessary to prevent packet storms on broadcast LANs. This rule is necessary to prevent packet storms on broadcast LANs.
In this version of the spec, each RSVP message must occupy exactly 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 one IP datagram. If it exceeds the MTU, such a datagram will be
skipping to change at page 52, line 48 skipping to change at page 53, line 48
The following rules are used for SCOPE objects in ResvErr messages The following rules are used for SCOPE objects in ResvErr messages
with WF style: with WF style:
1. The node that detected the error initiates an ResvErr message 1. The node that detected the error initiates an ResvErr message
containing a copy of the SCOPE object associated with the containing a copy of the SCOPE object associated with the
reservation state or message in error. reservation state or message in error.
2. Suppose a wildcard-style ResvErr message arrives at a node 2. Suppose a wildcard-style ResvErr message arrives at a node
with a SCOPE object containing the sender host address list with a SCOPE object containing the sender host address list
L. The node forwards the ResvErr message using the rules of L. The node forwards the ResvErr message using the rules of
Section 3.1.8. However, the ResvErr message forwarded out OI Section 3.1.8. However,
must contain a SCOPE object derived from L by including only the ResvErr message forwarded out OI must contain a SCOPE
those senders that route to OI. If this SCOPE object is object derived from L by including only those senders that
empty, the ResvErr message should not be sent out OI. route to OI. If this SCOPE object is empty, the ResvErr
message should not be sent out OI.
3.5 Blockade State 3.5 Blockade State
The basic rule for creating a Resv refresh message is to merge the The basic rule for creating a Resv refresh message is to merge the
flowspecs of the reservation requests in place in the node, by flowspecs of the reservation requests in place in the node, by
computing their LUB. However, this rule is modified by the computing their LUB. However, this rule is modified by the
existence of "blockade state" resulting from ResvErr messages, to existence of "blockade state" resulting from ResvErr messages, to
solve the KR-II problem (see Section 2.5). The blockade state solve the KR-II problem (see Section 2.5). The blockade state
also enters into the routing of ResvErr messages for Admission also enters into the routing of ResvErr messages for Admission
Control failure. Control failure.
skipping to change at page 58, line 25 skipping to change at page 59, line 25
This flag should be set on when the flowspec being installed This flag should be set on when the flowspec being installed
is smaller than, or incomparable to, a FLOWSPEC in place on is smaller than, or incomparable to, a FLOWSPEC in place on
any other interface, for the same FILTER_SPEC and SESSION. any other interface, for the same FILTER_SPEC and SESSION.
RSVP must also test for the presence of non-RSVP hops in the path RSVP must also test for the presence of non-RSVP hops in the path
and pass this information to traffic control. From this flag bit and pass this information to traffic control. From this flag bit
that the RSVP process supplies and from its own local knowledge, that the RSVP process supplies and from its own local knowledge,
traffic control can detect the presence of a hop in the path that traffic control can detect the presence of a hop in the path that
is not capable of QoS control, and it passes this information to is not capable of QoS control, and it passes this information to
the receivers in Adspecs [ISrsvp96]. the receivers in Adspecs [RFC 2210].
With normal IP forwarding, RSVP can detect a non-RSVP hop by With normal IP forwarding, RSVP can detect a non-RSVP hop by
comparing the IP TTL with which a Path message is sent to the TTL comparing the IP TTL with which a Path message is sent to the TTL
with which it is received; for this purpose, the transmission TTL with which it is received; for this purpose, the transmission TTL
is placed in the common header. However, the TTL is not always a is placed in the common header. However, the TTL is not always a
reliable indicator of non-RSVP hops, and other means must reliable indicator of non-RSVP hops, and other means must
sometimes be used. For example, if the routing protocol uses IP sometimes be used. For example, if the routing protocol uses IP
encapsulating tunnels, then the routing protocol must inform RSVP encapsulating tunnels, then the routing protocol must inform RSVP
when non-RSVP hops are included. If no automatic mechanism will when non-RSVP hops are included. If no automatic mechanism will
work, manual configuration will be required. work, manual configuration will be required.
skipping to change at page 63, line 35 skipping to change at page 64, line 35
- Sender_Template - Sender_Template
This parameter is included as an escape mechanism to This parameter is included as an escape mechanism to
support a more general definition of the sender support a more general definition of the sender
("generalized source port"). Normally this parameter ("generalized source port"). Normally this parameter
may be omitted. may be omitted.
- Sender_Tspec - Sender_Tspec
This parameter describes the traffic flow to be sent; This parameter describes the traffic flow to be sent;
see [ISrsvp96]. see [RFC 2210].
- Adspec - Adspec
This parameter may be specified to initialize the This parameter may be specified to initialize the
computation of QoS properties along the path; see computation of QoS properties along the path; see
[ISrsvp96]. [RFC 2210].
- Data_TTL - Data_TTL
This is the (non-default) IP Time-To-Live parameter This is the (non-default) IP Time-To-Live parameter
that is being supplied on the data packets. It is that is being supplied on the data packets. It is
needed to ensure that Path messages do not have a needed to ensure that Path messages do not have a
scope larger than multicast data packets. scope larger than multicast data packets.
- Policy_data - Policy_data
skipping to change at page 75, line 5 skipping to change at page 76, line 14
The possible result_codes indicate: Tspecs are equal, or The possible result_codes indicate: Tspecs are equal, or
Tspecs are unequal. Tspecs are unequal.
o Sum Tspecs o Sum Tspecs
Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum
This call is used to compute Path_Te (see Section 2.2). This call is used to compute Path_Te (see Section 2.2).
APPENDIX A. Object Definitions 4. Acknowledgments
C-Types are defined for the two Internet address families IPv4 and IPv6. The design of RSVP is based upon research performed in 1992-1993 by a
To accommodate other address families, additional C-Types could easily collaboration including Lixia Zhang (UCLA), Deborah Estrin
be defined. These definitions are contained as an Appendix, to ease (USC/ISI), Scott Shenker (Xerox PARC), Sugih Jamin (USC/Xerox PARC),
updating. and Daniel Zappala (USC). Sugih Jamin developed the first prototype
implementation of RSVP and successfully demonstrated it in May 1993.
Shai Herzog, and later Steve Berson, continued development of RSVP
prototypes.
All unused fields should be sent as zero and ignored on receipt. Since 1993, many members of the Internet research community have
contributed to the design and development of RSVP; these include (in
alphabetical order) Steve Berson, Bob Braden, Lee Breslau, Dave
Clark, Deborah Estrin, Shai Herzog, Craig Partridge, Scott Shenker,
John Wroclawski, Daniel Zappala, and Lixia Zhang. In addition, a
number of host and router vendors have made valuable contributions to
the RSVP documents, particularly Fred Baker (Cisco), Mark Baugher
(Intel), Lou Berger (Fore Systems), Don Hoffman (Sun), Steve Jakowski
(NetManage), John Krawczyk (Bay Networks), and Bill Nowicki (SGI), as
well as many others.
A.1 SESSION Class APPENDIX A. Object Definitions
SESSION Class = 1. 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.
o IPv4/UDP SESSION object: Class = 1, C-Type = 1 All unused fields should be sent as zero and ignored on receipt.
+-------------+-------------+-------------+-------------+ A.1 SESSION Class
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+
o IPv6/UDP SESSION object: Class = 1, C-Type = 2 SESSION Class = 1.
+-------------+-------------+-------------+-------------+ o IPv4/UDP SESSION object: Class = 1, C-Type = 1
| |
+ +
| |
+ IPv6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+
DestAddress +-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+
The IP unicast or multicast destination address of the session. o IPv6/UDP SESSION object: Class = 1, C-Type = 2
This field must be non-zero.
Protocol Id +-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+
The IP Protocol Identifier for the data flow. This field must DestAddress
be non-zero.
Flags The IP unicast or multicast destination address of the
session. This field must be non-zero.
0x01 = E_Police flag Protocol Id
The E_Police flag is used in Path messages to determine the The IP Protocol Identifier for the data flow. This field
effective "edge" of the network, to control traffic must be non-zero.
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 Flags
The UDP/TCP destination port for the session. Zero may be used 0x01 = E_Police flag
to indicate `none'.
Other SESSION C-Types could be defined in the future to support The E_Police flag is used in Path messages to determine
other demultiplexing conventions in the transport-layer or the effective "edge" of the network, to control traffic
application layer. 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.
A.2 RSVP_HOP Class DstPort
RSVP_HOP class = 3. The UDP/TCP destination port for the session. Zero may be
used to indicate `none'.
o IPv4 RSVP_HOP object: Class = 3, C-Type = 1 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
| IPv4 Next/Previous Hop Address |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
o IPv6 RSVP_HOP object: Class = 3, C-Type = 2 RSVP_HOP class = 3.
+-------------+-------------+-------------+-------------+ o IPv4 RSVP_HOP object: Class = 3, C-Type = 1
| |
+ +
| |
+ 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 | IPv4 Next/Previous Hop Address |
Interface Handle (LIH) is used to distinguish logical outgoing +-------------+-------------+-------------+-------------+
interfaces, as discussed in Sections 3.3 and 3.9. A node receiving | Logical Interface Handle |
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 o IPv6 RSVP_HOP object: Class = 3, C-Type = 2
INTEGRITY class = 4. +-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Next/Previous Hop Address +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
See [Baker96]. 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.4 TIME_VALUES Class A.3 INTEGRITY Class
TIME_VALUES class = 5. INTEGRITY class = 4.
o TIME_VALUES Object: Class = 5, C-Type = 1 See [Baker96].
+-------------+-------------+-------------+-------------+ A.4 TIME_VALUES Class
| Refresh Period R |
+-------------+-------------+-------------+-------------+
Refresh Period TIME_VALUES class = 5.
The refresh timeout period R used to generate this message; in o TIME_VALUES Object: Class = 5, C-Type = 1
milliseconds.
A.5 ERROR_SPEC Class +-------------+-------------+-------------+-------------+
| Refresh Period R |
+-------------+-------------+-------------+-------------+
ERROR_SPEC class = 6. Refresh Period
o IPv4 ERROR_SPEC object: Class = 6, C-Type = 1 The refresh timeout period R used to generate this message;
in milliseconds.
+-------------+-------------+-------------+-------------+ A.5 ERROR_SPEC Class
| IPv4 Error Node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
o IPv6 ERROR_SPEC object: Class = 6, C-Type = 2 ERROR_SPEC class = 6.
+-------------+-------------+-------------+-------------+ o IPv4 ERROR_SPEC object: Class = 6, C-Type = 1
| |
+ +
| |
+ IPv6 Error Node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
Error Node Address +-------------+-------------+-------------+-------------+
| IPv4 Error Node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
The IP address of the node in which the error was detected. o IPv6 ERROR_SPEC object: Class = 6, C-Type = 2
Flags +-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Error Node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
0x01 = InPlace Error Node Address
This flag is used only for an ERROR_SPEC object in a The IP address of the node in which the error was detected.
ResvErr message. If it on, this flag indicates that there
was, and still is, a reservation in place at the failure
point.
0x02 = NotGuilty Flags
This flag is used only for an ERROR_SPEC object in a 0x01 = InPlace
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 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.
A one-octet error description. 0x02 = NotGuilty
Error Value 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.
A two-octet field containing additional information about the Error Code
error. Its contents depend upon the Error Type.
The values for Error Code and Error Value are defined in Appendix B. A one-octet error description.
A.6 SCOPE Class Error Value
SCOPE class = 7. A two-octet field containing additional information about the
error. Its contents depend upon the Error Type.
This object contains a list of IP addresses, used for routing The values for Error Code and Error Value are defined in Appendix
messages with wildcard scope without loops. The addresses must be B.
listed in ascending numerical order.
o IPv4 SCOPE List object: Class = 7, C-Type = 1 A.6 SCOPE Class
+-------------+-------------+-------------+-------------+ SCOPE class = 7.
| IPv4 Src Address (4 bytes) |
+-------------+-------------+-------------+-------------+
// //
+-------------+-------------+-------------+-------------+
| IPv4 Src Address (4 bytes) |
+-------------+-------------+-------------+-------------+
o IPv6 SCOPE list object: Class = 7, C-Type = 2 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
| |
+ +
| |
+ IPv6 Src Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
// //
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Src Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
A.7 STYLE Class +-------------+-------------+-------------+-------------+
| IPv4 Src Address (4 bytes) |
+-------------+-------------+-------------+-------------+
// //
+-------------+-------------+-------------+-------------+
| IPv4 Src Address (4 bytes) |
+-------------+-------------+-------------+-------------+
STYLE class = 8. o IPv6 SCOPE list object: Class = 7, C-Type = 2
o STYLE object: Class = 8, C-Type = 1 +-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Src Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
// //
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Src Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ A.7 STYLE Class
| Flags | Option Vector |
+-------------+-------------+-------------+-------------+
Flags: 8 bits STYLE class = 8.
(None assigned yet) o STYLE object: Class = 8, C-Type = 1
Option Vector: 24 bits +-------------+-------------+-------------+-------------+
| Flags | Option Vector |
+-------------+-------------+-------------+-------------+
A set of bit fields giving values for the reservation options. Flags: 8 bits
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: (None assigned yet)
19 bits: Reserved Option Vector: 24 bits
2 bits: Sharing control 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.
00b: Reserved The option vector bits are assigned (from the left) as
follows:
01b: Distinct reservations 19 bits: Reserved
10b: Shared reservations 2 bits: Sharing control
11b: Reserved 00b: Reserved
3 bits: Sender selection control 01b: Distinct reservations
000b: Reserved 10b: Shared reservations
001b: Wildcard 11b: Reserved
010b: Explicit 3 bits: Sender selection control
011b - 111b: Reserved 000b: Reserved
The low order bits of the option vector are determined by the style, 001b: Wildcard
as follows:
WF 10001b 010b: Explicit
FF 01010b 011b - 111b: Reserved
SE 10010b
A.8 FLOWSPEC Class The low order bits of the option vector are determined by the
style, as follows:
FLOWSPEC class = 9. WF 10001b
FF 01010b
SE 10010b
o Reserved (obsolete) flowspec object: Class = 9, C-Type = 1 A.8 FLOWSPEC Class
o Inv-serv Flowspec object: Class = 9, C-Type = 2 FLOWSPEC class = 9.
The contents and encoding rules for this object are specified in o Reserved (obsolete) flowspec object: Class = 9, C-Type = 1
documents prepared by the int-serv working group [ISrsvp96].
A.9 FILTER_SPEC Class o Inv-serv Flowspec object: Class = 9, C-Type = 2
FILTER_SPEC class = 10. The contents and encoding rules for this object are specified
in documents prepared by the int-serv working group [RFC
2210].
o IPv4 FILTER_SPEC object: Class = 10, C-Type = 1 A.9 FILTER_SPEC Class
+-------------+-------------+-------------+-------------+ FILTER_SPEC class = 10.
| IPv4 SrcAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| ////// | ////// | SrcPort |
+-------------+-------------+-------------+-------------+
o IPv6 FILTER_SPEC object: Class = 10, C-Type = 2 o IPv4 FILTER_SPEC object: Class = 10, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | IPv4 SrcAddress (4 bytes) |
+ + +-------------+-------------+-------------+-------------+
| | | ////// | ////// | SrcPort |
+ IPv6 SrcAddress (16 bytes) + +-------------+-------------+-------------+-------------+
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| ////// | ////// | SrcPort |
+-------------+-------------+-------------+-------------+
o IPv6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3 o IPv6 FILTER_SPEC object: Class = 10, C-Type = 2
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IPv6 SrcAddress (16 bytes) + + IPv6 SrcAddress (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| /////// | Flow Label (24 bits) | | ////// | ////// | SrcPort |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
SrcAddress o IPv6 Flow-label FILTER_SPEC object: Class = 10, C-Type = 3
The IP source address for a sender host. Must be non-zero. +-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 SrcAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| /////// | Flow Label (24 bits) |
+-------------+-------------+-------------+-------------+
SrcPort SrcAddress
The UDP/TCP source port for a sender, or zero to indicate The IP source address for a sender host. Must be non-zero.
`none'.
Flow Label SrcPort
A 24-bit Flow Label, defined in IPv6. This value may be used by The UDP/TCP source port for a sender, or zero to indicate
the packet classifier to efficiently identify the packets `none'.
belonging to a particular (sender->destination) data flow.
A.10 SENDER_TEMPLATE Class Flow Label
SENDER_TEMPLATE class = 11. 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.
o IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 1 A.10 SENDER_TEMPLATE Class
Definition same as IPv4/UDP FILTER_SPEC object. SENDER_TEMPLATE class = 11.
o IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 2 o IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 1
Definition same as IPv6/UDP FILTER_SPEC object. Definition same as IPv4/UDP FILTER_SPEC object.
o IPv6 Flow-label SENDER_TEMPLATE object: Class = 11, C-Type = 3 o IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 2
A.11 SENDER_TSPEC Class Definition same as IPv6/UDP FILTER_SPEC object.
SENDER_TSPEC class = 12. o IPv6 Flow-label SENDER_TEMPLATE object: Class = 11, C-Type =
3
o Intserv SENDER_TSPEC object: Class = 12, C-Type = 2 A.11 SENDER_TSPEC Class
The contents and encoding rules for this object are specified in SENDER_TSPEC class = 12.
documents prepared by the int-serv working group.
A.12 ADSPEC Class o Intserv SENDER_TSPEC object: Class = 12, C-Type = 2
ADSPEC class = 13. The contents and encoding rules for this object are specified
in documents prepared by the int-serv working group.
o Intserv ADSPEC object: Class = 13, C-Type = 2 A.12 ADSPEC Class
The contents and format for this object are specified in ADSPEC class = 13.
documents prepared by the int-serv working group.
A.13 POLICY_DATA Class o Intserv ADSPEC object: Class = 13, C-Type = 2
POLICY_DATA class = 14. The contents and format for this object are specified in
documents prepared by the int-serv working group.
o Type 1 POLICY_DATA object: Class = 14, C-Type = 1 A.13 POLICY_DATA Class
The contents of this object are for further study. POLICY_DATA class = 14.
A.14 Resv_CONFIRM Class o Type 1 POLICY_DATA object: Class = 14, C-Type = 1
RESV_CONFIRM class = 15. The contents of this object are for further study.
o IPv4 RESV_CONFIRM object: Class = 15, C-Type = 1 A.14 Resv_CONFIRM Class
+-------------+-------------+-------------+-------------+ RESV_CONFIRM class = 15.
| IPv4 Receiver Address (4 bytes) |
+-------------+-------------+-------------+-------------+
o IPv6 RESV_CONFIRM object: Class = 15, C-Type = 2 o IPv4 RESV_CONFIRM object: Class = 15, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | IPv4 Receiver Address (4 bytes) |
+ + +-------------+-------------+-------------+-------------+
| |
+ IPv6 Receiver Address (16 bytes) + o IPv6 RESV_CONFIRM object: Class = 15, C-Type = 2
| |
+ + +-------------+-------------+-------------+-------------+
| | | |
+-------------+-------------+-------------+-------------+ + +
| |
+ IPv6 Receiver Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
APPENDIX B. Error Codes and Values APPENDIX B. Error Codes and Values
The following Error Codes may appear in ERROR_SPEC objects and be passed The following Error Codes may appear in ERROR_SPEC objects and be
to end systems. Except where noted, these Error Codes may appear only passed to end systems. Except where noted, these Error Codes may
in ResvErr messages. appear only in ResvErr messages.
o Error Code = 00: Confirmation o Error Code = 00: Confirmation
This code is reserved for use in the ERROR_SPEC object of a This code is reserved for use in the ERROR_SPEC object of a
ResvConf message. The Error Value will also be zero. ResvConf message. The Error Value will also be zero.
o Error Code = 01: Admission Control failure o Error Code = 01: Admission Control failure
Reservation request was rejected by Admission Control due to Reservation request was rejected by Admission Control due to
unavailable resources. unavailable resources.
For this Error Code, the 16 bits of the Error Value field are: For this Error Code, the 16 bits of the Error Value field are:
ssur cccc cccc cccc ssur cccc cccc cccc
where the bits are: where the bits are:
ss = 00: Low order 12 bits contain a globally-defined sub-code ss = 00: Low order 12 bits contain a globally-defined sub-code
(values listed below). (values listed below).
ss = 10: Low order 12 bits contain a organization-specific sub- ss = 10: Low order 12 bits contain a organization-specific sub-
code. RSVP is not expected to be able to interpret this code. RSVP is not expected to be able to interpret this
except as a numeric value. except as a numeric value.
ss = 11: Low order 12 bits contain a service-specific sub-code. 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 RSVP is not expected to be able to interpret this except as
numeric value. a numeric value.
Since the traffic control mechanism might substitute a Since the traffic control mechanism might substitute a
different service, this encoding may include some different service, this encoding may include some
representation of the service in use. representation of the service in use.
u = 0: RSVP rejects the message without updating local state. u = 0: RSVP rejects the message without updating local
state.
u = 1: RSVP may use message to update local state and forward the u = 1: RSVP may use message to update local state and forward
message. This means that the message is informational. the message. This means that the message is informational.
r: Reserved bit, should be zero. r: Reserved bit, should be zero.
cccc cccc cccc: 12 bit code. cccc cccc cccc: 12 bit code.
The following globally-defined sub-codes may appear in the low- The following globally-defined sub-codes may appear in the low-
order 12 bits when ssur = 0000: order 12 bits when ssur = 0000:
- Sub-code = 1: Delay bound cannot be met - Sub-code = 1: Delay bound cannot be met
- Sub-code = 2: Requested bandwidth unavailable - Sub-code = 2: Requested bandwidth unavailable
- Sub-code = 3: MTU in flowspec larger than interface MTU. - Sub-code = 3: MTU in flowspec larger than interface MTU.
o Error Code = 02: Policy Control failure o Error Code = 02: Policy Control failure
Reservation or path message has been rejected for administrative Reservation or path message has been rejected for administrative
reasons, for example, required credentials not submitted, reasons, for example, required credentials not submitted,
insufficient quota or balance, or administrative preemption. This insufficient quota or balance, or administrative preemption.
Error Code may appear in a PathErr or ResvErr message. This Error Code may appear in a PathErr or ResvErr message.
Contents of the Error Value field are to be determined in the Contents of the Error Value field are to be determined in the
future. future.
o Error Code = 03: No path information for this Resv message. o Error Code = 03: No path information for this Resv message.
No path state for this session. Resv message cannot be forwarded. No path state for this session. Resv message cannot be
forwarded.
o Error Code = 04: No sender information for this Resv message. o Error Code = 04: No sender information for this Resv message.
There is path state for this session, but it does not include the There is path state for this session, but it does not include
sender matching some flow descriptor contained in the Resv message. the sender matching some flow descriptor contained in the Resv
Resv message cannot be forwarded. message. Resv message cannot be forwarded.
o Error Code = 05: Conflicting reservation style o Error Code = 05: Conflicting reservation style
Reservation style conflicts with style(s) of existing reservation Reservation style conflicts with style(s) of existing
state. The Error Value field contains the low-order 16 bits of the reservation state. The Error Value field contains the low-order
Option Vector of the existing style with which the conflict 16 bits of the Option Vector of the existing style with which
occurred. This Resv message cannot be forwarded. the conflict occurred. This Resv message cannot be forwarded.
o Error Code = 06: Unknown reservation style o Error Code = 06: Unknown reservation style
Reservation style is unknown. This Resv message cannot be Reservation style is unknown. This Resv message cannot be
forwarded. forwarded.
o Error Code = 07: Conflicting dest ports 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 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.
Sender port is both zero and non-zero in Path messages for the same o Error Code = 08: Conflicting sender ports
session. This Error Code may appear only in a PathErr message.
o Error Code = 09, 10, 11: (reserved) 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 = 12: Service preempted o Error Code = 09, 10, 11: (reserved)
The service request defined by the STYLE object and the flow o Error Code = 12: Service preempted
descriptor has been administratively preempted.
For this Error Code, the 16 bits of the Error Value field are: The service request defined by the STYLE object and the flow
descriptor has been administratively preempted.
ssur cccc cccc cccc For this Error Code, the 16 bits of the Error Value field are:
Here the high-order bits ssur are as defined under Error Code 01. ssur cccc cccc cccc
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 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.
Error Value contains 16-bit value composed of (Class-Num, C-Type) o Error Code = 13: Unknown object class
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 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.
Error Value contains 16-bit value composed of (Class-Num, C-Type) o Error Code = 14: Unknown object C-Type
of object.
o Error Code = 15-19: (reserved) Error Value contains 16-bit value composed of (Class-Num, C-
Type) of object.
o Error Code = 20: Reserved for API o Error Code = 15-19: (reserved)
Error Value field contains an API error code, for an API error that o Error Code = 20: Reserved for API
was detected asynchronously and must be reported via an upcall.
o Error Code = 21: Traffic Control Error Error Value field contains an API error code, for an API error
that was detected asynchronously and must be reported via an
upcall.
Traffic Control call failed due to the format or contents of the o Error Code = 21: Traffic Control Error
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: 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.
ss00 cccc cccc cccc For this Error Code, the 16 bits of the Error Value field are:
Here the high-order bits ss are as defined under Error Code 01. ss00 cccc cccc cccc
The following globally-defined sub-codes may appear in the low Here the high-order bits ss are as defined under Error Code 01.
order 12 bits (cccc cccc cccc) when ss = 00:
- Sub-code = 01: Service conflict The following globally-defined sub-codes may appear in the low
order 12 bits (cccc cccc cccc) when ss = 00:
Trying to merge two incompatible service requests. - Sub-code = 01: Service conflict
- Sub-code = 02: Service unsupported Trying to merge two incompatible service requests.
Traffic control can provide neither the requested service nor - Sub-code = 02: Service unsupported
an acceptable replacement.
- Sub-code = 03: Bad Flowspec value Traffic control can provide neither the requested service
nor an acceptable replacement.
Malformed or unreasonable request. - Sub-code = 03: Bad Flowspec value
- Sub-code = 04: Bad Tspec value Malformed or unreasonable request.
Malformed or unreasonable request. - Sub-code = 04: Bad Tspec value
- Sub-code = 05: Bad Adspec value Malformed or unreasonable request.
Malformed or unreasonable request. - Sub-code = 05: Bad Adspec value
o Error Code = 22: Traffic Control System error Malformed or unreasonable request.
A system error was detected and reported by the traffic control o Error Code = 22: Traffic Control System error
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 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.
The Error Value field will provide implementation-dependent o Error Code = 23: RSVP System error
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 The Error Value field will provide implementation-dependent
creates an RSVP message is responsible for its correct construction. information on the error. RSVP is not expected to be able to
Similarly, each node is required to verify the correct construction of interpret this value.
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 In general, every RSVP message is rebuilt at each hop, and the node
those that may reflect version mismatches, and which the end system that creates an RSVP message is responsible for its correct
might be able to circumvent, e.g., by falling back to a previous CType construction. Similarly, each node is required to verify the correct
for an object; see code 13 and 14 above. 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 choice of message formatting errors that an RSVP may detect and log The only message formatting errors that are reported to end systems
locally is implementation-specific, but it will typically include the are those that may reflect version mismatches, and which the end
following: system might be able to circumvent, e.g., by falling back to a
previous CType for an object; see code 13 and 14 above.
o Wrong-length message: RSVP Length field does not match message The choice of message formatting errors that an RSVP may detect and
length. log locally is implementation-specific, but it will typically include
the following:
o Unknown or unsupported RSVP version. o Wrong-length message: RSVP Length field does not match message
length.
o Bad RSVP checksum o Unknown or unsupported RSVP version.
o INTEGRITY failure o Bad RSVP checksum
o Illegal RSVP message Type o INTEGRITY failure
o Illegal object length: not a multiple of 4, or less than 4. o Illegal RSVP message Type
o Next hop/Previous hop address in HOP object is illegal. o Illegal object length: not a multiple of 4, or less than 4.
o Bad source port: Source port is non-zero in a filter spec or sender o Next hop/Previous hop address in HOP object is illegal.
template for a session with destination port zero.
o Required object class (specify) missing o Bad source port: Source port is non-zero in a filter spec or
sender template for a session with destination port zero.
o Illegal object class (specify) in this message type. o Required object class (specify) missing
o Violation of required object order o Illegal object class (specify) in this message type.
o Flow descriptor count wrong for style or message type o Violation of required object order
o Flow descriptor count wrong for style or message type
o Logical Interface Handle invalid o Logical Interface Handle invalid
o Unknown object Class-Num. o Unknown object Class-Num.
o Destination address of ResvConf message does not match Receiver o Destination address of ResvConf message does not match Receiver
Address in the RESV_CONFIRM object it contains. Address in the RESV_CONFIRM object it contains.
APPENDIX C. UDP Encapsulation APPENDIX C. UDP Encapsulation
An RSVP implementation will generally require the ability to perform An RSVP implementation will generally require the ability to perform
"raw" network I/O, i.e., to send and receive IP datagrams using protocol "raw" network I/O, i.e., to send and receive IP datagrams using
46. However, some important classes of host systems may not support raw protocol 46. However, some important classes of host systems may not
network I/O. To use RSVP, such hosts must encapsulate RSVP messages in support raw network I/O. To use RSVP, such hosts must encapsulate
UDP. RSVP messages in UDP.
The basic UDP encapsulation scheme makes two assumptions: The basic UDP encapsulation scheme makes two assumptions:
1. All hosts are capable of sending and receiving multicast packets if 1. All hosts are capable of sending and receiving multicast packets
multicast destinations are to be supported. if multicast destinations are to be supported.
2. The first/last-hop routers are RSVP-capable. 2. The first/last-hop routers are RSVP-capable.
A method of relaxing the second assumption is given later. A method of relaxing the second assumption is given later.
Let Hu be a "UDP-only" host that requires UDP encapsulation, and Hr a 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 host that can do raw network I/O. The UDP encapsulation scheme must
allow RSVP interoperation among an arbitrary topology of Hr hosts, Hu allow RSVP interoperation among an arbitrary topology of Hr hosts, Hu
hosts, and routers. hosts, and routers.
Resv, ResvErr, ResvTear, and PathErr messages are sent to unicast Resv, ResvErr, ResvTear, and PathErr messages are sent to unicast
addresses learned from the path or reservation state in the node. If addresses learned from the path or reservation state in the node. If
the node keeps track of which previous hops and which interfaces need the node keeps track of which previous hops and which interfaces need
UDP encapsulation, these messages can be sent using UDP encapsulation UDP encapsulation, these messages can be sent using UDP encapsulation
when necessary. On the other hand, Path and PathTear messages are sent when necessary. On the other hand, Path and PathTear messages are
to the destination address for the session, which may be unicast or sent to the destination address for the session, which may be unicast
multicast. or multicast.
The tables in Figures 13 and 14 show the basic rules for UDP The tables in Figures 13 and 14 show the basic rules for UDP
encapsulation of Path and PathTear messages, for unicast DestAddress and encapsulation of Path and PathTear messages, for unicast DestAddress
multicast DestAddress, respectively. The other message types, which are and multicast DestAddress, respectively. The other message types,
sent unicast, should follow the unicast rules in Figure 13. Under the which are sent unicast, should follow the unicast rules in Figure 13.
`RSVP Send' columns in these figures, the notation is `mode(destaddr, Under the `RSVP Send' columns in these figures, the notation is
destport)'; destport is omitted for raw packets. The `Receive' columns `mode(destaddr, destport)'; destport is omitted for raw packets. The
show the group that is joined and, where relevant, the UDP Listen port. `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 It is useful to define two flavors of UDP encapsulation, one to be
by Hu and the other to be sent by Hr and R, to avoid double processing sent by Hu and the other to be sent by Hr and R, to avoid double
by the recipient. In practice, these two flavors are distinguished by processing by the recipient. In practice, these two flavors are
differing UDP port numbers Pu and Pu'. distinguished by differing UDP port numbers Pu and Pu'.
The following symbols are used in the tables. The following symbols are used in the tables.
o D is the DestAddress for the particular session. 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 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. group that is limited to the local connected network.
o Pu and Pu' are two well-known UDP ports for UDP encapsulation of o Pu and Pu' are two well-known UDP ports for UDP encapsulation of
RSVP, with values 1698 and 1699. RSVP, with values 1698 and 1699.
o Ra is the IP address of the router interface `a'. o Ra is the IP address of the router interface `a'.
o Router interface `a' is on the local network connected to Hu and o Router interface `a' is on the local network connected to Hu and
Hr. Hr.
o o
The following notes apply to these figures: The following notes apply to these figures:
[Note 1] Hu sends a unicast Path message either to the destination [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 address D, if D is local, or to the address Ra of the first-hop
router. Ra is presumably known to the host. router. Ra is presumably known to the host.
[Note 2] Here D is the address of the local interface through which [Note 2] Here D is the address of the local interface through
the message arrived. which the message arrived.
[Note 3] This assumes that the application has joined the group D. [Note 3] This assumes that the application has joined the group D.
UNICAST DESTINATION D: UNICAST DESTINATION D:
RSVP RSVP RSVP RSVP
Node Send Receive Node Send Receive
___ _____________ _______________ ___ _____________ _______________
Hu UDP(D/Ra,Pu) UDP(D,Pu) Hu UDP(D/Ra,Pu) UDP(D,Pu)
[Note 1] and UDP(D,Pu') [Note 1] and UDP(D,Pu')
[Note 2] [Note 2]
Hr Raw(D) Raw() Hr Raw(D) Raw()
and if (UDP) and UDP(D, Pu) and if (UDP) and UDP(D, Pu)
then UDP(D,Pu') [Note 2] then UDP(D,Pu') [Note 2]
(Ignore Pu') (Ignore Pu')
R (Interface a): R (Interface a):
Raw(D) Raw() Raw(D) Raw()
and if (UDP) and UDP(Ra, Pu) and if (UDP) and UDP(Ra, Pu)
then UDP(D,Pu') (Ignore Pu') then UDP(D,Pu') (Ignore Pu')
Figure 13: UDP Encapsulation Rules for Unicast Path and Resv Messages Figure 13: UDP Encapsulation Rules for Unicast Path and Resv Messages
MULTICAST DESTINATION D: MULTICAST DESTINATION D:
RSVP RSVP RSVP RSVP
Node Send Receive Node Send Receive
___ _____________ _________________ ___ _____________ _________________
Hu UDP(G*,Pu) UDP(D,Pu') Hu UDP(G*,Pu) UDP(D,Pu')
[Note 3] [Note 3]
and UDP(G*,Pu) and UDP(G*,Pu)
Hr Raw(D,Tr) Raw() Hr Raw(D,Tr) Raw()
and if (UDP) and UDP(G*,Pu) and if (UDP) and UDP(G*,Pu)
then UDP(D,Pu') (Ignore Pu') then UDP(D,Pu') (Ignore Pu')
R (Interface a): R (Interface a):
Raw(D,Tr) Raw() Raw(D,Tr) Raw()
and if (UDP) and UDP(G*,Pu) and if (UDP) and UDP(G*,Pu)
then UDP(D,Pu') (Ignore Pu') then UDP(D,Pu') (Ignore Pu')
Figure 14: UDP Encapsulation Rules for Multicast Path Messages Figure 14: UDP Encapsulation Rules for Multicast Path Messages
A router may determine if its interface X needs UDP encapsulation by A router may determine if its interface X needs UDP encapsulation by
listening for UDP-encapsulated Path messages that were sent to either G* listening for UDP-encapsulated Path messages that were sent to either
(multicast D) or to the address of interface X (unicast D). There is G* (multicast D) or to the address of interface X (unicast D). There
one failure mode for this scheme: if no host on the connected network is one failure mode for this scheme: if no host on the connected
acts as an RSVP sender, there will be no Path messages to trigger UDP network acts as an RSVP sender, there will be no Path messages to
encapsulation. In this (unlikely) case, it will be necessary to trigger UDP encapsulation. In this (unlikely) case, it will be
explicitly configure UDP encapsulation on the local network interface of necessary to explicitly configure UDP encapsulation on the local
the router. network interface of the router.
When a UDP-encapsulated packet is received, the IP TTL is not available When a UDP-encapsulated packet is received, the IP TTL is not
to the application on most systems. The RSVP process that receives a available to the application on most systems. The RSVP process that
UDP-encapsulated Path or PathTear message should therefore use the receives a UDP-encapsulated Path or PathTear message should therefore
Send_TTL field of the RSVP common header as the effective receive TTL. use the Send_TTL field of the RSVP common header as the effective
This may be overridden by manual configuration. receive TTL. This may be overridden by manual configuration.
We have assumed that the first-hop RSVP-capable router R is on the We have assumed that the first-hop RSVP-capable router R is on the
directly-connected network. There are several possible approaches if directly-connected network. There are several possible approaches if
this is not the case. this is not the case.
1. Hu can send both unicast and multicast sessions to UDP(Ra,Pu) with 1. Hu can send both unicast and multicast sessions to UDP(Ra,Pu)
TTL=Ta with TTL=Ta
Here Ta must be the TTL to exactly reach R. If Ta is too small, 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 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 succeeding routers may forward the UDP packet until its hop
expires. This will turn on UDP encapsulation between routers count expires. This will turn on UDP encapsulation between
within the Internet, perhaps causing bogus UDP traffic. The host routers within the Internet, perhaps causing bogus UDP traffic.
Hu must be explicitly configured with Ra and Ta. 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 2. A particular host on the LAN connected to Hu could be designated
an "RSVP relay host". A relay host would listen on (G*,Pu) and as an "RSVP relay host". A relay host would listen on (G*,Pu)
forward any Path messages directly to R, although it would not be and forward any Path messages directly to R, although it would
in the data path. The relay host would have to be configured with not be in the data path. The relay host would have to be
Ra and Ta. configured with Ra and Ta.
APPENDIX D. Glossary APPENDIX D. Glossary
o Admission control o Admission control
A traffic control function that decides whether the packet A traffic control function that decides whether the packet
scheduler in the node can supply the requested QoS while continuing scheduler in the node can supply the requested QoS while
to provide the QoS requested by previously-admitted requests. See continuing to provide the QoS requested by previously-admitted
also "policy control" and "traffic control". requests. See also "policy control" and "traffic control".
o Adspec o Adspec
An Adspec is a data element (object) in a Path message that carries An Adspec is a data element (object) in a Path message that
a package of OPWA advertising information. See "OPWA". carries a package of OPWA advertising information. See "OPWA".
o Auto-refresh loop o Auto-refresh loop
An auto-refresh loop is an error condition that occurs when a An auto-refresh loop is an error condition that occurs when a
topological loop of routers continues to refresh existing topological loop of routers continues to refresh existing
reservation state even though all receivers have stopped requesting reservation state even though all receivers have stopped
these reservations. See section 3.4 for more information. requesting these reservations. See section 3.4 for more
information.
o Blockade state o Blockade state
Blockade state helps to solve a "killer reservation" problem. See Blockade state helps to solve a "killer reservation" problem.
sections 2.5 and 3.5, and "killer reservation". See sections 2.5 and 3.5, and "killer reservation".
o Branch policing o Branch policing
Traffic policing at a multicast branching point on an outgoing Traffic policing at a multicast branching point on an outgoing
interface that has "less" resources reserved than another outgoing interface that has "less" resources reserved than another
interface for the same flow. See "traffic policing". outgoing interface for the same flow. See "traffic policing".
o C-Type o C-Type
The class type of an object; unique within class-name. See The class type of an object; unique within class-name. See
"class-name". "class-name".
o Class-name o Class-name
The class of an object. See "object". The class of an object. See "object".
o DestAddress o DestAddress
The IP destination address; part of session identification. See The IP destination address; part of session identification. See
"session". "session".
o Distinct style o Distinct style
A (reservation) style attribute; separate resources are reserved
for each different sender. See also "shared style".
o Downstream A (reservation) style attribute; separate resources are reserved
for each different sender. See also "shared style".
Towards the data receiver(s). o Downstream
o DstPort Towards the data receiver(s).
The IP (generalized) destination port used as part of a session. o DstPort
See "generalized destination port".
o Entry policing The IP (generalized) destination port used as part of a session.
See "generalized destination port".
Traffic policing done at the first RSVP- (and policing-) capable o Entry policing
router on a data path.
o ERROR_SPEC Traffic policing done at the first RSVP- (and policing-) capable
router on a data path.
Object that carries the error report in a PathErr or ResvErr o ERROR_SPEC
message.
o Explicit sender selection Object that carries the error report in a PathErr or ResvErr
message.
A (reservation) style attribute; all reserved senders are to be o Explicit sender selection
listed explicitly in the reservation message. See also "wildcard
sender selection".
o FF style A (reservation) style attribute; all reserved senders are to be
listed explicitly in the reservation message. See also
"wildcard sender selection".
Fixed Filter reservation style, which has explicit sender selection o FF style
and distinct attributes.
o FilterSpec Fixed Filter reservation style, which has explicit sender
selection and distinct attributes.
Together with the session information, defines the set of data o FilterSpec
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 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.
The combination of a flowspec and a filterspec. o Flow descriptor
o Flowspec The combination of a flowspec and a filterspec.
Defines the QoS to be provided for a flow. The flowspec is used to o Flowspec
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 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.
The component of a session definition that provides further o Generalized destination port
transport or application protocol layer demultiplexing beyond
DestAddress. See "session".
o Generalized source port The component of a session definition that provides further
transport or application protocol layer demultiplexing beyond
DestAddress. See "session".
The component of a filter spec that provides further transport or o Generalized source port
application protocol layer demultiplexing beyond the sender
address.
o GLB The component of a filter spec that provides further transport
or application protocol layer demultiplexing beyond the sender
address.
Greatest Lower Bound o GLB
o Incoming interface Greatest Lower Bound
The interface on which data packets are expected to arrive, and on o Incoming interface
which Resv messages are sent.
o INTEGRITY The interface on which data packets are expected to arrive, and
on which Resv messages are sent.
Object of an RSVP control message that contains cryptographic data o INTEGRITY
to authenticate the originating node and to verify the contents of
an RSVP message.
o Killer reservation problem Object of an RSVP control message that contains cryptographic
data to authenticate the originating node and to verify the
contents of an RSVP message.
The killer reservation problem describes a case where a receiver o Killer reservation problem
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 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.
The LIH (Logical Interface Handle) is used to help deal with non- o LIH
RSVP clouds. See Section 2.9 for more information.
o Local repair The LIH (Logical Interface Handle) is used to help deal with
non-RSVP clouds. See Section 2.9 for more information.
Allows RSVP to rapidly adapt its reservations to changes in o Local repair
routing. See Section 3.6 for more information.
o LPM Allows RSVP to rapidly adapt its reservations to changes in
routing. See Section 3.6 for more information.
Local Policy Module. the function that exerts policy control. o LPM
o LUB Local Policy Module. the function that exerts policy control.
Least Upper Bound. o LUB
o Merge policing Least Upper Bound.
Traffic policing that takes place at data merge point of a shared o Merge policing
reservation.
o Merging Traffic policing that takes place at data merge point of a
shared reservation.
The process of taking the maximum (or more generally the least o Merging
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 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.
Maximum Transmission Unit. o MTU
o Next hop Maximum Transmission Unit.
The next router in the direction of traffic flow. o Next hop
o NHOP The next router in the direction of traffic flow.
An object that carries the Next Hop information in RSVP control o NHOP
messages.
o Node An object that carries the Next Hop information in RSVP control
messages.
A router or host system. o Node
o Non-RSVP clouds A router or host system.
Groups of hosts and routers that do not run RSVP. Dealing with o Non-RSVP clouds
nodes that do not support RSVP is important for backwards
compatibility. See section 2.9.
o Object 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.
An element of an RSVP control message; a type, length, value o Object
triplet.
o OPWA An element of an RSVP control message; a type, length, value
triplet.
Abbreviation for "One Pass With Advertising". Describes a o OPWA
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 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".
Interface through which data packets and Path messages are o Outgoing interface
forwarded.
o Packet classifier Interface through which data packets and Path messages are
forwarded.
Traffic control function in the primary data packet forwarding path o Packet classifier
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 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".
Traffic control function in the primary data packet forwarding path o Packet scheduler
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 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".
Information kept in routers and hosts about all RSVP senders. o Path state
o PathErr Information kept in routers and hosts about all RSVP senders.
Path Error RSVP control message. o PathErr
o PathTear Path Error RSVP control message.
Path Teardown RSVP control message. o PathTear
o PHOP Path Teardown RSVP control message.
An object that carries the Previous Hop information in RSVP control o PHOP
messages.
o Police An object that carries the Previous Hop information in RSVP
control messages.
See traffic policing. o Police
o Policy control See traffic policing.
A function that determines whether a new request for quality of o Policy control
service has administrative permission to make the requested
reservation. Policy control may also perform accounting (usage
feedback) for a reservation.
o Policy data 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.
Data carried in a Path or Resv message and used as input to policy o Policy data
control to determine authorization and/or usage feedback for the
given flow.
o Previous hop 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.
The previous router in the direction of traffic flow. Resv o Previous hop
messages flow towards previous hops.
o ProtocolId The previous router in the direction of traffic flow. Resv
messages flow towards previous hops.
The component of session identification that specifies the IP o ProtocolId
protocol number used by the data stream.
o QoS The component of session identification that specifies the IP
protocol number used by the data stream.
Quality of Service. o QoS
o Reservation state Quality of Service.
Information kept in RSVP-capable nodes about successful RSVP o Reservation state
reservation requests.
o Reservation style Information kept in RSVP-capable nodes about successful RSVP
reservation requests.
Describes a set of attributes for a reservation, including the o Reservation style
sharing attributes and sender selection attributes. See Section
1.3 for details.
o Resv message Describes a set of attributes for a reservation, including the
sharing attributes and sender selection attributes. See Section
1.3 for details.
Reservation request RSVP control message. o Resv message
o ResvConf Reservation request RSVP control message.
Reservation Confirmation RSVP control message, confirms successful o ResvConf
installation of a reservation at some upstream node.
o ResvErr Reservation Confirmation RSVP control message, confirms
Reservation Error control message, indicates that a reservation successful installation of a reservation at some upstream node.
request has failed or an active reservation has been preempted.
o ResvTear o ResvErr
Reservation Teardown RSVP control message, deletes reservation Reservation Error control message, indicates that a reservation
state. request has failed or an active reservation has been preempted.
o Rspec o ResvTear
The component of a flowspec that defines a desired QoS. The Rspec Reservation Teardown RSVP control message, deletes reservation
format is opaque to RSVP and is defined by the Integrated Services state.
Working Group of the IETF.
o RSVP_HOP o Rspec
Object of an RSVP control message that carries the PHOP or NHOP The component of a flowspec that defines a desired QoS. The
address of the source of the message. Rspec format is opaque to RSVP and is defined by the Integrated
Services Working Group of the IETF.
o Scope o RSVP_HOP
The set of sender hosts to which a given reservation request is to Object of an RSVP control message that carries the PHOP or NHOP
be propagated. address of the source of the message.
o SE style o Scope
Shared Explicit reservation style, which has explicit sender The set of sender hosts to which a given reservation request is
selection and shared attributes. to be propagated.
o Semantic fragmentation o SE style
A method of fragmenting a large RSVP message using information Shared Explicit reservation style, which has explicit sender
about the structure and contents of the message, so that each selection and shared attributes.
fragment is a logically complete RSVP message.
o Sender template o Semantic fragmentation
Parameter in a Path message that defines a sender; carried in a A method of fragmenting a large RSVP message using information
SENDER_TEMPLATE object. It has the form of a filter spec that can about the structure and contents of the message, so that each
be used to select this sender's packets from other packets in the fragment is a logically complete RSVP message.
same session on the same link.
o Sender Tspec o Sender template
Parameter in a Path message, a Tspec that characterizes the traffic Parameter in a Path message that defines a sender; carried in a
parameters for the data flow from the corresponding sender. It is SENDER_TEMPLATE object. It has the form of a filter spec that
carried in a SENDER_TSPEC object. can be used to select this sender's packets from other packets
in the same session on the same link.
o Session o Sender Tspec
An RSVP session defines one simplex unicast or multicast data flow Parameter in a Path message, a Tspec that characterizes the
for which reservations are required. A session is identified by traffic parameters for the data flow from the corresponding
the destination address, transport-layer protocol, and an optional sender. It is carried in a SENDER_TSPEC object.
(generalized) destination port.
o Shared style o Session
A (reservation) style attribute: all reserved senders share the An RSVP session defines one simplex unicast or multicast data
same reserved resources. See also "distinct style". flow for which reservations are required. A session is
identified by the destination address, transport-layer protocol,
and an optional (generalized) destination port.
o Soft state o Shared style
Control state in hosts and routers that will expire if not A (reservation) style attribute: all reserved senders share the
refreshed within a specified amount of time. same reserved resources. See also "distinct style".
o STYLE o Soft state
Object of an RSVP message that specifies the desired reservation Control state in hosts and routers that will expire if not
style. refreshed within a specified amount of time.
o Style o STYLE
See "reservation style" Object of an RSVP message that specifies the desired reservation
style.
o TIME_VALUES o Style
Object in an RSVP control message that specifies the time period See "reservation style"
timer used for refreshing the state in this message.
o Traffic control o TIME_VALUES
The entire set of machinery in the node that supplies requested QoS Object in an RSVP control message that specifies the time period
to data streams. Traffic control includes packet classifier, timer used for refreshing the state in this message.
packet scheduler, and admission control functions.
o Traffic policing o Traffic control
The function, performed by traffic control, of forcing a given data The entire set of machinery in the node that supplies requested
flow into compliance with the traffic parameters implied by the QoS to data streams. Traffic control includes packet
reservation. It may involve dropping non-compliant packets or classifier, packet scheduler, and admission control functions.
sending them with lower priority, for example.
o TSpec o Traffic policing
A traffic parameter set that describes a flow. The format of a The function, performed by traffic control, of forcing a given
Tspec is opaque to RSVP and is defined by the Integrated Service data flow into compliance with the traffic parameters implied by
Working Group. the reservation. It may involve dropping non-compliant packets
or sending them with lower priority, for example.
o UDP encapsulation o TSpec
A way for hosts that cannot use raw sockets to participate in RSVP A traffic parameter set that describes a flow. The format of a
by encapsulating the RSVP protocol (raw) packets in ordinary UDP Tspec is opaque to RSVP and is defined by the Integrated Service
packets. See Section APPENDIX C for more information. Working Group.
o Upstream o UDP encapsulation
Towards the traffic source. RSVP Resv messages flow upstream. 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 WF style o Upstream
Wildcard Filter reservation style, which has wildcard sender Towards the traffic source. RSVP Resv messages flow upstream.
selection and shared attributes.
o Wildcard sender selection o WF style
A (reservation) style attribute: traffic from any sender to a Wildcard Filter reservation style, which has wildcard sender
specific session receives the same QoS. See also "explicit sender selection and shared attributes.
selection".
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 References
[Baker96] Baker, F., "RSVP Cryptographic Authentication", Internet [Baker96] Baker, F., "RSVP Cryptographic Authentication", Work in
Draft <draft-ietf-rsvp-md5-02.txt>, June 1996. Progress.
[ISInt93] Braden, R., Clark, D., and S. Shenker, "Integrated Services [RFC 1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services
in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and
PARC, June 1994. PARC, June 1994.
[FJ94] Floyd, S. and V. Jacobson, "Synchronization of Periodic Routing [FJ94] Floyd, S. and V. Jacobson, "Synchronization of Periodic Routing
Messages", IEEE/ACM Transactions on Networking, Vol. 2, No. 2, Messages", IEEE/ACM Transactions on Networking, Vol. 2, No. 2,
April, 1994. April, 1994.
[IPSEC96] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data [RFC 2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
Flows", Internet Draft, <draft-ietf-rsvp-ext-07.txt>, Fore Systems Flows", RFC 2207, September 1997.
and BBN, March 1997.
[Katz97] Katz, D., "IP Router Alert Option", RFC 2113, cisco Systems, [RFC 2113] Katz, D., "IP Router Alert Option", RFC 2113, cisco Systems,
February 1997. February 1997.
[ISrsvp96] Wroclawski, J., "The Use of RSVP with Integrated Services", [RFC 2210] Wroclawski, J., "The Use of RSVP with Integrated Services",
<draft-ietf-intserv-rsvp-use.01.txt>, MIT, October 1996. RFC 2210, September 1997.
[PolArch96] Herzog, S., "Policy Control for RSVP: Architectural [PolArch96] Herzog, S., "Policy Control for RSVP: Architectural
Overview". <draft-ietf-rsvp-policy-arch-01.txt>, IBM, November Overview". Work in Progress.
1996.
[OPWA95] Shenker, S. and L. Breslau, "Two Issues in Reservation [OPWA95] Shenker, S. and L. Breslau, "Two Issues in Reservation
Establishment", Proc. ACM SIGCOMM '95, Cambridge, MA, August 1995. Establishment", Proc. ACM SIGCOMM '95, Cambridge, MA, August 1995.
[RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. [RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D.
Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network, Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network,
September 1993. September 1993.
Security Considerations Security Considerations
skipping to change at page 109, line 29 skipping to change at page 112, line 16
Bob Braden Bob Braden
USC Information Sciences Institute USC Information Sciences Institute
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292 Marina del Rey, CA 90292
Phone: (310) 822-1511 Phone: (310) 822-1511
EMail: Braden@ISI.EDU EMail: Braden@ISI.EDU
Lixia Zhang Lixia Zhang
Xerox Palo Alto Research Center UCLA Computer Science Department
3333 Coyote Hill Road 4531G Boelter Hall
Palo Alto, CA 94304 Los Angeles, CA 90095-1596 USA
Phone: (415) 812-4415 Phone: 310-825-2695
EMail: Lixia@PARC.XEROX.COM EMail: lixia@cs.ucla.edu
Steve Berson Steve Berson
USC Information Sciences Institute USC Information Sciences Institute
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292 Marina del Rey, CA 90292
Phone: (310) 822-1511 Phone: (310) 822-1511
EMail: Berson@ISI.EDU EMail: Berson@ISI.EDU
Shai Herzog Shai Herzog
IBM T. J. Watson Research Center IBM T. J. Watson Research Center
P.O Box 704 P.O Box 704
Yorktown Heights, NY 10598 Yorktown Heights, NY 10598
Phone: (914) 784-6059 Phone: (914) 784-6059
EMail: Herzog@WATSON.IBM.COM EMail: Herzog@WATSON.IBM.COM
Sugih Jamin Sugih Jamin
University of Michigan University of Michigan
 End of changes. 425 change blocks. 
882 lines changed or deleted 910 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/