draft-ietf-issll-is802-svc-mapping-01.txt   draft-ietf-issll-is802-svc-mapping-02.txt 
Internet Draft Mick Seaman Internet Draft M. Seaman
Expires May 1998 3Com Expires February 1999 3Com
draft-ietf-issll-is802-svc-mapping-01.txt Andrew Smith draft-ietf-issll-is802-svc-mapping-02.txt A. Smith
Extreme Networks Extreme Networks
Eric Crawley E. Crawley
Argon Networks Argon Networks
November 1997 J. Wroclawski
MIT LCS
August 1998
Integrated Service Mappings on IEEE 802 Networks Integrated Service Mappings on IEEE 802 Networks
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet 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 Drafts as reference material or to cite them other than as a "working
draft" or "work in progress." draft" or "work in progress."
To view the entire list of current Internet-Drafts, please check the To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast). This document is a product of the IS802 ftp.isi.edu (US West Coast).
subgroup of the ISSLL working group of the Internet Engineering Task
Force. Comments are solicited and should be addressed to the working This document is a product of the IS802 subgroup of the ISSLL working
group's mailing list at issll@mercury.lcs.mit.edu and/or the authors. 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 Abstract
This document describes mappings of IETF Integrated Services over LANs This document describes mappings of IETF Integrated Services over
built from IEEE 802 network segments which may be interconnected by IEEE LANs built from IEEE 802 network segments which may be interconnected
802.1 MAC Bridges (switches) [1][2]. by IEEE 802.1 MAC Bridges (switches) [1][2].
It describes parameter mappings for supporting Controlled Load [6] and 9
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 9 Seaman,Smith,Crawley,Wroclawski. Expires February 1999
in [5]. It describes parameter mappings for supporting Controlled Load [6]
and Guaranteed Service [7] using the inherent capabilities of
relevant IEEE 802 technologies and, in particular, 802.1D-1998
queuing features in switches [2].
These mappings are one component of the Integrated Services over IEEE
802 LANs framework described in [5].
1. Introduction 1. Introduction
The IEEE 802.1 Interworking Task Group has recently agreed on The IEEE 802.1 Interworking Task Group has developed a set of
enhancements to the basic MAC Service provided in Bridged Local Area enhancements to the basic MAC Service provided in Bridged Local Area
Networks (a.k.a. "switched LANs"). As a supplement to the original IEEE Networks (a.k.a. "switched LANs"). As a supplement to the original
MAC Bridges standard [1], the update P802.1p [2] proposes differential IEEE MAC Bridges standard, IEEE 802.1D-1990 [1], the updated IEEE
traffic class queuing and access to media on the basis of a 802.1D-1998 [2] proposes differential traffic class queuing in
"user_priority" signaled in frames. switches and extends the capabilities of Ethernet/802.3 media to
carry a traffic class indicator, or "user_priority" field, within
data frames [8].
In this document we summarise the model for selecting traffic classes The availability of this differential traffic queuing, together with
described in the framework [5] and how we identify those classes in additional mechanisms to provide admission control and signaling,
data-link layer devices. We then discuss how to map the existing IETF- allows IEEE 802 networks to support a close approximation of the
defined Integrated Services onto the ISSLL 802 traffic class model, IETF-defined Integrated Services capabilities [6][7]. This document
propose an example of particular choices of traffic class, discuss some describes methods for mapping the service classes and parameters of
particular issues with the use of RSVP/SBM signaling protocols and the IETF model into IEEE 802.1D network parameters. A companion
discuss the applicability of all of the above in some different network 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; this framework is described fully in [5].
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
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. topologies.
It is recommended that readers be familiar with the framework in which 9
these mappings are expected to be used - this is described fully in [5].
2. Selecting traffic classes 9 Seaman,Smith,Crawley,Wroclawski. Expires February 1999
2. Flow Identification and Traffic Class Selection
One fundamental question is "who gets to decide what the classes mean One model for supporting integrated services over specific link
and who gets access to them?" One approach would be for the meanings of layers treats layer-2 devices very much as a special case of routers.
the classes to be "well-known": we would then need to standardise a set In this model, switches and other devices along the data path make
of classes e.g. 1 = best effort, 2 = controlled- load, 3 = guaranteed packet handling decisions based on the RSVP flow and filter
(loose delay bound, high bandwidth), 4 = guaranteed (slightly tighter specifications, and use these specifications to classify the
delay) etc. The values to encode in such a table in end stations, in corresponding data packets. The specifications could either be used
isolation from the network to which they are connected, is directly, or could be used indirectly by mapping each RSVP session
problematical: one approach could be to define one user_priority value onto a layer-2 construct such as an ATM virtual circuit.
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 This approach is inappropriate for use in the IEEE 802 environment.
"the network" which user_priority traffic class to use for a given Filtering to the per-flow level becomes expensive with increasing
traffic flow, as categorised by its flow-spec and layer-2 endpoints. The switch speed; devices with such filtering capabilities are likely to
network provides a value back to the requester which is appropriate to have a very similar implementation complexity to IP routers, and may
the current network topology, load conditions, other admitted flows etc. not make use of simpler mechanisms such as 802.1D user priority.
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.
Given the need for a new session or "flow" requiring some QoS support, a The Integrated Services over IEEE 802 LANs framework [5] and this
client then needs answers to the following questions: 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 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 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.
1. which traffic class do I add this flow to? In the aggregated flow model, traffic arriving at the boundary of a
The client needs to know how to label the packets of the flow as it layer 2 cloud is tagged by the boundary device (end host or border
places them into the network. 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?"
2. who do I ask/tell? One approach to answering these questions would be for the meanings
The client asks "the network" which user_priority traffic class to of the classes to be universally defined. This document would then
use for a given traffic flow. standardise 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
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.
3. how do I ask/tell them? Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page
A request/response protocol is needed between client and network: in 3]
fact, the request can be piggy-backed onto an admission control This universal definition approach would be simple to implement, but
request and the response can be piggy-backed onto an admission is too rigid to map the wide range of possible user requirements onto
control acknowledgment: this "one pass" assignment has the benefit of the limited number of available 802.1D classes. The model described
completing the admission control in a timely way and reducing the in [5] uses a more flexible mapping: clients ask "the network" which
exposure to changing conditions which could occur if clients cached user_priority traffic class to use for a given traffic flow, as
the knowledge for extensive periods. ISSLL WG has defined extensions categorised by its flow-spec and layer-2 endpoints. The network
to the RSVP protocol for communicating this information [10]. 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.
The network (i.e. the first network element encountered downstream from In this model, when a new session or "flow" requiring QoS support is
the client) must then answer the following questions: created, a client must ask "the network" which user_priority traffic
class 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[10].
1. to which traffic class do I add this flow? The network (i.e. the first network element encountered downstream
This is a packing problem, difficult to solve in general, but many from the client) must then answer the following questions:
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 1. Which of the available traffic classes would be appropriate for
this flow? this flow?
This might be an ordering/comparison problem: which of two service In general, a newly arriving flow might be assigned to a number
classes is "better" than the other? Again, we can make this tractable of classes. For example, if 10ms of delay is acceptable, the
by observing that all of the current int- serv classes can be ranked flow could potentially be assigned to either a 10ms delay class
(best effort <= Controlled Load <= Guaranteed Service) in a simple or a 1ms delay class. This packing problem is quite difficult to
manner. If any classes are implemented in the future that cannot be solve if the target parameters of the classes are allowed to
simply ranked then the issue can be finessed by either a priori change dynamically as flows arrive and depart. It is quite
knowledge about what classes are supported or by configuration. simple if the target parameters of each class is held fixed, and
the class table is simply searched to find a class appropriate
and return the chosen user_priority value to the client. Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page
4]
for the arriving flow. This document adopts the latter approach.
Note that the client may be either an end station, router or a first 2. Of the appropriate traffic classes, which if any have enough
switch which may be acting as a proxy for a client which does not capacity available to accept the new flow?
participate in these protocols for whatever reason. Note also that a This is the admission control problem. It is necessary to
device e.g. a server or router, may choose to implement both the compare the level of traffic currently assigned to each class
"client" as well as the "network" portion of this model so that it can with the available level of network resources (bandwidth,
select its own user_priority values: such an implementation would, 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.
however, be discouraged unless the device really does have a close tie- If an acceptable class is found, the network returns the chosen
in with the network topology and resource allocation policies but would user_priority value to the client.
work in some cases where there is known over- provisioning of resources.
3. Flow Identification 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.
Some other models for int-serv over lower-layers treat layer-2 switches 3. Choosing a flow's IEEE 802 user_priority class
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 This section describes the method by which IP-level flows are mapped
"user_priority" as a viable intermediate point between no QoS and full into appropriate IEEE user_priority classes. The IP-level services
router-type integrated services and this is the minimum flow considered are Best Effort, Controlled Load, and Guaranteed Service.
classification capability required of switches in the "ISSLL over IEEE
802 networks" model.
4. Mappings of int-serv characterisation parameters for IEEE 802 devices 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 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
It is assumed that admission control will be applied when deciding Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page
whether or not to admit a new flow through a given network element and 5]
that a device sending onto a link will be proxying the parameters and enforce an absolute (quantifiable) delay bound for a traffic class,
admission control decisions on behalf of that link: this process will nor can it discriminate amongst Int-Serv flows within the aggregate
require the device to be able to determine (by estimation, measurement in a traffic class. Therefore, it cannot provide the absolute control
or calculation) several parameters. It is assumed that details of the of packet loss and delay required for individual Int-Serv flows.
potential flow are provided to the device by some means (e.g. a
signaling protocol, network management). The service definition To provide absolute control of loss and delay three things must
specifications themselves provide some implementation guidance as to how occur:
to calculate some of these quantities.
(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 provide policing (function three), policing for
IEEE networks is generally implemented at the edge of 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. Thus, any attempt to quantify the delay bounds expected by a
given traffic class has to made in the context of the admission
control elements. Section 6 of the framework [5] provides for two
different models of admission control - centralized or distributed
Bandwidth Allocators.
It is important to note that in this approach it is the admission
Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page
6]
control algorithm that determines which of the Int-Serv services is
being offered. Given a 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 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 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 The accuracy of calculation of these parameters may not be very
critical: indeed it is an assumption of the use of this model by critical; in some cases loose estimates are all that is required to
relatively simple switches ("Class I" according to the taxonomy provide a useful service. This is important in the IEEE 802 case,
presented in [5]) that they merely provide values to describe the device where it will be virtually impossible to compute parameters
and admit flows conservatively. 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.
4.1 General characterisation parameters 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 There are some general parameters [9] that a device will need to use
and/or supply for all service types: and/or supply for all service types:
* Ingress link * 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 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).
A network element must be able to determine the following parameters * available path bandwidth: updated hop-by-hop by any device along
[7]: the path of the flow.
* Constant delay bound through this device (in addition to any value * minimum latency
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 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.
A network element must be able to determine the following parameters 4.2. Parameters to implement Guaranteed Service
which can be extracted from [6]:
* Receive resources that would need to be associated with this flow A network element supporting the Guaranteed Service must be able to
(e.g. buffering) if it were to be admitted. determine the following parameters [7]:
* 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 * 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.
For a network element to implement best effort service there are no * Rate-proportional delay bound through this device and up to the
explicit parameters that need to be characterised. 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.
5. Mapping to IEEE 802 user_priority * 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.
There are many options available for mapping aggregations of flows Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page
described by int-serv service models (Best Effort, Controlled Load, and 11]
Guaranteed are the services considered here) onto user_priority classes. * Transmit resources that would need to be associated with this
The following mappings are presented as an example set in order to flow (e.g. buffering, bandwidth, constant- and rate-proportional
stimulate experimentation in this area - they may be refined in future delay bounds) if it were to be admitted. These values are used
editions of this memo. Note, this does not dictate what by the admission control algorithm to decide whether a new flow
mechanisms/algorithms a network element (e.g. an Ethernet switch) needs can be accepted by the device.
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 The exported characterization parameters for this service should be
implemented that serviced requests from clients e.g. traffic_class = reported as accurately as possible. If estimations or approximations
getQoSbyName("H.323 video") and notified switches of what sorts of are used, they should err in whatever direction causes the user to
traffic categories they were likely to encounter and how to allocate receive better performance than requested. For example, the C and D
those requests into traffic classes: such mechanisms are for further error terms should overestimate delay, rather than underestimate it.
study.
user_priority Service 4.3. Parameters to implement Controlled Load
0 Default, assumed to be Best Effort A network element implementing the Controlled Load service must be
1 Background, "less than" Best Effort able to determine the following [6]:
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 * Receive resources that would need to be associated with this
flow (e.g. buffering) if it were to be admitted. These values
are used by the admission control algorithm to decide whether a
new flow can be accepted by the device.
With this example set of mappings, all traffic that uses the Controlled * Transmit resources that would need to be associated with this
Load service is mapped to a single user_priority whilst that for flow (e.g. buffering) if it were to be admitted. These values
Guaranteed Service is placed into one of two user_priority classes with are used by the admission control algorithm to decide whether a
different delay bounds. Unreserved best effort traffic is mapped to new flow can be accepted by the device.
another.
The use of classes 4, 5 and 6 for Controlled Load and Guaranteed Service The Controlled Load service does not export any service-specific
is somewhat arbitrary as long as they are increasing. Any two classes characterization parameters. Internal resource allocation estimates
greater than Best Effort can be used as long as GS is "greater" than CL should ensure that the service quality remains high when considering
although those proposed here have the advantage that, for transit the statistical aggregation of Controlled Load flows into 802 traffic
classes.
through 802.1p switches with only two-level strict priority queuing, 4.4. Parameters to implement Best Effort
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 For a network element that implements only best effort service there
wish to "penalty tag" all of the data of flows that have abused the are no explicit parameters that need to be characterized. Note that
network by excessively exceeding their Allocation or profile: these an integrated services aware network element that implements only
might be preferentially discarded by a downstream device. It would best effort service will set the "break bit" described in [11].
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 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page
the Guaranteed Service without adding any additional complexity to the 12]
other services. It still ignores the amount of *bandwidth* available 5. Merging of RSVP/SBM objects
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 Where reservations that use the SBM protocol's TCLASS object [10]
there is no need to map to a particular delay bound. There may be cases need to be merged, an algorithm needs to be defined that is
where an administrator might map CL onto more classes for particular consistent with the mappings to individual user_priority values in
bandwidths or policy levels. It may also be desirable to further use in the network.
subdivide CL traffic in cases where it is frequently non-conformant for
certain applications.
6. Merging of RSVP/SBM objects 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.
Where reservations that use the SBM protocol's TCLASS object [10] need For the example mappings proposed in this document, the merging
to be merged, an algorithm needs to be defined that is consistent with device should merge to the "highest" priority value of the values
the mappings to individual user_priority values in use in the network. received in TCLASS objects of the PATH/RESV messages where "highest"
is defined as follows:
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 Lowest -------> Highest
1, 2, 0, 3, 4, 5, 6, 7 1, 2, 0, 3, 4, 5, 6, 7
Note: this counter-intuitive ordering is an artifact of the *default* Note: this counter-intuitive ordering is an artifact of the *default*
relative treatment of user_priority values in the IEEE 802.1p relative treatment of user_priority values in the IEEE 802.1D
specification (see Annex H of [2]). If a device has been configured to specification (see Annex H of [2]). If a device has been configured
apply non-default treatment of user_priority values then it should to apply non-default treatment of user_priority values then it should
adjust this merging operation accordingly. adjust this merging operation accordingly.
7. Applicability of these service mappings 6. Applicability of these service mappings
Switches using layer-2-only standards (e.g. 802.1D-1990, 802.1D-
1998) need to inter-operate with routers and layer-3 switches. Wide
deployment of such 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
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 * only the edge devices are pure layer-2
Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page
13]
* every alternate device lacks layer-3 functionality * 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. * 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 Where int-serv flows pass through equipment which does not support
Integrated Services or 802.1p traffic management and which places all Integrated Services or 802.1D traffic management and which places all
packets through the same queuing and overload-dropping paths, it is packets through the same queuing and overload-dropping paths, it is
obvious that some of a flow's desired service parameters become more obvious that some of a flow's desired service parameters become more
difficult to support. In particular, the two integrated service classes difficult to support. In particular, the two integrated service
studied here, Controlled Load and Guaranteed Service, both assume that classes studied here, Controlled Load and Guaranteed Service, both
flows will be policed and kept "insulated" from mis-behaving other flows assume that flows will be policed and kept "insulated" from
or from best effort traffic during their passage through the network. 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 In addition, in order to provide a Guaranteed Service, *all*
elements along the path must participate in special treatment for switching elements along the path must participate in special
packets in such flows: where there is a "break" in guaranteed service, treatment for packets in such flows: where there is a "break" in
all bets are off. Thus, a network path that includes even a single guaranteed service, all bets are off. Thus, a network path that
switch transmitting onto a shared or half- duplex LAN segment is includes even a single switch transmitting onto a shared or half-
unlikely to be able to provide a very good approximation to Guaranteed duplex LAN segment is unlikely to be able to provide a very good
Service. For Controlled Load service, the requirements on the switches approximation to Guaranteed Service. For Controlled Load service, the
and link types are less stringent although it is still necessary to requirements on the switches and link types are less stringent
provide differential queueing and buffering in switches for CL flows although it is still necessary to provide differential queueing and
over best effort in order to approximate CL service. 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 Other approaches might be to pass more information between switches
about the capabilities of their neighbours and to route around non- about the capabilities of their neighbours and to route around non-
QoS-capable switches: such methods are for further study. And of course QoS-capable switches: such methods are for further study. And of
the easiest solution of all is to upgrade links and switches to higher course the easiest solution of all is to upgrade links and switches
capacities. to higher capacities.
8. References
[1] ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC Bridges" Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page
14]
7. References
[2] "Supplement to MAC Bridges: Traffic Class Expediting and [1] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993
Dynamic Multicast Filtering", September 1997, IEEE P802.1p/D8
[3] "Integrated Services in the Internet Architecture: an Overview" [2] "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", ISO/IEC Final CD
15802-3 IEEE P802.1D/D15, November 1997
[4] "Resource Reservation Protocol (RSVP) - Version 1 Functional [3] Clark, D. et al. "Integrated Services in the Internet
[4] Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource
Reservation Protocol (RSVP) - Version 1 Functional
Specification", RFC 2205, September 1997 Specification", RFC 2205, September 1997
[5] "A Framework for Providing Integrated Services Over Shared and [5] Ghanwani, A., Pace, W., Srinivasan, V., Smith, A., Seaman, M.,
Switched LAN Technologies", Internet Draft, November 1997 "A Framework for Providing Integrated Services Over Shared and
<draft-ietf-issll-is802-framework-03> Switched LAN Technologies", Internet Draft, March 1998 <draft-
ietf-issll-is802-framework-04>
[6] "Specification of the Controlled-Load Network Element Service", [6] Wroclawski, J., "Specification of the Controlled-Load Network
RFC 2211, September 1997 Element Service", RFC 2211, September 1997
[7] "Specification of Guaranteed Quality of Service", [7] Schenker, S., Partridge, C., Guerin, R., "Specification of
RFC 2212 September 1997 Guaranteed Quality of Service", RFC 2212 September 1997
[8] "Draft Standard for Virtual Bridged Local Area Networks", [8]
October 1997, IEEE P802.1Q/D8 "IEEE Standards for Local and Metropolitan Area Networks: for
Virtual Bridged Local Area Networks", March 1998, IEEE Draft
Standard P802.1Q/D10
[9] "General Characterization Parameters for Integrated [9] Shenker, S., Wroclawski, J., "General Characterization
Service Network Elements", RFC 2215, September 1997 Parameters for Integrated Service Network Elements", RFC 2215,
September 1997
[10] D.Hoffman et al. "SBM (Subnet Bandwidth Manager): A Proposal for [10] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F., Speer, M.,
Admission Control over Ethernet", Internet Draft, November 1997 "SBM (Subnet Bandwidth Manager): A Protocol for Admission
<draft-ietf-issll-sbm-05> Control over IEEE 802-style Networks", Internet Draft, March
1998 <draft-ietf-issll-sbm-06>
9. Security Considerations [11] Wroclawski, J., "The use of RSVP with IETF Integrated Services",
RFC 2210, September 1997.
This memo introduces no new security issues on top of those discussed in Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page
the companion ISSLL documents [5] and [10]. 15]
8. Security Considerations
10. Acknowledgments 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 document introduces no new security issues
on top of those discussed in the companion ISSLL documents [5] and
[10]. Any use of these service mappings assumes that all requests
for service are authenticated appropriately.
This document draws heavily on the work of the ISSLL WG of the IETF and 9. Acknowledgments
the IEEE P802.1 Interworking Task Group.
11. Authors' addresses This document draws heavily on the work of the ISSLL WG of the IETF
and the IEEE P802.1 Interworking Task Group.
9. Authors' Addresses
Mick Seaman Mick Seaman
3Com Corp. 3Com Corp.
5400 Bayfront Plaza 5400 Bayfront Plaza
Santa Clara CA 95052-8145 Santa Clara CA 95052-8145
USA USA
+1 (408) 764 5000 +1 (408) 764 5000
mick_seaman@3com.com mick_seaman@3com.com
Andrew Smith Andrew Smith
skipping to change at page 10, line 28 skipping to change at line 721
Cupertino CA 95014 Cupertino CA 95014
USA USA
+1 (408) 863 2821 +1 (408) 863 2821
andrew@extremenetworks.com andrew@extremenetworks.com
Eric Crawley Eric Crawley
Argon Networks Argon Networks
25 Porter Rd. 25 Porter Rd.
Littleton MA 01460 Littleton MA 01460
USA USA
+1 (508) 486 0665 +1 (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]
 End of changes. 82 change blocks. 
301 lines changed or deleted 582 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/