rfc2815.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 956 行 · 第 1/3 页

Network Working Group                                          M. Seaman
Request for Comments: 2815                                       Telseon
Category: Standards Track                                       A. Smith
                                                        Extreme Networks
                                                              E. Crawley
                                                     Unisphere Solutions
                                                           J. Wroclawski
                                                                 MIT LCS
                                                                May 2000


            Integrated Service Mappings on IEEE 802 Networks

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  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.1D MAC Bridges (switches).  It describes parameter
   mappings for supporting Controlled Load and Guaranteed Service using
   the inherent capabilities of relevant IEEE 802 technologies and, in
   particular, 802.1D-1998 queuing features in switches.

   These mappings are one component of the Integrated Services over IEEE
   802 LANs framework.















Seaman, et al.              Standards Track                     [Page 1]

RFC 2815         Int-Serv Mappings on IEEE 802 Networks         May 2000


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 ..................11
   4.4 Parameters to implement Best Effort ......................12
   5 Merging of RSVP/SBM objects ................................12
   6 Applicability of these service mappings ....................13
   7 References .................................................14
   8 Security Considerations ....................................15
   9 Acknowledgments ............................................15
   10 Authors' Addresses ........................................16
   11 Full Copyright Statement ..................................17

1.  Introduction

   The IEEE 802.1 Interworking Task Group has 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, IEEE 802.1D-1990 [802.1D-ORIG], the
   updated IEEE 802.1D-1998 [802.1D] proposes differential traffic class
   queuing in switches. The IEEE 802.1Q specification [802.1Q] extends
   the capabilities of Ethernet/802.3 media to carry a traffic class
   indicator, or "user_priority" field, within data frames.

   The availability of this differential traffic queuing, together with
   additional mechanisms to provide admission control and signaling,
   allows IEEE 802 networks to support a close approximation of the IETF
   Integrated Services capabilities [CL][GS]. This document describes
   methods for mapping the service classes and parameters of the IETF
   model into IEEE 802.1D network parameters.  A companion document
   [SBM] 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;
   this framework is described fully in [IS802FRAME].

   Within this document, Section 2 describes the method by which end
   systems and routers bordering the IEEE Layer-2 cloud learn what
   traffic class should be used for each data flow's packets.  Section 3
   describes the approach recommended to map IP-level traffic flows to



Seaman, et al.              Standards Track                     [Page 2]

RFC 2815         Int-Serv Mappings on IEEE 802 Networks         May 2000


   IEEE traffic classes within the Layer 2 network.  Section 4 describes
   the 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 describe the
   applicability of all of the above to different layer 2 network
   topologies.

2.  Flow Identification and Traffic Class Selection

   One model for supporting integrated services over specific link
   layers treats layer-2 devices very much as a special case of routers.
   In this model, switches and other devices along the data path make
   packet handling decisions based on the RSVP flow and filter
   specifications, and use these specifications to classify the
   corresponding data packets. The specifications could either be used
   directly, or could be used indirectly by mapping each RSVP session
   onto a layer-2 construct such as an ATM virtual circuit.

   This approach is inappropriate for use in the IEEE 802 environment.
   Filtering to the per-flow level becomes expensive with increasing
   switch speed; devices with such filtering capabilities are likely to
   have a very similar implementation complexity to IP routers, and may
   not make use of simpler mechanisms such as 802.1D user priority.

   The Integrated Services over IEEE 802 LANs framework [IS802FRAME] and
   this document use an "aggregated flow" approach based on use of
   layer-2 traffic classes. In this model, each arriving flow is
   assigned to one of the available classes for the duration of the flow
   and traverses the 802 cloud in this class.  Traffic flows requiring
   similar service are grouped together into a single class, while the
   system's admission control and class selection rules ensure that the
   service requirements for flows in each of the classes are met.  In
   many situations this is a viable intermediate point between no QoS
   control and full router-type integrated services. The approach can
   work effectively even with switches implementing only the simplest
   differential traffic classification capability specified in the
   802.1D model.  In the aggregated flow model, traffic arriving at the
   boundary of a layer-2 cloud is tagged by the 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 correspondence between IP-level traffic flows and
   link-level classes?" and  "how is this correspondence conveyed to the
   boundary devices that must mark the data frames?"

   One approach to answering these questions would be for the meanings
   of the classes to be universally defined. This document would then
   standardize the meanings of a set of classes; e.g., 1 = best effort,
   2 = 100 ms peak delay target, 3 = 10 ms peak delay target, 4 = 1 ms



Seaman, et al.              Standards Track                     [Page 3]

RFC 2815         Int-Serv Mappings on IEEE 802 Networks         May 2000


   peak delay target, etc. The meanings of these universally defined
   classes could then be encoded directly in end stations, and the
   flow-to-class mappings computed directly in these devices.

   This universal definition approach would be simple to implement, but
   is too rigid to map the wide range of possible user requirements onto
   the limited number of available 802.1D classes. The model described
   in [IS802FRAME] uses a more flexible mapping: clients ask "the
   network" which user_priority traffic class to use for a given traffic
   flow, as categorized by its flow-spec and layer-2 endpoints. The
   network provides a value back to the requester that is appropriate
   considering 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.

   In the current model it is assumed that all data packets of a flow
   are assigned to the same traffic class for the duration of the flow:
   the characteristics of the MAC service, as defined by Clause 6 of
   [802.1D], then ensure the ordering of the data packets of the flow
   between adjacent Layer 3 routers. This is usually desirable to avoid
   potential re-ordering problems as discussed in [IS802FRAME] and [CL].
   Note that there are some scenarios where it might be desirable to
   send conforming data traffic in one traffic class and non-conforming
   traffic for the same flow in a different, lower traffic class: such a
   division into separate traffic classes is for future study.  When a
   new session or "flow" requiring QoS support is created, a client must
   ask "the network" which traffic class (IEEE 802 user_priority) to use
   for a given traffic flow, so that it can label the packets of the
   flow as it places them into the network.  A request/response protocol
   is needed between client and network to return this information. 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 transaction in a timely way and
   reducing the exposure to changing conditions that could occur if
   clients cached the knowledge for extensive periods. A set of
   extensions to the RSVP protocol for communicating this information
   have been defined [SBM].

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




Seaman, et al.              Standards Track                     [Page 4]

RFC 2815         Int-Serv Mappings on IEEE 802 Networks         May 2000


     1. Which of the available traffic classes would be appropriate for
        this flow?

        In general, a newly arriving flow might be assigned to a number
        of classes. For example, if 10ms of delay is acceptable, the
        flow could potentially be assigned to either a 10ms delay class
        or a 1ms delay class. This packing problem is quite difficult to
        solve if the target parameters of the classes are allowed to
        change dynamically as flows arrive and depart.  It is quite
        simple if the target parameters of each class is held fixed, and
        the class table is simply searched to find a class appropriate
        for the arriving flow.  This document adopts the latter
        approach.

     2. Of the appropriate traffic classes, which if any have enough
        capacity available to accept the new flow?

        This is the admission control problem. It is necessary to
        compare the level of traffic currently assigned to each class
        with the available level of network resources (bandwidth,
        buffers, etc), to ensure that adding the new flow to the class
        will not cause the class's performance to 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
        performance of lower-priority classes. The admission control
        algorithm for a system using the default 802 priority behavior
        must be reasonably sophisticated to provide acceptable results.

   If an acceptable class is found, the network returns the chosen
   user_priority value to the client.

   Note that the client may be an end station, a router at the edge of
   the layer 2 network, or a first switch acting as a proxy for a device
   that 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 generally be discouraged unless the device has a
   close tie-in with the network topology and resource allocation
   policies. It may, however, work acceptably in cases where there is
   known over-provisioning of resources.

3.  Choosing a flow's IEEE 802 user_priority class

   This section describes the method by which IP-level flows are mapped
   into appropriate IEEE user_priority classes. The IP-level services
   considered are Best Effort, Controlled Load, and Guaranteed Service.




Seaman, et al.              Standards Track                     [Page 5]

RFC 2815         Int-Serv Mappings on IEEE 802 Networks         May 2000


   The major issue is that admission control requests and application
   requirements are specified in terms of a multidimensional vector of
   parameters e.g., bandwidth, delay, jitter, service class.  This
   multidimensional space must be mapped onto a set of traffic classes
   whose default behavior 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
   enforce an absolute (quantifiable) delay bound for a traffic class,
   nor can it discriminate amongst Int-Serv flows within the aggregate
   in a traffic class. Therefore, it cannot provide the absolute control
   of packet loss and delay required for individual Int-Serv flows.

   To provide absolute control of loss and delay three things must
   occur:

   (1) The amount of bandwidth available to the QoS-controlled flows
       must be known, and the number of flows admitted to the network
       (allowed to use the bandwidth) must be limited.

   (2) A traffic 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 exceeding their Tspecs do not damage
       the quality of service delivered to in-Tspec QoS controlled
       flows. This mechanism could be part of the traffic scheduler, or
       it could be a separate policing mechanism.

   For IEEE 802 networks, the first function (admission control) is
   provided by a Subnet Bandwidth Manager, as discussed below. We use
   the link-level user_priority 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