[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 2816

Internet Engineering Task Force                              A. Ghanwani
INTERNET DRAFT                                                J. W. Pace
                                                           V. Srinivasan
                                                           February 1997

             A Framework for Providing Integrated Services
               Over Shared and Switched LAN Technologies


Status of This Memo

   This document is an Internet-Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months, and may be updated, replaced, or obsoleted by other documents
   at any time.  It is not appropriate to use Internet Drafts as
   reference material, or to cite them other than as a ``working draft''
   or ``work in progress.''

   To learn the current status of any Internet-Draft, please check
   the ``1id-abstracts.txt'' listing contained in the internet-drafts
   Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific


   Traditionally, LAN technologies such as ethernet and token ring have
   been required to handle best effort services only.  No standard
   mechanism exists for providing bandwidth or delay guarantees on these
   media.  It is therefore not possible to provide guaranteed quality
   of service as will be required by emerging and future multimedia
   applications.  The anticipated demand for real-time applications
   on the Internet has led to the development of RSVP, a signaling
   mechanism for performing resource reservation in the Internet.
   Concurrently, the Integrated Services working group within the
   IETF has been working on the definition of service classes called
   "Integrated Services" which are expected to make use of RSVP.
   Applications will use these service classes in order to obtain the
   desired quality of service from the network.  LAN technologies

Ghanwani, Pace, Srinivasan         Expires August 1997          [Page i]

Internet Draft        Integrated Services Over LANs        February 1997

   such as token ring and ethernet typically constitute the last hop
   in Internet connections.  There is therefore a need to enhance
   these technologies so that they are able to support the Integrated
   Services.  In order to enable such services, it is necessary to
   provide a resource management functions.  This memo describes a
   framework for providing the necessary functionality on shared and
   switched LAN technologies.

Ghanwani, Pace, Srinivasan         Expires August 1997         [Page ii]

Internet Draft        Integrated Services Over LANs        February 1997

1. Introduction

   The Internet has traditionally provided support for best effort
   traffic only.  However, with the recent advances in link layer
   technology, and with numerous emerging real-time applications such
   as video conferencing, Internet telephony, etc, there has been much
   interest for supporting real-time services over the Internet.  These
   new requirements have led to the development of RSVP [3], a signaling
   mechanism for providing resource reservation on the Internet.  The
   protocol is currently being standardized by the IETF. Simultaneously,
   the Integrated Services working group of the IETF has been working on
   the specification of various service classes.  Each of these service
   classes is designed to provide certain Quality of Service (QoS)
   guarantees to traffic conforming to a specified set of parameters.
   Applications are expected to use one of these classes depending on
   their QoS requirements.

   Legacy LAN technologies such as ethernet and token ring currently
   lack the necessary functionality to support real-time traffic.  They,
   however, typically constitute the last mile between users and the
   Internet backbone of campus networks.  Furthermore, the development
   of standards for high speed LANs such as gigabit ethernet favors the
   likelihood that these technologies will eventually be deployed in the
   backbone.  It is therefore necessary to enhance these technologies so
   that they are able to support end-to-end service guarantees such as
   those defined by the Integrated Services.

   In order to support real-time services, there must be some mechanism
   for resource management at the link level.  The ISSLL (Integrated
   Services over Specific Link Layers) working group was chartered with
   the purpose of exploring such mechanisms for various link layer
   technologies.  Resource management in this context encompasses the
   functions of admission control, scheduling, traffic policing, path
   selection, etc.

   This document is concerned with specifying a framework for providing
   Integrated Services over LAN technologies such as ethernet and
   token ring.  We begin by defining the scope of the solution to be
   developed.  A taxonomy of Layer 2 topologies is discussed with an
   emphasis on the capabilities of each which can be leveraged for
   enabling integrated services over these topologies.  Next, the
   requirements and goals for a resource management mechanism capable of
   providing Integrated Services in a subnet are listed and discussed.
   These functions will be provided by an entity which is referred to
   as the Bandwidth Manager.  We then discuss the various components
   of the Bandwidth Manager.  No assumptions have been made about the
   technology or topology at the link layer.  The framework is intended
   to be as exhaustive as possible; this means that it is possible that

Ghanwani, Pace, Srinivasan         Expires August 1997          [Page 1]

Internet Draft        Integrated Services Over LANs        February 1997

   all the functions discussed may not be supportable by a particular
   topology/technology, but this should not preclude the usage of this
   model for the technology.

2. Supporting Integrated Services Within a Subnet:  Requirements and

   This section discusses the requirements and goals which should drive
   the design of an architecture for supporting Integrated Services
   over legacy 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 RSVP.

2.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 for a session based
       on the existing reservations in order to decide whether or not
       the session can be admitted.  It should also be possible for a
       host to query about the availability of resources.  It must be
       able to provide different types of QoS such as guaranteed delay,
       guaranteed bandwidth, etc.

    -  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.  Scheduling algorithms can range
       from simple static priority queueing to more complex algorithms
       such as weighted fair queueing.

    -  Policing:  Traffic policing must be performed in order to ensure
       that sources adhere to their negotiated traffic specifications.
       Policing must be implemented at the sources and must ensure
       that violating traffic is either dropped or transmitted as best

Ghanwani, Pace, Srinivasan         Expires August 1997          [Page 2]

Internet Draft        Integrated Services Over LANs        February 1997

    -  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.  Back-up and failure recovery mechanisms
       must be provided.

    -  Synchronization:  There should be some mechanism for resolving
       synchronization and deadlock issues.  For instance, the case
       where multiple sessions simultaneously request resources on a
       common part of the network must be correctly handled.

    -  Soft state reservations:  The mechanism must maintain soft-state
       information about the reservations.  This means that reservations
       must be periodically refreshed if the reservation is to be
       maintained; otherwise the reservation 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 avoids synchronization and
       deadlock problems but will not scale to subnets with a large
       number of hosts.  In a fully distributed implementation, each
       segment will have a separate entity managing its resources.  This
       approach is scalable, but requires synchronization.  Ideally,
       implementation should be flexible; i.e.  a centralized approach
       may be used for small subnets and distributed approach, where
       one or more segments is managed by a single entity, can be used
       for larger subnets.  Examples of centralized and distributed
       implementations are discussed in Section 4.

    -  Network Management:  The MIBs supported must be specified.

    -  Interaction with Existing Resource Management Controls:  The
       interaction with existing infrastructure would need to be
       specified.  For instance, FDDI has resource management with
       its "Synchronous Bandwidth Manager".  The BM for FDDI must be
       designed so that it takes advantage of this.

2.2. Goals

    -  Independence from higher layer protocols:  The mechanism should
       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 STII. Independence from IP is
       desirable so that it can interwork with protocols such as IPX,
       NetBIOS, etc.

Ghanwani, Pace, Srinivasan         Expires August 1997          [Page 3]

Internet Draft        Integrated Services Over LANs        February 1997

    -  Receiver heterogeneity:  The mechanism should support
       heterogeneous receiver groups; i.e.  the level of reservation may
       be different for different receivers of a multicast group.

    -  Support for different filter styles:  It is desirable to provide
       support for the different filter as defined by RSVP such as fixed
       filter, shared explicit and shared wildcard.

    -  Scalability:  The mechanism and protocols should have a low
       overhead and should scale to large receiver groups.

    -  Path Selection:  In a bridged or switched LAN, it may be
       worthwhile to do path selection, where possible, for a given
       source-destination in order to utilize resources in an efficient
       manner.  Along with other mechanisms, such as source routing in
       token ring networks and bridge filtering, path selection can
       ensure optimum utilization of network resources.  Frames will
       appear only on those segments on which there are designated
       receivers, or when the segment is on the path between the sender
       and receiver.

3. Legacy LAN Topologies and Their Features

   We are concerned with specifying a framework for Integrated
   Services over legacy LAN technologies.  These technologies include
   ethernet/IEEE 802.3, token ring/IEEE 802.5 and FDDI. The extent to
   which real-time services can be supported on a network depend to a
   large degree on the available functions for providing priority media
   access as well as the ability to identify packets of real-time flows
   so that they can be given preferential treatment.  This section
   discusses some of the capabilities of these LAN technologies and
   provides a taxonomy of topologies.

   The basic topology of a legacy LAN network may be shared, switched
   half duplex or switched full duplex.  In the shared topology,
   multiple stations may be connected to a single segment.  Contention
   for media access is resolved using protocols such as CSMA/CD in
   ethernet and token passing in token ring and FDDI. Switched half
   duplex, is essentially a shared topology with the restriction that
   only a single station is attached per bridge/switch port, i.e.  there
   are only two stations contending for resources on any segment.
   This topology is fast becoming popular with the need for increased
   bandwidth.  Finally, in a switched full duplex topology, there is a
   single station per switch port and the media allows for full duplex
   operation.  Therefore, in this topology, there is no access control
   such as CSMA/CD or token passing.

Ghanwani, Pace, Srinivasan         Expires August 1997          [Page 4]

Internet Draft        Integrated Services Over LANs        February 1997

   Another important element in the discussion of topologies is the
   ability to support priority handling of traffic.  Priority provides
   a coarse method for isolation between flows and allows opens the
   possibility to easily support scheduling algorithms which give
   preferential treatment to high priority flows.  These functions are
   key requirements as pointed out in Section 2.  Native ethernet/802.3
   does not include support for priority.  Token ring/802.5 and FDDI on
   the other hand support up to eight levels of priority.  Three bits
   of the frame control field are used for carrying the frame priority.
   Equally important in token ring networks are the notions of reserved
   priority and access priority.  Reserved priority relates to the value
   of priority which a station uses to reserve the token for the next
   transmission on the ring.  When a free token is circulating, only
   those stations having an access priority greater than or equal to the
   reserved priority in the token will be allowed to seize the token
   for transmission.  More recently, the IEEE 802.1 Standards Committee
   has been working on the standards for expedited traffic classes in
   bridges/switches [1].  The proposed standard requires a new frame
   format for ethernet which carry three bits to indicate the frame
   priority.  This allows for the support of eight traffic classes.
   The standard does not specify scheduling algorithms between traffic
   classes, and indeed, a bridge/switch need not implement separate
   queues for each traffic class.

   Depending on the basic topology used and the ability to support
   priority, there are six possible scenarios as follows:

    1. Shared topology without priority:  This category includes pure
       shared media such as ethernet and legacy 802.3 networks which
       are multi-access technologies with no support for priority media
       access.  A special case of this topology is one where only a
       single device is attached to the port in the network.  Shared
       topology without priority offers no capability for isolation
       between reserved/unreserved flows.  No service guarantees can be
       provided for this scenario.

    2. Shared topology with priority:  This category includes
       ethernet/802.3 networks which implement the emerging IEEE 802.1p
       standard, token ring/802.5 networks and FDDI networks.  However,
       shared ethernet with frame priority may offer limited support
       for priority access because of the CSMA/CD protocol; at best
       loose statistical service guarantees may be possible.  On the
       other hand, deterministic guarantees can be provided for token
       ring media if the frame priority, reserved priority and access
       priority are used in conjunction with appropriate hardware.

    3. Switched half duplex topology without priority:  This scenario
       is a special case of shared topology without priority where

Ghanwani, Pace, Srinivasan         Expires August 1997          [Page 5]

Internet Draft        Integrated Services Over LANs        February 1997

       there are only two device per segment (an end station and a
       bridge/switch or two bridges/switches).  This allows for higher
       bandwidth per station.  Due to the absence of priority and
       the CSMA/CD protocol, little can be done to isolate flows for

    4. Switched half duplex topology with priority:  This scenario is
       a special case of shared topology with priority but there are
       now only two devices per segment.  This reduces the contention
       for resources.  Ethernet/802.3 with this topology will likely
       be able to support some statistical service guarantees.  More
       deterministic guarantees will be possible for token ring/802.5

    5. Switched full duplex topology without priority:  This scenario
       includes switched ethernet where the CSMA/CD protocol is no
       longer used and full duplex operation is possible.  Because
       priority is not available, again, it is not possible to provide
       flow isolation between best effort and reserved flows.

    6. Switched full duplex topology with priority:  This category is
       similar to the above, but frame priority is also available This
       topology provides best capabilities for priority access and, at
       the very least, enables a coarse level of flow separation based
       on frame priority and static priority scheduling.

   There is also the possibility of hybrid topologies where two or more
   of the above coexist.  For instance, it is possible that within a
   single subnet, there are some bridges/switches which support priority
   and some which do not.  If the flow in question traverses both kinds
   of bridges/switches in the network, the least common denominator
   will prevail.  In other words, for that flow, the network will be
   considered to be of the less capable of the topologies.

4. Architecture for Integrated Services in Legacy LANs

   The functional requirements described in Section 2 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 (1) to
   request QoS from the network.  The major components of the BM are
   discussed below.

1. We use "application" to indicate any higher layer protocol or

Ghanwani, Pace, Srinivasan         Expires August 1997          [Page 6]

Internet Draft        Integrated Services Over LANs        February 1997

4.1. Requester Module

   The requester module (RM) provides an interface between higher layer
   protocols (such as RSVP, STII, etc.)  and the bandwidth manager.  It
   provides a set of primitives which define the mechanism by which the
   various services of the BM are invoked.  For instance, the higher
   layer protocol will initiate the resource reservation at layer 2 by
   providing the RM with the traffic descriptors and desired quality
   of service.  The RM then communicates with the other components of
   the BM to perform admission control.  The function of the RM must be
   provided in every device (e.g.  host, router) which might need to
   initiate the resource reservation at the link layer.

4.2. Bandwidth Allocator

   The bandwidth allocator (BA) is responsible for performing admission
   control and tracking the allocation of resources in the subnet.  A
   host can request various services, e.g.  bandwidth reservation,
   changes in reservation, queries about resource availability, etc.
   The communication between the host and the BA will take 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 provided in all the
   hosts and bridges/switches as necessary.

4.3. Communication Protocols and Primitives

   The protocols and primitives for communication between the various
   components of the BM 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, and
       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 protocol 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 application.  Additionally, the protocol must specify a
       method by which a RM can send a query message which will trigger
       a response from its BA.

Ghanwani, Pace, Srinivasan         Expires August 1997          [Page 7]

Internet Draft        Integrated Services Over LANs        February 1997

    -  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
       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 required to handle failures.  When a BA fails,
       another BA should assume its responsibility.

4.4. Implementation Scenarios

   Example scenarios are provided below showing the location of the
   the components of the bandwidth manager in centralized and fully
   distributed implementations.  Note that in either case, the RM
   must be present on all end-stations/hosts which desire 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 a centralized Bandwidth Allocator

   Figure 1 shows a centralized implementation.  Each host would contain
   an 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 station requesting a reservation
   initiates communication with its BA. With this approach, the end

Ghanwani, Pace, Srinivasan         Expires August 1997          [Page 8]

Internet Draft        Integrated Services Over LANs        February 1997

   host must be able to identify 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 non-overlapping subset of segments.  In a
   centralized implementation, the BA must maintain topology information
   in order to be able to reserve resources on appropriate segments.

  +---------+                                              +---------+
  |  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 a fully distributed Bandwidth

   Figure 2 depicts the scenario of a fully distributed bandwidth
   manager.  In this case, all devices in the subnet must have some BM
   functionality.  All the end hosts are still required to have an RM.
   In addition, all bridges and switches must participate in admission
   control, but there is the possibility of relying on the link layer
   for the maintenance of topology information.

   Note that in the figures above, the arrows between peer layers are
   used to indicate logical connectivity.

4.5. Logical Operation of the BM in Hosts/Routers and Layer 2 Domain

   The figure below shows the location and logical operation of the
   BM in hosts/routers and the Layer 2 domain.  It is not possible to
   provide an explicit example because of the inherent differences that
   arise in centralized and distributed implementations discussed in
   Section 4.4.

Ghanwani, Pace, Srinivasan         Expires August 1997          [Page 9]

Internet Draft        Integrated Services Over LANs        February 1997

    |  +--------+   +------+  |
    |  |Appli-  <--->  RM  |  |
    |  | cation |   +--^---+  |
    |  +--------+      |      |     +-------------------------+
    |    ||         +--V---+  |     |               +------+  |
    |    ||  +------|  BA  <------------------------>  BA  |  |
    |    ||  |      +------+  |     |  +----------+ +-^-^|-+  |
    |    ||  |         |      |     |  |Forwarding|   | ||    |
    |    ||  |         |      |     |  |Process   <---+ ||    |
    |    ||  |         |      |     |  +---|------+     ||    |
    |    ||  |         |      |     |      |  +---------+|    |
    |    \/  |         |      |     |      |  |          |    |
    |  +-----V-+    +--V---+  |     |  +---V--V+    +----V-+  |
    |  |Class- |    |Sched-|  |     |  |Class- |    |Sched-|  |
    |  | ifier |===>| uler |==========>| ifier |===>| uler |====>
    |  +-------+    +------+  |     |  +-------+    +------+  |
    +-------------------------+     +-------------------------+

         Host/Router                      Layer 2 Domain

    ---->  Signaling/control
    ====>  Data

   Figure 3:  The logical Operation of the BM in the hosts/routers and
   the Layer 2 network.

   The application, which may be RSVP or some other higher layer
   reservation protocol requests resources by passing information to
   the RM which includes the following:  (i) MAC addresses of the
   source and destination, (ii) traffic descriptors for the flow, and
   (iii) quality of service desired.  The RM then starts the process
   of resource reservation at Layer 2 by contacting the local BA. The
   local BA is responsible for admission control on the segment to which
   the host/router is directly attached.  If the reservation succeeds,
   the local BA sets up the classifier and scheduler as required so
   that the appropriate priority is used for the flow.  The request
   is then propagated to the the "remote" BA controlling the other
   segments along the forwarding path.  In a centralized implementation,
   the BA resides in a server within the subnet.  The classifier and
   scheduler in the bridges/switches along the forwarding path are
   implicitly set up by the priority carried in the data frames if the
   reservation is successful.  On the other hand, in a fully distributed
   implementation, the remote BA resides in every bridge/switch
   and the process of resource reservation would be performed on a
   hop-by-hop basis.  In this scenario, it would also be possible to use
   sophisticated scheduling since the classifier can be explicitly set
   up for each flow.

Ghanwani, Pace, Srinivasan         Expires August 1997         [Page 10]

Internet Draft        Integrated Services Over LANs        February 1997

5. Mapping Issues and Link Layer Support for IntServ Traffic Classes

   As stated earlier, the Integrated Services working group has defined
   many service classes offering varying degrees of QoS guarantees.
   Initial effort will concentrate on enabling the controlled load
   and guaranteed service classes [4,5].  The controlled load service
   provides a loose guarantee, informally stated as "better than
   best effort".  The guaranteed service provides a delay bound which
   the network guarantees will never be exceeded.  The extent to
   which these services can be supported at the link layer will be
   technology dependent and will depend on many factors.  Some of the
   mapping issues in light of the emerging link layer standards are
   discussed below.  Further, considering the limitations of some of the
   topologies under consideration, it may not be possible to satisfy
   all the requirements for Integrated Services.  In such cases, it is
   to consider providing support for an approximation of the service
   which may suffice in most practical instances.  For example, it
   may not be feasible to provide policing/shaping at each network
   element (bridge/switch) as is specified in the controlled load
   specification [4].  But if this task is left to the routers/hosts, a
   good approximation to the service can be obtained.

5.1. Mapping of Services to Link Level Priority

   The number of delay priorities and access methods of the technology
   under consideration will determine how many and what services may be
   supported.  Native token ring, for instance, supports eight priority
   levels while ethernet has no support for priorities.  However, the
   IEEE 802 standards committee is working on two new standards for
   bridges related to multimedia traffic expediting, multicast filtering
   and virtual LANs [1,2].  These standards allow for eight levels of
   frame priority.  The frame priority is signaled on an end-to-end
   basis, unless overridden by bridge/switch management.  Work is in
   progress to address how each of these priorities will map to the
   traffic classes supported by a bridge/switch; even though eight
   levels of priority are allowed, a bridge/switch need not support
   eight distinct service classes.

   The priority that is used by a flow should depend on the quality
   of service desired and whether the reservation was successful or
   not.  A flow, therefore should use the priority which best effort
   traffic would use until told otherwise by the signaling mechanism.
   The signaling mechanism will, upon successful completion of resource
   reservation, specify the frame priority which the source must use.
   More details on exact mapping of priorities to services is beyond
   the scope of this document and will be a a part of another document
   dedicated to addressing mapping issues.

Ghanwani, Pace, Srinivasan         Expires August 1997         [Page 11]

Internet Draft        Integrated Services Over LANs        February 1997

5.2. Supporting Receiver Heterogeneity

   Receiver heterogeneity means that receivers within a group can each
   have different QoS requirements; i.e.  it is possible that, for a
   given flow, some receivers make a reservation while others decide
   to make use of best effort transport.  RSVP allows heterogeneous
   receivers within a group.  However, handling the problem at layer
   2 can be non-trivial.  Consider for instance, the scenario in the
   figure below.

                   | R1  |
      +-----+      +-----+      +-----+
      | R2  |<-----| SW  |----->| R3  |
      +-----+      +-----+      +-----+

   Figure 4:  An instance of receiver heterogeneity.  R1 is the source.
   R2 is a receiver which makes a reservation, and R3 is a receiver
   which is satisfied with best effort service.  SW is a Layer 2 device
   (bridge/switch) participating in resource reservation.

   In the figure above, R1 is the upstream router/source and R2 and R3
   are downstream routers/destinations.  R2 sends a RESV message to
   reserve resources for the flow.  R3 would like to simply receive
   the flow using best effort transport.  R1 sends PATH messages which
   are multicast to both R2 and R3.  R2 sends a RESV message to R1
   requesting the reservation of resources.  If the reservation is
   successful at Layer 2, the frames addressed to the group will have a
   high priority corresponding to the service requested by R3.  At SW,
   there must be some mechanism which forwards the packet using high
   priority at the interface to R3 while using the priority for best
   effort traffic at the interface to R2.  This may involve changing the
   contents of the frame itself, or ignoring the frame priority at the
   interface to R2.  Another possibility for supporting heterogeneous
   receivers would be to have separate groups, one for each class of

Ghanwani, Pace, Srinivasan         Expires August 1997         [Page 12]

Internet Draft        Integrated Services Over LANs        February 1997

5.3. Support for Different Reservation Styles

              +-----+       +-----+       +-----+
              | R1  |       | R2  |       | R3  |
              +-----+       +-----+       +-----+
                 |             |             |
                 |             v             |
                 |          +-----+          |
                 +--------->| SW  |<---------+
                            | R4  |

   Figure 5:  An illustration of filter styles.  R1, R2, R3 and R4 are
   RSVP hosts/routers which are members of the same group.  SW is a
   bridge/switch at Layer 2.

   In the figure above, R1, R2 and R3 are upstream routers/sources.  R4
   is the downstream router/destination which is the receiver for all of
   these flows.  RSVP allows receiver R4 to specify reservations which
   can apply to:  (a) one specific sender only (fixed filter); (b) any
   of two or more explicitly specified senders (shared explicit filter);
   (c) any sender in the group (shared wildcard filter).  Support for
   the fixed filter is relatively straightforward.  However, support for
   the the other two styles has implications regarding policing; i.e.
   the merged flows from the different sources should be policed so that
   they conform to traffic parameters specified in the filter's Rspec.

6. Summary

   This document has specified a framework for providing Integrated
   Services over shared and switched LAN technologies.  The ability to
   provide QoS guarantees necessitates some form of admission control
   and resource management.  The requirements and goals of a resource
   management scheme for subnets have been identified and discussed.
   We refer to the entire resource management scheme as a Bandwidth
   Manager.  Architectural considerations were discussed and examples
   were provided to illustrate possible implementations of a Bandwidth
   Manager.  Some of the issues involved in mapping the services from
   higher layers to Layer 2 were discussed.


Ghanwani, Pace, Srinivasan         Expires August 1997         [Page 13]

Internet Draft        Integrated Services Over LANs        February 1997

[1] IEEE Standards for Local and Metropolitan Area Networks:
    Draft Standard for Traffic Class and Dynamic Multicast Filtering
    Services in Bridged Local Area Networks (Draft Supplement to
    802.1D), P802.1p/D4, September, 1996.

[2] IEEE Standards for Local and Metropolitan Area Networks:
    Draft Standard for Virtual Bridged Local Area Networks,
    P802.1Q/D4, January, 1997.

[3] B. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin,
    "Resource Reservation Protocol (RSVP) - Version 1 Functional
    Specification," Internet Draft, November 1996,

[4] J. Wroclawski, "Specification of the Controlled-Load Network
    Element Service," Internet Draft, November 1996,

[5] S. Shenker, C. Partridge and R. Guerin, "Specification of
    Guaranteed Quality of Service," Internet Draft, August 1996,

[6] R. Braden, D. Clark and S. Shenker, "Integrated Services in the
    Internet Architecture: An Overview,"  RFC 1633, June 1994.


   Much of the work presented in this document has benefited greatly
   from discussion held at the meetings of the Integrated Services over
   Specific Link Layers (ISSLL) working group.  In particular we would
   like to thank Eric Crawley, Don Hoffman, Mick Seaman, Andrew Smith
   and Raj Yavatkar who have contributed to this effort via earlier
   Internet drafts.

Authors' Address

          Anoop Ghanwani
          IBM Corporation
          P. O. Box 12195
          Research Triangle Park, NC 27709
          Phone:   +1-919-254-0260
          Fax:     +1-919-254-5410
          Email:   anoop@raleigh.ibm.com

          Wayne Pace

Ghanwani, Pace, Srinivasan         Expires August 1997         [Page 14]

Internet Draft        Integrated Services Over LANs        February 1997

          IBM Corporation
          P. O. Box 12195
          Research Triangle Park, NC 27709
          Phone:   +1-919-254-4930
          Fax:     +1-919-254-5410
          Email:   pacew@raleigh.ibm.com

          Vijay Srinivasan
          IBM Corporation
          P. O. Box 12195
          Research Triangle Park, NC 27709
          Phone:   +1-919-254-2730
          Fax:     +1-919-254-5410
          Email:   vijay@raleigh.ibm.com

Ghanwani, Pace, Srinivasan         Expires August 1997         [Page 15]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/