Cisco IOS Software supports two fundamental Quality of Service architectures: Differentiated Services (DiffServ) and Integrated Services (IntServ). In the DiffServ model a packet's "class" can be marked directly in the packet, which contrasts with the IntServ model where a signaling protocol is required to tell the routers which flows of packets requires special QoS treatment. DiffServ achieves better QoS scalability, while IntServ provides a tighter QoS mechanism for real-time traffic. These approaches can be complimentary and are not mutually exclusive.

The IntServ architecture model (RFC 1633, June 1994) was motivated by the needs of real-time applications such as remote video, multimedia conferencing, visualization, and virtual reality. It provides a way to deliver the end-to-end Quality of Service (QoS) that real-time applications require by explicitly managing network resources to provide QoS to specific user packet streams (flows). It uses resource reservation and admission control mechanisms as key building blocks to establish and maintain QoS.

IntServ uses Resource Reservation Protocol (RSVP) to explicitly signal the QoS needs of an application's traffic along the devices in the end-to-end path through the network. If every network device along the path can reserve the necessary bandwidth, the originating application can begin transmitting.

Besides end-to-end signaling, IntServ requires several functions on routers and switches along the path:

Network Working Group R. Braden, Ed. Request for Comments: 2205 ISI Category: Standards Track L. Zhang

                                                              UCLA

19. Berson

                                                                   ISI

20. Herzog IBM Research
21. Jamin Univ. of Michigan September 1997 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. Braden, Ed., et. al. Standards Track [Page 1]

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

---

RFC 2205 RSVP September 1997 What's Changed This revision contains the following very minor changes from the ID14 version.

  o    For clarity, each message type is now defined separately in
       [Section 3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1).

  o    We added more precise and complete rules for accepting Path
       messages for unicast and multicast destinations ([Section](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)

       [3.1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)).

  o    We added more precise and complete rules for processing and
       forwarding PathTear messages ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    A note was added that a SCOPE object will be ignored if it
       appears in a ResvTear message ([Section 3.1.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.6)).

  o    A note was added that a SENDER_TSPEC or ADSPEC object will be
       ignored if it appears in a PathTear message ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    The obsolete error code Ambiguous Filter Spec (09) was
       removed, and a new (and more consistent) name was given to
       error code 08 (Appendix B).
  o    In the generic interface to traffic control, the Adspec was
       added as a parameter to the AddFlow and ModFlow calls
       (3.11.2).  This is needed to accommodate a node that updates
       the slack term (S) of Guaranteed service.
  o    An error subtype was added for an Adspec error (Appendix B).
  o    Additional explanation was added for handling a CONFIRM
       object ([Section 3.1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.4)).

  o    The rules for forwarding objects with unknown class type were
       clarified.
  o    Additional discussion was added to the Introduction and to
       [Section 3.11.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11.2) about the relationship of RSVP to the link

       layer.  ([Section 3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10)).

  o    [Section 2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) on Policy and Security was split into two

       sections, and some additional discussion of security was
       included.
  o    There were some minor editorial improvements.

Braden, Ed., et. al. Standards Track [Page 3]

---

RFC 2205 RSVP September 1997 [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction

This document defines RSVP, a resource reservation setup protocol designed for an integrated services Internet RSVP93, [RFC 1633]. The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or 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 establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path. RSVP requests resources for simplex flows, i.e., it requests resources in only one direction. Therefore, RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. Like the implementations of routing and management protocols, an implementation of RSVP will typically execute in the background, not in the data forwarding path, as shown in Figure 1. RSVP is not itself a routing protocol; RSVP is designed to operate with current and future unicast and multicast routing protocols. An RSVP process consults the local routing database(s) to obtain routes. In the multicast case, for example, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group. Routing protocols determine where packets get forwarded; RSVP is only concerned with the QoS of those packets that are forwarded in accordance with routing. In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)]. A QoS

request from a receiver host application is passed to the local RSVP process. The RSVP protocol then carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data source(s), but only as far as the router where the receiver's data path joins the multicast distribution tree. As a result, RSVP's reservation overhead is in general logarithmic rather than linear in the number of receivers. Braden, Ed., et. al. Standards Track [Page 4]

---

RFC 2205 RSVP September 1997

          HOST                              ROUTER

_

_
		_		_
	Appli-				RSVP

| | cation| | RSVP <---------------------------> RSVP <---------->

<-->

_

process

_

Routing

process

_

.

-->Polcy

<> >Polcy

.._

Cntrl

process

.._

Cntrl

data

_

.

_

===

===========

==

==========

===

==========

==

==========

_

_

>Admis

>Admis

V__V V_

Cntrl

V__V V_

Cntrl

_

_

Class-

Packet

Class-

Packet

| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>

| || || |data | || || |data

|_____________________________| |____________________________|

              Figure 1: RSVP in Hosts and Routers

Quality of service is implemented for a particular data flow by

mechanisms collectively called "traffic control". These mechanisms include (1) a packet classifier, (2) admission control, and (3) a "packet scheduler" or some other link-layer-dependent mechanism to determine when particular packets are forwarded. The "packet classifier" determines the QoS class (and perhaps the route) for each packet. For each outgoing interface, the "packet scheduler" or other link-layer-dependent mechanism achieves the promised QoS. Traffic control implements QoS service models defined by the Integrated Services Working Group. During reservation setup, an RSVP QoS request is passed to two local decision modules, "admission control" and "policy control". Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy control Braden, Ed., et. al. Standards Track [Page 5]

---

RFC 2205 RSVP September 1997 determines whether the user has administrative permission to make the reservation. If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. If either check fails, the RSVP program returns an error notification to the application process that originated the request. RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths. RSVP itself transfers and manipulates QoS and policy control parameters as opaque data, passing them to the appropriate traffic control and policy control modules for interpretation. The structure and contents of the QoS parameters are documented in specifications developed by the Integrated Services Working Group; see [RFC 2210]. The structure and contents of the policy parameters are under development. Since the membership of a large multicast group and the resulting multicast tree topology are likely to change with time, the RSVP design assumes that state for RSVP and traffic control state is to be built and destroyed incrementally in routers and hosts. For this purpose, RSVP establishes "soft" state; that is, RSVP sends periodic refresh messages to maintain the state along the reserved path(s). In the absence of refresh messages, the state automatically times out and is deleted. In summary, RSVP has the following attributes: o RSVP makes resource reservations for both unicast and many-to-

    many multicast applications, adapting dynamically to changing
    group membership as well as to changing routes.

o RSVP is simplex, i.e., it makes reservations for unidirectional

    data flows.

o RSVP is receiver-oriented, i.e., the receiver of a data flow

    initiates and maintains the resource reservation used for that
    flow.

o RSVP maintains "soft" state in routers and hosts, providing

    graceful support for dynamic membership changes and automatic
    adaptation to routing changes.

o RSVP is not a routing protocol but depends upon present and

    future routing protocols.

o RSVP transports and maintains traffic control and policy control

    parameters that are opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 6]

---

RFC 2205 RSVP September 1997 o RSVP provides several reservation models or "styles" (defined

    below) to fit a variety of applications.

o RSVP provides transparent operation through routers that do not

    support it.

o RSVP supports both IPv4 and IPv6. Further discussion on the objectives and general justification for RSVP design are presented in [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)] and [RFC 1633].

The remainder of this section describes the RSVP reservation services. [Section 2](https://datatracker.ietf.org/doc/html/rfc2205

section-2) presents an overview of the RSVP protocol

mechanisms. [Section 3](https://datatracker.ietf.org/doc/html/rfc2205

section-3) contains the functional specification of RSVP,

while [Section 4](https://datatracker.ietf.org/doc/html/rfc2205

section-4) presents explicit message processing rules. [Appendix](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A)

[A](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A) defines the variable-length typed data objects used in the RSVP

protocol. [Appendix B](https://datatracker.ietf.org/doc/html/rfc2205

appendix-B) defines error codes and values. [Appendix C](https://datatracker.ietf.org/doc/html/rfc2205

appendix-C)

defines a UDP encapsulation of RSVP messages, for hosts whose operating systems provide inadequate raw network I/O support. 1.1 Data Flows

  RSVP defines a "session" to be a data flow with a particular
  destination and transport-layer protocol.  RSVP treats each
  session independently, and this document often omits the implied
  qualification "for the same session".
  An RSVP session is defined by the triple: (DestAddress, ProtocolId
  [, DstPort]).  Here DestAddress, the IP destination address of the
  data packets, may be a unicast or multicast address.  ProtocolId
  is the IP protocol ID.  The optional DstPort parameter is a
  "generalized destination port", i.e., some further demultiplexing
  point in the transport or application protocol layer.  DstPort
  could be defined by a UDP/TCP destination port field, by an
  equivalent field in another transport protocol, or by some
  application-specific information.
  Although the RSVP protocol is designed to be easily extensible for
  greater generality, the basic protocol documented here supports
  only UDP/TCP ports as generalized ports.  Note that it is not
  strictly necessary to include DstPort in the session definition
  when DestAddress is multicast, since different sessions can always
  have different multicast addresses.  However, DstPort is necessary
  to allow more than one unicast session addressed to the same
  receiver host.

Braden, Ed., et. al. Standards Track [Page 7]

---

RFC 2205 RSVP September 1997

  Figure 2 illustrates the flow of data packets in a single RSVP
  session, assuming multicast data distribution.  The arrows
  indicate data flowing from senders S1 and S2 to receivers R1, R2,
  and R3, and the cloud represents the distribution mesh created by
  multicast routing.  Multicast distribution forwards a copy of each
  data packet from a sender Si to every receiver Rj; a unicast
  distribution session has a single receiver R.  Each sender Si may
  be running in a unique Internet host, or a single host may contain
  multiple senders distinguished by "generalized source ports".
          Senders                              Receivers
                      _____________________
                     (                     ) ===> R1
             S1 ===> (    Multicast        )
                     (                     ) ===> R2
                     (    distribution     )
             S2 ===> (                     )
                     (    by Internet      ) ===> R3
                     (_____________________)
             Figure 2: Multicast Distribution Session
  For unicast transmission, there will be a single destination host
  but there may be multiple senders; RSVP can set up reservations
  for multipoint-to-single-point transmission.

1.2 Reservation Model

  An elementary RSVP reservation request consists of a "flowspec"
  together with a "filter spec"; this pair is called a "flow
  descriptor".  The flowspec specifies a desired QoS.  The filter
  spec, together with a session specification, defines the set of
  data packets -- the "flow" -- to receive the QoS defined by the
  flowspec.  The flowspec is used to set parameters in the node's
  packet scheduler or other link layer mechanism, while the filter
  spec is used to set parameters in the packet classifier.  Data
  packets that are addressed to a particular session but do not
  match any of the filter specs for that session are handled as
  best-effort traffic.
  The flowspec in a reservation request will generally include a
  service class and two sets of numeric parameters: (1) an "Rspec"
  (R for `reserve') that defines the desired QoS, and (2) a "Tspec"
  (T for `traffic') that describes the data flow.  The formats and
  contents of Tspecs and Rspecs are determined by the integrated
  service models [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] and are generally opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 8]

---

RFC 2205 RSVP September 1997

  The exact format of a filter spec depends upon whether IPv4 or
  IPv6 is in use; see [Appendix A](https://datatracker.ietf.org/doc/html/rfc2205

# appendix-A). In the most general approach

  [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

# ref-RSVP93)], filter specs may select arbitrary subsets of the packets

  in a given session.  Such subsets might be defined in terms of
  senders (i.e., sender IP address and generalized source port), in
  terms of a higher-level protocol, or generally in terms of any
  fields in any protocol headers in the packet.  For example, filter
  specs might be used to select different subflows of a
  hierarchically-encoded video stream by selecting on fields in an
  application-layer header.  In the interest of simplicity (and to
  minimize layer violation), the basic filter spec format defined in
  the present RSVP specification has a very restricted form: sender
  IP address and optionally the UDP/TCP port number SrcPort.
  Because the UDP/TCP port numbers are used for packet
  classification, each router must be able to examine these fields.
  This raises three potential problems.

1. It is necessary to avoid IP fragmentation of a data flow for

          which a resource reservation is desired.
          Document [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] specifies a procedure for applications
          using RSVP facilities to compute the minimum MTU over a
          multicast tree and return the result to the senders.

2. IPv6 inserts a variable number of variable-length Internet- layer headers before the transport header, increasing the difficulty and cost of packet classification for QoS. Efficient classification of IPv6 data packets could be obtained using the Flow Label field of the IPv6 header. The details will be provided in the future.
3. IP-level Security, under either IPv4 or IPv6, may encrypt the entire transport header, hiding the port numbers of data packets from intermediate routers. A small extension to RSVP for IP Security under IPv4 and IPv6 is described separately in [[RFC 2207](https://datatracker.ietf.org/doc/html/rfc2207)]. RSVP messages carrying reservation requests originate at receivers and are passed upstream towards the sender(s). Note: in this document, we define the directional terms "upstream" vs. "downstream", "previous hop" vs. "next hop", and "incoming interface" vs "outgoing interface" with respect to the direction of data flow. Braden, Ed., et. al. Standards Track [Page 9]

---

RFC 2205 RSVP September 1997

  At each intermediate node, a reservation request triggers two
  general actions, as follows:

1. Make a reservation on a link

          The RSVP process passes the request to admission control and
          policy control.  If either test fails, the reservation is
          rejected and the RSVP process returns an error message to the
          appropriate receiver(s).  If both succeed, the node sets the
          packet classifier to select the data packets defined by the
          filter spec, and it interacts with the appropriate link layer
          to obtain the desired QoS defined by the flowspec.
          The detailed rules for satisfying an RSVP QoS request depend
          upon the particular link layer technology in use on each
          interface.  Specifications are under development in the ISSLL
          Working Group for mapping reservation requests into popular
          link layer technologies.  For a simple leased line, the
          desired QoS will be obtained from the packet scheduler in the
          link layer driver, for example.  If the link-layer technology
          implements its own QoS management capability, then RSVP must
          negotiate with the link layer to obtain the requested QoS.
          Note that the action to control QoS occurs at the place where
          the data enters the link-layer medium, i.e., at the upstream
          end of the logical or physical link, although an RSVP
          reservation request originates from receiver(s) downstream.

2. Forward the request upstream A reservation request is propagated upstream towards the appropriate senders. The set of sender hosts to which a given reservation request is propagated is called the "scope" of that request. The reservation request that a node forwards upstream may differ from the request that it received from downstream, for two reasons. The traffic control mechanism may modify the flowspec hop-by-hop. More importantly, reservations from different downstream branches of the multicast tree(s) from the same sender (or set of senders) must be " merged" as reservations travel upstream. When a receiver originates a reservation request, it can also request a confirmation message to indicate that its request was (probably) installed in the network. A successful reservation request propagates upstream along the multicast tree until it reaches a point where an existing reservation is equal or greater Braden, Ed., et. al. Standards Track [Page 10]

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

0

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

1

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

2

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

3

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

4

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

5

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

6

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

7

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

8

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

9

---

RFC 2205 RSVP September 1997 What's Changed This revision contains the following very minor changes from the ID14 version.

  o    For clarity, each message type is now defined separately in
       [Section 3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1).

  o    We added more precise and complete rules for accepting Path
       messages for unicast and multicast destinations ([Section](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)

       [3.1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)).

  o    We added more precise and complete rules for processing and
       forwarding PathTear messages ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    A note was added that a SCOPE object will be ignored if it
       appears in a ResvTear message ([Section 3.1.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.6)).

  o    A note was added that a SENDER_TSPEC or ADSPEC object will be
       ignored if it appears in a PathTear message ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    The obsolete error code Ambiguous Filter Spec (09) was
       removed, and a new (and more consistent) name was given to
       error code 08 (Appendix B).
  o    In the generic interface to traffic control, the Adspec was
       added as a parameter to the AddFlow and ModFlow calls
       (3.11.2).  This is needed to accommodate a node that updates
       the slack term (S) of Guaranteed service.
  o    An error subtype was added for an Adspec error (Appendix B).
  o    Additional explanation was added for handling a CONFIRM
       object ([Section 3.1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.4)).

  o    The rules for forwarding objects with unknown class type were
       clarified.
  o    Additional discussion was added to the Introduction and to
       [Section 3.11.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11.2) about the relationship of RSVP to the link

       layer.  ([Section 3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10)).

  o    [Section 2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) on Policy and Security was split into two

       sections, and some additional discussion of security was
       included.
  o    There were some minor editorial improvements.

Braden, Ed., et. al. Standards Track [Page 3]

0

---

RFC 2205 RSVP September 1997 What's Changed This revision contains the following very minor changes from the ID14 version.

  o    For clarity, each message type is now defined separately in
       [Section 3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1).

  o    We added more precise and complete rules for accepting Path
       messages for unicast and multicast destinations ([Section](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)

       [3.1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)).

  o    We added more precise and complete rules for processing and
       forwarding PathTear messages ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    A note was added that a SCOPE object will be ignored if it
       appears in a ResvTear message ([Section 3.1.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.6)).

  o    A note was added that a SENDER_TSPEC or ADSPEC object will be
       ignored if it appears in a PathTear message ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    The obsolete error code Ambiguous Filter Spec (09) was
       removed, and a new (and more consistent) name was given to
       error code 08 (Appendix B).
  o    In the generic interface to traffic control, the Adspec was
       added as a parameter to the AddFlow and ModFlow calls
       (3.11.2).  This is needed to accommodate a node that updates
       the slack term (S) of Guaranteed service.
  o    An error subtype was added for an Adspec error (Appendix B).
  o    Additional explanation was added for handling a CONFIRM
       object ([Section 3.1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.4)).

  o    The rules for forwarding objects with unknown class type were
       clarified.
  o    Additional discussion was added to the Introduction and to
       [Section 3.11.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11.2) about the relationship of RSVP to the link

       layer.  ([Section 3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10)).

  o    [Section 2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) on Policy and Security was split into two

       sections, and some additional discussion of security was
       included.
  o    There were some minor editorial improvements.

Braden, Ed., et. al. Standards Track [Page 3]

1

---

RFC 2205 RSVP September 1997 What's Changed This revision contains the following very minor changes from the ID14 version.

  o    For clarity, each message type is now defined separately in
       [Section 3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1).

  o    We added more precise and complete rules for accepting Path
       messages for unicast and multicast destinations ([Section](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)

       [3.1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)).

  o    We added more precise and complete rules for processing and
       forwarding PathTear messages ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    A note was added that a SCOPE object will be ignored if it
       appears in a ResvTear message ([Section 3.1.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.6)).

  o    A note was added that a SENDER_TSPEC or ADSPEC object will be
       ignored if it appears in a PathTear message ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    The obsolete error code Ambiguous Filter Spec (09) was
       removed, and a new (and more consistent) name was given to
       error code 08 (Appendix B).
  o    In the generic interface to traffic control, the Adspec was
       added as a parameter to the AddFlow and ModFlow calls
       (3.11.2).  This is needed to accommodate a node that updates
       the slack term (S) of Guaranteed service.
  o    An error subtype was added for an Adspec error (Appendix B).
  o    Additional explanation was added for handling a CONFIRM
       object ([Section 3.1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.4)).

  o    The rules for forwarding objects with unknown class type were
       clarified.
  o    Additional discussion was added to the Introduction and to
       [Section 3.11.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11.2) about the relationship of RSVP to the link

       layer.  ([Section 3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10)).

  o    [Section 2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) on Policy and Security was split into two

       sections, and some additional discussion of security was
       included.
  o    There were some minor editorial improvements.

Braden, Ed., et. al. Standards Track [Page 3]

2

---

RFC 2205 RSVP September 1997 What's Changed This revision contains the following very minor changes from the ID14 version.

  o    For clarity, each message type is now defined separately in
       [Section 3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1).

  o    We added more precise and complete rules for accepting Path
       messages for unicast and multicast destinations ([Section](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)

       [3.1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)).

  o    We added more precise and complete rules for processing and
       forwarding PathTear messages ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    A note was added that a SCOPE object will be ignored if it
       appears in a ResvTear message ([Section 3.1.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.6)).

  o    A note was added that a SENDER_TSPEC or ADSPEC object will be
       ignored if it appears in a PathTear message ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    The obsolete error code Ambiguous Filter Spec (09) was
       removed, and a new (and more consistent) name was given to
       error code 08 (Appendix B).
  o    In the generic interface to traffic control, the Adspec was
       added as a parameter to the AddFlow and ModFlow calls
       (3.11.2).  This is needed to accommodate a node that updates
       the slack term (S) of Guaranteed service.
  o    An error subtype was added for an Adspec error (Appendix B).
  o    Additional explanation was added for handling a CONFIRM
       object ([Section 3.1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.4)).

  o    The rules for forwarding objects with unknown class type were
       clarified.
  o    Additional discussion was added to the Introduction and to
       [Section 3.11.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11.2) about the relationship of RSVP to the link

       layer.  ([Section 3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10)).

  o    [Section 2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) on Policy and Security was split into two

       sections, and some additional discussion of security was
       included.
  o    There were some minor editorial improvements.

Braden, Ed., et. al. Standards Track [Page 3]

3

---

RFC 2205 RSVP September 1997 What's Changed This revision contains the following very minor changes from the ID14 version.

  o    For clarity, each message type is now defined separately in
       [Section 3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1).

  o    We added more precise and complete rules for accepting Path
       messages for unicast and multicast destinations ([Section](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)

       [3.1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)).

  o    We added more precise and complete rules for processing and
       forwarding PathTear messages ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    A note was added that a SCOPE object will be ignored if it
       appears in a ResvTear message ([Section 3.1.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.6)).

  o    A note was added that a SENDER_TSPEC or ADSPEC object will be
       ignored if it appears in a PathTear message ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    The obsolete error code Ambiguous Filter Spec (09) was
       removed, and a new (and more consistent) name was given to
       error code 08 (Appendix B).
  o    In the generic interface to traffic control, the Adspec was
       added as a parameter to the AddFlow and ModFlow calls
       (3.11.2).  This is needed to accommodate a node that updates
       the slack term (S) of Guaranteed service.
  o    An error subtype was added for an Adspec error (Appendix B).
  o    Additional explanation was added for handling a CONFIRM
       object ([Section 3.1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.4)).

  o    The rules for forwarding objects with unknown class type were
       clarified.
  o    Additional discussion was added to the Introduction and to
       [Section 3.11.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11.2) about the relationship of RSVP to the link

       layer.  ([Section 3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10)).

  o    [Section 2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) on Policy and Security was split into two

       sections, and some additional discussion of security was
       included.
  o    There were some minor editorial improvements.

Braden, Ed., et. al. Standards Track [Page 3]

4

---

RFC 2205 RSVP September 1997 What's Changed This revision contains the following very minor changes from the ID14 version.

  o    For clarity, each message type is now defined separately in
       [Section 3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1).

  o    We added more precise and complete rules for accepting Path
       messages for unicast and multicast destinations ([Section](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)

       [3.1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)).

  o    We added more precise and complete rules for processing and
       forwarding PathTear messages ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    A note was added that a SCOPE object will be ignored if it
       appears in a ResvTear message ([Section 3.1.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.6)).

  o    A note was added that a SENDER_TSPEC or ADSPEC object will be
       ignored if it appears in a PathTear message ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    The obsolete error code Ambiguous Filter Spec (09) was
       removed, and a new (and more consistent) name was given to
       error code 08 (Appendix B).
  o    In the generic interface to traffic control, the Adspec was
       added as a parameter to the AddFlow and ModFlow calls
       (3.11.2).  This is needed to accommodate a node that updates
       the slack term (S) of Guaranteed service.
  o    An error subtype was added for an Adspec error (Appendix B).
  o    Additional explanation was added for handling a CONFIRM
       object ([Section 3.1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.4)).

  o    The rules for forwarding objects with unknown class type were
       clarified.
  o    Additional discussion was added to the Introduction and to
       [Section 3.11.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11.2) about the relationship of RSVP to the link

       layer.  ([Section 3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10)).

  o    [Section 2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) on Policy and Security was split into two

       sections, and some additional discussion of security was
       included.
  o    There were some minor editorial improvements.

Braden, Ed., et. al. Standards Track [Page 3]

5

---

RFC 2205 RSVP September 1997 What's Changed This revision contains the following very minor changes from the ID14 version.

  o    For clarity, each message type is now defined separately in
       [Section 3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1).

  o    We added more precise and complete rules for accepting Path
       messages for unicast and multicast destinations ([Section](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)

       [3.1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)).

  o    We added more precise and complete rules for processing and
       forwarding PathTear messages ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    A note was added that a SCOPE object will be ignored if it
       appears in a ResvTear message ([Section 3.1.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.6)).

  o    A note was added that a SENDER_TSPEC or ADSPEC object will be
       ignored if it appears in a PathTear message ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    The obsolete error code Ambiguous Filter Spec (09) was
       removed, and a new (and more consistent) name was given to
       error code 08 (Appendix B).
  o    In the generic interface to traffic control, the Adspec was
       added as a parameter to the AddFlow and ModFlow calls
       (3.11.2).  This is needed to accommodate a node that updates
       the slack term (S) of Guaranteed service.
  o    An error subtype was added for an Adspec error (Appendix B).
  o    Additional explanation was added for handling a CONFIRM
       object ([Section 3.1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.4)).

  o    The rules for forwarding objects with unknown class type were
       clarified.
  o    Additional discussion was added to the Introduction and to
       [Section 3.11.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11.2) about the relationship of RSVP to the link

       layer.  ([Section 3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10)).

  o    [Section 2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) on Policy and Security was split into two

       sections, and some additional discussion of security was
       included.
  o    There were some minor editorial improvements.

Braden, Ed., et. al. Standards Track [Page 3]

6

---

RFC 2205 RSVP September 1997 What's Changed This revision contains the following very minor changes from the ID14 version.

  o    For clarity, each message type is now defined separately in
       [Section 3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1).

  o    We added more precise and complete rules for accepting Path
       messages for unicast and multicast destinations ([Section](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)

       [3.1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)).

  o    We added more precise and complete rules for processing and
       forwarding PathTear messages ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    A note was added that a SCOPE object will be ignored if it
       appears in a ResvTear message ([Section 3.1.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.6)).

  o    A note was added that a SENDER_TSPEC or ADSPEC object will be
       ignored if it appears in a PathTear message ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    The obsolete error code Ambiguous Filter Spec (09) was
       removed, and a new (and more consistent) name was given to
       error code 08 (Appendix B).
  o    In the generic interface to traffic control, the Adspec was
       added as a parameter to the AddFlow and ModFlow calls
       (3.11.2).  This is needed to accommodate a node that updates
       the slack term (S) of Guaranteed service.
  o    An error subtype was added for an Adspec error (Appendix B).
  o    Additional explanation was added for handling a CONFIRM
       object ([Section 3.1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.4)).

  o    The rules for forwarding objects with unknown class type were
       clarified.
  o    Additional discussion was added to the Introduction and to
       [Section 3.11.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11.2) about the relationship of RSVP to the link

       layer.  ([Section 3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10)).

  o    [Section 2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) on Policy and Security was split into two

       sections, and some additional discussion of security was
       included.
  o    There were some minor editorial improvements.

Braden, Ed., et. al. Standards Track [Page 3]

7

---

RFC 2205 RSVP September 1997 What's Changed This revision contains the following very minor changes from the ID14 version.

  o    For clarity, each message type is now defined separately in
       [Section 3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1).

  o    We added more precise and complete rules for accepting Path
       messages for unicast and multicast destinations ([Section](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)

       [3.1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)).

  o    We added more precise and complete rules for processing and
       forwarding PathTear messages ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    A note was added that a SCOPE object will be ignored if it
       appears in a ResvTear message ([Section 3.1.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.6)).

  o    A note was added that a SENDER_TSPEC or ADSPEC object will be
       ignored if it appears in a PathTear message ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    The obsolete error code Ambiguous Filter Spec (09) was
       removed, and a new (and more consistent) name was given to
       error code 08 (Appendix B).
  o    In the generic interface to traffic control, the Adspec was
       added as a parameter to the AddFlow and ModFlow calls
       (3.11.2).  This is needed to accommodate a node that updates
       the slack term (S) of Guaranteed service.
  o    An error subtype was added for an Adspec error (Appendix B).
  o    Additional explanation was added for handling a CONFIRM
       object ([Section 3.1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.4)).

  o    The rules for forwarding objects with unknown class type were
       clarified.
  o    Additional discussion was added to the Introduction and to
       [Section 3.11.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11.2) about the relationship of RSVP to the link

       layer.  ([Section 3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10)).

  o    [Section 2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) on Policy and Security was split into two

       sections, and some additional discussion of security was
       included.
  o    There were some minor editorial improvements.

Braden, Ed., et. al. Standards Track [Page 3]

8

---

RFC 2205 RSVP September 1997 What's Changed This revision contains the following very minor changes from the ID14 version.

  o    For clarity, each message type is now defined separately in
       [Section 3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1).

  o    We added more precise and complete rules for accepting Path
       messages for unicast and multicast destinations ([Section](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)

       [3.1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.3)).

  o    We added more precise and complete rules for processing and
       forwarding PathTear messages ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    A note was added that a SCOPE object will be ignored if it
       appears in a ResvTear message ([Section 3.1.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.6)).

  o    A note was added that a SENDER_TSPEC or ADSPEC object will be
       ignored if it appears in a PathTear message ([Section 3.1.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.5)).

  o    The obsolete error code Ambiguous Filter Spec (09) was
       removed, and a new (and more consistent) name was given to
       error code 08 (Appendix B).
  o    In the generic interface to traffic control, the Adspec was
       added as a parameter to the AddFlow and ModFlow calls
       (3.11.2).  This is needed to accommodate a node that updates
       the slack term (S) of Guaranteed service.
  o    An error subtype was added for an Adspec error (Appendix B).
  o    Additional explanation was added for handling a CONFIRM
       object ([Section 3.1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1.4)).

  o    The rules for forwarding objects with unknown class type were
       clarified.
  o    Additional discussion was added to the Introduction and to
       [Section 3.11.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11.2) about the relationship of RSVP to the link

       layer.  ([Section 3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10)).

  o    [Section 2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) on Policy and Security was split into two

       sections, and some additional discussion of security was
       included.
  o    There were some minor editorial improvements.

Braden, Ed., et. al. Standards Track [Page 3]

9

---

RFC 2205 RSVP September 1997 [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction

This document defines RSVP, a resource reservation setup protocol designed for an integrated services Internet RSVP93, [RFC 1633]. The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or 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 establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path. RSVP requests resources for simplex flows, i.e., it requests resources in only one direction. Therefore, RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. Like the implementations of routing and management protocols, an implementation of RSVP will typically execute in the background, not in the data forwarding path, as shown in Figure 1. RSVP is not itself a routing protocol; RSVP is designed to operate with current and future unicast and multicast routing protocols. An RSVP process consults the local routing database(s) to obtain routes. In the multicast case, for example, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group. Routing protocols determine where packets get forwarded; RSVP is only concerned with the QoS of those packets that are forwarded in accordance with routing. In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)]. A QoS

request from a receiver host application is passed to the local RSVP process. The RSVP protocol then carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data source(s), but only as far as the router where the receiver's data path joins the multicast distribution tree. As a result, RSVP's reservation overhead is in general logarithmic rather than linear in the number of receivers. Braden, Ed., et. al. Standards Track [Page 4]

0

---

RFC 2205 RSVP September 1997 [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction

This document defines RSVP, a resource reservation setup protocol designed for an integrated services Internet RSVP93, [RFC 1633]. The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or 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 establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path. RSVP requests resources for simplex flows, i.e., it requests resources in only one direction. Therefore, RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. Like the implementations of routing and management protocols, an implementation of RSVP will typically execute in the background, not in the data forwarding path, as shown in Figure 1. RSVP is not itself a routing protocol; RSVP is designed to operate with current and future unicast and multicast routing protocols. An RSVP process consults the local routing database(s) to obtain routes. In the multicast case, for example, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group. Routing protocols determine where packets get forwarded; RSVP is only concerned with the QoS of those packets that are forwarded in accordance with routing. In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)]. A QoS

request from a receiver host application is passed to the local RSVP process. The RSVP protocol then carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data source(s), but only as far as the router where the receiver's data path joins the multicast distribution tree. As a result, RSVP's reservation overhead is in general logarithmic rather than linear in the number of receivers. Braden, Ed., et. al. Standards Track [Page 4]

1

---

RFC 2205 RSVP September 1997 [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction

This document defines RSVP, a resource reservation setup protocol designed for an integrated services Internet RSVP93, [RFC 1633]. The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or 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 establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path. RSVP requests resources for simplex flows, i.e., it requests resources in only one direction. Therefore, RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. Like the implementations of routing and management protocols, an implementation of RSVP will typically execute in the background, not in the data forwarding path, as shown in Figure 1. RSVP is not itself a routing protocol; RSVP is designed to operate with current and future unicast and multicast routing protocols. An RSVP process consults the local routing database(s) to obtain routes. In the multicast case, for example, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group. Routing protocols determine where packets get forwarded; RSVP is only concerned with the QoS of those packets that are forwarded in accordance with routing. In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)]. A QoS

request from a receiver host application is passed to the local RSVP process. The RSVP protocol then carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data source(s), but only as far as the router where the receiver's data path joins the multicast distribution tree. As a result, RSVP's reservation overhead is in general logarithmic rather than linear in the number of receivers. Braden, Ed., et. al. Standards Track [Page 4]

2

---

RFC 2205 RSVP September 1997 [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction

This document defines RSVP, a resource reservation setup protocol designed for an integrated services Internet RSVP93, [RFC 1633]. The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or 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 establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path. RSVP requests resources for simplex flows, i.e., it requests resources in only one direction. Therefore, RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. Like the implementations of routing and management protocols, an implementation of RSVP will typically execute in the background, not in the data forwarding path, as shown in Figure 1. RSVP is not itself a routing protocol; RSVP is designed to operate with current and future unicast and multicast routing protocols. An RSVP process consults the local routing database(s) to obtain routes. In the multicast case, for example, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group. Routing protocols determine where packets get forwarded; RSVP is only concerned with the QoS of those packets that are forwarded in accordance with routing. In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)]. A QoS

request from a receiver host application is passed to the local RSVP process. The RSVP protocol then carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data source(s), but only as far as the router where the receiver's data path joins the multicast distribution tree. As a result, RSVP's reservation overhead is in general logarithmic rather than linear in the number of receivers. Braden, Ed., et. al. Standards Track [Page 4]

3

---

RFC 2205 RSVP September 1997 [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction

This document defines RSVP, a resource reservation setup protocol designed for an integrated services Internet RSVP93, [RFC 1633]. The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or 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 establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path. RSVP requests resources for simplex flows, i.e., it requests resources in only one direction. Therefore, RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. Like the implementations of routing and management protocols, an implementation of RSVP will typically execute in the background, not in the data forwarding path, as shown in Figure 1. RSVP is not itself a routing protocol; RSVP is designed to operate with current and future unicast and multicast routing protocols. An RSVP process consults the local routing database(s) to obtain routes. In the multicast case, for example, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group. Routing protocols determine where packets get forwarded; RSVP is only concerned with the QoS of those packets that are forwarded in accordance with routing. In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)]. A QoS

request from a receiver host application is passed to the local RSVP process. The RSVP protocol then carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data source(s), but only as far as the router where the receiver's data path joins the multicast distribution tree. As a result, RSVP's reservation overhead is in general logarithmic rather than linear in the number of receivers. Braden, Ed., et. al. Standards Track [Page 4]

4

---

RFC 2205 RSVP September 1997 [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction

This document defines RSVP, a resource reservation setup protocol designed for an integrated services Internet RSVP93, [RFC 1633]. The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or 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 establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path. RSVP requests resources for simplex flows, i.e., it requests resources in only one direction. Therefore, RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. Like the implementations of routing and management protocols, an implementation of RSVP will typically execute in the background, not in the data forwarding path, as shown in Figure 1. RSVP is not itself a routing protocol; RSVP is designed to operate with current and future unicast and multicast routing protocols. An RSVP process consults the local routing database(s) to obtain routes. In the multicast case, for example, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group. Routing protocols determine where packets get forwarded; RSVP is only concerned with the QoS of those packets that are forwarded in accordance with routing. In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)]. A QoS

request from a receiver host application is passed to the local RSVP process. The RSVP protocol then carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data source(s), but only as far as the router where the receiver's data path joins the multicast distribution tree. As a result, RSVP's reservation overhead is in general logarithmic rather than linear in the number of receivers. Braden, Ed., et. al. Standards Track [Page 4]

5

---

RFC 2205 RSVP September 1997 [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction

This document defines RSVP, a resource reservation setup protocol designed for an integrated services Internet RSVP93, [RFC 1633]. The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or 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 establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path. RSVP requests resources for simplex flows, i.e., it requests resources in only one direction. Therefore, RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. Like the implementations of routing and management protocols, an implementation of RSVP will typically execute in the background, not in the data forwarding path, as shown in Figure 1. RSVP is not itself a routing protocol; RSVP is designed to operate with current and future unicast and multicast routing protocols. An RSVP process consults the local routing database(s) to obtain routes. In the multicast case, for example, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group. Routing protocols determine where packets get forwarded; RSVP is only concerned with the QoS of those packets that are forwarded in accordance with routing. In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)]. A QoS

request from a receiver host application is passed to the local RSVP process. The RSVP protocol then carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data source(s), but only as far as the router where the receiver's data path joins the multicast distribution tree. As a result, RSVP's reservation overhead is in general logarithmic rather than linear in the number of receivers. Braden, Ed., et. al. Standards Track [Page 4]

6

---

RFC 2205 RSVP September 1997 [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction

This document defines RSVP, a resource reservation setup protocol designed for an integrated services Internet RSVP93, [RFC 1633]. The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or 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 establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path. RSVP requests resources for simplex flows, i.e., it requests resources in only one direction. Therefore, RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. Like the implementations of routing and management protocols, an implementation of RSVP will typically execute in the background, not in the data forwarding path, as shown in Figure 1. RSVP is not itself a routing protocol; RSVP is designed to operate with current and future unicast and multicast routing protocols. An RSVP process consults the local routing database(s) to obtain routes. In the multicast case, for example, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group. Routing protocols determine where packets get forwarded; RSVP is only concerned with the QoS of those packets that are forwarded in accordance with routing. In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)]. A QoS

request from a receiver host application is passed to the local RSVP process. The RSVP protocol then carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data source(s), but only as far as the router where the receiver's data path joins the multicast distribution tree. As a result, RSVP's reservation overhead is in general logarithmic rather than linear in the number of receivers. Braden, Ed., et. al. Standards Track [Page 4]

7

---

RFC 2205 RSVP September 1997 [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction

This document defines RSVP, a resource reservation setup protocol designed for an integrated services Internet RSVP93, [RFC 1633]. The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or 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 establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path. RSVP requests resources for simplex flows, i.e., it requests resources in only one direction. Therefore, RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. Like the implementations of routing and management protocols, an implementation of RSVP will typically execute in the background, not in the data forwarding path, as shown in Figure 1. RSVP is not itself a routing protocol; RSVP is designed to operate with current and future unicast and multicast routing protocols. An RSVP process consults the local routing database(s) to obtain routes. In the multicast case, for example, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group. Routing protocols determine where packets get forwarded; RSVP is only concerned with the QoS of those packets that are forwarded in accordance with routing. In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)]. A QoS

request from a receiver host application is passed to the local RSVP process. The RSVP protocol then carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data source(s), but only as far as the router where the receiver's data path joins the multicast distribution tree. As a result, RSVP's reservation overhead is in general logarithmic rather than linear in the number of receivers. Braden, Ed., et. al. Standards Track [Page 4]

8

---

RFC 2205 RSVP September 1997 [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction

This document defines RSVP, a resource reservation setup protocol designed for an integrated services Internet RSVP93, [RFC 1633]. The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or 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 establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path. RSVP requests resources for simplex flows, i.e., it requests resources in only one direction. Therefore, RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. Like the implementations of routing and management protocols, an implementation of RSVP will typically execute in the background, not in the data forwarding path, as shown in Figure 1. RSVP is not itself a routing protocol; RSVP is designed to operate with current and future unicast and multicast routing protocols. An RSVP process consults the local routing database(s) to obtain routes. In the multicast case, for example, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group. Routing protocols determine where packets get forwarded; RSVP is only concerned with the QoS of those packets that are forwarded in accordance with routing. In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)]. A QoS

request from a receiver host application is passed to the local RSVP process. The RSVP protocol then carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data source(s), but only as far as the router where the receiver's data path joins the multicast distribution tree. As a result, RSVP's reservation overhead is in general logarithmic rather than linear in the number of receivers. Braden, Ed., et. al. Standards Track [Page 4]

9

---

RFC 2205 RSVP September 1997

          HOST                              ROUTER

_

_
		_		_
	Appli-				RSVP

| | cation| | RSVP <---------------------------> RSVP <---------->

<-->

_

process

_

Routing

process

_

.

-->Polcy

<> >Polcy

.._

Cntrl

process

.._

Cntrl

data

_

.

_

===

===========

==

==========

===

==========

==

==========

_

_

>Admis

>Admis

V__V V_

Cntrl

V__V V_

Cntrl

_

_

Class-

Packet

Class-

Packet

| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>

| || || |data | || || |data

|_____________________________| |____________________________|

              Figure 1: RSVP in Hosts and Routers

Quality of service is implemented for a particular data flow by

mechanisms collectively called "traffic control". These mechanisms include (1) a packet classifier, (2) admission control, and (3) a "packet scheduler" or some other link-layer-dependent mechanism to determine when particular packets are forwarded. The "packet classifier" determines the QoS class (and perhaps the route) for each packet. For each outgoing interface, the "packet scheduler" or other link-layer-dependent mechanism achieves the promised QoS. Traffic control implements QoS service models defined by the Integrated Services Working Group. During reservation setup, an RSVP QoS request is passed to two local decision modules, "admission control" and "policy control". Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy control Braden, Ed., et. al. Standards Track [Page 5]

0

---

RFC 2205 RSVP September 1997

          HOST                              ROUTER

_

_
		_		_
	Appli-				RSVP

| | cation| | RSVP <---------------------------> RSVP <---------->

<-->

_

process

_

Routing

process

_

.

-->Polcy

<> >Polcy

.._

Cntrl

process

.._

Cntrl

data

_

.

_

===

===========

==

==========

===

==========

==

==========

_

_

>Admis

>Admis

V__V V_

Cntrl

V__V V_

Cntrl

_

_

Class-

Packet

Class-

Packet

| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>

| || || |data | || || |data

|_____________________________| |____________________________|

              Figure 1: RSVP in Hosts and Routers

Quality of service is implemented for a particular data flow by

mechanisms collectively called "traffic control". These mechanisms include (1) a packet classifier, (2) admission control, and (3) a "packet scheduler" or some other link-layer-dependent mechanism to determine when particular packets are forwarded. The "packet classifier" determines the QoS class (and perhaps the route) for each packet. For each outgoing interface, the "packet scheduler" or other link-layer-dependent mechanism achieves the promised QoS. Traffic control implements QoS service models defined by the Integrated Services Working Group. During reservation setup, an RSVP QoS request is passed to two local decision modules, "admission control" and "policy control". Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy control Braden, Ed., et. al. Standards Track [Page 5]

1

---

RFC 2205 RSVP September 1997

          HOST                              ROUTER

_

_
		_		_
	Appli-				RSVP

| | cation| | RSVP <---------------------------> RSVP <---------->

<-->

_

process

_

Routing

process

_

.

-->Polcy

<> >Polcy

.._

Cntrl

process

.._

Cntrl

data

_

.

_

===

===========

==

==========

===

==========

==

==========

_

_

>Admis

>Admis

V__V V_

Cntrl

V__V V_

Cntrl

_

_

Class-

Packet

Class-

Packet

| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>

| || || |data | || || |data

|_____________________________| |____________________________|

              Figure 1: RSVP in Hosts and Routers

Quality of service is implemented for a particular data flow by

mechanisms collectively called "traffic control". These mechanisms include (1) a packet classifier, (2) admission control, and (3) a "packet scheduler" or some other link-layer-dependent mechanism to determine when particular packets are forwarded. The "packet classifier" determines the QoS class (and perhaps the route) for each packet. For each outgoing interface, the "packet scheduler" or other link-layer-dependent mechanism achieves the promised QoS. Traffic control implements QoS service models defined by the Integrated Services Working Group. During reservation setup, an RSVP QoS request is passed to two local decision modules, "admission control" and "policy control". Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy control Braden, Ed., et. al. Standards Track [Page 5]

2

---

RFC 2205 RSVP September 1997

          HOST                              ROUTER

_

_
		_		_
	Appli-				RSVP

| | cation| | RSVP <---------------------------> RSVP <---------->

<-->

_

process

_

Routing

process

_

.

-->Polcy

<> >Polcy

.._

Cntrl

process

.._

Cntrl

data

_

.

_

===

===========

==

==========

===

==========

==

==========

_

_

>Admis

>Admis

V__V V_

Cntrl

V__V V_

Cntrl

_

_

Class-

Packet

Class-

Packet

| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>

| || || |data | || || |data

|_____________________________| |____________________________|

              Figure 1: RSVP in Hosts and Routers

Quality of service is implemented for a particular data flow by

mechanisms collectively called "traffic control". These mechanisms include (1) a packet classifier, (2) admission control, and (3) a "packet scheduler" or some other link-layer-dependent mechanism to determine when particular packets are forwarded. The "packet classifier" determines the QoS class (and perhaps the route) for each packet. For each outgoing interface, the "packet scheduler" or other link-layer-dependent mechanism achieves the promised QoS. Traffic control implements QoS service models defined by the Integrated Services Working Group. During reservation setup, an RSVP QoS request is passed to two local decision modules, "admission control" and "policy control". Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy control Braden, Ed., et. al. Standards Track [Page 5]

3

---

RFC 2205 RSVP September 1997

          HOST                              ROUTER

_

_
		_		_
	Appli-				RSVP

| | cation| | RSVP <---------------------------> RSVP <---------->

<-->

_

process

_

Routing

process

_

.

-->Polcy

<> >Polcy

.._

Cntrl

process

.._

Cntrl

data

_

.

_

===

===========

==

==========

===

==========

==

==========

_

_

>Admis

>Admis

V__V V_

Cntrl

V__V V_

Cntrl

_

_

Class-

Packet

Class-

Packet

| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>

| || || |data | || || |data

|_____________________________| |____________________________|

              Figure 1: RSVP in Hosts and Routers

Quality of service is implemented for a particular data flow by

mechanisms collectively called "traffic control". These mechanisms include (1) a packet classifier, (2) admission control, and (3) a "packet scheduler" or some other link-layer-dependent mechanism to determine when particular packets are forwarded. The "packet classifier" determines the QoS class (and perhaps the route) for each packet. For each outgoing interface, the "packet scheduler" or other link-layer-dependent mechanism achieves the promised QoS. Traffic control implements QoS service models defined by the Integrated Services Working Group. During reservation setup, an RSVP QoS request is passed to two local decision modules, "admission control" and "policy control". Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy control Braden, Ed., et. al. Standards Track [Page 5]

4

---

RFC 2205 RSVP September 1997

          HOST                              ROUTER

_

_
		_		_
	Appli-				RSVP

| | cation| | RSVP <---------------------------> RSVP <---------->

<-->

_

process

_

Routing

process

_

.

-->Polcy

<> >Polcy

.._

Cntrl

process

.._

Cntrl

data

_

.

_

===

===========

==

==========

===

==========

==

==========

_

_

>Admis

>Admis

V__V V_

Cntrl

V__V V_

Cntrl

_

_

Class-

Packet

Class-

Packet

| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>

| || || |data | || || |data

|_____________________________| |____________________________|

              Figure 1: RSVP in Hosts and Routers

Quality of service is implemented for a particular data flow by

mechanisms collectively called "traffic control". These mechanisms include (1) a packet classifier, (2) admission control, and (3) a "packet scheduler" or some other link-layer-dependent mechanism to determine when particular packets are forwarded. The "packet classifier" determines the QoS class (and perhaps the route) for each packet. For each outgoing interface, the "packet scheduler" or other link-layer-dependent mechanism achieves the promised QoS. Traffic control implements QoS service models defined by the Integrated Services Working Group. During reservation setup, an RSVP QoS request is passed to two local decision modules, "admission control" and "policy control". Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy control Braden, Ed., et. al. Standards Track [Page 5]

5

---

RFC 2205 RSVP September 1997

          HOST                              ROUTER

_

_
		_		_
	Appli-				RSVP

| | cation| | RSVP <---------------------------> RSVP <---------->

<-->

_

process

_

Routing

process

_

.

-->Polcy

<> >Polcy

.._

Cntrl

process

.._

Cntrl

data

_

.

_

===

===========

==

==========

===

==========

==

==========

_

_

>Admis

>Admis

V__V V_

Cntrl

V__V V_

Cntrl

_

_

Class-

Packet

Class-

Packet

| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>

| || || |data | || || |data

|_____________________________| |____________________________|

              Figure 1: RSVP in Hosts and Routers

Quality of service is implemented for a particular data flow by

mechanisms collectively called "traffic control". These mechanisms include (1) a packet classifier, (2) admission control, and (3) a "packet scheduler" or some other link-layer-dependent mechanism to determine when particular packets are forwarded. The "packet classifier" determines the QoS class (and perhaps the route) for each packet. For each outgoing interface, the "packet scheduler" or other link-layer-dependent mechanism achieves the promised QoS. Traffic control implements QoS service models defined by the Integrated Services Working Group. During reservation setup, an RSVP QoS request is passed to two local decision modules, "admission control" and "policy control". Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy control Braden, Ed., et. al. Standards Track [Page 5]

6

---

RFC 2205 RSVP September 1997

          HOST                              ROUTER

_

_
		_		_
	Appli-				RSVP

| | cation| | RSVP <---------------------------> RSVP <---------->

<-->

_

process

_

Routing

process

_

.

-->Polcy

<> >Polcy

.._

Cntrl

process

.._

Cntrl

data

_

.

_

===

===========

==

==========

===

==========

==

==========

_

_

>Admis

>Admis

V__V V_

Cntrl

V__V V_

Cntrl

_

_

Class-

Packet

Class-

Packet

| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>

| || || |data | || || |data

|_____________________________| |____________________________|

              Figure 1: RSVP in Hosts and Routers

Quality of service is implemented for a particular data flow by

mechanisms collectively called "traffic control". These mechanisms include (1) a packet classifier, (2) admission control, and (3) a "packet scheduler" or some other link-layer-dependent mechanism to determine when particular packets are forwarded. The "packet classifier" determines the QoS class (and perhaps the route) for each packet. For each outgoing interface, the "packet scheduler" or other link-layer-dependent mechanism achieves the promised QoS. Traffic control implements QoS service models defined by the Integrated Services Working Group. During reservation setup, an RSVP QoS request is passed to two local decision modules, "admission control" and "policy control". Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy control Braden, Ed., et. al. Standards Track [Page 5]

7

---

RFC 2205 RSVP September 1997

          HOST                              ROUTER

_

_
		_		_
	Appli-				RSVP

| | cation| | RSVP <---------------------------> RSVP <---------->

<-->

_

process

_

Routing

process

_

.

-->Polcy

<> >Polcy

.._

Cntrl

process

.._

Cntrl

data

_

.

_

===

===========

==

==========

===

==========

==

==========

_

_

>Admis

>Admis

V__V V_

Cntrl

V__V V_

Cntrl

_

_

Class-

Packet

Class-

Packet

| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>

| || || |data | || || |data

|_____________________________| |____________________________|

              Figure 1: RSVP in Hosts and Routers

Quality of service is implemented for a particular data flow by

mechanisms collectively called "traffic control". These mechanisms include (1) a packet classifier, (2) admission control, and (3) a "packet scheduler" or some other link-layer-dependent mechanism to determine when particular packets are forwarded. The "packet classifier" determines the QoS class (and perhaps the route) for each packet. For each outgoing interface, the "packet scheduler" or other link-layer-dependent mechanism achieves the promised QoS. Traffic control implements QoS service models defined by the Integrated Services Working Group. During reservation setup, an RSVP QoS request is passed to two local decision modules, "admission control" and "policy control". Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy control Braden, Ed., et. al. Standards Track [Page 5]

8

---

RFC 2205 RSVP September 1997

          HOST                              ROUTER

_

_
		_		_
	Appli-				RSVP

| | cation| | RSVP <---------------------------> RSVP <---------->

<-->

_

process

_

Routing

process

_

.

-->Polcy

<> >Polcy

.._

Cntrl

process

.._

Cntrl

data

_

.

_

===

===========

==

==========

===

==========

==

==========

_

_

>Admis

>Admis

V__V V_

Cntrl

V__V V_

Cntrl

_

_

Class-

Packet

Class-

Packet

| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>

| || || |data | || || |data

|_____________________________| |____________________________|

              Figure 1: RSVP in Hosts and Routers

Quality of service is implemented for a particular data flow by

mechanisms collectively called "traffic control". These mechanisms include (1) a packet classifier, (2) admission control, and (3) a "packet scheduler" or some other link-layer-dependent mechanism to determine when particular packets are forwarded. The "packet classifier" determines the QoS class (and perhaps the route) for each packet. For each outgoing interface, the "packet scheduler" or other link-layer-dependent mechanism achieves the promised QoS. Traffic control implements QoS service models defined by the Integrated Services Working Group. During reservation setup, an RSVP QoS request is passed to two local decision modules, "admission control" and "policy control". Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy control Braden, Ed., et. al. Standards Track [Page 5]

9

---

RFC 2205 RSVP September 1997 determines whether the user has administrative permission to make the reservation. If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. If either check fails, the RSVP program returns an error notification to the application process that originated the request. RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths. RSVP itself transfers and manipulates QoS and policy control parameters as opaque data, passing them to the appropriate traffic control and policy control modules for interpretation. The structure and contents of the QoS parameters are documented in specifications developed by the Integrated Services Working Group; see [RFC 2210]. The structure and contents of the policy parameters are under development. Since the membership of a large multicast group and the resulting multicast tree topology are likely to change with time, the RSVP design assumes that state for RSVP and traffic control state is to be built and destroyed incrementally in routers and hosts. For this purpose, RSVP establishes "soft" state; that is, RSVP sends periodic refresh messages to maintain the state along the reserved path(s). In the absence of refresh messages, the state automatically times out and is deleted. In summary, RSVP has the following attributes: o RSVP makes resource reservations for both unicast and many-to-

    many multicast applications, adapting dynamically to changing
    group membership as well as to changing routes.

o RSVP is simplex, i.e., it makes reservations for unidirectional

    data flows.

o RSVP is receiver-oriented, i.e., the receiver of a data flow

    initiates and maintains the resource reservation used for that
    flow.

o RSVP maintains "soft" state in routers and hosts, providing

    graceful support for dynamic membership changes and automatic
    adaptation to routing changes.

o RSVP is not a routing protocol but depends upon present and

    future routing protocols.

o RSVP transports and maintains traffic control and policy control

    parameters that are opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 6]

0

---

RFC 2205 RSVP September 1997 determines whether the user has administrative permission to make the reservation. If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. If either check fails, the RSVP program returns an error notification to the application process that originated the request. RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths. RSVP itself transfers and manipulates QoS and policy control parameters as opaque data, passing them to the appropriate traffic control and policy control modules for interpretation. The structure and contents of the QoS parameters are documented in specifications developed by the Integrated Services Working Group; see [RFC 2210]. The structure and contents of the policy parameters are under development. Since the membership of a large multicast group and the resulting multicast tree topology are likely to change with time, the RSVP design assumes that state for RSVP and traffic control state is to be built and destroyed incrementally in routers and hosts. For this purpose, RSVP establishes "soft" state; that is, RSVP sends periodic refresh messages to maintain the state along the reserved path(s). In the absence of refresh messages, the state automatically times out and is deleted. In summary, RSVP has the following attributes: o RSVP makes resource reservations for both unicast and many-to-

    many multicast applications, adapting dynamically to changing
    group membership as well as to changing routes.

o RSVP is simplex, i.e., it makes reservations for unidirectional

    data flows.

o RSVP is receiver-oriented, i.e., the receiver of a data flow

    initiates and maintains the resource reservation used for that
    flow.

o RSVP maintains "soft" state in routers and hosts, providing

    graceful support for dynamic membership changes and automatic
    adaptation to routing changes.

o RSVP is not a routing protocol but depends upon present and

    future routing protocols.

o RSVP transports and maintains traffic control and policy control

    parameters that are opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 6]

1

---

RFC 2205 RSVP September 1997 determines whether the user has administrative permission to make the reservation. If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. If either check fails, the RSVP program returns an error notification to the application process that originated the request. RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths. RSVP itself transfers and manipulates QoS and policy control parameters as opaque data, passing them to the appropriate traffic control and policy control modules for interpretation. The structure and contents of the QoS parameters are documented in specifications developed by the Integrated Services Working Group; see [RFC 2210]. The structure and contents of the policy parameters are under development. Since the membership of a large multicast group and the resulting multicast tree topology are likely to change with time, the RSVP design assumes that state for RSVP and traffic control state is to be built and destroyed incrementally in routers and hosts. For this purpose, RSVP establishes "soft" state; that is, RSVP sends periodic refresh messages to maintain the state along the reserved path(s). In the absence of refresh messages, the state automatically times out and is deleted. In summary, RSVP has the following attributes: o RSVP makes resource reservations for both unicast and many-to-

    many multicast applications, adapting dynamically to changing
    group membership as well as to changing routes.

o RSVP is simplex, i.e., it makes reservations for unidirectional

    data flows.

o RSVP is receiver-oriented, i.e., the receiver of a data flow

    initiates and maintains the resource reservation used for that
    flow.

o RSVP maintains "soft" state in routers and hosts, providing

    graceful support for dynamic membership changes and automatic
    adaptation to routing changes.

o RSVP is not a routing protocol but depends upon present and

    future routing protocols.

o RSVP transports and maintains traffic control and policy control

    parameters that are opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 6]

2

---

RFC 2205 RSVP September 1997 determines whether the user has administrative permission to make the reservation. If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. If either check fails, the RSVP program returns an error notification to the application process that originated the request. RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths. RSVP itself transfers and manipulates QoS and policy control parameters as opaque data, passing them to the appropriate traffic control and policy control modules for interpretation. The structure and contents of the QoS parameters are documented in specifications developed by the Integrated Services Working Group; see [RFC 2210]. The structure and contents of the policy parameters are under development. Since the membership of a large multicast group and the resulting multicast tree topology are likely to change with time, the RSVP design assumes that state for RSVP and traffic control state is to be built and destroyed incrementally in routers and hosts. For this purpose, RSVP establishes "soft" state; that is, RSVP sends periodic refresh messages to maintain the state along the reserved path(s). In the absence of refresh messages, the state automatically times out and is deleted. In summary, RSVP has the following attributes: o RSVP makes resource reservations for both unicast and many-to-

    many multicast applications, adapting dynamically to changing
    group membership as well as to changing routes.

o RSVP is simplex, i.e., it makes reservations for unidirectional

    data flows.

o RSVP is receiver-oriented, i.e., the receiver of a data flow

    initiates and maintains the resource reservation used for that
    flow.

o RSVP maintains "soft" state in routers and hosts, providing

    graceful support for dynamic membership changes and automatic
    adaptation to routing changes.

o RSVP is not a routing protocol but depends upon present and

    future routing protocols.

o RSVP transports and maintains traffic control and policy control

    parameters that are opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 6]

3

---

RFC 2205 RSVP September 1997 determines whether the user has administrative permission to make the reservation. If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. If either check fails, the RSVP program returns an error notification to the application process that originated the request. RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths. RSVP itself transfers and manipulates QoS and policy control parameters as opaque data, passing them to the appropriate traffic control and policy control modules for interpretation. The structure and contents of the QoS parameters are documented in specifications developed by the Integrated Services Working Group; see [RFC 2210]. The structure and contents of the policy parameters are under development. Since the membership of a large multicast group and the resulting multicast tree topology are likely to change with time, the RSVP design assumes that state for RSVP and traffic control state is to be built and destroyed incrementally in routers and hosts. For this purpose, RSVP establishes "soft" state; that is, RSVP sends periodic refresh messages to maintain the state along the reserved path(s). In the absence of refresh messages, the state automatically times out and is deleted. In summary, RSVP has the following attributes: o RSVP makes resource reservations for both unicast and many-to-

    many multicast applications, adapting dynamically to changing
    group membership as well as to changing routes.

o RSVP is simplex, i.e., it makes reservations for unidirectional

    data flows.

o RSVP is receiver-oriented, i.e., the receiver of a data flow

    initiates and maintains the resource reservation used for that
    flow.

o RSVP maintains "soft" state in routers and hosts, providing

    graceful support for dynamic membership changes and automatic
    adaptation to routing changes.

o RSVP is not a routing protocol but depends upon present and

    future routing protocols.

o RSVP transports and maintains traffic control and policy control

    parameters that are opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 6]

4

---

RFC 2205 RSVP September 1997 determines whether the user has administrative permission to make the reservation. If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. If either check fails, the RSVP program returns an error notification to the application process that originated the request. RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths. RSVP itself transfers and manipulates QoS and policy control parameters as opaque data, passing them to the appropriate traffic control and policy control modules for interpretation. The structure and contents of the QoS parameters are documented in specifications developed by the Integrated Services Working Group; see [RFC 2210]. The structure and contents of the policy parameters are under development. Since the membership of a large multicast group and the resulting multicast tree topology are likely to change with time, the RSVP design assumes that state for RSVP and traffic control state is to be built and destroyed incrementally in routers and hosts. For this purpose, RSVP establishes "soft" state; that is, RSVP sends periodic refresh messages to maintain the state along the reserved path(s). In the absence of refresh messages, the state automatically times out and is deleted. In summary, RSVP has the following attributes: o RSVP makes resource reservations for both unicast and many-to-

    many multicast applications, adapting dynamically to changing
    group membership as well as to changing routes.

o RSVP is simplex, i.e., it makes reservations for unidirectional

    data flows.

o RSVP is receiver-oriented, i.e., the receiver of a data flow

    initiates and maintains the resource reservation used for that
    flow.

o RSVP maintains "soft" state in routers and hosts, providing

    graceful support for dynamic membership changes and automatic
    adaptation to routing changes.

o RSVP is not a routing protocol but depends upon present and

    future routing protocols.

o RSVP transports and maintains traffic control and policy control

    parameters that are opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 6]

5

---

RFC 2205 RSVP September 1997 determines whether the user has administrative permission to make the reservation. If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. If either check fails, the RSVP program returns an error notification to the application process that originated the request. RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths. RSVP itself transfers and manipulates QoS and policy control parameters as opaque data, passing them to the appropriate traffic control and policy control modules for interpretation. The structure and contents of the QoS parameters are documented in specifications developed by the Integrated Services Working Group; see [RFC 2210]. The structure and contents of the policy parameters are under development. Since the membership of a large multicast group and the resulting multicast tree topology are likely to change with time, the RSVP design assumes that state for RSVP and traffic control state is to be built and destroyed incrementally in routers and hosts. For this purpose, RSVP establishes "soft" state; that is, RSVP sends periodic refresh messages to maintain the state along the reserved path(s). In the absence of refresh messages, the state automatically times out and is deleted. In summary, RSVP has the following attributes: o RSVP makes resource reservations for both unicast and many-to-

    many multicast applications, adapting dynamically to changing
    group membership as well as to changing routes.

o RSVP is simplex, i.e., it makes reservations for unidirectional

    data flows.

o RSVP is receiver-oriented, i.e., the receiver of a data flow

    initiates and maintains the resource reservation used for that
    flow.

o RSVP maintains "soft" state in routers and hosts, providing

    graceful support for dynamic membership changes and automatic
    adaptation to routing changes.

o RSVP is not a routing protocol but depends upon present and

    future routing protocols.

o RSVP transports and maintains traffic control and policy control

    parameters that are opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 6]

6

---

RFC 2205 RSVP September 1997 determines whether the user has administrative permission to make the reservation. If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. If either check fails, the RSVP program returns an error notification to the application process that originated the request. RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths. RSVP itself transfers and manipulates QoS and policy control parameters as opaque data, passing them to the appropriate traffic control and policy control modules for interpretation. The structure and contents of the QoS parameters are documented in specifications developed by the Integrated Services Working Group; see [RFC 2210]. The structure and contents of the policy parameters are under development. Since the membership of a large multicast group and the resulting multicast tree topology are likely to change with time, the RSVP design assumes that state for RSVP and traffic control state is to be built and destroyed incrementally in routers and hosts. For this purpose, RSVP establishes "soft" state; that is, RSVP sends periodic refresh messages to maintain the state along the reserved path(s). In the absence of refresh messages, the state automatically times out and is deleted. In summary, RSVP has the following attributes: o RSVP makes resource reservations for both unicast and many-to-

    many multicast applications, adapting dynamically to changing
    group membership as well as to changing routes.

o RSVP is simplex, i.e., it makes reservations for unidirectional

    data flows.

o RSVP is receiver-oriented, i.e., the receiver of a data flow

    initiates and maintains the resource reservation used for that
    flow.

o RSVP maintains "soft" state in routers and hosts, providing

    graceful support for dynamic membership changes and automatic
    adaptation to routing changes.

o RSVP is not a routing protocol but depends upon present and

    future routing protocols.

o RSVP transports and maintains traffic control and policy control

    parameters that are opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 6]

7

---

RFC 2205 RSVP September 1997 determines whether the user has administrative permission to make the reservation. If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. If either check fails, the RSVP program returns an error notification to the application process that originated the request. RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths. RSVP itself transfers and manipulates QoS and policy control parameters as opaque data, passing them to the appropriate traffic control and policy control modules for interpretation. The structure and contents of the QoS parameters are documented in specifications developed by the Integrated Services Working Group; see [RFC 2210]. The structure and contents of the policy parameters are under development. Since the membership of a large multicast group and the resulting multicast tree topology are likely to change with time, the RSVP design assumes that state for RSVP and traffic control state is to be built and destroyed incrementally in routers and hosts. For this purpose, RSVP establishes "soft" state; that is, RSVP sends periodic refresh messages to maintain the state along the reserved path(s). In the absence of refresh messages, the state automatically times out and is deleted. In summary, RSVP has the following attributes: o RSVP makes resource reservations for both unicast and many-to-

    many multicast applications, adapting dynamically to changing
    group membership as well as to changing routes.

o RSVP is simplex, i.e., it makes reservations for unidirectional

    data flows.

o RSVP is receiver-oriented, i.e., the receiver of a data flow

    initiates and maintains the resource reservation used for that
    flow.

o RSVP maintains "soft" state in routers and hosts, providing

    graceful support for dynamic membership changes and automatic
    adaptation to routing changes.

o RSVP is not a routing protocol but depends upon present and

    future routing protocols.

o RSVP transports and maintains traffic control and policy control

    parameters that are opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 6]

8

---

RFC 2205 RSVP September 1997 determines whether the user has administrative permission to make the reservation. If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. If either check fails, the RSVP program returns an error notification to the application process that originated the request. RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths. RSVP itself transfers and manipulates QoS and policy control parameters as opaque data, passing them to the appropriate traffic control and policy control modules for interpretation. The structure and contents of the QoS parameters are documented in specifications developed by the Integrated Services Working Group; see [RFC 2210]. The structure and contents of the policy parameters are under development. Since the membership of a large multicast group and the resulting multicast tree topology are likely to change with time, the RSVP design assumes that state for RSVP and traffic control state is to be built and destroyed incrementally in routers and hosts. For this purpose, RSVP establishes "soft" state; that is, RSVP sends periodic refresh messages to maintain the state along the reserved path(s). In the absence of refresh messages, the state automatically times out and is deleted. In summary, RSVP has the following attributes: o RSVP makes resource reservations for both unicast and many-to-

    many multicast applications, adapting dynamically to changing
    group membership as well as to changing routes.

o RSVP is simplex, i.e., it makes reservations for unidirectional

    data flows.

o RSVP is receiver-oriented, i.e., the receiver of a data flow

    initiates and maintains the resource reservation used for that
    flow.

o RSVP maintains "soft" state in routers and hosts, providing

    graceful support for dynamic membership changes and automatic
    adaptation to routing changes.

o RSVP is not a routing protocol but depends upon present and

    future routing protocols.

o RSVP transports and maintains traffic control and policy control

    parameters that are opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 6]

9

---

RFC 2205 RSVP September 1997 o RSVP provides several reservation models or "styles" (defined

    below) to fit a variety of applications.

o RSVP provides transparent operation through routers that do not

    support it.

o RSVP supports both IPv4 and IPv6. Further discussion on the objectives and general justification for RSVP design are presented in [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)] and [RFC 1633].

The remainder of this section describes the RSVP reservation services. [Section 2](https://datatracker.ietf.org/doc/html/rfc2205

section-2) presents an overview of the RSVP protocol

mechanisms. [Section 3](https://datatracker.ietf.org/doc/html/rfc2205

section-3) contains the functional specification of RSVP,

while [Section 4](https://datatracker.ietf.org/doc/html/rfc2205

section-4) presents explicit message processing rules. [Appendix](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A)

[A](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A) defines the variable-length typed data objects used in the RSVP

protocol. [Appendix B](https://datatracker.ietf.org/doc/html/rfc2205

appendix-B) defines error codes and values. [Appendix C](https://datatracker.ietf.org/doc/html/rfc2205

appendix-C)

defines a UDP encapsulation of RSVP messages, for hosts whose operating systems provide inadequate raw network I/O support. 1.1 Data Flows

  RSVP defines a "session" to be a data flow with a particular
  destination and transport-layer protocol.  RSVP treats each
  session independently, and this document often omits the implied
  qualification "for the same session".
  An RSVP session is defined by the triple: (DestAddress, ProtocolId
  [, DstPort]).  Here DestAddress, the IP destination address of the
  data packets, may be a unicast or multicast address.  ProtocolId
  is the IP protocol ID.  The optional DstPort parameter is a
  "generalized destination port", i.e., some further demultiplexing
  point in the transport or application protocol layer.  DstPort
  could be defined by a UDP/TCP destination port field, by an
  equivalent field in another transport protocol, or by some
  application-specific information.
  Although the RSVP protocol is designed to be easily extensible for
  greater generality, the basic protocol documented here supports
  only UDP/TCP ports as generalized ports.  Note that it is not
  strictly necessary to include DstPort in the session definition
  when DestAddress is multicast, since different sessions can always
  have different multicast addresses.  However, DstPort is necessary
  to allow more than one unicast session addressed to the same
  receiver host.

Braden, Ed., et. al. Standards Track [Page 7]

0

---

RFC 2205 RSVP September 1997 o RSVP provides several reservation models or "styles" (defined

    below) to fit a variety of applications.

o RSVP provides transparent operation through routers that do not

    support it.

o RSVP supports both IPv4 and IPv6. Further discussion on the objectives and general justification for RSVP design are presented in [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)] and [RFC 1633].

The remainder of this section describes the RSVP reservation services. [Section 2](https://datatracker.ietf.org/doc/html/rfc2205

section-2) presents an overview of the RSVP protocol

mechanisms. [Section 3](https://datatracker.ietf.org/doc/html/rfc2205

section-3) contains the functional specification of RSVP,

while [Section 4](https://datatracker.ietf.org/doc/html/rfc2205

section-4) presents explicit message processing rules. [Appendix](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A)

[A](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A) defines the variable-length typed data objects used in the RSVP

protocol. [Appendix B](https://datatracker.ietf.org/doc/html/rfc2205

appendix-B) defines error codes and values. [Appendix C](https://datatracker.ietf.org/doc/html/rfc2205

appendix-C)

defines a UDP encapsulation of RSVP messages, for hosts whose operating systems provide inadequate raw network I/O support. 1.1 Data Flows

  RSVP defines a "session" to be a data flow with a particular
  destination and transport-layer protocol.  RSVP treats each
  session independently, and this document often omits the implied
  qualification "for the same session".
  An RSVP session is defined by the triple: (DestAddress, ProtocolId
  [, DstPort]).  Here DestAddress, the IP destination address of the
  data packets, may be a unicast or multicast address.  ProtocolId
  is the IP protocol ID.  The optional DstPort parameter is a
  "generalized destination port", i.e., some further demultiplexing
  point in the transport or application protocol layer.  DstPort
  could be defined by a UDP/TCP destination port field, by an
  equivalent field in another transport protocol, or by some
  application-specific information.
  Although the RSVP protocol is designed to be easily extensible for
  greater generality, the basic protocol documented here supports
  only UDP/TCP ports as generalized ports.  Note that it is not
  strictly necessary to include DstPort in the session definition
  when DestAddress is multicast, since different sessions can always
  have different multicast addresses.  However, DstPort is necessary
  to allow more than one unicast session addressed to the same
  receiver host.

Braden, Ed., et. al. Standards Track [Page 7]

1

---

RFC 2205 RSVP September 1997 o RSVP provides several reservation models or "styles" (defined

    below) to fit a variety of applications.

o RSVP provides transparent operation through routers that do not

    support it.

o RSVP supports both IPv4 and IPv6. Further discussion on the objectives and general justification for RSVP design are presented in [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)] and [RFC 1633].

The remainder of this section describes the RSVP reservation services. [Section 2](https://datatracker.ietf.org/doc/html/rfc2205

section-2) presents an overview of the RSVP protocol

mechanisms. [Section 3](https://datatracker.ietf.org/doc/html/rfc2205

section-3) contains the functional specification of RSVP,

while [Section 4](https://datatracker.ietf.org/doc/html/rfc2205

section-4) presents explicit message processing rules. [Appendix](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A)

[A](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A) defines the variable-length typed data objects used in the RSVP

protocol. [Appendix B](https://datatracker.ietf.org/doc/html/rfc2205

appendix-B) defines error codes and values. [Appendix C](https://datatracker.ietf.org/doc/html/rfc2205

appendix-C)

defines a UDP encapsulation of RSVP messages, for hosts whose operating systems provide inadequate raw network I/O support. 1.1 Data Flows

  RSVP defines a "session" to be a data flow with a particular
  destination and transport-layer protocol.  RSVP treats each
  session independently, and this document often omits the implied
  qualification "for the same session".
  An RSVP session is defined by the triple: (DestAddress, ProtocolId
  [, DstPort]).  Here DestAddress, the IP destination address of the
  data packets, may be a unicast or multicast address.  ProtocolId
  is the IP protocol ID.  The optional DstPort parameter is a
  "generalized destination port", i.e., some further demultiplexing
  point in the transport or application protocol layer.  DstPort
  could be defined by a UDP/TCP destination port field, by an
  equivalent field in another transport protocol, or by some
  application-specific information.
  Although the RSVP protocol is designed to be easily extensible for
  greater generality, the basic protocol documented here supports
  only UDP/TCP ports as generalized ports.  Note that it is not
  strictly necessary to include DstPort in the session definition
  when DestAddress is multicast, since different sessions can always
  have different multicast addresses.  However, DstPort is necessary
  to allow more than one unicast session addressed to the same
  receiver host.

Braden, Ed., et. al. Standards Track [Page 7]

2

---

RFC 2205 RSVP September 1997 o RSVP provides several reservation models or "styles" (defined

    below) to fit a variety of applications.

o RSVP provides transparent operation through routers that do not

    support it.

o RSVP supports both IPv4 and IPv6. Further discussion on the objectives and general justification for RSVP design are presented in [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)] and [RFC 1633].

The remainder of this section describes the RSVP reservation services. [Section 2](https://datatracker.ietf.org/doc/html/rfc2205

section-2) presents an overview of the RSVP protocol

mechanisms. [Section 3](https://datatracker.ietf.org/doc/html/rfc2205

section-3) contains the functional specification of RSVP,

while [Section 4](https://datatracker.ietf.org/doc/html/rfc2205

section-4) presents explicit message processing rules. [Appendix](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A)

[A](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A) defines the variable-length typed data objects used in the RSVP

protocol. [Appendix B](https://datatracker.ietf.org/doc/html/rfc2205

appendix-B) defines error codes and values. [Appendix C](https://datatracker.ietf.org/doc/html/rfc2205

appendix-C)

defines a UDP encapsulation of RSVP messages, for hosts whose operating systems provide inadequate raw network I/O support. 1.1 Data Flows

  RSVP defines a "session" to be a data flow with a particular
  destination and transport-layer protocol.  RSVP treats each
  session independently, and this document often omits the implied
  qualification "for the same session".
  An RSVP session is defined by the triple: (DestAddress, ProtocolId
  [, DstPort]).  Here DestAddress, the IP destination address of the
  data packets, may be a unicast or multicast address.  ProtocolId
  is the IP protocol ID.  The optional DstPort parameter is a
  "generalized destination port", i.e., some further demultiplexing
  point in the transport or application protocol layer.  DstPort
  could be defined by a UDP/TCP destination port field, by an
  equivalent field in another transport protocol, or by some
  application-specific information.
  Although the RSVP protocol is designed to be easily extensible for
  greater generality, the basic protocol documented here supports
  only UDP/TCP ports as generalized ports.  Note that it is not
  strictly necessary to include DstPort in the session definition
  when DestAddress is multicast, since different sessions can always
  have different multicast addresses.  However, DstPort is necessary
  to allow more than one unicast session addressed to the same
  receiver host.

Braden, Ed., et. al. Standards Track [Page 7]

3

---

RFC 2205 RSVP September 1997 o RSVP provides several reservation models or "styles" (defined

    below) to fit a variety of applications.

o RSVP provides transparent operation through routers that do not

    support it.

o RSVP supports both IPv4 and IPv6. Further discussion on the objectives and general justification for RSVP design are presented in [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)] and [RFC 1633].

The remainder of this section describes the RSVP reservation services. [Section 2](https://datatracker.ietf.org/doc/html/rfc2205

section-2) presents an overview of the RSVP protocol

mechanisms. [Section 3](https://datatracker.ietf.org/doc/html/rfc2205

section-3) contains the functional specification of RSVP,

while [Section 4](https://datatracker.ietf.org/doc/html/rfc2205

section-4) presents explicit message processing rules. [Appendix](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A)

[A](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A) defines the variable-length typed data objects used in the RSVP

protocol. [Appendix B](https://datatracker.ietf.org/doc/html/rfc2205

appendix-B) defines error codes and values. [Appendix C](https://datatracker.ietf.org/doc/html/rfc2205

appendix-C)

defines a UDP encapsulation of RSVP messages, for hosts whose operating systems provide inadequate raw network I/O support. 1.1 Data Flows

  RSVP defines a "session" to be a data flow with a particular
  destination and transport-layer protocol.  RSVP treats each
  session independently, and this document often omits the implied
  qualification "for the same session".
  An RSVP session is defined by the triple: (DestAddress, ProtocolId
  [, DstPort]).  Here DestAddress, the IP destination address of the
  data packets, may be a unicast or multicast address.  ProtocolId
  is the IP protocol ID.  The optional DstPort parameter is a
  "generalized destination port", i.e., some further demultiplexing
  point in the transport or application protocol layer.  DstPort
  could be defined by a UDP/TCP destination port field, by an
  equivalent field in another transport protocol, or by some
  application-specific information.
  Although the RSVP protocol is designed to be easily extensible for
  greater generality, the basic protocol documented here supports
  only UDP/TCP ports as generalized ports.  Note that it is not
  strictly necessary to include DstPort in the session definition
  when DestAddress is multicast, since different sessions can always
  have different multicast addresses.  However, DstPort is necessary
  to allow more than one unicast session addressed to the same
  receiver host.

Braden, Ed., et. al. Standards Track [Page 7]

4

---

RFC 2205 RSVP September 1997 o RSVP provides several reservation models or "styles" (defined

    below) to fit a variety of applications.

o RSVP provides transparent operation through routers that do not

    support it.

o RSVP supports both IPv4 and IPv6. Further discussion on the objectives and general justification for RSVP design are presented in [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)] and [RFC 1633].

The remainder of this section describes the RSVP reservation services. [Section 2](https://datatracker.ietf.org/doc/html/rfc2205

section-2) presents an overview of the RSVP protocol

mechanisms. [Section 3](https://datatracker.ietf.org/doc/html/rfc2205

section-3) contains the functional specification of RSVP,

while [Section 4](https://datatracker.ietf.org/doc/html/rfc2205

section-4) presents explicit message processing rules. [Appendix](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A)

[A](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A) defines the variable-length typed data objects used in the RSVP

protocol. [Appendix B](https://datatracker.ietf.org/doc/html/rfc2205

appendix-B) defines error codes and values. [Appendix C](https://datatracker.ietf.org/doc/html/rfc2205

appendix-C)

defines a UDP encapsulation of RSVP messages, for hosts whose operating systems provide inadequate raw network I/O support. 1.1 Data Flows

  RSVP defines a "session" to be a data flow with a particular
  destination and transport-layer protocol.  RSVP treats each
  session independently, and this document often omits the implied
  qualification "for the same session".
  An RSVP session is defined by the triple: (DestAddress, ProtocolId
  [, DstPort]).  Here DestAddress, the IP destination address of the
  data packets, may be a unicast or multicast address.  ProtocolId
  is the IP protocol ID.  The optional DstPort parameter is a
  "generalized destination port", i.e., some further demultiplexing
  point in the transport or application protocol layer.  DstPort
  could be defined by a UDP/TCP destination port field, by an
  equivalent field in another transport protocol, or by some
  application-specific information.
  Although the RSVP protocol is designed to be easily extensible for
  greater generality, the basic protocol documented here supports
  only UDP/TCP ports as generalized ports.  Note that it is not
  strictly necessary to include DstPort in the session definition
  when DestAddress is multicast, since different sessions can always
  have different multicast addresses.  However, DstPort is necessary
  to allow more than one unicast session addressed to the same
  receiver host.

Braden, Ed., et. al. Standards Track [Page 7]

5

---

RFC 2205 RSVP September 1997 o RSVP provides several reservation models or "styles" (defined

    below) to fit a variety of applications.

o RSVP provides transparent operation through routers that do not

    support it.

o RSVP supports both IPv4 and IPv6. Further discussion on the objectives and general justification for RSVP design are presented in [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)] and [RFC 1633].

The remainder of this section describes the RSVP reservation services. [Section 2](https://datatracker.ietf.org/doc/html/rfc2205

section-2) presents an overview of the RSVP protocol

mechanisms. [Section 3](https://datatracker.ietf.org/doc/html/rfc2205

section-3) contains the functional specification of RSVP,

while [Section 4](https://datatracker.ietf.org/doc/html/rfc2205

section-4) presents explicit message processing rules. [Appendix](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A)

[A](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A) defines the variable-length typed data objects used in the RSVP

protocol. [Appendix B](https://datatracker.ietf.org/doc/html/rfc2205

appendix-B) defines error codes and values. [Appendix C](https://datatracker.ietf.org/doc/html/rfc2205

appendix-C)

defines a UDP encapsulation of RSVP messages, for hosts whose operating systems provide inadequate raw network I/O support. 1.1 Data Flows

  RSVP defines a "session" to be a data flow with a particular
  destination and transport-layer protocol.  RSVP treats each
  session independently, and this document often omits the implied
  qualification "for the same session".
  An RSVP session is defined by the triple: (DestAddress, ProtocolId
  [, DstPort]).  Here DestAddress, the IP destination address of the
  data packets, may be a unicast or multicast address.  ProtocolId
  is the IP protocol ID.  The optional DstPort parameter is a
  "generalized destination port", i.e., some further demultiplexing
  point in the transport or application protocol layer.  DstPort
  could be defined by a UDP/TCP destination port field, by an
  equivalent field in another transport protocol, or by some
  application-specific information.
  Although the RSVP protocol is designed to be easily extensible for
  greater generality, the basic protocol documented here supports
  only UDP/TCP ports as generalized ports.  Note that it is not
  strictly necessary to include DstPort in the session definition
  when DestAddress is multicast, since different sessions can always
  have different multicast addresses.  However, DstPort is necessary
  to allow more than one unicast session addressed to the same
  receiver host.

Braden, Ed., et. al. Standards Track [Page 7]

6

---

RFC 2205 RSVP September 1997 o RSVP provides several reservation models or "styles" (defined

    below) to fit a variety of applications.

o RSVP provides transparent operation through routers that do not

    support it.

o RSVP supports both IPv4 and IPv6. Further discussion on the objectives and general justification for RSVP design are presented in [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)] and [RFC 1633].

The remainder of this section describes the RSVP reservation services. [Section 2](https://datatracker.ietf.org/doc/html/rfc2205

section-2) presents an overview of the RSVP protocol

mechanisms. [Section 3](https://datatracker.ietf.org/doc/html/rfc2205

section-3) contains the functional specification of RSVP,

while [Section 4](https://datatracker.ietf.org/doc/html/rfc2205

section-4) presents explicit message processing rules. [Appendix](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A)

[A](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A) defines the variable-length typed data objects used in the RSVP

protocol. [Appendix B](https://datatracker.ietf.org/doc/html/rfc2205

appendix-B) defines error codes and values. [Appendix C](https://datatracker.ietf.org/doc/html/rfc2205

appendix-C)

defines a UDP encapsulation of RSVP messages, for hosts whose operating systems provide inadequate raw network I/O support. 1.1 Data Flows

  RSVP defines a "session" to be a data flow with a particular
  destination and transport-layer protocol.  RSVP treats each
  session independently, and this document often omits the implied
  qualification "for the same session".
  An RSVP session is defined by the triple: (DestAddress, ProtocolId
  [, DstPort]).  Here DestAddress, the IP destination address of the
  data packets, may be a unicast or multicast address.  ProtocolId
  is the IP protocol ID.  The optional DstPort parameter is a
  "generalized destination port", i.e., some further demultiplexing
  point in the transport or application protocol layer.  DstPort
  could be defined by a UDP/TCP destination port field, by an
  equivalent field in another transport protocol, or by some
  application-specific information.
  Although the RSVP protocol is designed to be easily extensible for
  greater generality, the basic protocol documented here supports
  only UDP/TCP ports as generalized ports.  Note that it is not
  strictly necessary to include DstPort in the session definition
  when DestAddress is multicast, since different sessions can always
  have different multicast addresses.  However, DstPort is necessary
  to allow more than one unicast session addressed to the same
  receiver host.

Braden, Ed., et. al. Standards Track [Page 7]

7

---

RFC 2205 RSVP September 1997 o RSVP provides several reservation models or "styles" (defined

    below) to fit a variety of applications.

o RSVP provides transparent operation through routers that do not

    support it.

o RSVP supports both IPv4 and IPv6. Further discussion on the objectives and general justification for RSVP design are presented in [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)] and [RFC 1633].

The remainder of this section describes the RSVP reservation services. [Section 2](https://datatracker.ietf.org/doc/html/rfc2205

section-2) presents an overview of the RSVP protocol

mechanisms. [Section 3](https://datatracker.ietf.org/doc/html/rfc2205

section-3) contains the functional specification of RSVP,

while [Section 4](https://datatracker.ietf.org/doc/html/rfc2205

section-4) presents explicit message processing rules. [Appendix](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A)

[A](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A) defines the variable-length typed data objects used in the RSVP

protocol. [Appendix B](https://datatracker.ietf.org/doc/html/rfc2205

appendix-B) defines error codes and values. [Appendix C](https://datatracker.ietf.org/doc/html/rfc2205

appendix-C)

defines a UDP encapsulation of RSVP messages, for hosts whose operating systems provide inadequate raw network I/O support. 1.1 Data Flows

  RSVP defines a "session" to be a data flow with a particular
  destination and transport-layer protocol.  RSVP treats each
  session independently, and this document often omits the implied
  qualification "for the same session".
  An RSVP session is defined by the triple: (DestAddress, ProtocolId
  [, DstPort]).  Here DestAddress, the IP destination address of the
  data packets, may be a unicast or multicast address.  ProtocolId
  is the IP protocol ID.  The optional DstPort parameter is a
  "generalized destination port", i.e., some further demultiplexing
  point in the transport or application protocol layer.  DstPort
  could be defined by a UDP/TCP destination port field, by an
  equivalent field in another transport protocol, or by some
  application-specific information.
  Although the RSVP protocol is designed to be easily extensible for
  greater generality, the basic protocol documented here supports
  only UDP/TCP ports as generalized ports.  Note that it is not
  strictly necessary to include DstPort in the session definition
  when DestAddress is multicast, since different sessions can always
  have different multicast addresses.  However, DstPort is necessary
  to allow more than one unicast session addressed to the same
  receiver host.

Braden, Ed., et. al. Standards Track [Page 7]

8

---

RFC 2205 RSVP September 1997 o RSVP provides several reservation models or "styles" (defined

    below) to fit a variety of applications.

o RSVP provides transparent operation through routers that do not

    support it.

o RSVP supports both IPv4 and IPv6. Further discussion on the objectives and general justification for RSVP design are presented in [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

ref-RSVP93)] and [RFC 1633].

The remainder of this section describes the RSVP reservation services. [Section 2](https://datatracker.ietf.org/doc/html/rfc2205

section-2) presents an overview of the RSVP protocol

mechanisms. [Section 3](https://datatracker.ietf.org/doc/html/rfc2205

section-3) contains the functional specification of RSVP,

while [Section 4](https://datatracker.ietf.org/doc/html/rfc2205

section-4) presents explicit message processing rules. [Appendix](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A)

[A](https://datatracker.ietf.org/doc/html/rfc2205

appendix-A) defines the variable-length typed data objects used in the RSVP

protocol. [Appendix B](https://datatracker.ietf.org/doc/html/rfc2205

appendix-B) defines error codes and values. [Appendix C](https://datatracker.ietf.org/doc/html/rfc2205

appendix-C)

defines a UDP encapsulation of RSVP messages, for hosts whose operating systems provide inadequate raw network I/O support. 1.1 Data Flows

  RSVP defines a "session" to be a data flow with a particular
  destination and transport-layer protocol.  RSVP treats each
  session independently, and this document often omits the implied
  qualification "for the same session".
  An RSVP session is defined by the triple: (DestAddress, ProtocolId
  [, DstPort]).  Here DestAddress, the IP destination address of the
  data packets, may be a unicast or multicast address.  ProtocolId
  is the IP protocol ID.  The optional DstPort parameter is a
  "generalized destination port", i.e., some further demultiplexing
  point in the transport or application protocol layer.  DstPort
  could be defined by a UDP/TCP destination port field, by an
  equivalent field in another transport protocol, or by some
  application-specific information.
  Although the RSVP protocol is designed to be easily extensible for
  greater generality, the basic protocol documented here supports
  only UDP/TCP ports as generalized ports.  Note that it is not
  strictly necessary to include DstPort in the session definition
  when DestAddress is multicast, since different sessions can always
  have different multicast addresses.  However, DstPort is necessary
  to allow more than one unicast session addressed to the same
  receiver host.

Braden, Ed., et. al. Standards Track [Page 7]

9

---

RFC 2205 RSVP September 1997

  Figure 2 illustrates the flow of data packets in a single RSVP
  session, assuming multicast data distribution.  The arrows
  indicate data flowing from senders S1 and S2 to receivers R1, R2,
  and R3, and the cloud represents the distribution mesh created by
  multicast routing.  Multicast distribution forwards a copy of each
  data packet from a sender Si to every receiver Rj; a unicast
  distribution session has a single receiver R.  Each sender Si may
  be running in a unique Internet host, or a single host may contain
  multiple senders distinguished by "generalized source ports".
          Senders                              Receivers
                      _____________________
                     (                     ) ===> R1
             S1 ===> (    Multicast        )
                     (                     ) ===> R2
                     (    distribution     )
             S2 ===> (                     )
                     (    by Internet      ) ===> R3
                     (_____________________)
             Figure 2: Multicast Distribution Session
  For unicast transmission, there will be a single destination host
  but there may be multiple senders; RSVP can set up reservations
  for multipoint-to-single-point transmission.

1.2 Reservation Model

  An elementary RSVP reservation request consists of a "flowspec"
  together with a "filter spec"; this pair is called a "flow
  descriptor".  The flowspec specifies a desired QoS.  The filter
  spec, together with a session specification, defines the set of
  data packets -- the "flow" -- to receive the QoS defined by the
  flowspec.  The flowspec is used to set parameters in the node's
  packet scheduler or other link layer mechanism, while the filter
  spec is used to set parameters in the packet classifier.  Data
  packets that are addressed to a particular session but do not
  match any of the filter specs for that session are handled as
  best-effort traffic.
  The flowspec in a reservation request will generally include a
  service class and two sets of numeric parameters: (1) an "Rspec"
  (R for `reserve') that defines the desired QoS, and (2) a "Tspec"
  (T for `traffic') that describes the data flow.  The formats and
  contents of Tspecs and Rspecs are determined by the integrated
  service models [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] and are generally opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 8]

0

---

RFC 2205 RSVP September 1997

  Figure 2 illustrates the flow of data packets in a single RSVP
  session, assuming multicast data distribution.  The arrows
  indicate data flowing from senders S1 and S2 to receivers R1, R2,
  and R3, and the cloud represents the distribution mesh created by
  multicast routing.  Multicast distribution forwards a copy of each
  data packet from a sender Si to every receiver Rj; a unicast
  distribution session has a single receiver R.  Each sender Si may
  be running in a unique Internet host, or a single host may contain
  multiple senders distinguished by "generalized source ports".
          Senders                              Receivers
                      _____________________
                     (                     ) ===> R1
             S1 ===> (    Multicast        )
                     (                     ) ===> R2
                     (    distribution     )
             S2 ===> (                     )
                     (    by Internet      ) ===> R3
                     (_____________________)
             Figure 2: Multicast Distribution Session
  For unicast transmission, there will be a single destination host
  but there may be multiple senders; RSVP can set up reservations
  for multipoint-to-single-point transmission.

1.2 Reservation Model

  An elementary RSVP reservation request consists of a "flowspec"
  together with a "filter spec"; this pair is called a "flow
  descriptor".  The flowspec specifies a desired QoS.  The filter
  spec, together with a session specification, defines the set of
  data packets -- the "flow" -- to receive the QoS defined by the
  flowspec.  The flowspec is used to set parameters in the node's
  packet scheduler or other link layer mechanism, while the filter
  spec is used to set parameters in the packet classifier.  Data
  packets that are addressed to a particular session but do not
  match any of the filter specs for that session are handled as
  best-effort traffic.
  The flowspec in a reservation request will generally include a
  service class and two sets of numeric parameters: (1) an "Rspec"
  (R for `reserve') that defines the desired QoS, and (2) a "Tspec"
  (T for `traffic') that describes the data flow.  The formats and
  contents of Tspecs and Rspecs are determined by the integrated
  service models [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] and are generally opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 8]

1

---

RFC 2205 RSVP September 1997

  Figure 2 illustrates the flow of data packets in a single RSVP
  session, assuming multicast data distribution.  The arrows
  indicate data flowing from senders S1 and S2 to receivers R1, R2,
  and R3, and the cloud represents the distribution mesh created by
  multicast routing.  Multicast distribution forwards a copy of each
  data packet from a sender Si to every receiver Rj; a unicast
  distribution session has a single receiver R.  Each sender Si may
  be running in a unique Internet host, or a single host may contain
  multiple senders distinguished by "generalized source ports".
          Senders                              Receivers
                      _____________________
                     (                     ) ===> R1
             S1 ===> (    Multicast        )
                     (                     ) ===> R2
                     (    distribution     )
             S2 ===> (                     )
                     (    by Internet      ) ===> R3
                     (_____________________)
             Figure 2: Multicast Distribution Session
  For unicast transmission, there will be a single destination host
  but there may be multiple senders; RSVP can set up reservations
  for multipoint-to-single-point transmission.

1.2 Reservation Model

  An elementary RSVP reservation request consists of a "flowspec"
  together with a "filter spec"; this pair is called a "flow
  descriptor".  The flowspec specifies a desired QoS.  The filter
  spec, together with a session specification, defines the set of
  data packets -- the "flow" -- to receive the QoS defined by the
  flowspec.  The flowspec is used to set parameters in the node's
  packet scheduler or other link layer mechanism, while the filter
  spec is used to set parameters in the packet classifier.  Data
  packets that are addressed to a particular session but do not
  match any of the filter specs for that session are handled as
  best-effort traffic.
  The flowspec in a reservation request will generally include a
  service class and two sets of numeric parameters: (1) an "Rspec"
  (R for `reserve') that defines the desired QoS, and (2) a "Tspec"
  (T for `traffic') that describes the data flow.  The formats and
  contents of Tspecs and Rspecs are determined by the integrated
  service models [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] and are generally opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 8]

2

---

RFC 2205 RSVP September 1997

  Figure 2 illustrates the flow of data packets in a single RSVP
  session, assuming multicast data distribution.  The arrows
  indicate data flowing from senders S1 and S2 to receivers R1, R2,
  and R3, and the cloud represents the distribution mesh created by
  multicast routing.  Multicast distribution forwards a copy of each
  data packet from a sender Si to every receiver Rj; a unicast
  distribution session has a single receiver R.  Each sender Si may
  be running in a unique Internet host, or a single host may contain
  multiple senders distinguished by "generalized source ports".
          Senders                              Receivers
                      _____________________
                     (                     ) ===> R1
             S1 ===> (    Multicast        )
                     (                     ) ===> R2
                     (    distribution     )
             S2 ===> (                     )
                     (    by Internet      ) ===> R3
                     (_____________________)
             Figure 2: Multicast Distribution Session
  For unicast transmission, there will be a single destination host
  but there may be multiple senders; RSVP can set up reservations
  for multipoint-to-single-point transmission.

1.2 Reservation Model

  An elementary RSVP reservation request consists of a "flowspec"
  together with a "filter spec"; this pair is called a "flow
  descriptor".  The flowspec specifies a desired QoS.  The filter
  spec, together with a session specification, defines the set of
  data packets -- the "flow" -- to receive the QoS defined by the
  flowspec.  The flowspec is used to set parameters in the node's
  packet scheduler or other link layer mechanism, while the filter
  spec is used to set parameters in the packet classifier.  Data
  packets that are addressed to a particular session but do not
  match any of the filter specs for that session are handled as
  best-effort traffic.
  The flowspec in a reservation request will generally include a
  service class and two sets of numeric parameters: (1) an "Rspec"
  (R for `reserve') that defines the desired QoS, and (2) a "Tspec"
  (T for `traffic') that describes the data flow.  The formats and
  contents of Tspecs and Rspecs are determined by the integrated
  service models [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] and are generally opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 8]

3

---

RFC 2205 RSVP September 1997

  Figure 2 illustrates the flow of data packets in a single RSVP
  session, assuming multicast data distribution.  The arrows
  indicate data flowing from senders S1 and S2 to receivers R1, R2,
  and R3, and the cloud represents the distribution mesh created by
  multicast routing.  Multicast distribution forwards a copy of each
  data packet from a sender Si to every receiver Rj; a unicast
  distribution session has a single receiver R.  Each sender Si may
  be running in a unique Internet host, or a single host may contain
  multiple senders distinguished by "generalized source ports".
          Senders                              Receivers
                      _____________________
                     (                     ) ===> R1
             S1 ===> (    Multicast        )
                     (                     ) ===> R2
                     (    distribution     )
             S2 ===> (                     )
                     (    by Internet      ) ===> R3
                     (_____________________)
             Figure 2: Multicast Distribution Session
  For unicast transmission, there will be a single destination host
  but there may be multiple senders; RSVP can set up reservations
  for multipoint-to-single-point transmission.

1.2 Reservation Model

  An elementary RSVP reservation request consists of a "flowspec"
  together with a "filter spec"; this pair is called a "flow
  descriptor".  The flowspec specifies a desired QoS.  The filter
  spec, together with a session specification, defines the set of
  data packets -- the "flow" -- to receive the QoS defined by the
  flowspec.  The flowspec is used to set parameters in the node's
  packet scheduler or other link layer mechanism, while the filter
  spec is used to set parameters in the packet classifier.  Data
  packets that are addressed to a particular session but do not
  match any of the filter specs for that session are handled as
  best-effort traffic.
  The flowspec in a reservation request will generally include a
  service class and two sets of numeric parameters: (1) an "Rspec"
  (R for `reserve') that defines the desired QoS, and (2) a "Tspec"
  (T for `traffic') that describes the data flow.  The formats and
  contents of Tspecs and Rspecs are determined by the integrated
  service models [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] and are generally opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 8]

4

---

RFC 2205 RSVP September 1997

  Figure 2 illustrates the flow of data packets in a single RSVP
  session, assuming multicast data distribution.  The arrows
  indicate data flowing from senders S1 and S2 to receivers R1, R2,
  and R3, and the cloud represents the distribution mesh created by
  multicast routing.  Multicast distribution forwards a copy of each
  data packet from a sender Si to every receiver Rj; a unicast
  distribution session has a single receiver R.  Each sender Si may
  be running in a unique Internet host, or a single host may contain
  multiple senders distinguished by "generalized source ports".
          Senders                              Receivers
                      _____________________
                     (                     ) ===> R1
             S1 ===> (    Multicast        )
                     (                     ) ===> R2
                     (    distribution     )
             S2 ===> (                     )
                     (    by Internet      ) ===> R3
                     (_____________________)
             Figure 2: Multicast Distribution Session
  For unicast transmission, there will be a single destination host
  but there may be multiple senders; RSVP can set up reservations
  for multipoint-to-single-point transmission.

1.2 Reservation Model

  An elementary RSVP reservation request consists of a "flowspec"
  together with a "filter spec"; this pair is called a "flow
  descriptor".  The flowspec specifies a desired QoS.  The filter
  spec, together with a session specification, defines the set of
  data packets -- the "flow" -- to receive the QoS defined by the
  flowspec.  The flowspec is used to set parameters in the node's
  packet scheduler or other link layer mechanism, while the filter
  spec is used to set parameters in the packet classifier.  Data
  packets that are addressed to a particular session but do not
  match any of the filter specs for that session are handled as
  best-effort traffic.
  The flowspec in a reservation request will generally include a
  service class and two sets of numeric parameters: (1) an "Rspec"
  (R for `reserve') that defines the desired QoS, and (2) a "Tspec"
  (T for `traffic') that describes the data flow.  The formats and
  contents of Tspecs and Rspecs are determined by the integrated
  service models [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] and are generally opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 8]

5

---

RFC 2205 RSVP September 1997

  Figure 2 illustrates the flow of data packets in a single RSVP
  session, assuming multicast data distribution.  The arrows
  indicate data flowing from senders S1 and S2 to receivers R1, R2,
  and R3, and the cloud represents the distribution mesh created by
  multicast routing.  Multicast distribution forwards a copy of each
  data packet from a sender Si to every receiver Rj; a unicast
  distribution session has a single receiver R.  Each sender Si may
  be running in a unique Internet host, or a single host may contain
  multiple senders distinguished by "generalized source ports".
          Senders                              Receivers
                      _____________________
                     (                     ) ===> R1
             S1 ===> (    Multicast        )
                     (                     ) ===> R2
                     (    distribution     )
             S2 ===> (                     )
                     (    by Internet      ) ===> R3
                     (_____________________)
             Figure 2: Multicast Distribution Session
  For unicast transmission, there will be a single destination host
  but there may be multiple senders; RSVP can set up reservations
  for multipoint-to-single-point transmission.

1.2 Reservation Model

  An elementary RSVP reservation request consists of a "flowspec"
  together with a "filter spec"; this pair is called a "flow
  descriptor".  The flowspec specifies a desired QoS.  The filter
  spec, together with a session specification, defines the set of
  data packets -- the "flow" -- to receive the QoS defined by the
  flowspec.  The flowspec is used to set parameters in the node's
  packet scheduler or other link layer mechanism, while the filter
  spec is used to set parameters in the packet classifier.  Data
  packets that are addressed to a particular session but do not
  match any of the filter specs for that session are handled as
  best-effort traffic.
  The flowspec in a reservation request will generally include a
  service class and two sets of numeric parameters: (1) an "Rspec"
  (R for `reserve') that defines the desired QoS, and (2) a "Tspec"
  (T for `traffic') that describes the data flow.  The formats and
  contents of Tspecs and Rspecs are determined by the integrated
  service models [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] and are generally opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 8]

6

---

RFC 2205 RSVP September 1997

  Figure 2 illustrates the flow of data packets in a single RSVP
  session, assuming multicast data distribution.  The arrows
  indicate data flowing from senders S1 and S2 to receivers R1, R2,
  and R3, and the cloud represents the distribution mesh created by
  multicast routing.  Multicast distribution forwards a copy of each
  data packet from a sender Si to every receiver Rj; a unicast
  distribution session has a single receiver R.  Each sender Si may
  be running in a unique Internet host, or a single host may contain
  multiple senders distinguished by "generalized source ports".
          Senders                              Receivers
                      _____________________
                     (                     ) ===> R1
             S1 ===> (    Multicast        )
                     (                     ) ===> R2
                     (    distribution     )
             S2 ===> (                     )
                     (    by Internet      ) ===> R3
                     (_____________________)
             Figure 2: Multicast Distribution Session
  For unicast transmission, there will be a single destination host
  but there may be multiple senders; RSVP can set up reservations
  for multipoint-to-single-point transmission.

1.2 Reservation Model

  An elementary RSVP reservation request consists of a "flowspec"
  together with a "filter spec"; this pair is called a "flow
  descriptor".  The flowspec specifies a desired QoS.  The filter
  spec, together with a session specification, defines the set of
  data packets -- the "flow" -- to receive the QoS defined by the
  flowspec.  The flowspec is used to set parameters in the node's
  packet scheduler or other link layer mechanism, while the filter
  spec is used to set parameters in the packet classifier.  Data
  packets that are addressed to a particular session but do not
  match any of the filter specs for that session are handled as
  best-effort traffic.
  The flowspec in a reservation request will generally include a
  service class and two sets of numeric parameters: (1) an "Rspec"
  (R for `reserve') that defines the desired QoS, and (2) a "Tspec"
  (T for `traffic') that describes the data flow.  The formats and
  contents of Tspecs and Rspecs are determined by the integrated
  service models [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] and are generally opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 8]

7

---

RFC 2205 RSVP September 1997

  Figure 2 illustrates the flow of data packets in a single RSVP
  session, assuming multicast data distribution.  The arrows
  indicate data flowing from senders S1 and S2 to receivers R1, R2,
  and R3, and the cloud represents the distribution mesh created by
  multicast routing.  Multicast distribution forwards a copy of each
  data packet from a sender Si to every receiver Rj; a unicast
  distribution session has a single receiver R.  Each sender Si may
  be running in a unique Internet host, or a single host may contain
  multiple senders distinguished by "generalized source ports".
          Senders                              Receivers
                      _____________________
                     (                     ) ===> R1
             S1 ===> (    Multicast        )
                     (                     ) ===> R2
                     (    distribution     )
             S2 ===> (                     )
                     (    by Internet      ) ===> R3
                     (_____________________)
             Figure 2: Multicast Distribution Session
  For unicast transmission, there will be a single destination host
  but there may be multiple senders; RSVP can set up reservations
  for multipoint-to-single-point transmission.

1.2 Reservation Model

  An elementary RSVP reservation request consists of a "flowspec"
  together with a "filter spec"; this pair is called a "flow
  descriptor".  The flowspec specifies a desired QoS.  The filter
  spec, together with a session specification, defines the set of
  data packets -- the "flow" -- to receive the QoS defined by the
  flowspec.  The flowspec is used to set parameters in the node's
  packet scheduler or other link layer mechanism, while the filter
  spec is used to set parameters in the packet classifier.  Data
  packets that are addressed to a particular session but do not
  match any of the filter specs for that session are handled as
  best-effort traffic.
  The flowspec in a reservation request will generally include a
  service class and two sets of numeric parameters: (1) an "Rspec"
  (R for `reserve') that defines the desired QoS, and (2) a "Tspec"
  (T for `traffic') that describes the data flow.  The formats and
  contents of Tspecs and Rspecs are determined by the integrated
  service models [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] and are generally opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 8]

8

---

RFC 2205 RSVP September 1997

  Figure 2 illustrates the flow of data packets in a single RSVP
  session, assuming multicast data distribution.  The arrows
  indicate data flowing from senders S1 and S2 to receivers R1, R2,
  and R3, and the cloud represents the distribution mesh created by
  multicast routing.  Multicast distribution forwards a copy of each
  data packet from a sender Si to every receiver Rj; a unicast
  distribution session has a single receiver R.  Each sender Si may
  be running in a unique Internet host, or a single host may contain
  multiple senders distinguished by "generalized source ports".
          Senders                              Receivers
                      _____________________
                     (                     ) ===> R1
             S1 ===> (    Multicast        )
                     (                     ) ===> R2
                     (    distribution     )
             S2 ===> (                     )
                     (    by Internet      ) ===> R3
                     (_____________________)
             Figure 2: Multicast Distribution Session
  For unicast transmission, there will be a single destination host
  but there may be multiple senders; RSVP can set up reservations
  for multipoint-to-single-point transmission.

1.2 Reservation Model

  An elementary RSVP reservation request consists of a "flowspec"
  together with a "filter spec"; this pair is called a "flow
  descriptor".  The flowspec specifies a desired QoS.  The filter
  spec, together with a session specification, defines the set of
  data packets -- the "flow" -- to receive the QoS defined by the
  flowspec.  The flowspec is used to set parameters in the node's
  packet scheduler or other link layer mechanism, while the filter
  spec is used to set parameters in the packet classifier.  Data
  packets that are addressed to a particular session but do not
  match any of the filter specs for that session are handled as
  best-effort traffic.
  The flowspec in a reservation request will generally include a
  service class and two sets of numeric parameters: (1) an "Rspec"
  (R for `reserve') that defines the desired QoS, and (2) a "Tspec"
  (T for `traffic') that describes the data flow.  The formats and
  contents of Tspecs and Rspecs are determined by the integrated
  service models [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] and are generally opaque to RSVP.

Braden, Ed., et. al. Standards Track [Page 8]

9

---

RFC 2205 RSVP September 1997

  The exact format of a filter spec depends upon whether IPv4 or
  IPv6 is in use; see [Appendix A](https://datatracker.ietf.org/doc/html/rfc2205

# appendix-A). In the most general approach

  [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

# ref-RSVP93)], filter specs may select arbitrary subsets of the packets

  in a given session.  Such subsets might be defined in terms of
  senders (i.e., sender IP address and generalized source port), in
  terms of a higher-level protocol, or generally in terms of any
  fields in any protocol headers in the packet.  For example, filter
  specs might be used to select different subflows of a
  hierarchically-encoded video stream by selecting on fields in an
  application-layer header.  In the interest of simplicity (and to
  minimize layer violation), the basic filter spec format defined in
  the present RSVP specification has a very restricted form: sender
  IP address and optionally the UDP/TCP port number SrcPort.
  Because the UDP/TCP port numbers are used for packet
  classification, each router must be able to examine these fields.
  This raises three potential problems.

1. It is necessary to avoid IP fragmentation of a data flow for

          which a resource reservation is desired.
          Document [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] specifies a procedure for applications
          using RSVP facilities to compute the minimum MTU over a
          multicast tree and return the result to the senders.

2. IPv6 inserts a variable number of variable-length Internet- layer headers before the transport header, increasing the difficulty and cost of packet classification for QoS. Efficient classification of IPv6 data packets could be obtained using the Flow Label field of the IPv6 header. The details will be provided in the future.
3. IP-level Security, under either IPv4 or IPv6, may encrypt the entire transport header, hiding the port numbers of data packets from intermediate routers. A small extension to RSVP for IP Security under IPv4 and IPv6 is described separately in [[RFC 2207](https://datatracker.ietf.org/doc/html/rfc2207)]. RSVP messages carrying reservation requests originate at receivers and are passed upstream towards the sender(s). Note: in this document, we define the directional terms "upstream" vs. "downstream", "previous hop" vs. "next hop", and "incoming interface" vs "outgoing interface" with respect to the direction of data flow. Braden, Ed., et. al. Standards Track [Page 9]

0

---

RFC 2205 RSVP September 1997

  The exact format of a filter spec depends upon whether IPv4 or
  IPv6 is in use; see [Appendix A](https://datatracker.ietf.org/doc/html/rfc2205

# appendix-A). In the most general approach

  [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

# ref-RSVP93)], filter specs may select arbitrary subsets of the packets

  in a given session.  Such subsets might be defined in terms of
  senders (i.e., sender IP address and generalized source port), in
  terms of a higher-level protocol, or generally in terms of any
  fields in any protocol headers in the packet.  For example, filter
  specs might be used to select different subflows of a
  hierarchically-encoded video stream by selecting on fields in an
  application-layer header.  In the interest of simplicity (and to
  minimize layer violation), the basic filter spec format defined in
  the present RSVP specification has a very restricted form: sender
  IP address and optionally the UDP/TCP port number SrcPort.
  Because the UDP/TCP port numbers are used for packet
  classification, each router must be able to examine these fields.
  This raises three potential problems.

1. It is necessary to avoid IP fragmentation of a data flow for

          which a resource reservation is desired.
          Document [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] specifies a procedure for applications
          using RSVP facilities to compute the minimum MTU over a
          multicast tree and return the result to the senders.

2. IPv6 inserts a variable number of variable-length Internet- layer headers before the transport header, increasing the difficulty and cost of packet classification for QoS. Efficient classification of IPv6 data packets could be obtained using the Flow Label field of the IPv6 header. The details will be provided in the future.
3. IP-level Security, under either IPv4 or IPv6, may encrypt the entire transport header, hiding the port numbers of data packets from intermediate routers. A small extension to RSVP for IP Security under IPv4 and IPv6 is described separately in [[RFC 2207](https://datatracker.ietf.org/doc/html/rfc2207)]. RSVP messages carrying reservation requests originate at receivers and are passed upstream towards the sender(s). Note: in this document, we define the directional terms "upstream" vs. "downstream", "previous hop" vs. "next hop", and "incoming interface" vs "outgoing interface" with respect to the direction of data flow. Braden, Ed., et. al. Standards Track [Page 9]

1

---

RFC 2205 RSVP September 1997

  The exact format of a filter spec depends upon whether IPv4 or
  IPv6 is in use; see [Appendix A](https://datatracker.ietf.org/doc/html/rfc2205

# appendix-A). In the most general approach

  [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

# ref-RSVP93)], filter specs may select arbitrary subsets of the packets

  in a given session.  Such subsets might be defined in terms of
  senders (i.e., sender IP address and generalized source port), in
  terms of a higher-level protocol, or generally in terms of any
  fields in any protocol headers in the packet.  For example, filter
  specs might be used to select different subflows of a
  hierarchically-encoded video stream by selecting on fields in an
  application-layer header.  In the interest of simplicity (and to
  minimize layer violation), the basic filter spec format defined in
  the present RSVP specification has a very restricted form: sender
  IP address and optionally the UDP/TCP port number SrcPort.
  Because the UDP/TCP port numbers are used for packet
  classification, each router must be able to examine these fields.
  This raises three potential problems.

1. It is necessary to avoid IP fragmentation of a data flow for

          which a resource reservation is desired.
          Document [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] specifies a procedure for applications
          using RSVP facilities to compute the minimum MTU over a
          multicast tree and return the result to the senders.

2. IPv6 inserts a variable number of variable-length Internet- layer headers before the transport header, increasing the difficulty and cost of packet classification for QoS. Efficient classification of IPv6 data packets could be obtained using the Flow Label field of the IPv6 header. The details will be provided in the future.
3. IP-level Security, under either IPv4 or IPv6, may encrypt the entire transport header, hiding the port numbers of data packets from intermediate routers. A small extension to RSVP for IP Security under IPv4 and IPv6 is described separately in [[RFC 2207](https://datatracker.ietf.org/doc/html/rfc2207)]. RSVP messages carrying reservation requests originate at receivers and are passed upstream towards the sender(s). Note: in this document, we define the directional terms "upstream" vs. "downstream", "previous hop" vs. "next hop", and "incoming interface" vs "outgoing interface" with respect to the direction of data flow. Braden, Ed., et. al. Standards Track [Page 9]

2

---

RFC 2205 RSVP September 1997

  The exact format of a filter spec depends upon whether IPv4 or
  IPv6 is in use; see [Appendix A](https://datatracker.ietf.org/doc/html/rfc2205

# appendix-A). In the most general approach

  [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

# ref-RSVP93)], filter specs may select arbitrary subsets of the packets

  in a given session.  Such subsets might be defined in terms of
  senders (i.e., sender IP address and generalized source port), in
  terms of a higher-level protocol, or generally in terms of any
  fields in any protocol headers in the packet.  For example, filter
  specs might be used to select different subflows of a
  hierarchically-encoded video stream by selecting on fields in an
  application-layer header.  In the interest of simplicity (and to
  minimize layer violation), the basic filter spec format defined in
  the present RSVP specification has a very restricted form: sender
  IP address and optionally the UDP/TCP port number SrcPort.
  Because the UDP/TCP port numbers are used for packet
  classification, each router must be able to examine these fields.
  This raises three potential problems.

1. It is necessary to avoid IP fragmentation of a data flow for

          which a resource reservation is desired.
          Document [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] specifies a procedure for applications
          using RSVP facilities to compute the minimum MTU over a
          multicast tree and return the result to the senders.

2. IPv6 inserts a variable number of variable-length Internet- layer headers before the transport header, increasing the difficulty and cost of packet classification for QoS. Efficient classification of IPv6 data packets could be obtained using the Flow Label field of the IPv6 header. The details will be provided in the future.
3. IP-level Security, under either IPv4 or IPv6, may encrypt the entire transport header, hiding the port numbers of data packets from intermediate routers. A small extension to RSVP for IP Security under IPv4 and IPv6 is described separately in [[RFC 2207](https://datatracker.ietf.org/doc/html/rfc2207)]. RSVP messages carrying reservation requests originate at receivers and are passed upstream towards the sender(s). Note: in this document, we define the directional terms "upstream" vs. "downstream", "previous hop" vs. "next hop", and "incoming interface" vs "outgoing interface" with respect to the direction of data flow. Braden, Ed., et. al. Standards Track [Page 9]

3

---

RFC 2205 RSVP September 1997

  The exact format of a filter spec depends upon whether IPv4 or
  IPv6 is in use; see [Appendix A](https://datatracker.ietf.org/doc/html/rfc2205

# appendix-A). In the most general approach

  [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

# ref-RSVP93)], filter specs may select arbitrary subsets of the packets

  in a given session.  Such subsets might be defined in terms of
  senders (i.e., sender IP address and generalized source port), in
  terms of a higher-level protocol, or generally in terms of any
  fields in any protocol headers in the packet.  For example, filter
  specs might be used to select different subflows of a
  hierarchically-encoded video stream by selecting on fields in an
  application-layer header.  In the interest of simplicity (and to
  minimize layer violation), the basic filter spec format defined in
  the present RSVP specification has a very restricted form: sender
  IP address and optionally the UDP/TCP port number SrcPort.
  Because the UDP/TCP port numbers are used for packet
  classification, each router must be able to examine these fields.
  This raises three potential problems.

1. It is necessary to avoid IP fragmentation of a data flow for

          which a resource reservation is desired.
          Document [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] specifies a procedure for applications
          using RSVP facilities to compute the minimum MTU over a
          multicast tree and return the result to the senders.

2. IPv6 inserts a variable number of variable-length Internet- layer headers before the transport header, increasing the difficulty and cost of packet classification for QoS. Efficient classification of IPv6 data packets could be obtained using the Flow Label field of the IPv6 header. The details will be provided in the future.
3. IP-level Security, under either IPv4 or IPv6, may encrypt the entire transport header, hiding the port numbers of data packets from intermediate routers. A small extension to RSVP for IP Security under IPv4 and IPv6 is described separately in [[RFC 2207](https://datatracker.ietf.org/doc/html/rfc2207)]. RSVP messages carrying reservation requests originate at receivers and are passed upstream towards the sender(s). Note: in this document, we define the directional terms "upstream" vs. "downstream", "previous hop" vs. "next hop", and "incoming interface" vs "outgoing interface" with respect to the direction of data flow. Braden, Ed., et. al. Standards Track [Page 9]

4

---

RFC 2205 RSVP September 1997

  The exact format of a filter spec depends upon whether IPv4 or
  IPv6 is in use; see [Appendix A](https://datatracker.ietf.org/doc/html/rfc2205

# appendix-A). In the most general approach

  [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

# ref-RSVP93)], filter specs may select arbitrary subsets of the packets

  in a given session.  Such subsets might be defined in terms of
  senders (i.e., sender IP address and generalized source port), in
  terms of a higher-level protocol, or generally in terms of any
  fields in any protocol headers in the packet.  For example, filter
  specs might be used to select different subflows of a
  hierarchically-encoded video stream by selecting on fields in an
  application-layer header.  In the interest of simplicity (and to
  minimize layer violation), the basic filter spec format defined in
  the present RSVP specification has a very restricted form: sender
  IP address and optionally the UDP/TCP port number SrcPort.
  Because the UDP/TCP port numbers are used for packet
  classification, each router must be able to examine these fields.
  This raises three potential problems.

1. It is necessary to avoid IP fragmentation of a data flow for

          which a resource reservation is desired.
          Document [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] specifies a procedure for applications
          using RSVP facilities to compute the minimum MTU over a
          multicast tree and return the result to the senders.

2. IPv6 inserts a variable number of variable-length Internet- layer headers before the transport header, increasing the difficulty and cost of packet classification for QoS. Efficient classification of IPv6 data packets could be obtained using the Flow Label field of the IPv6 header. The details will be provided in the future.
3. IP-level Security, under either IPv4 or IPv6, may encrypt the entire transport header, hiding the port numbers of data packets from intermediate routers. A small extension to RSVP for IP Security under IPv4 and IPv6 is described separately in [[RFC 2207](https://datatracker.ietf.org/doc/html/rfc2207)]. RSVP messages carrying reservation requests originate at receivers and are passed upstream towards the sender(s). Note: in this document, we define the directional terms "upstream" vs. "downstream", "previous hop" vs. "next hop", and "incoming interface" vs "outgoing interface" with respect to the direction of data flow. Braden, Ed., et. al. Standards Track [Page 9]

5

---

RFC 2205 RSVP September 1997

  The exact format of a filter spec depends upon whether IPv4 or
  IPv6 is in use; see [Appendix A](https://datatracker.ietf.org/doc/html/rfc2205

# appendix-A). In the most general approach

  [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

# ref-RSVP93)], filter specs may select arbitrary subsets of the packets

  in a given session.  Such subsets might be defined in terms of
  senders (i.e., sender IP address and generalized source port), in
  terms of a higher-level protocol, or generally in terms of any
  fields in any protocol headers in the packet.  For example, filter
  specs might be used to select different subflows of a
  hierarchically-encoded video stream by selecting on fields in an
  application-layer header.  In the interest of simplicity (and to
  minimize layer violation), the basic filter spec format defined in
  the present RSVP specification has a very restricted form: sender
  IP address and optionally the UDP/TCP port number SrcPort.
  Because the UDP/TCP port numbers are used for packet
  classification, each router must be able to examine these fields.
  This raises three potential problems.

1. It is necessary to avoid IP fragmentation of a data flow for

          which a resource reservation is desired.
          Document [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] specifies a procedure for applications
          using RSVP facilities to compute the minimum MTU over a
          multicast tree and return the result to the senders.

2. IPv6 inserts a variable number of variable-length Internet- layer headers before the transport header, increasing the difficulty and cost of packet classification for QoS. Efficient classification of IPv6 data packets could be obtained using the Flow Label field of the IPv6 header. The details will be provided in the future.
3. IP-level Security, under either IPv4 or IPv6, may encrypt the entire transport header, hiding the port numbers of data packets from intermediate routers. A small extension to RSVP for IP Security under IPv4 and IPv6 is described separately in [[RFC 2207](https://datatracker.ietf.org/doc/html/rfc2207)]. RSVP messages carrying reservation requests originate at receivers and are passed upstream towards the sender(s). Note: in this document, we define the directional terms "upstream" vs. "downstream", "previous hop" vs. "next hop", and "incoming interface" vs "outgoing interface" with respect to the direction of data flow. Braden, Ed., et. al. Standards Track [Page 9]

6

---

RFC 2205 RSVP September 1997

  The exact format of a filter spec depends upon whether IPv4 or
  IPv6 is in use; see [Appendix A](https://datatracker.ietf.org/doc/html/rfc2205

# appendix-A). In the most general approach

  [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

# ref-RSVP93)], filter specs may select arbitrary subsets of the packets

  in a given session.  Such subsets might be defined in terms of
  senders (i.e., sender IP address and generalized source port), in
  terms of a higher-level protocol, or generally in terms of any
  fields in any protocol headers in the packet.  For example, filter
  specs might be used to select different subflows of a
  hierarchically-encoded video stream by selecting on fields in an
  application-layer header.  In the interest of simplicity (and to
  minimize layer violation), the basic filter spec format defined in
  the present RSVP specification has a very restricted form: sender
  IP address and optionally the UDP/TCP port number SrcPort.
  Because the UDP/TCP port numbers are used for packet
  classification, each router must be able to examine these fields.
  This raises three potential problems.

1. It is necessary to avoid IP fragmentation of a data flow for

          which a resource reservation is desired.
          Document [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] specifies a procedure for applications
          using RSVP facilities to compute the minimum MTU over a
          multicast tree and return the result to the senders.

2. IPv6 inserts a variable number of variable-length Internet- layer headers before the transport header, increasing the difficulty and cost of packet classification for QoS. Efficient classification of IPv6 data packets could be obtained using the Flow Label field of the IPv6 header. The details will be provided in the future.
3. IP-level Security, under either IPv4 or IPv6, may encrypt the entire transport header, hiding the port numbers of data packets from intermediate routers. A small extension to RSVP for IP Security under IPv4 and IPv6 is described separately in [[RFC 2207](https://datatracker.ietf.org/doc/html/rfc2207)]. RSVP messages carrying reservation requests originate at receivers and are passed upstream towards the sender(s). Note: in this document, we define the directional terms "upstream" vs. "downstream", "previous hop" vs. "next hop", and "incoming interface" vs "outgoing interface" with respect to the direction of data flow. Braden, Ed., et. al. Standards Track [Page 9]

7

---

RFC 2205 RSVP September 1997

  The exact format of a filter spec depends upon whether IPv4 or
  IPv6 is in use; see [Appendix A](https://datatracker.ietf.org/doc/html/rfc2205

# appendix-A). In the most general approach

  [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

# ref-RSVP93)], filter specs may select arbitrary subsets of the packets

  in a given session.  Such subsets might be defined in terms of
  senders (i.e., sender IP address and generalized source port), in
  terms of a higher-level protocol, or generally in terms of any
  fields in any protocol headers in the packet.  For example, filter
  specs might be used to select different subflows of a
  hierarchically-encoded video stream by selecting on fields in an
  application-layer header.  In the interest of simplicity (and to
  minimize layer violation), the basic filter spec format defined in
  the present RSVP specification has a very restricted form: sender
  IP address and optionally the UDP/TCP port number SrcPort.
  Because the UDP/TCP port numbers are used for packet
  classification, each router must be able to examine these fields.
  This raises three potential problems.

1. It is necessary to avoid IP fragmentation of a data flow for

          which a resource reservation is desired.
          Document [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] specifies a procedure for applications
          using RSVP facilities to compute the minimum MTU over a
          multicast tree and return the result to the senders.

2. IPv6 inserts a variable number of variable-length Internet- layer headers before the transport header, increasing the difficulty and cost of packet classification for QoS. Efficient classification of IPv6 data packets could be obtained using the Flow Label field of the IPv6 header. The details will be provided in the future.
3. IP-level Security, under either IPv4 or IPv6, may encrypt the entire transport header, hiding the port numbers of data packets from intermediate routers. A small extension to RSVP for IP Security under IPv4 and IPv6 is described separately in [[RFC 2207](https://datatracker.ietf.org/doc/html/rfc2207)]. RSVP messages carrying reservation requests originate at receivers and are passed upstream towards the sender(s). Note: in this document, we define the directional terms "upstream" vs. "downstream", "previous hop" vs. "next hop", and "incoming interface" vs "outgoing interface" with respect to the direction of data flow. Braden, Ed., et. al. Standards Track [Page 9]

8

---

RFC 2205 RSVP September 1997

  The exact format of a filter spec depends upon whether IPv4 or
  IPv6 is in use; see [Appendix A](https://datatracker.ietf.org/doc/html/rfc2205

# appendix-A). In the most general approach

  [[RSVP93](https://datatracker.ietf.org/doc/html/rfc2205

# ref-RSVP93)], filter specs may select arbitrary subsets of the packets

  in a given session.  Such subsets might be defined in terms of
  senders (i.e., sender IP address and generalized source port), in
  terms of a higher-level protocol, or generally in terms of any
  fields in any protocol headers in the packet.  For example, filter
  specs might be used to select different subflows of a
  hierarchically-encoded video stream by selecting on fields in an
  application-layer header.  In the interest of simplicity (and to
  minimize layer violation), the basic filter spec format defined in
  the present RSVP specification has a very restricted form: sender
  IP address and optionally the UDP/TCP port number SrcPort.
  Because the UDP/TCP port numbers are used for packet
  classification, each router must be able to examine these fields.
  This raises three potential problems.

1. It is necessary to avoid IP fragmentation of a data flow for

          which a resource reservation is desired.
          Document [[RFC 2210](https://datatracker.ietf.org/doc/html/rfc2210)] specifies a procedure for applications
          using RSVP facilities to compute the minimum MTU over a
          multicast tree and return the result to the senders.

2. IPv6 inserts a variable number of variable-length Internet- layer headers before the transport header, increasing the difficulty and cost of packet classification for QoS. Efficient classification of IPv6 data packets could be obtained using the Flow Label field of the IPv6 header. The details will be provided in the future.
3. IP-level Security, under either IPv4 or IPv6, may encrypt the entire transport header, hiding the port numbers of data packets from intermediate routers. A small extension to RSVP for IP Security under IPv4 and IPv6 is described separately in [[RFC 2207](https://datatracker.ietf.org/doc/html/rfc2207)]. RSVP messages carrying reservation requests originate at receivers and are passed upstream towards the sender(s). Note: in this document, we define the directional terms "upstream" vs. "downstream", "previous hop" vs. "next hop", and "incoming interface" vs "outgoing interface" with respect to the direction of data flow. Braden, Ed., et. al. Standards Track [Page 9]

9

---

RFC 2205 RSVP September 1997

  At each intermediate node, a reservation request triggers two
  general actions, as follows:

1. Make a reservation on a link

          The RSVP process passes the request to admission control and
          policy control.  If either test fails, the reservation is
          rejected and the RSVP process returns an error message to the
          appropriate receiver(s).  If both succeed, the node sets the
          packet classifier to select the data packets defined by the
          filter spec, and it interacts with the appropriate link layer
          to obtain the desired QoS defined by the flowspec.
          The detailed rules for satisfying an RSVP QoS request depend
          upon the particular link layer technology in use on each
          interface.  Specifications are under development in the ISSLL
          Working Group for mapping reservation requests into popular
          link layer technologies.  For a simple leased line, the
          desired QoS will be obtained from the packet scheduler in the
          link layer driver, for example.  If the link-layer technology
          implements its own QoS management capability, then RSVP must
          negotiate with the link layer to obtain the requested QoS.
          Note that the action to control QoS occurs at the place where
          the data enters the link-layer medium, i.e., at the upstream
          end of the logical or physical link, although an RSVP
          reservation request originates from receiver(s) downstream.

2. Forward the request upstream A reservation request is propagated upstream towards the appropriate senders. The set of sender hosts to which a given reservation request is propagated is called the "scope" of that request. The reservation request that a node forwards upstream may differ from the request that it received from downstream, for two reasons. The traffic control mechanism may modify the flowspec hop-by-hop. More importantly, reservations from different downstream branches of the multicast tree(s) from the same sender (or set of senders) must be " merged" as reservations travel upstream. When a receiver originates a reservation request, it can also request a confirmation message to indicate that its request was (probably) installed in the network. A successful reservation request propagates upstream along the multicast tree until it reaches a point where an existing reservation is equal or greater Braden, Ed., et. al. Standards Track [Page 10]

0

---

RFC 2205 RSVP September 1997

  At each intermediate node, a reservation request triggers two
  general actions, as follows:

1. Make a reservation on a link

          The RSVP process passes the request to admission control and
          policy control.  If either test fails, the reservation is
          rejected and the RSVP process returns an error message to the
          appropriate receiver(s).  If both succeed, the node sets the
          packet classifier to select the data packets defined by the
          filter spec, and it interacts with the appropriate link layer
          to obtain the desired QoS defined by the flowspec.
          The detailed rules for satisfying an RSVP QoS request depend
          upon the particular link layer technology in use on each
          interface.  Specifications are under development in the ISSLL
          Working Group for mapping reservation requests into popular
          link layer technologies.  For a simple leased line, the
          desired QoS will be obtained from the packet scheduler in the
          link layer driver, for example.  If the link-layer technology
          implements its own QoS management capability, then RSVP must
          negotiate with the link layer to obtain the requested QoS.
          Note that the action to control QoS occurs at the place where
          the data enters the link-layer medium, i.e., at the upstream
          end of the logical or physical link, although an RSVP
          reservation request originates from receiver(s) downstream.

2. Forward the request upstream A reservation request is propagated upstream towards the appropriate senders. The set of sender hosts to which a given reservation request is propagated is called the "scope" of that request. The reservation request that a node forwards upstream may differ from the request that it received from downstream, for two reasons. The traffic control mechanism may modify the flowspec hop-by-hop. More importantly, reservations from different downstream branches of the multicast tree(s) from the same sender (or set of senders) must be " merged" as reservations travel upstream. When a receiver originates a reservation request, it can also request a confirmation message to indicate that its request was (probably) installed in the network. A successful reservation request propagates upstream along the multicast tree until it reaches a point where an existing reservation is equal or greater Braden, Ed., et. al. Standards Track [Page 10]

1

---

RFC 2205 RSVP September 1997

  At each intermediate node, a reservation request triggers two
  general actions, as follows:

1. Make a reservation on a link

          The RSVP process passes the request to admission control and
          policy control.  If either test fails, the reservation is
          rejected and the RSVP process returns an error message to the
          appropriate receiver(s).  If both succeed, the node sets the
          packet classifier to select the data packets defined by the
          filter spec, and it interacts with the appropriate link layer
          to obtain the desired QoS defined by the flowspec.
          The detailed rules for satisfying an RSVP QoS request depend
          upon the particular link layer technology in use on each
          interface.  Specifications are under development in the ISSLL
          Working Group for mapping reservation requests into popular
          link layer technologies.  For a simple leased line, the
          desired QoS will be obtained from the packet scheduler in the
          link layer driver, for example.  If the link-layer technology
          implements its own QoS management capability, then RSVP must
          negotiate with the link layer to obtain the requested QoS.
          Note that the action to control QoS occurs at the place where
          the data enters the link-layer medium, i.e., at the upstream
          end of the logical or physical link, although an RSVP
          reservation request originates from receiver(s) downstream.

2. Forward the request upstream A reservation request is propagated upstream towards the appropriate senders. The set of sender hosts to which a given reservation request is propagated is called the "scope" of that request. The reservation request that a node forwards upstream may differ from the request that it received from downstream, for two reasons. The traffic control mechanism may modify the flowspec hop-by-hop. More importantly, reservations from different downstream branches of the multicast tree(s) from the same sender (or set of senders) must be " merged" as reservations travel upstream. When a receiver originates a reservation request, it can also request a confirmation message to indicate that its request was (probably) installed in the network. A successful reservation request propagates upstream along the multicast tree until it reaches a point where an existing reservation is equal or greater Braden, Ed., et. al. Standards Track [Page 10]

2

---

RFC 2205 RSVP September 1997

  At each intermediate node, a reservation request triggers two
  general actions, as follows:

1. Make a reservation on a link

          The RSVP process passes the request to admission control and
          policy control.  If either test fails, the reservation is
          rejected and the RSVP process returns an error message to the
          appropriate receiver(s).  If both succeed, the node sets the
          packet classifier to select the data packets defined by the
          filter spec, and it interacts with the appropriate link layer
          to obtain the desired QoS defined by the flowspec.
          The detailed rules for satisfying an RSVP QoS request depend
          upon the particular link layer technology in use on each
          interface.  Specifications are under development in the ISSLL
          Working Group for mapping reservation requests into popular
          link layer technologies.  For a simple leased line, the
          desired QoS will be obtained from the packet scheduler in the
          link layer driver, for example.  If the link-layer technology
          implements its own QoS management capability, then RSVP must
          negotiate with the link layer to obtain the requested QoS.
          Note that the action to control QoS occurs at the place where
          the data enters the link-layer medium, i.e., at the upstream
          end of the logical or physical link, although an RSVP
          reservation request originates from receiver(s) downstream.

2. Forward the request upstream A reservation request is propagated upstream towards the appropriate senders. The set of sender hosts to which a given reservation request is propagated is called the "scope" of that request. The reservation request that a node forwards upstream may differ from the request that it received from downstream, for two reasons. The traffic control mechanism may modify the flowspec hop-by-hop. More importantly, reservations from different downstream branches of the multicast tree(s) from the same sender (or set of senders) must be " merged" as reservations travel upstream. When a receiver originates a reservation request, it can also request a confirmation message to indicate that its request was (probably) installed in the network. A successful reservation request propagates upstream along the multicast tree until it reaches a point where an existing reservation is equal or greater Braden, Ed., et. al. Standards Track [Page 10]

3

---

RFC 2205 RSVP September 1997

  At each intermediate node, a reservation request triggers two
  general actions, as follows:

1. Make a reservation on a link

          The RSVP process passes the request to admission control and
          policy control.  If either test fails, the reservation is
          rejected and the RSVP process returns an error message to the
          appropriate receiver(s).  If both succeed, the node sets the
          packet classifier to select the data packets defined by the
          filter spec, and it interacts with the appropriate link layer
          to obtain the desired QoS defined by the flowspec.
          The detailed rules for satisfying an RSVP QoS request depend
          upon the particular link layer technology in use on each
          interface.  Specifications are under development in the ISSLL
          Working Group for mapping reservation requests into popular
          link layer technologies.  For a simple leased line, the
          desired QoS will be obtained from the packet scheduler in the
          link layer driver, for example.  If the link-layer technology
          implements its own QoS management capability, then RSVP must
          negotiate with the link layer to obtain the requested QoS.
          Note that the action to control QoS occurs at the place where
          the data enters the link-layer medium, i.e., at the upstream
          end of the logical or physical link, although an RSVP
          reservation request originates from receiver(s) downstream.

2. Forward the request upstream A reservation request is propagated upstream towards the appropriate senders. The set of sender hosts to which a given reservation request is propagated is called the "scope" of that request. The reservation request that a node forwards upstream may differ from the request that it received from downstream, for two reasons. The traffic control mechanism may modify the flowspec hop-by-hop. More importantly, reservations from different downstream branches of the multicast tree(s) from the same sender (or set of senders) must be " merged" as reservations travel upstream. When a receiver originates a reservation request, it can also request a confirmation message to indicate that its request was (probably) installed in the network. A successful reservation request propagates upstream along the multicast tree until it reaches a point where an existing reservation is equal or greater Braden, Ed., et. al. Standards Track [Page 10]

4

---

RFC 2205 RSVP September 1997

  At each intermediate node, a reservation request triggers two
  general actions, as follows:

1. Make a reservation on a link

          The RSVP process passes the request to admission control and
          policy control.  If either test fails, the reservation is
          rejected and the RSVP process returns an error message to the
          appropriate receiver(s).  If both succeed, the node sets the
          packet classifier to select the data packets defined by the
          filter spec, and it interacts with the appropriate link layer
          to obtain the desired QoS defined by the flowspec.
          The detailed rules for satisfying an RSVP QoS request depend
          upon the particular link layer technology in use on each
          interface.  Specifications are under development in the ISSLL
          Working Group for mapping reservation requests into popular
          link layer technologies.  For a simple leased line, the
          desired QoS will be obtained from the packet scheduler in the
          link layer driver, for example.  If the link-layer technology
          implements its own QoS management capability, then RSVP must
          negotiate with the link layer to obtain the requested QoS.
          Note that the action to control QoS occurs at the place where
          the data enters the link-layer medium, i.e., at the upstream
          end of the logical or physical link, although an RSVP
          reservation request originates from receiver(s) downstream.

2. Forward the request upstream A reservation request is propagated upstream towards the appropriate senders. The set of sender hosts to which a given reservation request is propagated is called the "scope" of that request. The reservation request that a node forwards upstream may differ from the request that it received from downstream, for two reasons. The traffic control mechanism may modify the flowspec hop-by-hop. More importantly, reservations from different downstream branches of the multicast tree(s) from the same sender (or set of senders) must be " merged" as reservations travel upstream. When a receiver originates a reservation request, it can also request a confirmation message to indicate that its request was (probably) installed in the network. A successful reservation request propagates upstream along the multicast tree until it reaches a point where an existing reservation is equal or greater Braden, Ed., et. al. Standards Track [Page 10]

5

---

RFC 2205 RSVP September 1997

  At each intermediate node, a reservation request triggers two
  general actions, as follows:

1. Make a reservation on a link

          The RSVP process passes the request to admission control and
          policy control.  If either test fails, the reservation is
          rejected and the RSVP process returns an error message to the
          appropriate receiver(s).  If both succeed, the node sets the
          packet classifier to select the data packets defined by the
          filter spec, and it interacts with the appropriate link layer
          to obtain the desired QoS defined by the flowspec.
          The detailed rules for satisfying an RSVP QoS request depend
          upon the particular link layer technology in use on each
          interface.  Specifications are under development in the ISSLL
          Working Group for mapping reservation requests into popular
          link layer technologies.  For a simple leased line, the
          desired QoS will be obtained from the packet scheduler in the
          link layer driver, for example.  If the link-layer technology
          implements its own QoS management capability, then RSVP must
          negotiate with the link layer to obtain the requested QoS.
          Note that the action to control QoS occurs at the place where
          the data enters the link-layer medium, i.e., at the upstream
          end of the logical or physical link, although an RSVP
          reservation request originates from receiver(s) downstream.

2. Forward the request upstream A reservation request is propagated upstream towards the appropriate senders. The set of sender hosts to which a given reservation request is propagated is called the "scope" of that request. The reservation request that a node forwards upstream may differ from the request that it received from downstream, for two reasons. The traffic control mechanism may modify the flowspec hop-by-hop. More importantly, reservations from different downstream branches of the multicast tree(s) from the same sender (or set of senders) must be " merged" as reservations travel upstream. When a receiver originates a reservation request, it can also request a confirmation message to indicate that its request was (probably) installed in the network. A successful reservation request propagates upstream along the multicast tree until it reaches a point where an existing reservation is equal or greater Braden, Ed., et. al. Standards Track [Page 10]

6

---

RFC 2205 RSVP September 1997

  At each intermediate node, a reservation request triggers two
  general actions, as follows:

1. Make a reservation on a link

          The RSVP process passes the request to admission control and
          policy control.  If either test fails, the reservation is
          rejected and the RSVP process returns an error message to the
          appropriate receiver(s).  If both succeed, the node sets the
          packet classifier to select the data packets defined by the
          filter spec, and it interacts with the appropriate link layer
          to obtain the desired QoS defined by the flowspec.
          The detailed rules for satisfying an RSVP QoS request depend
          upon the particular link layer technology in use on each
          interface.  Specifications are under development in the ISSLL
          Working Group for mapping reservation requests into popular
          link layer technologies.  For a simple leased line, the
          desired QoS will be obtained from the packet scheduler in the
          link layer driver, for example.  If the link-layer technology
          implements its own QoS management capability, then RSVP must
          negotiate with the link layer to obtain the requested QoS.
          Note that the action to control QoS occurs at the place where
          the data enters the link-layer medium, i.e., at the upstream
          end of the logical or physical link, although an RSVP
          reservation request originates from receiver(s) downstream.

2. Forward the request upstream A reservation request is propagated upstream towards the appropriate senders. The set of sender hosts to which a given reservation request is propagated is called the "scope" of that request. The reservation request that a node forwards upstream may differ from the request that it received from downstream, for two reasons. The traffic control mechanism may modify the flowspec hop-by-hop. More importantly, reservations from different downstream branches of the multicast tree(s) from the same sender (or set of senders) must be " merged" as reservations travel upstream. When a receiver originates a reservation request, it can also request a confirmation message to indicate that its request was (probably) installed in the network. A successful reservation request propagates upstream along the multicast tree until it reaches a point where an existing reservation is equal or greater Braden, Ed., et. al. Standards Track [Page 10]

7

---

RFC 2205 RSVP September 1997

  At each intermediate node, a reservation request triggers two
  general actions, as follows:

1. Make a reservation on a link

          The RSVP process passes the request to admission control and
          policy control.  If either test fails, the reservation is
          rejected and the RSVP process returns an error message to the
          appropriate receiver(s).  If both succeed, the node sets the
          packet classifier to select the data packets defined by the
          filter spec, and it interacts with the appropriate link layer
          to obtain the desired QoS defined by the flowspec.
          The detailed rules for satisfying an RSVP QoS request depend
          upon the particular link layer technology in use on each
          interface.  Specifications are under development in the ISSLL
          Working Group for mapping reservation requests into popular
          link layer technologies.  For a simple leased line, the
          desired QoS will be obtained from the packet scheduler in the
          link layer driver, for example.  If the link-layer technology
          implements its own QoS management capability, then RSVP must
          negotiate with the link layer to obtain the requested QoS.
          Note that the action to control QoS occurs at the place where
          the data enters the link-layer medium, i.e., at the upstream
          end of the logical or physical link, although an RSVP
          reservation request originates from receiver(s) downstream.

2. Forward the request upstream A reservation request is propagated upstream towards the appropriate senders. The set of sender hosts to which a given reservation request is propagated is called the "scope" of that request. The reservation request that a node forwards upstream may differ from the request that it received from downstream, for two reasons. The traffic control mechanism may modify the flowspec hop-by-hop. More importantly, reservations from different downstream branches of the multicast tree(s) from the same sender (or set of senders) must be " merged" as reservations travel upstream. When a receiver originates a reservation request, it can also request a confirmation message to indicate that its request was (probably) installed in the network. A successful reservation request propagates upstream along the multicast tree until it reaches a point where an existing reservation is equal or greater Braden, Ed., et. al. Standards Track [Page 10]

8

---

RFC 2205 RSVP September 1997

  At each intermediate node, a reservation request triggers two
  general actions, as follows:

1. Make a reservation on a link

          The RSVP process passes the request to admission control and
          policy control.  If either test fails, the reservation is
          rejected and the RSVP process returns an error message to the
          appropriate receiver(s).  If both succeed, the node sets the
          packet classifier to select the data packets defined by the
          filter spec, and it interacts with the appropriate link layer
          to obtain the desired QoS defined by the flowspec.
          The detailed rules for satisfying an RSVP QoS request depend
          upon the particular link layer technology in use on each
          interface.  Specifications are under development in the ISSLL
          Working Group for mapping reservation requests into popular
          link layer technologies.  For a simple leased line, the
          desired QoS will be obtained from the packet scheduler in the
          link layer driver, for example.  If the link-layer technology
          implements its own QoS management capability, then RSVP must
          negotiate with the link layer to obtain the requested QoS.
          Note that the action to control QoS occurs at the place where
          the data enters the link-layer medium, i.e., at the upstream
          end of the logical or physical link, although an RSVP
          reservation request originates from receiver(s) downstream.

2. Forward the request upstream A reservation request is propagated upstream towards the appropriate senders. The set of sender hosts to which a given reservation request is propagated is called the "scope" of that request. The reservation request that a node forwards upstream may differ from the request that it received from downstream, for two reasons. The traffic control mechanism may modify the flowspec hop-by-hop. More importantly, reservations from different downstream branches of the multicast tree(s) from the same sender (or set of senders) must be " merged" as reservations travel upstream. When a receiver originates a reservation request, it can also request a confirmation message to indicate that its request was (probably) installed in the network. A successful reservation request propagates upstream along the multicast tree until it reaches a point where an existing reservation is equal or greater Braden, Ed., et. al. Standards Track [Page 10]

9

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

00

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

01

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

02

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

03

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

04

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

05

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

06

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

07

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

08

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

09

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

10

---

RFC 2205 RSVP September 1997 Table of Contents [1](https://datatracker.ietf.org/doc/html/rfc2205

section-1). Introduction ................................................... [4](https://datatracker.ietf.org/doc/html/rfc2205

page-4)

  [1.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.1) Data Flows ................................................. [7](https://datatracker.ietf.org/doc/html/rfc2205

page-7)

  [1.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.2) Reservation Model .......................................... [8](https://datatracker.ietf.org/doc/html/rfc2205

page-8)

  [1.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.3) Reservation Styles .........................................[11](https://datatracker.ietf.org/doc/html/rfc2205

page-11)

  [1.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-1.4) Examples of Styles .........................................[14](https://datatracker.ietf.org/doc/html/rfc2205

page-14)

[2](https://datatracker.ietf.org/doc/html/rfc2205

section-2). RSVP Protocol Mechanisms .......................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.1) RSVP Messages ..............................................[19](https://datatracker.ietf.org/doc/html/rfc2205

page-19)

  [2.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.2) Merging Flowspecs ..........................................[21](https://datatracker.ietf.org/doc/html/rfc2205

page-21)

  [2.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.3) Soft State .................................................[22](https://datatracker.ietf.org/doc/html/rfc2205

page-22)

  [2.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.4) Teardown ...................................................[24](https://datatracker.ietf.org/doc/html/rfc2205

page-24)

  [2.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.5) Errors .....................................................[25](https://datatracker.ietf.org/doc/html/rfc2205

page-25)

  [2.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.6) Confirmation ...............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.7) Policy Control .............................................[27](https://datatracker.ietf.org/doc/html/rfc2205

page-27)

  [2.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.8) Security ...................................................[28](https://datatracker.ietf.org/doc/html/rfc2205

page-28)

  [2.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.9) Non-RSVP Clouds ............................................[29](https://datatracker.ietf.org/doc/html/rfc2205

page-29)

  [2.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-2.10) Host Model ................................................[30](https://datatracker.ietf.org/doc/html/rfc2205

page-30)

[3](https://datatracker.ietf.org/doc/html/rfc2205

section-3). RSVP Functional Specification ..................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.1](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.1) RSVP Message Formats .......................................[32](https://datatracker.ietf.org/doc/html/rfc2205

page-32)

  [3.2](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.2) Port Usage .................................................[47](https://datatracker.ietf.org/doc/html/rfc2205

page-47)

  [3.3](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.3) Sending RSVP Messages ......................................[48](https://datatracker.ietf.org/doc/html/rfc2205

page-48)

  [3.4](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.4) Avoiding RSVP Message Loops ................................[50](https://datatracker.ietf.org/doc/html/rfc2205

page-50)

  [3.5](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.5) Blockade State .............................................[54](https://datatracker.ietf.org/doc/html/rfc2205

page-54)

  [3.6](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.6) Local Repair ...............................................[56](https://datatracker.ietf.org/doc/html/rfc2205

page-56)

  [3.7](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.7) Time Parameters ............................................[57](https://datatracker.ietf.org/doc/html/rfc2205

page-57)

  [3.8](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.8) Traffic Policing and Non-Integrated Service Hops ...........[58](https://datatracker.ietf.org/doc/html/rfc2205

page-58)

  [3.9](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.9) Multihomed Hosts ...........................................[59](https://datatracker.ietf.org/doc/html/rfc2205

page-59)

  [3.10](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.10) Future Compatibility ......................................[61](https://datatracker.ietf.org/doc/html/rfc2205

page-61)

  [3.11](https://datatracker.ietf.org/doc/html/rfc2205

# section-3.11) RSVP Interfaces ...........................................[63](https://datatracker.ietf.org/doc/html/rfc2205

page-63)

[4](https://datatracker.ietf.org/doc/html/rfc2205

section-4). Acknowledgments ................................................[76](https://datatracker.ietf.org/doc/html/rfc2205

page-76)

APPENDIX A. Object Definitions ....................................[77](https://datatracker.ietf.org/doc/html/rfc2205

page-77)

APPENDIX B. Error Codes and Values ................................[92](https://datatracker.ietf.org/doc/html/rfc2205

page-92)

APPENDIX C. UDP Encapsulation .....................................[98](https://datatracker.ietf.org/doc/html/rfc2205

page-98)

APPENDIX D. Glossary .............................................[102](https://datatracker.ietf.org/doc/html/rfc2205

page-102)

REFERENCES .......................................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

SECURITY CONSIDERATIONS ..........................................[111](https://datatracker.ietf.org/doc/html/rfc2205

page-111)

AUTHORS' ADDRESSES ...............................................[112](https://datatracker.ietf.org/doc/html/rfc2205

page-112)

Braden, Ed., et. al. Standards Track [Page 2]

11