[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 rfc2815                                           
Internet Draft                                        Mick Seaman
Expires May 1998                                             3Com
draft-ietf-issll-is802-svc-mapping-01.txt            Andrew Smith
                                                 Extreme Networks
                                                     Eric Crawley
                                                   Argon Networks
                                                    November 1997


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



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

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 queuing features in switches [2].

These mappings fit in with the ISSLL over 802 LANs framework described
in [5].



Seaman, Smith, Crawley      Expires May 1998            [Page 1]


INTERNET DRAFT           Int-Serv over IEEE 802            November 1997


1. Introduction

The IEEE 802.1 Interworking Task Group has recently agreed on
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 [1], the update P802.1p [2] proposes differential
traffic class queuing and access to media on the basis of a
"user_priority" signaled in frames.

In this document we summarise the model for selecting traffic classes
described in the framework [5] and how we identify those classes in
data-link layer devices.  We then discuss how to map the existing 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 the use of RSVP/SBM signaling protocols and
discuss the applicability of all of the above in some different network
topologies.

It is recommended that readers be familiar with the framework in which
these mappings are expected to be used - this is described fully in [5].


2. Selecting traffic classes

One fundamental question is "who gets to decide what the classes mean
and who gets access to them?" One approach would be for the meanings of
the classes to be "well-known": we would then need to standardise a set
of classes e.g. 1 = best effort, 2 = controlled- load, 3 = guaranteed
(loose delay bound, high bandwidth), 4 = guaranteed (slightly tighter
delay) etc. The values to encode in such a table in end stations, in
isolation from the network to which they are connected, is
problematical: one approach could be to define one user_priority value
per int-serv service and leave it at that (reserving the rest 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 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 requester which is appropriate to
the current network topology, load conditions, other admitted flows etc.
The task of configuring switches with this mapping (e.g. through network
management, a switch-switch protocol or via some network-wide QoS-
mapping directory service) is an order of magnitude less complex than
performing the same function 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 to be upgraded with new
queuing algorithms etc. and can be provided with new mappings at this
time.



Seaman, Smith, Crawley      Expires May 1998            [Page 2]


INTERNET DRAFT           Int-Serv over IEEE 802            November 1997


Given the need for a new session or "flow" requiring some QoS support, a
client then needs answers to the following questions:

1. which traffic class do I add this flow to?
   The client needs to know how to label the packets of the flow as it
   places them into the network.

2. who do I ask/tell?
   The client asks "the network" which user_priority traffic class to
   use for a given traffic flow.

3. how do I ask/tell them?
   A request/response protocol is needed between client and network: in
   fact, the request can be piggy-backed onto an admission control
   request and the response can be piggy-backed onto an admission
   control acknowledgment: this "one pass" assignment has the benefit of
   completing the admission control in a timely way and reducing the
   exposure to changing conditions which could occur if clients cached
   the knowledge for extensive periods. ISSLL WG has defined extensions
   to the RSVP protocol for communicating this information [10].

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

1. to which traffic class do I add this flow?
   This is a packing problem, difficult to solve in general, but many
   simplifying assumptions can be made: presumably some simple form of
   allocation can be done without a more complex scheme able to
   dynamically shift flows around between classes.

2. which traffic class has worst-case parameters which meet the needs of
this flow?
   This might be an ordering/comparison problem: which of two service
   classes is "better" than 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) in a simple
   manner. If any classes are implemented in the future that cannot be
   simply ranked then the issue can be finessed by either 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 or a first
switch which may be acting as a proxy for a client which does not
participate in these protocols for whatever reason. Note also that a
device e.g. a server or router, may choose to implement both the
"client" as well as the "network" portion of this model so that it can
select its own user_priority values: such an implementation would,



Seaman, Smith, Crawley      Expires May 1998            [Page 3]


INTERNET DRAFT           Int-Serv over IEEE 802            November 1997


however, be discouraged unless the device really does have a close tie-
in with the network topology and resource allocation policies but would
work 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 and use them to classify the
corresponding data packets. However, filtering 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
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 this is the minimum flow
classification capability required of switches in the "ISSLL over IEEE
802 networks" model.





4. Mappings of int-serv characterisation parameters for IEEE 802 devices

It is assumed that admission control will be applied when deciding
whether or not to admit a new flow through a given network element and
that a device sending onto a link will be proxying the parameters and
admission control decisions on behalf of that link: this process will
require the device to be able to determine (by estimation, measurement
or calculation) several parameters. It is assumed that details of the
potential flow are provided to the device by some means (e.g. a
signaling protocol, network management). The service definition
specifications themselves provide some implementation guidance as to how
to calculate some of these quantities.

The accuracy of calculation of these parameters may not be very
critical: indeed it is an assumption of the use of this model by
relatively simple switches ("Class I" according to the taxonomy
presented in [5]) that they merely provide values to describe the device
and admit flows conservatively.

4.1 General characterisation parameters




Seaman, Smith, Crawley      Expires May 1998            [Page 4]


INTERNET DRAFT           Int-Serv over IEEE 802            November 1997


There are some general parameters [9] that a device will need 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 the
path of the flow.
* minimum latency

4.2 Parameters to implement Guaranteed Service

A network element 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 would include any access latency bound to the outgoing link as well
as propagation delay across that link.
* 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.
* 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.
* Transmit resources that 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 be able to determine 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 a network element to implement best effort service there are no
explicit parameters that need to be characterised.








Seaman, Smith, Crawley      Expires May 1998            [Page 5]


INTERNET DRAFT           Int-Serv over IEEE 802            November 1997


5. Mapping to IEEE 802 user_priority

There are many options available for mapping aggregations of flows
described by int-serv service models (Best Effort, Controlled Load, and
Guaranteed are the services considered here) onto user_priority classes.
The following mappings are presented as an example set in order to
stimulate experimentation in this area - they may be refined in future
editions 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
service model are met. In order to reduce the administrative problems,
such a mapping table is held by *switches* (and routers if desired) but
generally not by end-station hosts and 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).

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 sorts of
traffic categories they were likely to encounter and how to allocate
those requests into traffic classes: such mechanisms are for further
study.

        user_priority   Service

          0             Default, assumed to 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 of mappings, all traffic that uses the Controlled
Load service is mapped to a single user_priority whilst that for
Guaranteed Service is placed into one of two user_priority classes with
different delay bounds. Unreserved best effort traffic is mapped to
another.

The use of classes 4, 5 and 6 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 is "greater" than CL
although those proposed here have the advantage that, for transit



Seaman, Smith, Crawley      Expires May 1998            [Page 6]


INTERNET DRAFT           Int-Serv over IEEE 802            November 1997


through 802.1p switches with only two-level strict priority queuing,
they both get "high priority" treatment (the 802.1p default split is 0-3
and 4-7 for a device with 2 queues). The choice of delay bound is also
arbitrary but potentially very significant: this can lead to a much more
efficient allocation of resources as well as greater (though still not
very good) isolation between flows.

The "less than best effort" class might be useful e.g. for devices that
wish to "penalty tag" all of the data of flows that have abused the
network by excessively exceeding their Allocation or profile: these
might be preferentially discarded by a downstream device.  It would
probably be a bad idea to just mark some of the packets of a 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* by any current
int-serv models but is under study e.g. in the IETF's Differential
Services WG.

The advantage to this approach is that it puts some real delay bounds on
the Guaranteed Service without adding any additional complexity to the
other services.  It still ignores the amount of *bandwidth* available
for each class. This should behave reasonably well as long as all
traffic for CL and GS flows does not exceed any 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
that flows will in general be well- behaved. In addition, this mapping
still leaves room for future service models.

Expanding the number of classes for CL service is not as appealing since
there is no need to map to a particular delay bound.  There may be cases
where an administrator might map CL onto more classes for particular
bandwidths or policy levels.  It may also be desirable to further
subdivide CL traffic in cases where it is frequently non-conformant for
certain applications.



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

For the example mappings proposed in this memo, the merging device
should merge to the "lowest" priority value of the values received in
TCLASS objects of the PATH/RESV messages where "lowest" is defined as
follows:
                Lowest  ------->   Highest
                  1, 2, 0, 3, 4, 5, 6, 7



Seaman, Smith, Crawley      Expires May 1998            [Page 7]


INTERNET DRAFT           Int-Serv over IEEE 802            November 1997


Note: this counter-intuitive ordering is an artifact of the *default*
relative treatment of user_priority values in the IEEE 802.1p
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. Applicability of these service mappings

Switches using layer-2-only standards (e.g. 802.1D, 802.1p) need to
inter-operate with routers and layer-3 switches. Wide deployment of such
802.1p 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
* 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 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 other flows
or from best effort traffic during their passage through the network.

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.

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.



Seaman, Smith, Crawley      Expires May 1998            [Page 8]


INTERNET DRAFT           Int-Serv over IEEE 802            November 1997


8. References


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

[2] "Supplement to MAC Bridges: Traffic Class Expediting and
        Dynamic Multicast Filtering", September 1997, IEEE P802.1p/D8

[3] "Integrated Services in the Internet Architecture: an Overview"
        RFC1633, June 1994

[4] "Resource Reservation Protocol (RSVP) - Version 1 Functional
        Specification", RFC 2205, September 1997

[5] "A Framework for Providing Integrated Services Over Shared and
        Switched LAN Technologies", Internet Draft, November 1997
        <draft-ietf-issll-is802-framework-03>

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

[7] "Specification of Guaranteed Quality of Service",
        RFC 2212 September 1997

[8] "Draft Standard for Virtual Bridged Local Area Networks",
        October 1997, IEEE P802.1Q/D8

[9] "General Characterization Parameters for Integrated
        Service Network Elements", RFC 2215, September 1997

[10] D.Hoffman et al. "SBM (Subnet Bandwidth Manager): A Proposal for
        Admission Control over Ethernet", Internet Draft, November 1997
        <draft-ietf-issll-sbm-05>

9. Security Considerations

This memo introduces no new security issues on top of those discussed in
the companion ISSLL documents [5] and [10].




10. Acknowledgments

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





Seaman, Smith, Crawley      Expires May 1998            [Page 9]


INTERNET DRAFT           Int-Serv over IEEE 802            November 1997


11. Authors' 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) 486 0665
esc@argon-net.com


























Seaman, Smith, Crawley      Expires May 1998           [Page 10]