rfc2816.txt

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

   for a time period longer than PACKET_PROMOTION (200 - 300 ms) [19],
   its priority is automatically promoted to high priority.  Thus, even
   normal priority packets have a maximum guaranteed access time to the
   medium.

   Integrated Services can be built on top of the IEEE 802.12 medium
   access mechanism.  When combined with admission control and bandwidth
   enforcement mechanisms, delay guarantees as required for a Guaranteed
   Service can be provided without any changes to the existing IEEE
   802.12 MAC protocol.

   Since the IEEE 802.12 standard supports the IEEE 802.3 and IEEE 802.5
   frame formats, the same framing overhead as reported in Sections 4.2
   and 4.3 must be considered in the admission control computations for
   IEEE 802.12 links.

5. Requirements and Goals

   This section discusses the requirements and goals which should drive
   the design of an architecture for supporting Integrated Services over
   LAN technologies.  The requirements refer to functions and features
   which must be supported, while goals refer to functions and features
   which are desirable, but are not an absolute necessity.  Many of the
   requirements and goals are driven by the functionality supported by
   Integrated Services and RSVP.

5.1. Requirements

   -  Resource Reservation:  The mechanism must be capable of reserving
      resources on a single segment or multiple segments and at
      bridges/switches connecting them.  It must be able to provide
      reservations for both unicast and multicast sessions.  It should
      be possible to change the level of reservation while the session
      is in progress.

   -  Admission Control:  The mechanism must be able to estimate the
      level of resources necessary to meet the QoS requested by the
      session in order to decide whether or not the session can be
      admitted.  For the purpose of management, it is useful to provide
      the ability to respond to queries about availability of resources.
      It must be able to make admission control decisions for different
      types of services such as Guaranteed Service, Controlled Load,
      etc.








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


   -  Flow Separation and Scheduling:  It is necessary to provide a
      mechanism for traffic flow separation so that real time flows can
      be given preferential treatment over best effort flows.  Packets
      of real time flows can then be isolated and scheduled according to
      their service requirements.

   -  Policing/Shaping:  Traffic must be shaped and/or policed by end
      stations (workstations, routers) to ensure conformance to
      negotiated traffic parameters.  Shaping is the recommended
      behavior for traffic sources.  A router initiating an ISSLL
      session must have implemented traffic control mechanisms according
      to the IntServ requirements which would ensure that all flows sent
      by the router are in conformance.  The ISSLL mechanisms at the
      link layer rely heavily on the correct implementation of
      policing/shaping mechanisms at higher layers by devices capable of
      doing so.  This is necessary because bridges and switches are not
      typically capable of maintaining per flow state which would be
      required to check flows for conformance.  Policing is left as an
      option for bridges and switches, which if implemented, may be used
      to enforce tighter control over traffic flows.  This issue is
      further discussed in Section 8.

   -  Soft State:  The mechanism must maintain soft state information
      about the reservations.  This means that state information must
      periodically be refreshed if the reservation is to be maintained;
      otherwise the state information and corresponding reservations
      will expire after some pre-specified interval.

   -  Centralized or Distributed Implementation:  In the case of a
      centralized implementation, a single entity manages the resources
      of the entire subnet.  This approach has the advantage of being
      easier to deploy since bridges and switches may not need to be
      upgraded with additional functionality.  However, this approach
      scales poorly with geographical size of the subnet and the number
      of end stations attached.  In a fully distributed implementation,
      each segment will have a local entity managing its resources.
      This approach has better scalability than the former.  However, it
      requires that all bridges and switches in the network support new
      mechanisms.  It is also possible to have a semi-distributed
      implementation where there is more than one entity, each managing
      the resources of a subset of segments and bridges/switches within
      the subnet.  Ideally, implementation should be flexible; i.e.  a
      centralized approach may be used for small subnets and a
      distributed approach can be used for larger subnets.  Examples of
      centralized and distributed implementations are discussed in
      Section 6.





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


   -  Scalability:  The mechanism and protocols should have a low
      overhead and should scale to the largest receiver groups likely to
      occur within a single link layer domain.

   -  Fault Tolerance and Recovery:  The mechanism must be able to
      function in the presence of failures; i.e.  there should not be a
      single point of failure.  For instance, in a centralized
      implementation, some mechanism must be specified for back-up and
      recovery in the event of failure.

   -  Interaction with Existing Resource Management Controls:  The
      interaction with existing infrastructure for resource management
      needs to be specified.  For example, FDDI has a resource
      management mechanism called the "Synchronous Bandwidth Manager".
      The mechanism must be designed so that it takes advantage of, and
      specifies the interaction with, existing controls where available.

5.2. Goals

   -  Independence from higher layer protocols:  The mechanism should,
      as far as possible, be independent of higher layer protocols such
      as RSVP and IP. Independence from RSVP is desirable so that it can
      interwork with other reservation protocols such as ST2 [10].
      Independence from IP is desirable so that it can interwork with
      other network layer protocols such as IPX, NetBIOS, etc.

   -  Receiver heterogeneity:  this refers to multicast communication
      where different receivers request different levels of service.
      For example, in a multicast group with many receivers, it is
      possible that one of the receivers desires a lower delay bound
      than the others.  A better delay bound may be provided by
      increasing the amount of resources reserved along the path to that
      receiver while leaving the reservations for the other receivers
      unchanged.  In its most complex form, receiver heterogeneity
      implies the ability to simultaneously provide various levels of
      service as requested by different receivers.  In its simplest
      form, receiver heterogeneity will allow a scenario where some of
      the receivers use best effort service and those requiring service
      guarantees make a reservation.  Receiver heterogeneity, especially
      for the reserved/best effort scenario, is a very desirable
      function.  More details on supporting receiver heterogeneity are
      provided in Section 8.

   -  Support for different filter styles:  It is desirable to provide
      support for the different filter styles defined by RSVP such as
      fixed filter, shared explicit and wildcard.  Some of the issues
      with respect to supporting such filter styles in the link layer
      domain are examined in Section 8.



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


   -  Path Selection:  In source routed LAN technologies such as Token
      Ring/IEEE 802.5, it may be useful for the mechanism to incorporate
      the function of path selection.  Using an appropriate path
      selection mechanism may optimize utilization of network resources.

5.3. Non-goals

   This document describes service mappings onto existing IEEE and ANSI
   defined standard MAC layers and uses standard MAC layer services as
   in IEEE 802.1 bridging.  It does not attempt to make use of or
   describe the capabilities of other proprietary or standard MAC layer
   protocols although it should be noted that published work regarding
   MAC layers suitable for QoS mappings exists.  These are outside the
   scope of the ISSLL working group charter.

5.4. Assumptions

   This framework assumes that typical subnetworks that are concerned
   about QoS will be "switch rich"; i.e. most communication between end
   stations using integrated services support is expected to pass
   through at least one switch.  The mechanisms and protocols described
   will be trivially extensible to communicating systems on the same
   shared medium, but it is important not to allow problem
   generalization which may complicate the targeted practical
   application to switch rich LAN topologies.  There have also been
   developments in the area of MAC enhancements to ensure delay
   deterministic access on network links e.g.  IEEE 802.12 [19] and also
   proprietary schemes.

   Although we illustrate most examples for this model using RSVP as the
   upper layer QoS signaling protocol, there are actually no real
   dependencies on this protocol.  RSVP could be replaced by some other
   dynamic protocol, or the requests could be made by network management
   or other policy entities.  The SBM signaling protocol [14], which is
   based upon RSVP, is designed to work seamlessly in the architecture
   described in this memo.

   There may be a heterogeneous mix of switches with different
   capabilities, all compliant with IEEE 802.1D [2,3], but implementing
   varied queuing and forwarding mechanisms ranging from simple systems
   with two queues per port and static priority scheduling, to more
   complex systems with multiple queues using WFQ or other algorithms.

   The problem is decomposed into smaller independent parts which may
   lead to sub-optimal use of the network resources but we contend that
   such benefits are often equivalent to very small improvement in
   network efficiency in a LAN environment.  Therefore, it is a goal
   that the switches in a network operate using a much simpler set of



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


   information than the RSVP engine in a router.  In particular, it is
   assumed that such switches do not need to implement per flow queuing
   and policing (although they are not precluded from doing so).

   A fundamental assumption of the IntServ model is that flows are
   isolated from each other throughout their transit across a network.
   Intermediate queuing nodes are expected to shape or police the
   traffic to ensure conformance to the negotiated traffic flow
   specification.  In the architecture proposed here for mapping to
   Layer 2, we diverge from that assumption in the interest of
   simplicity.  The policing/shaping functions are assumed to be
   implemented in end stations.  In some LAN environments, it is
   reasonable to assume that end stations are trusted to adhere to their
   negotiated contracts at the inputs to the network, and that we can
   afford to over-allocate resources during admission control to
   compensate for the inevitable packet jitter/bunching introduced by
   the switched network itself.  This divergence has some implications
   on the types of receiver heterogeneity that can be supported and the
   statistical multiplexing gains that may be exploited, especially for
   Controlled Load flows.  This is discussed in Section 8.7 of this
   document.

6. Basic Architecture

   The functional requirements described in Section 5 will be performed
   by an entity which we refer to as the Bandwidth Manager (BM). The BM
   is responsible for providing mechanisms for an application or higher
   layer protocol to request QoS from the network.  For architectural
   purposes, the BM consists of the following components.

6.1. Components

6.1.1. Requester Module

   The Requester Module (RM) resides in every end station in the subnet.
   One of its functions is to provide an interface between applications
   or higher layer protocols such as RSVP, ST2, SNMP, etc.  and the BM.
   An application can invoke the various functions of the BM by using
   the primitives for communication with the RM and providing it with
   the appropriate parameters.  To initiate a reservation, in the link
   layer domain, the following parameters must be passed to the RM: the
   service desired (Guaranteed Service or Controlled Load), the traffic
   descriptors contained in the TSpec, and an RSpec specifying the
   amount of resources to be reserved [9].  More information on these
   parameters may be found in the relevant Integrated Services documents
   [6,7,8,9].  When RSVP is used for signaling at the network layer,
   this information is available and needs to be extracted from the RSVP
   PATH and RSVP RESV messages (See [5] for details).  In addition to



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


   these parameters, the network layer addresses of the end points must
   be specified.  The RM must then translate the network layer addresses
   to link layer addresses and convert the request into an appropriate