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

Versions: 00 01 02 03 04 05 06 RFC 2816

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


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

                draft-ietf-issll-is802-framework-02.txt


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
   Rim).


Abstract

   Traditionally, LAN technologies such as Ethernet and token ring have
   been required to handle best effort services only.  No standard
   mechanism exists for providing service guarantees on these media as
   will be required by emerging and future multimedia applications.  The
   anticipated demand for such 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 such as token ring and Ethernet typically
   constitute the last hop in Internet connections.  It is therefore






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


Internet Draft          Integrated Services Over LANs           May 1997


   necessary to define standardized mechanisms for these technologies
   so that they are able to support the Integrated Services.  This memo
   describes a framework for providing the functionality to support
   Integrated Services on shared and switched LAN technologies.















































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


Internet Draft          Integrated Services Over LANs           May 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 and Internet telephony, there has been much
   interest for developing mechanisms which enable real-time services
   over the Internet.  These new requirements have led to the design
   of the ReSerVation Protocol (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.

   There is no standard mechanism for providing service guarantees on
   LAN technologies such as Ethernet and token ring.  They, however,
   typically constitute the last hop between users and the Internet
   backbone.  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 of campus
   networks.  It is therefore necessary to provide some standardized
   mechanism for 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.  Resource management
   in this context encompasses the functions of admission control,
   scheduling, traffic policing, etc.  The ISSLL (Integrated Services
   over Specific Link Layers) working group in the IETF was chartered
   with the purpose of exploring and standardizing such mechanisms for
   various link layer technologies.

   This document is concerned with specifying a framework for providing
   Integrated Services over shared and switched LAN technologies such
   as Ethernet/802.3, token ring/802.5, FDDI, etc.  We begin with a
   list of definitions in Section 2.  Section 3 lists the requirements
   and goals for a mechanism capable of providing Integrated Services
   in a subnet.  We then discuss a taxonomy of topologies for the LAN
   technologies under consideration with an emphasis on the capabilities
   of each which can be leveraged for enabling Integrated Services.  The
   resource management functions outlined in Section 3 are expected
   to be provided by an entity which, in this document, is referred
   to as the Bandwidth Manager (BM). The various components of the



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


Internet Draft          Integrated Services Over LANs           May 1997


   Bandwidth Manager are discussed in the following section and some
   examples of the implementation of the Bandwidth Manager are provided.
   Some issues with respect to link layer support for Integrated
   Services are examined in Section 6.  In the development of this
   framework, 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 all the
   functions discussed may not be supportable by a particular topology
   or technology, but this should not preclude the usage of this model
   for it.


2. Definitions

   The following is a list of the terms used in this document.

    -  End Station:  A device (e.g.  router, host) which runs the
       application program or higher layer protocol which needs to make
       reservations.

    -  Link Layer/Layer 2:  The data link layer.  This memo is concerned
       with link layer technologies such as Ethernet, token ring, and
       FDDI.

    -  Link Layer Domain:  An interconnection of segments and
       bridges/switches between two end stations.

    -  Segment:  A physical link which is shared by one or more senders.

    -  Traffic Class:  A category of flows which are given similar
       service within a bridge/switch.


3. Supporting Integrated Services Within a Subnet:  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.








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


Internet Draft          Integrated Services Over LANs           May 1997


3.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 delay,
       controlled load, 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.

    -  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
       effort.  Policing may optionally be implemented in the bridges
       and switches.  Alternatively, traffic may be shaped to insure
       conformance to the negotiated parameters.

    -  Soft State:  The mechanism must maintain soft state information
       about the reservations.  This means that state information must
       be periodically 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



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


Internet Draft          Integrated Services Over LANs           May 1997


       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 4.

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


3.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
       network layer protocols such as IPX, NetBIOS, etc.

    -  Receiver heterogeneity:  Receiver heterogeneity 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



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


Internet Draft          Integrated Services Over LANs           May 1997


       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 6.

    -  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 6.

    -  Path Selection:  In source routed LAN technologies such as token
       ring/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.


4. LAN Topologies and Their Features

   As stated earlier, this memo is concerned with specifying a framework
   for supporting Integrated Services in LAN technologies such as
   Ethernet/IEEE 802.3, token ring/IEEE 802.5, and FDDI. The extent
   to which service guarantees can be provided by a network depend to
   a large degree on the ability to provide the key functions of flow
   identification and scheduling in addition to admission control and
   policing.  This section discusses some of the capabilities of these
   LAN technologies and provides a taxonomy of possible topologies
   emphasizing the capabilities of each with regard to supporting the
   above functions.

   For the technologies considered here, the basic topology of a LAN
   may be shared, switched half duplex or switched full duplex.  In the
   shared topology, multiple senders share 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
   there are only two transmitters 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, a
   full bandwidth path is available to the transmitter at each end of
   the link at all times.  Therefore, in this topology, there is no need
   for any access control mechanism such as CSMA/CD or token passing as
   there is no contention between the transmitters.

   Another important element in the discussion of topologies is the
   support for multiple traffic classes.  Traffic classes provide a



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


Internet Draft          Integrated Services Over LANs           May 1997


   coarse method for isolation between flows and allows the possibility
   to easily support scheduling algorithms in order to meet service
   requirements.  Native Ethernet/802.3 does not support multiple
   traffic classes.  Token ring/802.5 and FDDI on the other hand
   provides support for traffic classes.  Three bits of the Frame
   Control field are used to indicate the Frame Priority which may be
   mapped to a traffic class as appropriate.  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 a station 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 Standards Committee has been working on
   the a 802.1p, a standard for expedited traffic classes and dynamic
   multicast filtering in bridges and switches [1].  The proposed
   standard requires a new frame format for Ethernet and token ring
   networks.  The new frame format adds 4 bytes of information of which
   3 bits are used to indicate User Priority.  This adds new information
   in the case of Ethernet networks.  For token ring networks this
   field carries the same information as the priority bits in the Frame
   Control field.  The User Priority may be mapped to any one of up to
   eight traffic classes in the bridge/switch.  The emerging standard
   does not specify a requirement for the minimum number of traffic
   classes which must be supported by a bridge/switch, nor does it
   specify the scheduling algorithm to be used between traffic classes.

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

    1. Shared topology without traffic classes:  This category includes
       pure shared media such as Ethernet/802.3 networks which are
       multi-access technologies with no support for priority signaling
       and traffic classes.  Shared topology without traffic classes
       offers little capability for isolation between reserved and
       unreserved flows.  No service guarantees can be provided in
       this scenario without modification to the basic transmission
       mechanisms.

    2. Shared topology with traffic classes:  This category includes
       Ethernet/802.3 networks which implement the emerging IEEE
       802.1p standard, as well as token ring/802.5 and FDDI networks.
       Even with support for traffic classes, shared Ethernet can at
       best offer loose statistical service guarantees because of the
       non-deterministic nature of the CSMA/CD protocol.  On the other
       hand, better guarantees can be provided on token ring media if
       the Frame Priority, Reserved Priority and Access Priority are
       used in conjunction with appropriate controls.



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


Internet Draft          Integrated Services Over LANs           May 1997


    3. Switched half duplex topology without traffic classes:  This
       scenario is a special case of shared topology without traffic
       classes where there are only two senders contending for resources
       on any segment (a host and a switch or two switches).  This
       topology provides higher bandwidth per station and fewer
       collisions.  Due to the use of the CSMA/CD protocol and the lack
       of traffic classes, little can be done to isolate flows and
       provide scheduling.

    4. Switched half duplex topology with traffic classes:  This
       scenario is a special case of shared topology with priority
       but there are now only two senders contending for resources
       on any segment.  This reduces the contention for resources.
       Ethernet/802.3 networks with this topology will likely be
       able to support better statistical service guarantees than
       the corresponding shared topology.  Better guarantees will be
       possible for token ring/802.5 media with this topology.

    5. Switched full duplex topology without traffic classes:  This
       scenario includes switched Ethernet/802.3 and token ring/802.5
       where the access control protocol is no longer used since a full
       bandwidth path is available to each transmitter.  However, since
       traffic classes are not available, it is not possible to isolate
       flows for scheduling.

    6. Switched full duplex topology with traffic classes:  This
       category is similar to the above, but traffic classes are
       also available.  This topology is the most capable in terms of
       link layer functions that can be exploited for supporting the
       functions of flow separation and 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 traffic
   classes 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, as far as that flow is
   concerned, the network is of the type corresponding to the least
   capable topology that is traversed.

   Note that even within the different switched topologies categorized
   above, there are likely to be switches having varied capabilities
   with respect to providing functions such as receiver heterogeneity
   and the ability to dedicate resources such as buffering and
   scheduling algorithms for supporting the various Integrated Services.
   Future work on service mappings in the ISSLL working group will
   elaborate on these issues.




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


Internet Draft          Integrated Services Over LANs           May 1997


5. Architecture for Supporting Integrated Services in LANs

   The functional requirements described in Section 3 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.


5.1. Components of the Bandwidth Manager

5.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, STII, 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 [8].  More information on these
   parameters may be found in the relevant Integrated Services documents
   [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 [7] for details).  In addition to 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
   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.


5.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



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


Internet Draft          Integrated Services Over LANs           May 1997


   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.


5.1.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 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
       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.


5.2. Implementation Scenarios

   Example scenarios are provided 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 in all end stations 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.



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


Internet Draft          Integrated Services Over LANs           May 1997


                               +---------+
                           .-->|  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 where a single BA is
   responsible for admission control decisions for the entire subnet.
   Every end station contains 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
   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
   non-overlapping subset of segments.  In a centralized implementation,
   the BA must be able to access topology information such as 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 the entire spanning tree for all
   flows leading to an inefficient utilization of resources.
















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


Internet Draft          Integrated Services Over LANs           May 1997



  +---------+                                              +---------+
  |  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
   Allocator

   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 actively participate in
   admission control.  With this approach, the BA would need only local
   topology information since each BA is responsible for the resources
   on segments that are directly connected to it.  This local topology
   information, such as which ports are on the spanning tree and
   which unicast addresses are reachable from which ports, is readily
   available in existing bridges/switches.

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


5.3. Logical Operation of the BM in End Stations and Link Layer Domain

   The figure below shows the location and logical operation of the
   BM in end stations and the link layer domain.  It is not possible
   to provide the details of physical flows because of the inherent
   differences that arise in centralized and distributed implementations
   as discussed in Section 5.2.














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


Internet Draft          Integrated Services Over LANs           May 1997


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

         End Station                      Link Layer Domain

    ---->  Signaling/Control
    ====>  Data

   Figure 3:  The logical Operation of the BM in end stations and the
   link layer domain.

   The application, which may be RSVP or some other higher layer
   reservation protocol requests resources by passing the relevant
   parameters to the RM. The RM then starts the process of resource
   reservation at the link layer by contacting the local BA. In the
   case of a distributed implementation, The local BA is responsible
   for admission control on the segment to which the end station 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 this case, it is possible to set up more complex
   schedulers as well as policing at the bridges/switches since the
   BA, which maintains the state, is co-located in every bridge/switch
   and participates actively in the process of admission control.  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.






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


Internet Draft          Integrated Services Over LANs           May 1997


6. Mapping Issues and Link Layer Support for Integrated Services

   As stated earlier, the Integrated Services working group has defined
   various 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 depend on many
   factors including the topology and technology used.  Some of the
   mapping issues are dicussed below in light of the emerging link layer
   standards and the functions supported by higher layer protocols.
   Considering the limitations of some of the topologies under
   consideration, it may not be possible to satisfy all the requirements
   for Integrated Services on a given topology.  In such cases, it
   is useful 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 required by the Controlled Load
   specification [4].  But if this task is left to the end stations, a
   reasonably good approximation to the service can be obtained.


6.1. Mapping of Services to Link Level Priority

   The number of traffic classes supported and access methods of
   the technology under consideration will determine how many and
   what services may be supported.  Native token ring/802.5, for
   instance, supports eight priority levels which may be mapped to
   one or more traffic classes.  Ethernet/802.3 has no support for
   signaling priorities within frames.  However, the IEEE 802 standards
   committee is working on a new standard for bridges/switches related
   to multimedia traffic expediting and dynamic multicast filtering
   [1].  The standard allows for up to eight traffic classes on all
   media.  The User Priority bits carried in the frame are mapped
   to a particular traffic class within a bridge/switch.  The User
   Priority is signaled on an end-to-end basis, unless overridden by
   bridge/switch management.

   The traffic class that is used by a flow should depend on the quality
   of service desired and whether the reservation is successful or not.
   Therefore, a sender should use the a User Priority value which maps
   to the best effort traffic class until told otherwise by the BM.
   The BM will, upon successful completion of resource reservation,
   specify the User Priority to be used by the sender for that session's
   data.  Future work in the ISSLL working group will address the issue




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


Internet Draft          Integrated Services Over LANs           May 1997


   of mapping the various Integrated Services to appropriate traffic
   classes in the bridges/switches.


6.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.

                   +-----+
                   |  S  |
                   +-----+
                      |
                      v
      +-----+      +-----+      +-----+
      | R1  |<-----| SW  |----->| R2  |
      +-----+      +-----+      +-----+

   Figure 4:  An instance of receiver heterogeneity.  S is the source.
   R1 is a receiver which makes a reservation, and R2 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, S is the upstream end station and R1 and R2
   are downstream end stations.  R1 would like to make a reservation
   for the flow while R2 would like to receive the flow using best
   effort transport.  S sends RSVP PATH messages which are multicast
   to both R1 and R2.  R1 sends an RSVP RESV message to S requesting
   the reservation of resources.  If the reservation is successful at
   Layer 2, the frames addressed to the group will be categorized in
   the traffic class corresponding to the service requested by R1.  At
   SW, there must be some mechanism which forwards the packet providing
   service corresponding to the reserved traffic class at the interface
   to R1 while using the best effort traffic class 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 with distinct MAC addresses, one for
   each class of service.  By default, a receiver would join the "best
   effort" group where the flow is classified as best effort.  If the
   receiver makes a reservation successfully, it can be transferred to
   the group for the class of service desired.  The dynamic multicast



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


Internet Draft          Integrated Services Over LANs           May 1997


   filtering capabilities of bridges and switches implementing the
   emerging IEEE 802.1p standard would be a very useful feature in
   such a scenario.  A given flow would be transmitted only on those
   segments which are on the path between the sender and the receivers
   of that flow.  The obvious disadvantage of such an approach is that
   the sender needs to send out multiple copies of the same packet
   corresponding to each class of service desired thus potentially
   duplicating the traffic on a portion of the distribution tree.


6.3. Support for Different Reservation Styles

              +-----+       +-----+       +-----+
              | S1  |       | S2  |       | S3  |
              +-----+       +-----+       +-----+
                 |             |             |
                 |             v             |
                 |          +-----+          |
                 +--------->| SW  |<---------+
                            +-----+
                             |   |
                        +----+   +----+
                        |             |
                        v             V
                     +-----+       +-----+
                     | R1  |       | R2  |
                     +-----+       +-----+

   Figure 5:  An illustration of filter styles.  S1, S2, S3, R1 and R2
   are RSVP end stations which are members of the same group.  SW is a
   bridge/switch in the link layer domain.

   In the figure above, S1, S2, S3, R1 and R2 are end stations which
   are members of a group associated with the same RSVP flow.  S1, S2
   and S3 are upstream end stations.  R1 and R2 are the downstream end
   stations which receive traffic from all the senders.  RSVP allows
   receivers R1 and R2 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); and (c) any
   sender in the group (shared wildcard filter).  Support for the fixed
   filter style is straightforward; a separate reservation is made for
   the traffic from each of the senders.  However, support for the the
   other two filter styles has implications regarding policing; i.e.
   the merged flow from the different senders must be policed so that
   they conform to traffic parameters specified in the filter's RSpec.
   This scenario is further complicated if the services requested by R1
   and R2 are different.  Therefore, in the absence of policing within




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


Internet Draft          Integrated Services Over LANs           May 1997


   bridges/switches, it may be possible to support only fixed filter
   reservations at the link layer.


7. 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 the link layer have also been discussed.
   Forthcoming documents from the ISSLL working group will address
   service mapping issues and provide a protocol specification for the
   Bandwidth manager based on the requirements and goals dicussed in
   this document.


References


[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/D5, February, 1997.

[2] IEEE Standards for Local and Metropolitan Area Networks:
    Draft Standard for Virtual Bridged Local Area Networks,
    P802.1Q/D5, February, 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,
    <draft-ietf-rsvp-spec-14.txt>

[4] J. Wroclawski, "Specification of the Controlled Load Network
    Element Service," Internet Draft, November 1996,
    <draft-ietf-intserv-ctrl-load-svc-04.txt>

[5] S. Shenker, C. Partridge and R. Guerin, "Specification of
    Guaranteed Quality of Service," Internet Draft, August 1996,
    <draft-ietf-intserv-guaranteed-svc-06.txt>

[6] R. Braden, D. Clark and S. Shenker, "Integrated Services in the



Ghanwani, Pace, Srinivasan        Expires November 1997        [Page 16]


Internet Draft          Integrated Services Over LANs           May 1997


    Internet Architecture: An Overview,"  RFC 1633, June 1994.

[7] J. Wroclawski, "The Use of RSVP with IETF Integrated Services,"
    Internet Draft, October 1996, <draft-ietf-intserv-rsvp-use-01.txt>

[8] S. Shenker and J. Wroclawski, "Network Element Service
    Specification Template," Internet Draft, November 1995,
    <draft-ietf-intserv-svc-template-02.txt>

[9] S. Shenker and J. Wroclawski, "General Characterization Parameters
    for Integrated Service Network Elements," Internet Draft,
    October 1996, <draft-ietf-intserv-charac-02.txt>

[10] L. Delgrossi and L. Berger (Editors), "Internet Stream Protocol
     Version 2 (ST2)  Protocol Specification - Version ST2+,"
     Request For Comments 1819, August 1995.



Acknowledgements

   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
          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



Ghanwani, Pace, Srinivasan        Expires November 1997        [Page 17]


Internet Draft          Integrated Services Over LANs           May 1997


          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 November 1997        [Page 18]


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