rfc2205.txt

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

Braden, Ed., et. al.        Standards Track                    [Page 11]

RFC 2205                          RSVP                    September 1997



           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.



Braden, Ed., et. al.        Standards Track                    [Page 12]

RFC 2205                          RSVP                    September 1997


           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.



Braden, Ed., et. al.        Standards Track                    [Page 13]

RFC 2205                          RSVP                    September 1997


      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.














Braden, Ed., et. al.        Standards Track                    [Page 14]

RFC 2205                          RSVP                    September 1997


                         ________________
                     (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.



















Braden, Ed., et. al.        Standards Track                    [Page 15]

RFC 2205                          RSVP                    September 1997



                             |
               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







Braden, Ed., et. al.        Standards Track                    [Page 16]

RFC 2205                          RSVP                    September 1997


      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} )
                          |     |__________|