Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2205

Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification

Pages: 112
Proposed Standard
Errata
Updated by:  275039364495594664376780
Part 1 of 4 – Pages 1 to 18
None   None   Next

Top   ToC   RFC2205 - Page 1
Network Working Group                                   R. Braden, Ed.
Request for Comments: 2205                                         ISI
Category: Standards Track                                     L. Zhang
                                                                  UCLA
                                                             S. Berson
                                                                   ISI
                                                             S. Herzog
                                                          IBM Research
                                                              S. 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.
Top   ToC   RFC2205 - Page 2
Table of Contents

   1. Introduction ................................................... 4
      1.1 Data Flows ................................................. 7
      1.2 Reservation Model .......................................... 8
      1.3 Reservation Styles .........................................11
      1.4 Examples of Styles .........................................14
   2. RSVP Protocol Mechanisms .......................................19
      2.1 RSVP Messages ..............................................19
      2.2 Merging Flowspecs ..........................................21
      2.3 Soft State .................................................22
      2.4 Teardown ...................................................24
      2.5 Errors .....................................................25
      2.6 Confirmation ...............................................27
      2.7 Policy Control .............................................27
      2.8 Security ...................................................28
      2.9 Non-RSVP Clouds ............................................29
      2.10 Host Model ................................................30
   3. RSVP Functional Specification ..................................32
      3.1 RSVP Message Formats .......................................32
      3.2 Port Usage .................................................47
      3.3 Sending RSVP Messages ......................................48
      3.4 Avoiding RSVP Message Loops ................................50
      3.5 Blockade State .............................................54
      3.6 Local Repair ...............................................56
      3.7 Time Parameters ............................................57
      3.8 Traffic Policing and Non-Integrated Service Hops ...........58
      3.9 Multihomed Hosts ...........................................59
      3.10 Future Compatibility ......................................61
      3.11 RSVP Interfaces ...........................................63
   4. Acknowledgments ................................................76
   APPENDIX A. Object Definitions ....................................77
   APPENDIX B. Error Codes and Values ................................92
   APPENDIX C. UDP Encapsulation .....................................98
   APPENDIX D. Glossary .............................................102
   REFERENCES .......................................................111
   SECURITY CONSIDERATIONS ..........................................111
   AUTHORS' ADDRESSES ...............................................112
Top   ToC   RFC2205 - Page 3
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.

      o    We added more precise and complete rules for accepting Path
           messages for unicast and multicast destinations (Section
           3.1.3).

      o    We added more precise and complete rules for processing and
           forwarding PathTear messages (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).

      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).

      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).

      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 about the relationship of RSVP to the link
           layer.  (Section 3.10).

      o    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.
Top   ToC   RFC2205 - Page 4
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].  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.
Top   ToC   RFC2205 - Page 5
              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
Top   ToC   RFC2205 - Page 6
   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.
Top   ToC   RFC2205 - Page 7
   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] and [RFC 1633].

   The remainder of this section describes the RSVP reservation
   services.  Section 2 presents an overview of the RSVP protocol
   mechanisms.  Section 3 contains the functional specification of RSVP,
   while Section 4 presents explicit message processing rules.  Appendix
   A defines the variable-length typed data objects used in the RSVP
   protocol.  Appendix B defines error codes and values.  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.
Top   ToC   RFC2205 - Page 8
      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] and are generally opaque to RSVP.
Top   ToC   RFC2205 - Page 9
      The exact format of a filter spec depends upon whether IPv4 or
      IPv6 is in use; see Appendix A.  In the most general approach
      [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] 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].

      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.
Top   ToC   RFC2205 - Page 10
      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
Top   ToC   RFC2205 - Page 11
      than that being requested.  At that point, the arriving request is
      merged with the reservation in place and need not be forwarded
      further; the node may then send a reservation confirmation message
      back to the receiver.  Note that the receipt of a confirmation is
      only a high-probability indication, not a guarantee, that the
      requested service is in place all the way to the sender(s), as
      explained in Section 2.6.

      The basic RSVP reservation model is "one pass": a receiver sends a
      reservation request upstream, and each node in the path either
      accepts or rejects the request.  This scheme provides no easy way
      for a receiver to find out the resulting end-to-end service.
      Therefore, RSVP supports an enhancement to one-pass service known
      as "One Pass With Advertising" (OPWA) [OPWA95].  With OPWA, RSVP
      control packets are sent downstream, following the data paths, to
      gather information that may be used to predict the end-to-end QoS.
      The results ("advertisements") are delivered by RSVP to the
      receiver hosts and perhaps to the receiver applications.  The
      advertisements may then be used by the receiver to construct, or
      to dynamically adjust, an appropriate reservation request.

   1.3 Reservation Styles

      A reservation request includes a set of options that are
      collectively called the reservation "style".

      One reservation option concerns the treatment of reservations for
      different senders within the same session: establish a "distinct"
      reservation for each upstream sender, or else make a single
      reservation that is "shared" among all packets of selected
      senders.

      Another reservation option controls the selection of senders; it
      may be an "explicit" list of all selected senders, or a "wildcard"
      that implicitly selects all the senders to the session.  In an
      explicit sender-selection reservation, each filter spec must match
      exactly one sender, while in a wildcard sender-selection no filter
      spec is needed.
Top   ToC   RFC2205 - Page 12
           Sender   ||             Reservations:
         Selection  ||     Distinct     |        Shared
           _________||__________________|____________________
                    ||                  |                    |
          Explicit  ||  Fixed-Filter    |  Shared-Explicit   |
                    ||  (FF) style      |  (SE) Style        |
          __________||__________________|____________________|
                    ||                  |                    |
          Wildcard  ||  (None defined)  |  Wildcard-Filter   |
                    ||                  |  (WF) Style        |
          __________||__________________|____________________|


                 Figure 3: Reservation Attributes and Styles



      The following styles are currently defined (see Figure 3):

      o    Wildcard-Filter (WF) Style

           The WF style implies the options: "shared" reservation and
           "wildcard" sender selection.  Thus, a WF-style reservation
           creates a single reservation shared by flows from all
           upstream senders.  This reservation may be thought of as a
           shared "pipe", whose "size" is the largest of the resource
           requests from all receivers, independent of the number of
           senders using it.  A WF-style reservation is propagated
           upstream towards all sender hosts, and it automatically
           extends to new senders as they appear.

           Symbolically, we can represent a WF-style reservation request
           by:

               WF( * {Q})


           where the asterisk represents wildcard sender selection and Q
           represents the flowspec.

      o    Fixed-Filter (FF) Style

           The FF style implies the options: "distinct" reservations and
           "explicit" sender selection.  Thus, an elementary FF-style
           reservation request creates a distinct reservation for data
           packets from a particular sender, not sharing them with other
           senders' packets for the same session.
Top   ToC   RFC2205 - Page 13
           Symbolically, we can represent an elementary FF reservation
           request by:

               FF( S{Q})


           where S is the selected sender and Q is the corresponding
           flowspec; the pair forms a flow descriptor.  RSVP allows
           multiple elementary FF-style reservations to be requested at
           the same time, using a list of flow descriptors:

               FF( S1{Q1}, S2{Q2}, ...)


           The total reservation on a link for a given session is the
           `sum' of Q1, Q2, ... for all requested senders.

      o    Shared Explicit (SE) Style

           The SE style implies the options: "shared" reservation and
           "explicit" sender selection.  Thus, an SE-style reservation
           creates a single reservation shared by selected upstream
           senders.  Unlike the WF style, the SE style allows a receiver
           to explicitly specify the set of senders to be included.

           We can represent an SE reservation request containing a
           flowspec Q and a list of senders S1, S2, ... by:

               SE( (S1,S2,...){Q} )


      Shared reservations, created by WF and SE styles, are appropriate
      for those multicast applications in which multiple data sources
      are unlikely to transmit simultaneously.  Packetized audio is an
      example of an application suitable for shared reservations; since
      a limited number of people talk at once, each receiver might issue
      a WF or SE reservation request for twice the bandwidth required
      for one sender (to allow some over-speaking).  On the other hand,
      the FF style, which creates distinct reservations for the flows
      from different senders, is appropriate for video signals.

      The RSVP rules disallow merging of shared reservations with
      distinct reservations, since these modes are fundamentally
      incompatible.  They also disallow merging explicit sender
      selection with wildcard sender selection, since this might produce
      an unexpected service for a receiver that specified explicit
      selection.  As a result of these prohibitions, WF, SE, and FF
      styles are all mutually incompatible.
Top   ToC   RFC2205 - Page 14
      It would seem possible to simulate the effect of a WF reservation
      using the SE style.  When an application asked for WF, the RSVP
      process on the receiver host could use local state to create an
      equivalent SE reservation that explicitly listed all senders.
      However, an SE reservation forces the packet classifier in each
      node to explicitly select each sender in the list, while a WF
      allows the packet classifier to simply "wild card" the sender
      address and port.  When there is a large list of senders, a WF
      style reservation can therefore result in considerably less
      overhead than an equivalent SE style reservation.  For this
      reason, both SE and WF are included in the protocol.

      Other reservation options and styles may be defined in the future.

   1.4 Examples of Styles

      This section presents examples of each of the reservation styles
      and shows the effects of merging.

      Figure 4 illustrates a router with two incoming interfaces,
      labeled (a) and (b), through which flows will arrive, and two
      outgoing interfaces, labeled (c) and (d), through which data will
      be forwarded.  This topology will be assumed in the examples that
      follow.  There are three upstream senders; packets from sender S1
      (S2 and S3) arrive through previous hop (a) ((b), respectively).
      There are also three downstream receivers; packets bound for R1
      (R2 and R3) are routed via outgoing interface (c) ((d),
      respectively).  We furthermore assume that outgoing interface (d)
      is connected to a broadcast LAN, i.e., that replication occurs in
      the network; R2 and R3 are reached via different next hop routers
      (not shown).

      We must also specify the multicast routes within the node of
      Figure 4.  Assume first that data packets from each Si shown in
      Figure 4 are routed to both outgoing interfaces.  Under this
      assumption, Figures 5, 6, and 7 illustrate Wildcard-Filter,
      Fixed-Filter, and Shared-Explicit reservations, respectively.
Top   ToC   RFC2205 - Page 15
                         ________________
                     (a)|                | (c)
      ( S1 ) ---------->|                |----------> ( R1 )
                        |     Router     |      |
                     (b)|                | (d)  |---> ( R2 )
      ( S2,S3 ) ------->|                |------|
                        |________________|      |---> ( R3 )
                                                |

                        Figure 4: Router Configuration



      For simplicity, these examples show flowspecs as one-dimensional
      multiples of some base resource quantity B.  The "Receives" column
      shows the RSVP reservation requests received over outgoing
      interfaces (c) and (d), and the "Reserves" column shows the
      resulting reservation state for each interface.   The "Sends"
      column shows the reservation requests that are sent upstream to
      previous hops (a) and (b).  In the "Reserves" column, each box
      represents one reserved "pipe" on the outgoing link, with the
      corresponding flow descriptor.

      Figure 5, showing the WF style, illustrates two distinct
      situations in which merging is required.  (1) Each of the two next
      hops on interface (d) results in a separate RSVP reservation
      request, as shown; these two requests must be merged into the
      effective flowspec, 3B, that is used to make the reservation on
      interface (d).  (2) The reservations on the interfaces (c) and (d)
      must be merged in order to forward the reservation requests
      upstream; as a result, the larger flowspec 4B is forwarded
      upstream to each previous hop.
Top   ToC   RFC2205 - Page 16
                             |
               Sends         |       Reserves             Receives
                             |
                             |       _______
         WF( *{4B} ) <- (a)  |  (c) | * {4B}|    (c) <- WF( *{4B} )
                             |      |_______|
                             |
      -----------------------|----------------------------------------
                             |       _______
         WF( *{4B} ) <- (b)  |  (d) | * {3B}|    (d) <- WF( *{3B} )
                             |      |_______|        <- WF( *{2B} )

              Figure 5: Wildcard-Filter (WF) Reservation Example



      Figure 6 shows Fixed-Filter (FF) style reservations.  For each
      outgoing interface, there is a separate reservation for each
      source that has been requested, but this reservation will be
      shared among all the receivers that made the request.  The flow
      descriptors for senders S2 and S3, received through outgoing
      interfaces (c) and (d), are packed (not merged) into the request
      forwarded to previous hop (b).  On the other hand, the three
      different flow descriptors specifying sender S1 are merged into
      the single request FF( S1{4B} ) that is sent to previous hop (a).


                          |
            Sends         |       Reserves             Receives
                          |
                          |       ________
     FF( S1{4B} ) <- (a)  |  (c) | S1{4B} |  (c) <- FF( S1{4B}, S2{5B} )
                          |      |________|
                          |      | S2{5B} |
                          |      |________|
     ---------------------|---------------------------------------------
                          |       ________
                  <- (b)  |  (d) | S1{3B} |  (d) <- FF( S1{3B}, S3{B} )
     FF( S2{5B}, S3{B} )  |      |________|      <- FF( S1{B} )
                          |      | S3{B}  |
                          |      |________|

              Figure 6: Fixed-Filter (FF) Reservation Example
Top   ToC   RFC2205 - Page 17
      Figure 7 shows an example of Shared-Explicit (SE) style
      reservations.  When SE-style reservations are merged, the
      resulting filter spec is the union of the original filter specs,
      and the resulting flowspec is the largest flowspec.


                          |
            Sends         |       Reserves             Receives
                          |
                          |       ________
     SE( S1{3B} ) <- (a)  |  (c) |(S1,S2) |   (c) <- SE( (S1,S2){B} )
                          |      |   {B}  |
                          |      |________|
     ---------------------|---------------------------------------------
                          |      __________
                  <- (b)  | (d) |(S1,S2,S3)|  (d) <- SE( (S1,S3){3B} )
     SE( (S2,S3){3B} )    |     |   {3B}   |      <- SE( S2{2B} )
                          |     |__________|

            Figure 7: Shared-Explicit (SE) Reservation Example



      The three examples just shown assume that data packets from S1,
      S2, and S3 are routed to both outgoing interfaces.  The top part
      of Figure 8 shows another routing assumption: data packets from S2
      and S3 are not forwarded to interface (c), e.g., because the
      network topology provides a shorter path for these senders towards
      R1, not traversing this node.  The bottom part of Figure 8 shows
      WF style reservations under this assumption.  Since there is no
      route from (b) to (c), the reservation forwarded out interface (b)
      considers only the reservation on interface (d).
Top   ToC   RFC2205 - Page 18
                         _______________
                     (a)|               | (c)
      ( S1 ) ---------->| >-----------> |----------> ( R1 )
                        |    >          |
                        |      >        |
                     (b)|        >      | (d)
      ( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 )
                        |_______________|

                       Router Configuration


                             |
               Sends         |       Reserves             Receives
                             |
                             |       _______
         WF( *{4B} ) <- (a)  |  (c) | * {4B}|   (c) <- WF( *{4B} )
                             |      |_______|
                             |
      -----------------------|----------------------------------------
                             |       _______
         WF( *{3B} ) <- (b)  |  (d) | * {3B}|   (d) <- WF( * {3B} )
                             |      |_______|       <- WF( * {2B} )

             Figure 8: WF Reservation Example -- Partial Routing


(next page on part 2)

Next Section