rfc2816.txt

<VC++网络游戏建摸与实现>源代码

   format which is understood by other components of the BM responsible
   admission control.  The RM is also responsible for returning the
   status of requests processed by the BM to the invoking application or
   higher layer protocol.

6.1.2. Bandwidth Allocator

   The Bandwidth Allocator (BA) is responsible for performing admission
   control and maintaining state about the allocation of resources in
   the subnet.  An end station can request various services, e.g.
   bandwidth reservation, modification of an existing reservation,
   queries about resource availability, etc.  These requests are
   processed by the BA. The communication between the end station and
   the BA takes place through the RM. The location of the BA will depend
   largely on the implementation method.  In a centralized
   implementation, the BA may reside on a single station in the subnet.
   In a distributed implementation, the functions of the BA may be
   distributed in all the end stations and bridges/switches as
   necessary.  The BA is also responsible for deciding how to label
   flows, e.g.  based on the admission control decision, the BA may
   indicate to the RM that packets belonging to a particular flow be
   tagged with some priority value which maps to the appropriate traffic
   class.

6.1.3. Communication Protocols

   The protocols for communication between the various components of the
   BM system must be specified.  These include the following:

   -  Communication between the higher layer protocols and the RM:  The
      BM must define primitives for the application to initiate
      reservations, query the BA about available resources, change
      change or delete reservations, etc.  These primitives could be
      implemented as an API for an application to invoke functions of
      the BM via the RM.

   -  Communication between the RM and the BA: A signaling mechanism
      must be defined for the communication between the RM and the BA.
      This protocol will specify the messages which must be exchanged
      between the RM and the BA in order to service various requests by
      the higher layer entity.

   -  Communication between peer BAs:  If there is more than one BA in
      the subnet, a means must be specified for inter-BA communication.
      Specifically, the BAs must be able to decide among themselves



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


      about which BA would be responsible for which segments and bridges
      or switches.  Further, if a request is made for resource
      reservation along the domain of multiple BAs, the BAs must be able
      to handle such a scenario correctly.  Inter-BA communication will
      also be responsible for back-up and recovery in the event of
      failure.

6.2. Centralized vs.  Distributed Implementations

   Example scenarios are provided showing the location of the components
   of the bandwidth manager in centralized and fully distributed
   implementations.  Note that in either case, the RM must be present in
   all end stations that need to make reservations.  Essentially,
   centralized or distributed refers to the implementation of the BA,
   the component responsible for resource reservation and admission
   control.  In the figures below, "App" refers to the application
   making use of the BM. It could either be a user application, or a
   higher layer protocol process such as RSVP.

                                +---------+
                            .-->|  BA     |<--.
                           /    +---------+    \
                          / .-->| Layer 2 |<--. \
                         / /    +---------+    \ \
                        / /                     \ \
                       / /                       \ \
   +---------+        / /                         \ \       +---------+
   |  App    |<----- /-/---------------------------\-\----->|  App    |
   +---------+      / /                             \ \     +---------+
   |  RM     |<----. /                               \ .--->|  RM     |
   +---------+      / +---------+        +---------+  \     +---------+
   | Layer 2 |<------>| Layer 2 |<------>| Layer 2 |<------>| Layer 2 |
   +---------+        +---------+        +---------+        +---------+

   RSVP Host/         Intermediate       Intermediate       RSVP Host/
      Router          Bridge/Switch      Bridge/Switch         Router

     Figure 1: Bandwidth Manager with centralized Bandwidth Allocator

   Figure 1 shows a centralized implementation where a single BA is
   responsible for admission control decisions for the entire subnet.
   Every end station contains a RM. Intermediate bridges and switches in
   the network need not have any functions of the BM since they will not
   be actively participating in admission control.  The RM at the end
   station requesting a reservation initiates communication with its BA.
   For larger subnets, a single BA may not be able to handle the
   reservations for the entire subnet.  In that case it would be
   necessary to deploy multiple BAs, each managing the resources of a



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


   non-overlapping subset of segments.  In a centralized implementation,
   the BA must have some knowledge of the Layer 2 topology of the subnet
   e.g., link layer spanning tree information, in order to be able to
   reserve resources on appropriate segments.  Without this topology
   information, the BM would have to reserve resources on all segments
   for all flows which, in a switched network, would lead to very
   inefficient utilization of resources.

   +---------+                                              +---------+
   |  App    |<-------------------------------------------->|  App    |
   +---------+        +---------+        +---------+        +---------+
   |  RM/BA  |<------>|  BA     |<------>|  BA     |<------>|  RM/BA  |
   +---------+        +---------+        +---------+        +---------+
   | Layer 2 |<------>| Layer 2 |<------>| Layer 2 |<------>| Layer 2 |
   +---------+        +---------+        +---------+        +---------+

   RSVP Host/         Intermediate       Intermediate       RSVP Host/
      Router          Bridge/Switch      Bridge/Switch         Router

                  Figure 2: Bandwidth Manager with fully
                     distributed Bandwidth Allocator

   Figure 2 depicts the scenario of a fully distributed bandwidth
   manager.  In this case, all devices in the subnet have BM
   functionality.  All the end hosts are still required to have a RM. In
   addition, all stations actively participate in admission control.
   With this approach, each BA would need only local topology
   information since it is responsible for the resources on segments
   that are directly connected to it.  This local topology information,
   such as a list of ports active on the spanning tree and which unicast
   addresses are reachable from which ports, is readily available in
   today's switches.  Note that in the figures above, the arrows between
   peer layers are used to indicate logical connectivity.

7. Model of the Bandwidth Manager in a Network

   In this section we describe how the model above fits with the
   existing IETF Integrated Services model of IP hosts and routers.
   First, we describe Layer 3 host and router implementations.  Next, we
   describe how the model is applied in Layer 2 switches.  Throughout we
   indicate any differences between centralized and distributed
   implementations.  Occasional references are made to terminology from
   the Subnet Bandwidth Manager specification [14].








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


7.1. End Station Model

7.1.1. Layer 3 Client Model

   We assume the same client model as IntServ and RSVP where we use the
   term "client" to mean the entity handling QoS in the Layer 3 device
   at each end of a Layer 2 Domain.  In this model, the sending client
   is responsible for local admission control and packet scheduling onto
   its link in accordance with the negotiated service.  As with the
   IntServ model, this involves per flow scheduling with possible
   traffic shaping/policing in every such originating node.

   For now, we assume that the client runs an RSVP process which
   presents a session establishment interface to applications, provides
   signaling over the network, programs a scheduler and classifier in
   the driver, and interfaces to a policy control module.  In
   particular, RSVP also interfaces to a local admission control module
   which is the focus of this section.

   The following figure, reproduced from the RSVP specification, depicts
   the RSVP process in sending hosts.

                     +-----------------------------+
                     | +-------+  +-------+        |   RSVP
                     | |Appli- |  | RSVP  <------------------->
                     | | cation<-->       |        |
                     | |       |  |process| +-----+|
                     | +-+-----+  |       +->Polcy||
                     |   |        +--+--+-+ |Cntrl||
                     |   |data       |  |   +-----+|
                     |===|===========|==|==========|
                     |   |  +--------+  |   +-----+|
                     |   |  |        |  +--->Admis||
                     | +-V--V-+  +---V----+ |Cntrl||
                     | |Class-|  | Packet | +-----+|
                     | | ifier|==>Schedulr|===================>
                     | +------+  +--------+        |    data
                     +-----------------------------+

                    Figure 3: RSVP in Sending Hosts

7.1.2. Requests to Layer 2 ISSLL

   The local admission control entity within a client is responsible for
   mapping Layer 3 session establishment requests into Layer 2
   semantics.





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


   The upper layer entity makes a request, in generalized terms to ISSLL
   of the form:

      "May I reserve for traffic with <traffic characteristic> with
      <performance requirements> from <here> to <there> and how should I
      label it?"

   where

   <traffic characteristic> = Sender Tspec (e.g. bandwidth, burstiness,
   MTU)
   <performance requirements> = FlowSpec (e.g. latency, jitter bounds)
   <here> = IP address(es)
   <there> = IP address(es) - may be multicast

7.1.3. At the Layer 3 Sender

   The ISSLL functionality in the sender is illustrated in Figure 4.

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

   -  Maps the endpoints of the conversation to Layer 2 addresses in the
      LAN, so that the client can determine what traffic is going where.
      This function probably makes reference to the ARP protocol cache
      for unicast or performs an algorithmic mapping for multicast
      destinations.

   -  Communicates with any local Bandwidth Allocator module for local
      admission control decisions.

   -  Formats a SBM request to the network with the mapped addresses and
      flow/filter specs.

   -  Receives a response from the network and reports the admission
      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 |        |