rfc2816.txt

RFC 的详细文档！

      control decision to the higher layer entity, along with any
      negotiated modifications to the session parameters.

   -  Saves any returned user_priority to be associated with this
      session in a "802 header" table.  This will be used when
      constructing the Layer 2 headers for future data packets belonging
      to this session.  This table might, for example, be indexed by the
      RSVP flow identifier.









Ghanwani, et al.             Informational                     [Page 20]

RFC 2816        Framework for Int-Serv Over IEEE 802 LAN        May 2000


                    from IP     from RSVP
                  +----|------------|------------+
                  | +--V----+   +---V---+        |
                  | | Addr  <--->       |        | SBM signaling
                  | |mapping|   |Request|<----------------------->
                  | +---+---+   |Module |        |
                  |     |       |       |        |
                  | +---+---+   |       |        |
                  | |  802  <--->       |        |
                  | | header|   +-+-+-+-+        |
                  | +--+----+    /  | |          |
                  |    |        /   | |  +-----+ |
                  |    | +-----+    | +->|Band-| |
                  |    | |          |    |width| |
                  | +--V-V-+  +-----V--+ |Alloc| |
                  | |Class-|  | Packet | +-----+ |
                  | | ifier|==>Schedulr|=========================>
                  | +------+  +--------+         |  data
                  +------------------------------+

                Figure 4: ISSLL in a Sending End Station

   The Bandwidth Allocator (BA) component is only present when a
   distributed BA model is implemented.  When present, its function is
   basically to apply local admission control for the outgoing link
   bandwidth and driver's queuing resources.

7.1.4. At the Layer 3 Receiver

   The ISSLL functionality in the receiver is simpler and is illustrated
   in Figure 5.

   The functions of the Requester Module may be summarized as follows:

   -  Handles any received SBM protocol indications.

   -  Communicates with any local BA for local admission control
      decisions.

   -  Passes indications up to RSVP if OK.

   -  Accepts confirmations from RSVP and relays them back via SBM
      signaling towards the requester.








Ghanwani, et al.             Informational                     [Page 21]

RFC 2816        Framework for Int-Serv Over IEEE 802 LAN        May 2000


                          to RSVP       to IP
                            ^            ^
                       +----|------------|------+
                       | +--+----+       |      |
         SBM signaling | |Request|   +---+---+  |
         <-------------> |Module |   | Strip |  |
                       | +--+---++   |802 hdr|  |
                       |    |    \   +---^---+  |
                       | +--v----+\      |      |
                       | | Band- | \     |      |
                       | |  width|  \    |      |
                       | | Alloc |   .   |      |
                       | +-------+   |   |      |
                       | +------+   +v---+----+ |
         data          | |Class-|   | Packet  | |
         <==============>| ifier|==>|Scheduler| |
                       | +------+   +---------+ |
                       +------------------------+

               Figure 5: ISSLL in a Receiving End Station

   -  May program a receive classifier and scheduler, if used, to
      identify traffic classes of received packets and accord them
      appropriate treatment e.g., reservation of buffers for particular
      traffic classes.

   -  Programs the receiver to strip away link layer header information
      from received packets.

   The Bandwidth Allocator, present only in a distributed implementation
   applies local admission control to see if a request can be supported
   with appropriate local receive resources.

7.2. Switch Model

7.2.1. Centralized Bandwidth Allocator

   Where a centralized Bandwidth Allocator model is implemented,
   switches do not take part in the admission control process.
   Admission control is implemented by a centralized BA, e.g., a "Subnet
   Bandwidth Manager" (SBM) as described in [14].  This centralized BA
   may actually be co-located with a switch but its functions would not
   necessarily then be closely tied with the switch's forwarding
   functions as is the case with the distributed BA described below.







Ghanwani, et al.             Informational                     [Page 22]

RFC 2816        Framework for Int-Serv Over IEEE 802 LAN        May 2000


7.2.2. Distributed Bandwidth Allocator

   The model of Layer 2 switch behavior described here uses the
   terminology of the SBM protocol as an example of an admission control
   protocol.  The model is equally applicable when other mechanisms,
   e.g.  static configuration or network management, are in use for
   admission control.  We define the following entities within the
   switch:

   -  Local Admission Control Module:  One of these on each port
      accounts for the available bandwidth on the link attached to that
      port.  For half duplex links, this involves taking account of the
      resources allocated to both transmit and receive flows.  For full
      duplex links, the input port accountant's task is trivial.

   -  Input SBM Module:  One instance on each port performs the
      "network" side of the signaling protocol for peering with clients
      or other switches.  It also holds knowledge about the mappings of
      IntServ classes to user_priority.

   -  SBM Propagation Module:  Relays requests that have passed
      admission control at the input port to the relevant output ports'
      SBM modules.  This will require access to the switch's forwarding
      table (Layer-2 "routing table" cf.  RSVP model) and port spanning
      tree state.

   -  Output SBM Module:  Forwards requests to the next Layer 2 or Layer
      3 hop.

   -  Classifier, Queue and Scheduler Module:  The functions of this
      module are basically as described by the Forwarding Process of
      IEEE 802.1D (see Section 3.7 of [3]).  The Classifier module
      identifies the relevant QoS information from incoming packets and
      uses this, together with the normal bridge forwarding database, to
      decide at which output port and traffic class to enqueue the
      packet.  Different types of switches will use different techniques
      for flow identification (see Section 8.1).  In IEEE 802.1D
      switches this information is the regenerated user_priority
      parameter which has already been decoded by the receiving MAC
      service and potentially remapped by the forwarding process (see
      Section 3.7.3 of [3]).  This does not preclude more sophisticated
      classification rules such as the classification of individual
      IntServ flows.  The Queue and Scheduler implement the








Ghanwani, et al.             Informational                     [Page 23]

RFC 2816        Framework for Int-Serv Over IEEE 802 LAN        May 2000


      output queues for ports and provide the algorithm for servicing
      the queues for transmission onto the output link in order to
      provide the promised IntServ service.  Switches will implement one
      or more output queues per port and all will implement at least a
      basic static priority dequeuing algorithm as their default, in
      accordance with IEEE 802.1D.

   -  Ingress Traffic Class Mapping and Policing Module:  Its functions
      are as described in IEEE 802.1D Section 3.7.  This optional module
      may police the data within traffic classes for conformance to the
      negotiated parameters, and may discard packets or re-map the
      user_priority.  The default behavior is to pass things through
      unchanged.

   -  Egress Traffic Class Mapping Module:  Its functions are as
      described in IEEE 802.1D Section 3.7.  This optional module may
      perform re-mapping of traffic classes on a per output port basis.
      The default behavior is to pass things through unchanged.

   Figure 6 shows all of the modules in an ISSLL enabled switch.  The
   ISSLL model is a superset of the IEEE 802.1D bridge model.

                     +-------------------------------+
    SBM signaling    | +-----+   +------+   +------+ | SBM signaling
   <------------------>| IN  |<->| SBM  |<->| OUT  |<---------------->
                     | | SBM |   | prop.|   | SBM  | |
                     | +-++--+   +---^--+   /----+-+ |
                     |  / |          |     /     |   |
       ______________| /  |          |     |     |   +-------------+
      | \             /+--V--+       |     |  +--V--+            / |
      |   \      ____/ |Local|       |     |  |Local|          /   |
      |     \   /      |Admis|       |     |  |Admis|        /     |
      |       \/       |Cntrl|       |     |  |Cntrl|      /       |
      | +-----V+\      +-----+       |     |  +-----+    /+-----+  |
      | |traff |  \              +---+--+ +V-------+   /  |egrss|  |
      | |class |    \            |Filter| |Queue & | /    |traff|  |
      | |map & |=====|==========>|Data- |=| Packet |=|===>|class|  |
      | |police|     |           |  base| |Schedule| |    |map  |  |
      | +------+     |           +------+ +--------+ |    +-+---+  |
      +----^---------+-------------------------------+------|------+
   data in |                                                |data out
   ========+                                                +========>

                      Figure 6: ISSLL in a Switch







Ghanwani, et al.             Informational                     [Page 24]

RFC 2816        Framework for Int-Serv Over IEEE 802 LAN        May 2000


7.3. Admission Control

   On receipt of an admission control request, a switch performs the
   following actions, again using SBM as an example.  The behavior is
   different depending on whether the "Designated SBM" for this segment
   is within this switch or not.  See [14] for a more detailed
   specification of the DSBM/SBM actions.

   -  If the ingress SBM is the "Designated SBM" for this link, it
      either translates any received user_priority or selects a Layer 2
      traffic class which appears compatible with the request and whose
      use does not violate any administrative policies in force.  In
      effect, it matches the requested service with the available
      traffic classes and chooses the "best" one.  It ensures that, if
      this reservation is successful, the value of user_priority
      corresponding to that traffic class is passed back to the client.

   -  The ingress DSBM observes the current state of allocation of
      resources on the input port/link and then determines whether the
      new resource allocation from the mapped traffic class can be
      accommodated.  The request is passed to the reservation propagator
      if accepted.

   -  If the ingress SBM is not the "Designated SBM" for this link then
      it directly passes the request on to the reservation propagator.

   -  The reservation propagator relays the request to the bandwidth
      accountants on each of the switch's outbound links to which this
      reservation would apply.  This implies an interface to