Internet Draft                                        Mick                                       M. Seaman
   Expires May 1998 February 1999                                     3Com
draft-ietf-issll-is802-svc-mapping-01.txt            Andrew
   draft-ietf-issll-is802-svc-mapping-02.txt             A. Smith
                                                 Extreme Networks
                                                     Eric
                                                       E. Crawley
                                                   Argon Networks
                                                    November 1997
                                                    J. Wroclawski
                                                          MIT LCS
                                                      August 1998

             Integrated Service Mappings on IEEE 802 Networks

   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. Internet Drafts 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 view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).

   This document is a product of the IS802 subgroup of the ISSLL working
   group of the Internet Engineering Task Force.  Comments are solicited
   and should be addressed to the working group's mailing list at
   issll@mercury.lcs.mit.edu and/or the authors.  Copyright (C) The
   Internet Society (1998). All Rights Reserved.

   Abstract

   This document describes mappings of IETF Integrated Services over
   LANs built from IEEE 802 network segments which may be interconnected
   by IEEE 802.1 MAC Bridges (switches) [1][2].

9

9   Seaman,Smith,Crawley,Wroclawski.  Expires February 1999
   It describes parameter mappings for supporting Controlled Load [6]
   and Guaranteed Service [7] using the inherent capabilities of
   relevant IEEE 802 technologies and 802.1D/802.1p and, in particular, 802.1D-1998
   queuing features in switches [2].

   These mappings fit in with are one component of the ISSLL Integrated Services over IEEE
   802 LANs framework described in [5].

   1.  Introduction

   The IEEE 802.1 Interworking Task Group has recently agreed on developed a set of
   enhancements to the basic MAC Service provided in Bridged Local Area
   Networks (a.k.a. "switched LANs"). As a supplement to the original
   IEEE MAC Bridges standard standard, IEEE 802.1D-1990 [1], the update P802.1p updated IEEE
   802.1D-1998 [2] proposes differential traffic class queuing in
   switches and access to media on extends the basis capabilities of Ethernet/802.3 media to
   carry a traffic class indicator, or "user_priority" signaled in frames.

In field, within
   data frames [8].

   The availability of this document we summarise the model for selecting differential traffic classes
described in the framework [5] queuing, together with
   additional mechanisms to provide admission control and how we identify those classes in
data-link layer devices.  We then discuss how signaling,
   allows IEEE 802 networks to map support a close approximation of the existing IETF-
defined
   IETF-defined Integrated Services onto the ISSLL 802 traffic class model,
propose an example of particular choices of traffic class, discuss some
particular issues with capabilities [6][7]. This document
   describes methods for mapping the use of RSVP/SBM signaling protocols service classes and
discuss the applicability of all parameters of
   the above in some different IETF model into IEEE 802.1D network
topologies. parameters.  A companion
   document [10] describes a signaling protocol for use with these
   mappings.  It is recommended that readers be familiar with the
   overall framework in which these mappings and signaling protocol are
   expected to be used - used; this framework is described fully in [5].

2. Selecting traffic classes

One fundamental question is "who gets to decide what

   Within this document, Section 2 describes the classes mean method by which end
   systems and who gets access to them?" One approach would routers bordering the IEEE Layer-2 cloud learn what
   traffic class should be used for each data flow's packets.  Section 3
   describes the meanings of
the classes approach recommended to be "well-known": we would then need map IP-level traffic flows to standardise a set
of
   IEEE traffic classes e.g. 1 = best effort, within the Layer 2 = controlled- load, 3 = guaranteed
(loose delay bound, high bandwidth), network.  Section 4 = guaranteed (slightly tighter
delay) etc. The values to encode in such a table in end stations, in
isolation from describes
   the network to which they are connected, is
problematical: one approach could be to define one user_priority value
per int-serv service computation of Characterization Parameters by the layer 2
   network.  The remaining sections discuss some particular issues with
   the use of the RSVP/SBM signaling protocols, and leave it at that (reserving describe the rest
   applicability of all of the
combinations for future traffic classes).

The model described in [5] uses a more flexible mapping: clients ask
"the network" which user_priority traffic class above to use for a given
traffic flow, as categorised by its flow-spec different layer 2 network
   topologies.

9

9   Seaman,Smith,Crawley,Wroclawski.  Expires February 1999
   2.  Flow Identification and Traffic Class Selection

   One model for supporting integrated services over specific link
   layers treats layer-2 endpoints. The
network provides devices very much as a value back to special case of routers.
   In this model, switches and other devices along the requester which is appropriate data path make
   packet handling decisions based on the RSVP flow and filter
   specifications, and use these specifications to classify the current network topology, load conditions, other admitted flows etc.
   corresponding data packets. The task of configuring switches with this mapping (e.g. through network
management, a switch-switch protocol specifications could either be used
   directly, or via some network-wide QoS- could be used indirectly by mapping directory service) is each RSVP session
   onto a layer-2 construct such as an order of magnitude less complex than
performing the same function ATM virtual circuit.

   This approach is inappropriate for use in end stations. Also, when new services
(or other network reconfigurations) are added to such a network, the
network elements will typically be the ones IEEE 802 environment.
   Filtering to be upgraded the per-flow level becomes expensive with new
queuing algorithms etc. and can be provided increasing
   switch speed; devices with new mappings at this
time.

Given the need for such filtering capabilities are likely to
   have a new session or "flow" requiring some QoS support, a
client then needs answers very similar implementation complexity to the following questions:

1. which IP routers, and may
   not make use of simpler mechanisms such as 802.1D user priority.

   The Integrated Services over IEEE 802 LANs framework [5] and this
   document use an "aggregated flow" approach based on use of layer 2
   traffic class do I add classes. In this model, each arriving flow to?
   The client needs to know how is assigned to label the packets one
   of the flow as it
   places them available layer-2 classes, and traverses the 802 cloud in this
   class.  Traffic flows requiring similar service are grouped together
   into a single class, while the network.

2. who do I ask/tell?
   The client asks "the network" which user_priority traffic system's admission control and class to
   use
   selection rules ensure that the service requirements for a given traffic flow.

3. how do I ask/tell them?
   A request/response protocol flows in
   each of the classes are met.  In many situations this is needed a viable
   intermediate point between client no QoS control and network: full router- type
   integrated services. The approach can work effectively even with
   switches implementing only the simplest differential traffic
   classification capability specified in
   fact, the request can be piggy-backed onto an admission control
   request and 802.1D model.

   In the response can be piggy-backed onto an admission
   control acknowledgment: this "one pass" assignment has aggregated flow model, traffic arriving at the benefit boundary of
   completing the admission control in a timely way and reducing
   layer 2 cloud is tagged by the
   exposure to changing conditions which could occur if clients cached boundary device (end host or border
   router) with an appropriate traffic class, represented as an 802.1D
   "user_priority" value. Two fundamental questions are "who determines
   the knowledge for extensive periods. ISSLL WG has defined extensions correspondence between IP-level traffic flows and link-level
   classes?" and "how is this correspondence conveyed to the RSVP protocol boundary
   devices that must mark the data frames?"

   One approach to answering these questions would be for communicating this information [10].

The network (i.e. the first network element encountered downstream from
the client) must then answer meanings
   of the following questions:

1. classes to which traffic class do I add this flow? be universally defined. This is document would then
   standardise the meanings of a packing problem, difficult to solve set of classes; e.g. 1 = best effort, 2
   = 100 ms peak delay target, 3 = 10 ms peak delay target, 4 = 1 ms
   peak delay target, etc. The meanings of these universally defined
   classes could then be encoded directly in general, but many
   simplifying assumptions can end stations, and the
   flow-to-class mappings computed directly in these devices.

   Seaman,Smith,Crawley,Wroclawski.  Expires February 1999        [Page
3]
   This universal definition approach would be made: presumably some simple form to implement, but
   is too rigid to map the wide range of
   allocation can be done without possible user requirements onto
   the limited number of available 802.1D classes. The model described
   in [5] uses a more complex scheme able to
   dynamically shift flows around between classes.

2. flexible mapping: clients ask "the network" which
   user_priority traffic class has worst-case parameters which meet to use for a given traffic flow, as
   categorised by its flow-spec and layer-2 endpoints. The network
   provides a value back to the needs requester that is appropriate
   considering the current network topology, load conditions, other
   admitted flows, etc.  The task of configuring switches with this flow?
   This might be
   mapping (e.g. through network management, a switch-switch protocol or
   via some network-wide QoS-mapping directory service) is an ordering/comparison problem: which order of two service
   classes is "better"
   magnitude less complex than performing the other? Again, we can make this tractable
   by observing that all of the current int- serv classes can be ranked
   (best effort <= Controlled Load <= Guaranteed Service) same function in a simple
   manner. If any classes end
   stations. Also, when new services (or other network reconfigurations)
   are implemented in added to such a network, the future that cannot network elements will typically be
   simply ranked then
   the issue ones to be upgraded with new queuing algorithms etc. and can be finessed by either
   provided with new mappings at this time.

   In this model, when a priori
   knowledge about what classes are supported or by configuration.

and return the chosen user_priority value to the client.

Note that the client may be either an end station, router new session or a first
switch which may be acting as a proxy for "flow" requiring QoS support is
   created, a client must ask "the network" which does not
participate in these protocols user_priority traffic
   class to use for whatever reason. Note also that a
device e.g. a server or router, may choose to implement both given traffic flow, so that it can label the
"client" as well
   packets of the flow as it places them into the "network" portion of network. A
   request/response protocol is needed between client and network to
   return this model so that it information. The request can
select its own user_priority values: such be piggy-backed onto an implementation would,

however,
   admission control request and the response can be discouraged unless piggy-backed onto
   an admission control acknowledgment. This "one pass" assignment has
   the device really does have a close tie-
in with benefit of completing the network topology and resource allocation policies but would
work admission control transaction in some cases where there is known over- provisioning of resources.

3. Flow Identification

Some other models for int-serv over lower-layers treat layer-2 switches
very much as a special case of routers: in particular, that switches
along the data path will make packet handling decisions based on the
RSVP flow and filter specifications
   timely way and use them reducing the exposure to classify changing conditions that
   could occur if clients cached the
corresponding data packets. However, filtering knowledge for extensive periods. A
   set of extensions to the per-flow level
becomes expensive with increasing switch speed: devices with such
filtering capabilities are unlikely to have a very different
implementation complexity from IP routers and there already exist IETF RSVP protocol specifications for those devices [4].

This memo uses "aggregated flow" identification based on data-link layer
"user_priority" as a viable intermediate point between no QoS and full
router-type integrated services and communicating this is
   information have been defined[10].

   The network (i.e. the minimum flow
classification capability required of switches in first network element encountered downstream
   from the "ISSLL over IEEE
802 networks" model.

4. Mappings client) must then answer the following questions:

   1. Which of int-serv characterisation parameters the available traffic classes would be appropriate for IEEE 802 devices

It is assumed that admission control will
        this flow?
        In general, a newly arriving flow might be applied when deciding
whether or not assigned to admit a new number
        of classes. For example, if 10ms of delay is acceptable, the
        flow through a given network element and
that could potentially be assigned to either a device sending onto 10ms delay class
        or a link will be proxying 1ms delay class. This packing problem is quite difficult to
        solve if the target parameters and
admission control decisions on behalf of that link: this process will
require the device to be able classes are allowed to determine (by estimation, measurement
or calculation) several parameters.
        change dynamically as flows arrive and depart.  It is assumed that details quite
        simple if the target parameters of each class is held fixed, and
        the
potential flow are provided class table is simply searched to the device by some means (e.g. find a
signaling protocol, network management). The service definition
specifications themselves provide some implementation guidance as class appropriate

   Seaman,Smith,Crawley,Wroclawski.  Expires February 1999        [Page
4]
        for the arriving flow. This document adopts the latter approach.

   2. Of the appropriate traffic classes, which if any have enough
        capacity available to how accept the new flow?
        This is the admission control problem. It is necessary to calculate some of these quantities.

The accuracy of calculation of these parameters may not be very
critical: indeed it is an assumption
        compare the level of traffic currently assigned to each class
        with the use available level of this model by
relatively simple switches ("Class I" according network resources (bandwidth,
        buffers, etc), to the taxonomy
presented in [5]) ensure that they merely provide values adding the new flow to describe the device
and admit flows conservatively.

4.1 General characterisation parameters

There are some general parameters [9] that a device class
        will need not cause the class's performance to use
and/or supply for all service types:
* Ingress link
* Egress links and their MTUs, framing overheads and minimum packet
sizes (see media-specific information presented above).
* available path bandwidth: updated hop-by-hop by any device along go below its target
        values. This problem is compounded because in a priority queuing
        system adding traffic to a higher-priority class can affect the
path
        performance of lower-priority classes. The admission control
        algorithm for a system using the flow.
* minimum latency

4.2 Parameters to implement Guaranteed Service

A network element default 802 priority behavior
        must be able reasonably sophisticated to determine provide acceptable results.

        If an acceptable class is found, the following parameters
[7]:

* Constant delay bound through this device (in addition to any network returns the chosen
        user_priority value
provided by "minimum latency" above) and up to the receiver at client.

        Note that the next
network element for client may be an end station, a router at the packets edge
        of this flow if it were to be admitted:
this would include any access latency bound to the outgoing link as well layer 2 network, or a first switch acting as propagation delay across a proxy for
        a device that link.
* Rate-proportional delay bound through this does not participate in these protocols for
        whatever reason. Note also that a device and up e.g. a server or router
        may choose to implement both the
receiver at the next network element for "client" as well as the packets
        "network" portion of this flow if it
were to be admitted.
* Receive resources model so that would need to be associated with this flow
(e.g. buffering, bandwidth) if it were to be admitted and not suffer
packet loss if it kept within can select its supplied Tspec/Rspec.
* Transmit resources that own
        user_priority values. Such an implementation would need to be associated with this flow
(e.g. buffering, bandwidth, constant- and rate-proportional delay
bounds) if it were to be admitted.

4.3 Parameters to implement Controlled Load

A network element must generally be able to determine
        discouraged unless the following parameters
which can be extracted from [6]:

* Receive resources that would need to be associated with this flow
(e.g. buffering) if it were to be admitted.
* Transmit resources that would need to be associated with this flow
(e.g. buffering) if it were to be admitted.

4.4 Parameters to implement Best Effort

For device has a close tie-in with the
        network element to implement best effort service topology and resource allocation policies. It may,
        however, work acceptably in cases where there are no
explicit parameters that need to be characterised.

5. Mapping to is known over-
        provisioning of resources.

   3.  Choosing a flow's IEEE 802 user_priority

There are many options available for mapping aggregations of flows
described class

   This section describes the method by int-serv service models (Best which IP-level flows are mapped
   into appropriate IEEE user_priority classes. The IP-level services
   considered are Best Effort, Controlled Load, and Guaranteed are the services considered here) onto user_priority classes. Service.

   The following mappings major issue is that admission control requests and application
   requirements are presented as an example set in order to
stimulate experimentation in this area - they may be refined specified in future
editions terms of this memo.  Note, this does not dictate what
mechanisms/algorithms a network element (e.g. an Ethernet switch) needs
to perform to implement these mappings: this is an implementation choice
and does not matter so long as the requirements for the particular multidimensional vector of
   parameters e.g. bandwidth, delay, jitter, service model are met. In order to reduce the administrative problems,
such class.  This
   multidimensional space must be mapped onto a mapping table is held by *switches* (and routers if desired) but
generally not by end-station hosts and set of traffic classes
   whose default behaviour in L2 switches is unidimensional (i.e. strict
   priority default queuing). This priority queuing alone can provide
   only relative ordering between traffic classes. It can neither

   Seaman,Smith,Crawley,Wroclawski.  Expires February 1999        [Page
5]
   enforce an absolute (quantifiable) delay bound for a read-write table. The values
proposed below are defaults and traffic class,
   nor can be overridden by management it discriminate amongst Int-Serv flows within the aggregate
   in a traffic class. Therefore, it cannot provide the absolute control
so long as all switches agree to some extent (the
   of packet loss and delay required level for individual Int-Serv flows.

   To provide absolute control of
agreement requires further analysis).

It is possible that some form loss and delay three things must
   occur:

   (1)  The amount of network-wide lookup service could bandwidth available to the QoS-controlled flows
        must be
implemented that serviced requests from clients e.g. traffic_class =
getQoSbyName("H.323 video") known, and notified switches of what sorts the number of
traffic categories they were likely flows admitted to encounter and how the network
        (allowed to allocate
those requests into use the bandwidth) must be limited.

   (2)  A traffic classes: such mechanisms scheduling mechanism is needed to give preferential
        service to flows with lower delay targets.

   (3)  Some mechanism must ensure that best-effort flows and QoS
        controlled flows that are for further
study.

        user_priority   Service

          0             Default, assumed exceeding their Tspecs do not damage
        the quality of service delivered to in-Tspec QoS controlled
        flows. This mechanism could be Best Effort
          1             Background, "less than" Best Effort
          2             reserved
          3             reserved
          4             Controlled Load
          5             Guaranteed Service, 100ms bound
          6             Guaranteed Service, 10ms bound
          7             reserved

          Table 1 - Example user_priority top service mappings

With this example set part of mappings, all the traffic that uses scheduler, or
        it could be a separate policing mechanism.

        For IEEE 802 networks, the Controlled
Load service first function (admission control) is mapped to
        provided by a single Subnet Bandwidth Manager, as discussed below. We
        use the link-level user_priority whilst that mechanism at each switch and
        bridge to implement the second function (preferential service to
        flows with lower delay targets). Because a simple priority
        scheduler cannot provide policing (function three), policing for
Guaranteed Service
        IEEE networks is placed into one generally implemented at the edge of two user_priority classes with
different the
        network by a layer-3 device. When this policing is performed
        only at the edges of the network it is of necessity approximate.
        This issue is discussed further in [5].

   3.1.  Context of admission control and delay bounds

   As described above, it is the combination of priority-based
   scheduling and admission control that creates quantified delay
   bounds. Unreserved best effort Thus, any attempt to quantify the delay bounds expected by a
   given traffic is mapped class has to
another.

The use made in the context of classes 4, 5 and the admission
   control elements. Section 6 of the framework [5] provides for Controlled Load and Guaranteed Service
is somewhat arbitrary as long as they are increasing. Any two classes
greater than Best Effort can be used as long as GS
   different models of admission control - centralized or distributed
   Bandwidth Allocators.

   It is important to note that in this approach it is "greater" than CL
although those proposed here have the advantage that, for transit

through 802.1p switches with only two-level strict priority queuing,
they both get "high priority" treatment (the 802.1p default split admission

   Seaman,Smith,Crawley,Wroclawski.  Expires February 1999        [Page
6]
   control algorithm that determines which of the Int-Serv services is 0-3
and 4-7 for
   being offered. Given a device with 2 queues). The choice set of priority classes with delay targets, a
   relatively simple admission control algorithm can place flows into
   classes so that the bandwidth and delay behavior experienced by each
   flow corresponds to the requirements of the Controlled-Load service,
   but cannot offer the higher assurance of the Guaranteed service. To
   offer the Guaranteed service, the admission control algorithm must be
   much more stringent in its allocation of resources, and must also
   compute the C and D error terms required of this service.

   A delay bound can only be realized at the admission control element
   itself so any delay numbers attached to a traffic class represent the
   delay that a single element can allow for.  That element may
   represent a whole L2 domain or just a single L2 segment.

   With either admission control model, the delay bound has no scope
   outside of a L2 domain. The only requirement is also
arbitrary that it be understood
   by all Bandwidth Allocators in the L2 domain and, for example, be
   exported as C and D terms to L3 devices implementing the Guaranteed
   Service. Thus, the end-to-end delay experienced by a flow can only be
   characterized by summing along the path using the usual RSVP
   mechanisms.

   3.2.  Default service mappings

   Table 1 presents the default mapping from delay targets to IEEE 802.1
   user_priority classes. However, these mappings must be viewed as
   defaults, and must be changeable.

   In order to simplify the task of changing mappings, this mapping
   table is held by *switches* (and routers if desired) but potentially very significant: generally
   not by end-station hosts.  It is a read-write table. The values
   proposed below are defaults and can be overridden by management
   control so long as all switches agree to some extent (the required
   level of agreement requires further analysis).

   In future networks this mapping table might be adjusted dynamically
   and without human intervention. It is possible that some form of
   network-wide lookup service could be implemented that serviced
   requests from clients e.g. traffic_class = getQoSbyName("H.323
   video") and notified switches of what traffic categories they were
   likely to encounter and how to allocate those requests into traffic
   classes. Alternatively, the network's admission control mechanisms
   might directly adjust the mapping table to maximize the utilization

   Seaman,Smith,Crawley,Wroclawski.  Expires February 1999        [Page
7]
   of network resources. Such mechanisms are for further study.

            user_priority  Service
              0            Default, assumed to be Best Effort
              1            reserved, "less than" Best Effort
              2            reserved
              3            reserved
              4            Delay Sensitive, no bound
              5            Delay Sensitive, 100ms bound
              6            Delay Sensitive, 10ms bound
              7            Network Control

       Table 1 - Example user_priority to service mappings

   The delay bounds numbers proposed above are for per-Bandwidth
   Allocator element delay targets and are derived from a subjective
   analysis of the needs of typical delay-sensitive applications e.g.
   voice, video. See Annex H of [2] for further discussion of the
   selection of these values. Although these values appear to address
   the needs of current video and voice technology, it should be noted
   that there is no requirement to adhere to these values and no
   dependence of IEEE 802.1 on these values.

   Note: These mappings are believed to be useful defaults but further
   implementation and usage experience is required. The mappings may be
   refined in future editions of this document.

   With this example set of mappings, delay-sensitive, admission
   controlled traffic flows are mapped to user_priority values in
   ascending order of their delay bound requirement. Note that the
   bounds are targets only - see [5] for a discussion of the effects of
   other non-conformant flows on delay bounds of other flows. Only by
   applying admission control to higher-priority classes can any
   promises be made to lower-priority classes.

   This set of mappings also leaves several classes as reserved for
   future definition.

   Note: this mapping does not dictate what mechanisms or algorithms a
   network element (e.g. an Ethernet switch) must perform to implement
   these mappings: this is an implementation choice and does not matter
   so long as the requirements for the particular service model are met.

   Note: these mappings apply primarily to networks constructed from
   devices that implement the priority-scheduling behavior defined as

   Seaman,Smith,Crawley,Wroclawski.  Expires February 1999        [Page
8]
   the default in 802.1D. Some devices may implement more complex
   scheduling behaviors not based only on priority. In that circumstance
   these mappings might still be used, but other, more specialized
   mappings may be more appropriate.

   3.3.  Discussion

   The recommendation of classes 4, 5 and 6 for Delay Sensitive,
   Admission Controlled flows is somewhat arbitrary; any classes with
   priorities greater than that assigned to Best Effort can be used.
   Those proposed here have the advantage that, for transit through
   802.1D switches with only two-level strict priority queuing, all
   delay-sensitive traffic gets "high priority" treatment (the 802.1D
   default split is 0-3 and 4-7 for a device with 2 queues).

   The choice of the delay bound targets is tuned to an average expected
   application mix, and might be retuned by a network manager facing a
   widely different mix of user needs. The choice is potentially very
   significant: wise choice can lead to a much more efficient allocation
   of resources as well as greater (though still not very good)
   isolation between flows.

   Placing Network Control traffic at class 7 is necessary to protect
   important traffic such as route updates and network management.
   Unfortunately, placing this traffic higher in the user_priority
   ordering causes it to have a direct effect on the ability of devices
   to provide assurances to QoS controlled application traffic.
   Therefore, an estimate of the amount of Network Control traffic must
   be made by any device that is performing admission control (e.g.
   SBMs). This would be in terms of the parameters that are normally
   taken into account by the admission control algorithm. This estimate
   should be used in the admission control decisions for the lower
   classes (the estimate is likely to be a configuration parameter of
   SBMs).

   A traffic class such as class 1 for "less than best effort" might be
   useful for devices that wish to dynamically "penalty tag" all of the
   data of flows that are presently exceeding their allocation or Tspec.
   This provides a way to isolate flows that are exceeding their service
   limits from flows that are not, to avoid reducing the QoS delivered
   to flows that are within their contract. Data from such tagged flows
   might also be preferentially discarded by an overloaded downstream
   device.
9

9   Seaman,Smith,Crawley,Wroclawski.  Expires February 1999
   A somewhat simpler approach would be to tag only the portion of a
   flow's packets that actually exceed the Tspec at any given instant as
   low priority. However, it is often considered to be a bad idea to
   treat flows in this way as it will likely cause significant re-
   ordering of the flow's packets, which is not desirable. Note that the
   default 802.1D treatment of user_priorities 1 and 2 is "less than"
   the default class 0.

   4.  Computation of integrated services characterization parameters by
   IEEE 802 devices

   The integrated service model requires that each network element that
   supports integrated services compute and make available certain
   "characterization parameters" describing the element's behavior.
   These parameters may be either generally applicable or specific to a
   particular QoS control service.  These parameters may be computed by
   calculation, measurement, or estimation. When a network element
   cannot compute its own parameters (for example, a simple link), we
   assume that the device sending onto or receiving data from the link
   will compute the link's parameters as well as it's own.

   The accuracy of calculation of these parameters may not be very
   critical; in some cases loose estimates are all that is required to
   provide a useful service. This is important in the IEEE 802 case,
   where it will be virtually impossible to compute parameters
   accurately for certain topologies and switch technologies. Indeed, it
   is an assumption of the use of this model by relatively simple
   switches (see [5] for a discussion of the different types of switch
   functionality that might be expected) that they merely provide values
   to describe the device and admit flows conservatively.

   The discussion below presents a general outline for the computation
   of these parameters, and points out some cases where the parameters
   must be computed accurately. Further specification of how to export
   these parameters is for further study.

   4.1.  General characterization parameters

   There are some general parameters [9] that a device will need to use
   and/or supply for all service types:

   *    Ingress link

   Seaman,Smith,Crawley,Wroclawski.  Expires February 1999       [Page
10]
   *    Egress links and their MTUs, framing overheads and minimum
        packet sizes (see media-specific information presented above).

   *    available path bandwidth: updated hop-by-hop by any device along
        the path of the flow.

   *    minimum latency

        Of these parameters, the MTU and minimum packet size information
        must be reported accurately. Also, the "break bits" must be set
        correctly, both the overall bit that indicates the existence of
        QoS control support and the individual bits that specify support
        for a particular scheduling service. The available bandwidth
        should be reported as accurately as possible, but very loose
        estimates are acceptable. The minimum latency parameter should
        be determined and reported as accurately as possible if the
        element offers Guaranteed service, but may be loosely estimated
        or reported as zero if the element offers only Controlled-Load
        service.

   4.2.  Parameters to implement Guaranteed Service

   A network element supporting the Guaranteed Service must be able to
   determine the following parameters [7]:

   *    Constant delay bound through this device (in addition to any
        value provided by "minimum latency" above) and up to the
        receiver at the next network element for the packets of this
        flow if it were to be admitted.  This includes any access
        latency bound to the outgoing link as well as propagation delay
        across that link. This value is advertised as the "C" parameter
        of the Guaranteed Service.

   *    Rate-proportional delay bound through this device and up to the
        receiver at the next network element for the packets of this
        flow if it were to be admitted.  This value is advertised as the
        "D" parameter of the Guaranteed Service.

   *    Receive resources that would need to be associated with this
        flow (e.g. buffering, bandwidth) if it were to be admitted and
        not suffer packet loss if it kept within its supplied
        Tspec/Rspec. These values are used by the admission control
        algorithm to decide whether a new flow can be accepted by the
        device.

   Seaman,Smith,Crawley,Wroclawski.  Expires February 1999       [Page
11]
   *    Transmit resources that would need to be associated with this can lead
        flow (e.g. buffering, bandwidth, constant- and rate-proportional
        delay bounds) if it were to be admitted. These values are used
        by the admission control algorithm to decide whether a much more
efficient allocation of resources new flow
        can be accepted by the device.

   The exported characterization parameters for this service should be
   reported as well accurately as greater (though still not
very good) isolation between flows.

The "less possible. If estimations or approximations
   are used, they should err in whatever direction causes the user to
   receive better performance than best effort" class might requested. For example, the C and D
   error terms should overestimate delay, rather than underestimate it.

   4.3.  Parameters to implement Controlled Load

   A network element implementing the Controlled Load service must be useful e.g. for devices that
wish
   able to "penalty tag" all of determine the data of flows following [6]:

   *    Receive resources that have abused the
network by excessively exceeding their Allocation or profile: these
might be preferentially discarded by a downstream device.  It would
probably need to be a bad idea associated with this
        flow (e.g. buffering) if it were to just mark some of be admitted. These values
        are used by the packets of admission control algorithm to decide whether a
        new flow in
this way as this will likely cause re-ordering of packets which is
generally a bad thing (tm). Note, this is not *required* can be accepted by any current
int-serv models but is under study e.g. in the IETF's Differential
Services WG.

The advantage device.

   *    Transmit resources that would need to be associated with this approach is that
        flow (e.g. buffering) if it puts some real delay bounds on
the Guaranteed Service without adding any additional complexity were to be admitted. These values
        are used by the
other services.  It still ignores admission control algorithm to decide whether a
        new flow can be accepted by the amount of *bandwidth* available
for each class. This should behave reasonably well as long as all
traffic for CL and GS flows device.

   The Controlled Load service does not exceed export any service-specific
   characterization parameters. Internal resource capacities in
the device. Some isolation between very delay-critical GS and less
critical GS flows is provided but there is still an overall assumption allocation estimates
   should ensure that flows will in general be well- behaved. In addition, this mapping
still leaves room for future the service models.

Expanding quality remains high when considering
   the number statistical aggregation of classes for CL Controlled Load flows into 802 traffic
   classes.

   4.4.  Parameters to implement Best Effort

   For a network element that implements only best effort service is not as appealing since there is
   are no explicit parameters that need to map to a particular delay bound.  There may be cases
where characterized. Note that
   an administrator might map CL onto more classes for particular
bandwidths or policy levels.  It may also be desirable to further
subdivide CL traffic integrated services aware network element that implements only
   best effort service will set the "break bit" described in cases where it is frequently non-conformant for
certain applications.

6. [11].

   Seaman,Smith,Crawley,Wroclawski.  Expires February 1999       [Page
12]
   5.  Merging of RSVP/SBM objects

   Where reservations that use the SBM protocol's TCLASS object [10]
   need to be merged, an algorithm needs to be defined that is
   consistent with the mappings to individual user_priority values in
   use in the network.

   A merged reservation must receive at least as good a service as the
   best of the component reservations. In the circumstances considered
   here, this translates into placing the merged reservation into the
   lowest delay class of those that could be used for the individual
   reservations.

   For the example mappings proposed in this memo, document, the merging
   device should merge to the "lowest" "highest" priority value of the values
   received in TCLASS objects of the PATH/RESV messages where "lowest" "highest"
   is defined as follows:

              Lowest  ------->   Highest
                1, 2, 0, 3, 4, 5, 6, 7

   Note: this counter-intuitive ordering is an artifact of the *default*
   relative treatment of user_priority values in the IEEE 802.1p 802.1D
   specification (see Annex H of [2]). If a device has been configured
   to apply non-default treatment of user_priority values then it should
   adjust this merging operation accordingly.

7.

   6.  Applicability of these service mappings

   Switches using layer-2-only standards (e.g. 802.1D, 802.1p) 802.1D-1990, 802.1D-
   1998) need to inter-operate with routers and layer-3 switches. Wide
   deployment of such
802.1p 802.1D-1998 switches will occur in a number of
   roles in the network: "desktop switches" provide dedicated 10/100
   Mbps links to end stations and high speed core switches often act as
   central campus switching points for layer-3 devices. Layer-2 devices
   will have to operate in all of the following scenarios:

   *    every device along a network path is layer-3 capable and
        intrusive into the full data stream

   *    only the edge devices are pure layer-2

   Seaman,Smith,Crawley,Wroclawski.  Expires February 1999       [Page
13]
   *    every alternate device lacks layer-3 functionality

   *    most devices lack layer-3 functionality except for some key
        control points such as router firewalls, for example.

   Where int-serv flows pass through equipment which does not support
   Integrated Services or 802.1p 802.1D traffic management and which places all
   packets through the same queuing and overload-dropping paths, it is
   obvious that some of a flow's desired service parameters become more
   difficult to support. In particular, the two integrated service
   classes studied here, Controlled Load and Guaranteed Service, both
   assume that flows will be policed and kept "insulated" from mis-behaving
   misbehaving other flows or from best effort traffic during their
   passage through the network. This cannot be done within an IEEE 802
   network using devices with the default user_priority function; in
   this case policing must be approximated at the network edges.

   In addition, in order to provide a Guaranteed Service, *all*
   switching elements along the path must participate in special
   treatment for packets in such flows: where there is a "break" in
   guaranteed service, all bets are off. Thus, a network path that
   includes even a single switch transmitting onto a shared or half-
   duplex LAN segment is unlikely to be able to provide a very good
   approximation to Guaranteed Service. For Controlled Load service, the
   requirements on the switches and link types are less stringent
   although it is still necessary to provide differential queueing and
   buffering in switches for CL flows over best effort in order to
   approximate CL service. Note that users receive indication of such
   breaks in the path through the "break bits" described in [11]. These
   bits must be correctly set when IEEE 802 devices that cannot provide
   a specific service exist in a network.

   Other approaches might be to pass more information between switches
   about the capabilities of their neighbours and to route around non-
   QoS-capable switches: such methods are for further study. And of
   course the easiest solution of all is to upgrade links and switches
   to higher capacities.

8.

   Seaman,Smith,Crawley,Wroclawski.  Expires February 1999       [Page
14]
   7.  References

   [1]  "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC Bridges"

   [2] "Supplement to MAC  "Information technology - Telecommunications and information
        exchange between systems - Local and metropolitan area networks
        - Common specifications - Part 3: Media Access Control (MAC)
        Bridges: Revision (Incorporating IEEE P802.1p: Traffic Class
        Expediting and Dynamic Multicast Filtering", September 1997, ISO/IEC Final CD
        15802-3 IEEE P802.1p/D8 P802.1D/D15, November 1997

   [3]  Clark, D. et al. "Integrated Services in the Internet Architecture: an Overview"
   [4]  Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource
        Reservation Protocol (RSVP) - Version 1 Functional
        Specification", RFC 2205, September 1997

   [5]  Ghanwani, A., Pace, W., Srinivasan, V., Smith, A., Seaman, M.,
        "A Framework for Providing Integrated Services Over Shared and
        Switched LAN Technologies", Internet Draft, November 1997
        <draft-ietf-issll-is802-framework-03> March 1998 <draft-
        ietf-issll-is802-framework-04>

   [6]  Wroclawski, J., "Specification of the Controlled-Load Network
        Element Service", RFC 2211, September 1997

   [7]  Schenker, S., Partridge, C., Guerin, R., "Specification of
        Guaranteed Quality of Service", RFC 2212 September 1997

   [8] "Draft Standard
        "IEEE Standards for Local and Metropolitan Area Networks: for
        Virtual Bridged Local Area Networks",
        October 1997, March 1998, IEEE P802.1Q/D8 Draft
        Standard P802.1Q/D10

   [9]  Shenker, S., Wroclawski, J., "General Characterization
        Parameters for Integrated Service Network Elements", RFC 2215,
        September 1997

   [10] D.Hoffman et al. Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F., Speer, M.,
        "SBM (Subnet Bandwidth Manager): A Proposal Protocol for Admission
        Control over Ethernet", IEEE 802-style Networks", Internet Draft, November 1997
        <draft-ietf-issll-sbm-05>

9. March
        1998 <draft-ietf-issll-sbm-06>

   [11] Wroclawski, J., "The use of RSVP with IETF Integrated Services",
        RFC 2210, September 1997.

   Seaman,Smith,Crawley,Wroclawski.  Expires February 1999       [Page
15]
   8.  Security Considerations

   Any use of QoS requires examination of security considerations
   because it leaves the possibility open for denial of service or theft
   of service attacks. This memo document introduces no new security issues
   on top of those discussed in the companion ISSLL documents [5] and
   [10].

10.  Any use of these service mappings assumes that all requests
   for service are authenticated appropriately.

   9. Acknowledgments

   This document draws heavily on the work of the ISSLL WG of the IETF
   and the IEEE P802.1 Interworking Task Group.

11.

   9.  Authors' addresses Addresses

        Mick Seaman
        3Com Corp.
        5400 Bayfront Plaza
        Santa Clara CA 95052-8145
        USA
        +1 (408) 764 5000
        mick_seaman@3com.com

        Andrew Smith
        Extreme Networks
        10460 Bandley Drive
        Cupertino CA 95014
        USA
        +1 (408) 863 2821
        andrew@extremenetworks.com

        Eric Crawley
        Argon Networks
        25 Porter Rd.
        Littleton MA 01460
        USA
        +1 (508) (978) 486 0665
esc@argon-net.com
        esc@argon.com

   Seaman,Smith,Crawley,Wroclawski.  Expires February 1999       [Page
16]
        John Wroclawski
        MIT Laboratory for Computer Science
        545 Technology Sq.
        Cambridge, MA  02139
        USA
        +1 (617) 253 7885
        jtw@lcs.mit.edu

   Table of Contents

   1 Introduction .................................................    2
   2 Flow Identification and Traffic Class Selection ..............    3
   3 Choosing a flow's IEEE 802 user_priority class ...............    5
   3.1 Context of admission control and delay bounds ..............    6
   3.2 Default service mappings ...................................    7
   3.3 Discussion .................................................    9
   4  Computation  of   integrated   services   characterization
        parameters by IEEE 802 devices ............................   10
   4.1 General characterization parameters ........................   10
   4.2 Parameters to implement Guaranteed Service .................   11
   4.3 Parameters to implement Controlled Load ....................   12
   4.4 Parameters to implement Best Effort ........................   12
   5 Merging of RSVP/SBM objects ..................................   13
   6 Applicability of these service mappings ......................   13
   7 References ...................................................   15
   8 Security Considerations ......................................   16
   9 Authors' Addresses ...........................................   16

   Seaman,Smith,Crawley,Wroclawski.  Expires February 1999       [Page
17]
         Copyright (C) The Internet Society (date).  All Rights
Reserved.

         This document and translations of it may be copied and
furnished
         to others, and derivative works that comment on or otherwise
         explain it or assist in its implmentation may be prepared,
copied,
         published and distributed, in whole or in part, without
         restriction of any kind, provided that the above copyright
notice
         and this paragraph are included on all such copies and
derivative
         works.  However, this document itself may not be modified in
any
         way, such as by removing the copyright notice or references to
the
         Internet Society or other Internet organizations, except as
needed
         for the purpose of developing Internet standards in which case
the
         procedures for copyrights defined in the Internet Standards
         process must be followed, or as required to translate it into
         languages other than English.

         The limited permissions granted above are perpetual and will
not
         be revoked by the Internet Society or its successors or
assigns.

         This document and the information contained herein is provided
on
         an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
         ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
         IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF
         THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED
         WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.

   Seaman,Smith,Crawley,Wroclawski.  Expires February 1999       [Page
18]