rfc2205.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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






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





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


      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.