draft-ietf-issll-is802-svc-mapping-03.txt   rfc2815.txt 
Internet Draft M. Seaman Network Working Group M. Seaman
Expires May 1999 3Com Corp. Request for Comments: 2815 Telseon
draft-ietf-issll-is802-svc-mapping-03.txt A. Smith Category: Standards Track A. Smith
Standards Track Extreme Networks Extreme Networks
E. Crawley E. Crawley
Argon Networks Unisphere Solutions
J. Wroclawski J. Wroclawski
MIT LCS MIT LCS
November 1998 May 2000
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 specifies an Internet standards track protocol for the
documents of the Internet Engineering Task Force (IETF), its Areas, and Internet community, and requests discussion and suggestions for
its Working Groups. Note that other groups may also distribute working improvements. Please refer to the current edition of the "Internet
documents as Internet Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
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 learn the current status of any Internet-Draft, please check the Copyright Notice
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
This document is a product of the IS802 subgroup of the ISSLL working Copyright (C) The Internet Society (2000). All Rights Reserved.
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.
A revised version of this draft document will be submitted to the RFC Abstract
editor as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested. This document will
expire before February 1999. Distribution of this draft is unlimited.
Copyright (C) The Internet Society (1998). All Rights Reserved. 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.
Abstract These mappings are one component of the Integrated Services over IEEE
802 LANs framework.
This document describes mappings of IETF Integrated Services over LANs Table of Contents
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, in
particular, 802.1D-1998 queuing features in switches [2].
These mappings are one component of the Integrated Services over IEEE 1 Introduction ............................................... 2
802 LANs framework described in [5]. 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 1. Introduction
The IEEE 802.1 Interworking Task Group has developed a set of 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, IEEE 802.1D-1990 [1], the updated IEEE 802.1D-1998 IEEE MAC Bridges standard, IEEE 802.1D-1990 [802.1D-ORIG], the
[2] proposes differential traffic class queuing in switches and extends updated IEEE 802.1D-1998 [802.1D] proposes differential traffic class
the capabilities of Ethernet/802.3 media to carry a traffic class queuing in switches. The IEEE 802.1Q specification [802.1Q] extends
indicator, or "user_priority" field, within data frames [8]. 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 The availability of this differential traffic queuing, together with
additional mechanisms to provide admission control and signaling, allows additional mechanisms to provide admission control and signaling,
IEEE 802 networks to support a close approximation of the IETF-defined allows IEEE 802 networks to support a close approximation of the IETF
Integrated Services capabilities [6][7]. This document describes methods Integrated Services capabilities [CL][GS]. This document describes
for mapping the service classes and parameters of the IETF model into methods for mapping the service classes and parameters of the IETF
IEEE 802.1D network parameters. A companion document [10] describes a model into IEEE 802.1D network parameters. A companion document
signaling protocol for use with these mappings. It is recommended that [SBM] describes a signaling protocol for use with these mappings. It
readers be familiar with the overall framework in which these mappings is recommended that readers be familiar with the overall framework in
and signaling protocol are expected to be used; this framework is which these mappings and signaling protocol are expected to be used;
described fully in [5]. this framework is described fully in [IS802FRAME].
Within this document, Section 2 describes the method by which end Within this document, Section 2 describes the method by which end
systems and routers bordering the IEEE Layer-2 cloud learn what traffic systems and routers bordering the IEEE Layer-2 cloud learn what
class should be used for each data flow's packets. Section 3 describes traffic class should be used for each data flow's packets. Section 3
the approach recommended to map IP-level traffic flows to IEEE traffic describes the approach recommended to map IP-level traffic flows to
classes within the Layer 2 network. Section 4 describes the computation IEEE traffic classes within the Layer 2 network. Section 4 describes
of Characterization Parameters by the layer 2 network. The remaining the computation of Characterization Parameters by the layer 2
sections discuss some particular issues with the use of the RSVP/SBM network. The remaining sections discuss some particular issues with
signaling protocols, and describe the applicability of all of the above the use of the RSVP/SBM signaling protocols, and describe the
to different layer 2 network topologies. applicability of all of the above to different layer 2 network
topologies.
2. Flow Identification and Traffic Class Selection 2. Flow Identification and Traffic Class Selection
One model for supporting integrated services over specific link layers One model for supporting integrated services over specific link
treats layer-2 devices very much as a special case of routers. In this layers treats layer-2 devices very much as a special case of routers.
model, switches and other devices along the data path make packet In this model, switches and other devices along the data path make
handling decisions based on the RSVP flow and filter specifications, and packet handling decisions based on the RSVP flow and filter
use these specifications to classify the corresponding data packets. The specifications, and use these specifications to classify the
specifications could either be used directly, or could be used corresponding data packets. The specifications could either be used
indirectly by mapping each RSVP session onto a layer-2 construct such as directly, or could be used indirectly by mapping each RSVP session
an ATM virtual circuit. onto a layer-2 construct such as an ATM virtual circuit.
This approach is inappropriate for use in the IEEE 802 environment. This approach is inappropriate for use in the IEEE 802 environment.
Filtering to the per-flow level becomes expensive with increasing switch Filtering to the per-flow level becomes expensive with increasing
speed; devices with such filtering capabilities are likely to have a switch speed; devices with such filtering capabilities are likely to
very similar implementation complexity to IP routers, and may not make have a very similar implementation complexity to IP routers, and may
use of simpler mechanisms such as 802.1D user priority. not make use of simpler mechanisms such as 802.1D user priority.
The Integrated Services over IEEE 802 LANs framework [5] and this The Integrated Services over IEEE 802 LANs framework [IS802FRAME] and
document use an "aggregated flow" approach based on use of layer 2 this document use an "aggregated flow" approach based on use of
traffic classes. In this model, each arriving flow is assigned to one of layer-2 traffic classes. In this model, each arriving flow is
the available layer-2 classes, and traverses the 802 cloud in this assigned to one of the available classes for the duration of the flow
class. Traffic flows requiring similar service are grouped together and traverses the 802 cloud in this class. Traffic flows requiring
into a single class, while the system's admission control and class similar service are grouped together into a single class, while the
selection rules ensure that the service requirements for flows in each system's admission control and class selection rules ensure that the
of the classes are met. In many situations this is a viable service requirements for flows in each of the classes are met. In
intermediate point between no QoS control and full router-type many situations this is a viable intermediate point between no QoS
integrated services. The approach can work effectively even with control and full router-type integrated services. The approach can
switches implementing only the simplest differential traffic work effectively even with switches implementing only the simplest
classification capability specified in the 802.1D model. In the differential traffic classification capability specified in the
aggregated flow model, traffic arriving at the boundary of a layer-2 802.1D model. In the aggregated flow model, traffic arriving at the
cloud is tagged by the boundary device (end host or border router) with boundary of a layer-2 cloud is tagged by the boundary device (end
an appropriate traffic class, represented as an 802.1D "user_priority" host or border router) with an appropriate traffic class, represented
value. Two fundamental questions are "who determines the correspondence as an 802.1D "user_priority" value. Two fundamental questions are
between IP-level traffic flows and link-level classes?" and "how is "who determines the correspondence between IP-level traffic flows and
this correspondence conveyed to the boundary devices that must mark the link-level classes?" and "how is this correspondence conveyed to the
data frames?" boundary devices that must mark the data frames?"
One approach to answering these questions would be for the meanings of One approach to answering these questions would be for the meanings
the classes to be universally defined. This document would then of the classes to be universally defined. This document would then
standardise the meanings of a set of classes; e.g. 1 = best effort, 2 = standardize the meanings of a set of classes; e.g., 1 = best effort,
100 ms peak delay target, 3 = 10 ms peak delay target, 4 = 1 ms peak 2 = 100 ms peak delay target, 3 = 10 ms peak delay target, 4 = 1 ms
delay target, etc. The meanings of these universally defined classes peak delay target, etc. The meanings of these universally defined
could then be encoded directly in end stations, and the flow-to-class classes could then be encoded directly in end stations, and the
mappings computed directly in these devices. flow-to-class mappings computed directly in these devices.
This universal definition approach would be simple to implement, but is This universal definition approach would be simple to implement, but
too rigid to map the wide range of possible user requirements onto the is too rigid to map the wide range of possible user requirements onto
limited number of available 802.1D classes. The model described in [5] the limited number of available 802.1D classes. The model described
uses a more flexible mapping: clients ask "the network" which in [IS802FRAME] uses a more flexible mapping: clients ask "the
user_priority traffic class to use for a given traffic flow, as network" which user_priority traffic class to use for a given traffic
categorised by its flow-spec and layer-2 endpoints. The network provides flow, as categorized by its flow-spec and layer-2 endpoints. The
a value back to the requester that is appropriate considering the network provides a value back to the requester that is appropriate
current network topology, load conditions, other admitted flows, etc. considering the current network topology, load conditions, other
The task of configuring switches with this mapping (e.g. through network admitted flows, etc. The task of configuring switches with this
management, a switch-switch protocol or via some network-wide QoS- mapping (e.g., through network management, a switch-switch protocol
mapping directory service) is an order of magnitude less complex than or via some network-wide QoS-mapping directory service) is an order
performing the same function in end stations. Also, when new services of magnitude less complex than performing the same function in end
(or other network reconfigurations) are added to such a network, the stations. Also, when new services (or other network reconfigurations)
network elements will typically be the ones to be upgraded with new are added to such a network, the network elements will typically be
queuing algorithms etc. and can be provided with new mappings at this the ones to be upgraded with new queuing algorithms etc. and can be
time. provided with new mappings at this time.
In this model, when a new session or "flow" requiring QoS support is In the current model it is assumed that all data packets of a flow
created, a client must ask "the network" which traffic class (IEEE 802 are assigned to the same traffic class for the duration of the flow:
user_priority) to use for a given traffic flow, so that it can label the the characteristics of the MAC service, as defined by Clause 6 of
packets of the flow as it places them into the network. A [802.1D], then ensure the ordering of the data packets of the flow
request/response protocol is needed between client and network to return between adjacent Layer 3 routers. This is usually desirable to avoid
this information. The request can be piggy-backed onto an admission potential re-ordering problems as discussed in [IS802FRAME] and [CL].
control request and the response can be piggy-backed onto an admission Note that there are some scenarios where it might be desirable to
control acknowledgment. This "one pass" assignment has the benefit of send conforming data traffic in one traffic class and non-conforming
completing the admission control transaction in a timely way and traffic for the same flow in a different, lower traffic class: such a
reducing the exposure to changing conditions that could occur if clients division into separate traffic classes is for future study. When a
cached the knowledge for extensive periods. A set of extensions to the new session or "flow" requiring QoS support is created, a client must
RSVP protocol for communicating this information have been defined[10]. 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 network (i.e., the first network element encountered downstream
the client) must then answer the following questions: from the client) must then answer the following questions:
1. Which of the available traffic classes would be appropriate for this 1. Which of the available traffic classes would be appropriate for
flow? 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 In general, a newly arriving flow might be assigned to a number
available to accept the new flow? of classes. For example, if 10ms of delay is acceptable, the
This is the admission control problem. It is necessary to compare flow could potentially be assigned to either a 10ms delay class
the level of traffic currently assigned to each class with the or a 1ms delay class. This packing problem is quite difficult to
available level of network resources (bandwidth, buffers, etc), to solve if the target parameters of the classes are allowed to
ensure that adding the new flow to the class will not cause the change dynamically as flows arrive and depart. It is quite
class's performance to go below its target values. This problem is simple if the target parameters of each class is held fixed, and
compounded because in a priority queuing system adding traffic to a the class table is simply searched to find a class appropriate
higher-priority class can affect the performance of lower-priority for the arriving flow. This document adopts the latter
classes. The admission control algorithm for a system using the approach.
default 802 priority behavior must be reasonably sophisticated to
provide acceptable results.
If an acceptable class is found, the network returns the chosen 2. Of the appropriate traffic classes, which if any have enough
user_priority value to the client. capacity available to accept the new flow?
Note that the client may be an end station, a router at the edge of the This is the admission control problem. It is necessary to
layer 2 network, or a first switch acting as a proxy for a device that compare the level of traffic currently assigned to each class
does not participate in these protocols for whatever reason. Note also with the available level of network resources (bandwidth,
that a device e.g. a server or router may choose to implement both the buffers, etc), to ensure that adding the new flow to the class
"client" as well as the "network" portion of this model so that it can will not cause the class's performance to go below its target
select its own user_priority values. Such an implementation would values. This problem is compounded because in a priority queuing
generally be discouraged unless the device has a close tie-in with the system adding traffic to a higher-priority class can affect the
network topology and resource allocation policies. It may, however, work performance of lower-priority classes. The admission control
acceptably in cases where there is known over-provisioning of resources. 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 3. Choosing a flow's IEEE 802 user_priority class
This section describes the method by which IP-level flows are mapped This section describes the method by which IP-level flows are mapped
into appropriate IEEE user_priority classes. The IP-level services into appropriate IEEE user_priority classes. The IP-level services
considered are Best Effort, Controlled Load, and Guaranteed Service. considered are Best Effort, Controlled Load, and Guaranteed Service.
The major issue is that admission control requests and application The major issue is that admission control requests and application
requirements are specified in terms of a multidimensional vector of requirements are specified in terms of a multidimensional vector of
parameters e.g. bandwidth, delay, jitter, service class. This parameters e.g., bandwidth, delay, jitter, service class. This
multidimensional space must be mapped onto a set of traffic classes multidimensional space must be mapped onto a set of traffic classes
whose default behaviour in L2 switches is unidimensional (i.e. strict whose default behavior in L2 switches is unidimensional (i.e., strict
priority default queuing). This priority queuing alone can provide only priority default queuing). This priority queuing alone can provide
relative ordering between traffic classes. It can neither enforce an only relative ordering between traffic classes. It can neither
absolute (quantifiable) delay bound for a traffic class, nor can it enforce an absolute (quantifiable) delay bound for a traffic class,
discriminate amongst Int-Serv flows within the aggregate in a traffic nor can it discriminate amongst Int-Serv flows within the aggregate
class. Therefore, it cannot provide the absolute control of packet loss in a traffic class. Therefore, it cannot provide the absolute control
and delay required for individual Int-Serv flows. of packet loss and delay required for individual Int-Serv flows.
To provide absolute control of loss and delay three things must occur: To provide absolute control of loss and delay three things must
occur:
(1) The amount of bandwidth available to the QoS-controlled flows (1) The amount of bandwidth available to the QoS-controlled flows
must be known, and the number of flows admitted to the network must be known, and the number of flows admitted to the network
(allowed to use the bandwidth) must be limited. (allowed to use the bandwidth) must be limited.
(2) A traffic scheduling mechanism is needed to give preferential (2) A traffic scheduling mechanism is needed to give preferential
service to flows with lower delay targets. service to flows with lower delay targets.
(3) Some mechanism must ensure that best-effort flows and QoS (3) Some mechanism must ensure that best-effort flows and QoS
controlled flows that are exceeding their Tspecs do not damage controlled flows that are exceeding their Tspecs do not damage
the quality of service delivered to in-Tspec QoS controlled the quality of service delivered to in-Tspec QoS controlled
flows. This mechanism could be part of the traffic scheduler, or flows. This mechanism could be part of the traffic scheduler, or
it could be a separate policing mechanism. it could be a separate policing mechanism.
For IEEE 802 networks, the first function (admission control) is For IEEE 802 networks, the first function (admission control) is
provided by a Subnet Bandwidth Manager, as discussed below. We use the provided by a Subnet Bandwidth Manager, as discussed below. We use
link-level user_priority mechanism at each switch and bridge to the link-level user_priority mechanism at each switch and bridge to
implement the second function (preferential service to flows with lower implement the second function (preferential service to flows with
delay targets). Because a simple priority scheduler cannot provide lower delay targets). Because a simple priority scheduler cannot
policing (function three), policing for IEEE networks is generally provide policing (function three), policing for IEEE networks is
implemented at the edge of the network by a layer-3 device. When this generally implemented at the edge of the network by a layer-3 device.
policing is performed only at the edges of the network it is of When this policing is performed only at the edges of the network it
necessity approximate. This issue is discussed further in [5]. is of necessity approximate. This issue is discussed further in
[IS802FRAME].
3.1. Context of admission control and delay bounds 3.1. Context of admission control and delay bounds
As described above, it is the combination of priority-based scheduling As described above, it is the combination of priority-based
and admission control that creates quantified delay bounds. Thus, any scheduling and admission control that creates quantified delay
attempt to quantify the delay bounds expected by a given traffic class bounds. Thus, any attempt to quantify the delay bounds expected by a
has to made in the context of the admission control elements. Section 6 given traffic class has to made in the context of the admission
of the framework [5] provides for two different models of admission control elements. Section 6 of the framework [IS802FRAME] provides
control - centralized or distributed Bandwidth Allocators. 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 It is important to note that in this approach it is the admission
control algorithm that determines which of the Int-Serv services is control algorithm that determines which of the Int-Serv services is
being offered. Given a set of priority classes with delay targets, a being offered. Given a set of priority classes with delay targets, a
relatively simple admission control algorithm can place flows into relatively simple admission control algorithm can place flows into
classes so that the bandwidth and delay behavior experienced by each classes so that the bandwidth and delay behavior experienced by each
flow corresponds to the requirements of the Controlled-Load service, but flow corresponds to the requirements of the Controlled-Load service,
cannot offer the higher assurance of the Guaranteed service. To offer but cannot offer the higher assurance of the Guaranteed service. To
the Guaranteed service, the admission control algorithm must be much offer the Guaranteed service, the admission control algorithm must be
more stringent in its allocation of resources, and must also compute the much more stringent in its allocation of resources, and must also
C and D error terms required of this service. compute the C and D error terms required of this service.
A delay bound can only be realized at the admission control element A delay bound can only be realized at the admission control element
itself so any delay numbers attached to a traffic class represent the 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 delay that a single element can allow for. That element may
whole L2 domain or just a single L2 segment. represent a whole L2 domain or just a single L2 segment.
With either admission control model, the delay bound has no scope 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 outside of a L2 domain. The only requirement is that it be understood
all Bandwidth Allocators in the L2 domain and, for example, be exported by all Bandwidth Allocators in the L2 domain and, for example, be
as C and D terms to L3 devices implementing the Guaranteed Service. exported as C and D terms to L3 devices implementing the Guaranteed
Thus, the end-to-end delay experienced by a flow can only be Service. Thus, the end-to-end delay experienced by a flow can only
characterized by summing along the path using the usual RSVP mechanisms. be characterized by summing along the path using the usual RSVP
mechanisms.
3.2. Default service mappings 3.2. Default service mappings
Table 1 presents the default mapping from delay targets to IEEE 802.1 Table 1 presents the default mapping from delay targets to IEEE 802.1
user_priority classes. However, these mappings must be viewed as user_priority classes. However, these mappings must be viewed as
defaults, and must be changeable. defaults, and must be changeable.
In order to simplify the task of changing mappings, this mapping table In order to simplify the task of changing mappings, this mapping
is held by *switches* (and routers if desired) but generally not by end- table is held by *switches* (and routers if desired) but generally
station hosts. It is a read-write table. The values proposed below are not by end-station hosts. It is a read-write table. The values
defaults and can be overridden by management control so long as all proposed below are defaults and can be overridden by management
switches agree to some extent (the required level of agreement requires control so long as all switches agree to some extent (the required
further analysis). level of agreement requires further analysis).
In future networks this mapping table might be adjusted dynamically and In future networks this mapping table might be adjusted dynamically
without human intervention. It is possible that some form of network- and without human intervention. It is possible that some form of
wide lookup service could be implemented that serviced requests from network-wide lookup service could be implemented that serviced
clients e.g. traffic_class = getQoSbyName("H.323 video") and notified requests from clients e.g., traffic_class = getQoSbyName("H.323
switches of what traffic categories they were likely to encounter and video") and notified switches of what traffic categories they were
how to allocate those requests into traffic classes. Alternatively, the likely to encounter and how to allocate those requests into traffic
network's admission control mechanisms might directly adjust the mapping classes. Alternatively, the network's admission control mechanisms
table to maximize the utilization of network resources. Such mechanisms might directly adjust the mapping table to maximize the utilization
are for further study. of network resources. Such mechanisms are for further study.
The delay bounds numbers proposed in Table 1 are for per-Bandwidth The delay bounds numbers proposed in Table 1 are for per-Bandwidth
Allocator element delay targets and are derived from a subjective Allocator element delay targets and are derived from a subjective
analysis of the needs of typical delay-sensitive applications e.g. analysis of the needs of typical delay-sensitive applications e.g.,
voice, video. See Annex H of [2] for further discussion of the selection voice, video. See Annex H of [802.1D] for further discussion of the
of these values. Although these values appear to address the needs of selection of these values. Although these values appear to address
current video and voice technology, it should be noted that there is no the needs of current video and voice technology, it should be noted
requirement to adhere to these values and no dependence of IEEE 802.1 on that there is no requirement to adhere to these values and no
these values. dependence of IEEE 802.1 on these values.
user_priority Service user_priority Service
0 Default, assumed to be Best Effort 0 Default, assumed to be Best Effort
1 reserved, "less than" Best Effort 1 reserved, "less than" Best Effort
2 reserved 2 reserved
3 reserved 3 reserved
4 Delay Sensitive, no bound 4 Delay Sensitive, no bound
5 Delay Sensitive, 100ms bound 5 Delay Sensitive, 100ms bound
6 Delay Sensitive, 10ms bound 6 Delay Sensitive, 10ms bound
7 Network Control 7 Network Control
Table 1 - Example user_priority to service mappings Table 1 - Example user_priority to service mappings
Note: These mappings are believed to be useful defaults but further Note: These mappings are believed to be useful defaults but
implementation and usage experience is required. The mappings may be further implementation and usage experience is required. The
refined in future editions of this document. mappings may be refined in future editions of this document.
With this example set of mappings, delay-sensitive, admission controlled With this example set of mappings, delay-sensitive, admission
traffic flows are mapped to user_priority values in ascending order of controlled traffic flows are mapped to user_priority values in
their delay bound requirement. Note that the bounds are targets only - ascending order of their delay bound requirement. Note that the
see [5] for a discussion of the effects of other non-conformant flows on bounds are targets only - see [IS802FRAME] for a discussion of the
delay bounds of other flows. Only by applying admission control to effects of other non-conformant flows on delay bounds of other flows.
higher-priority classes can any promises be made to lower-priority Only by applying admission control to higher-priority classes can any
classes. promises be made to lower-priority classes.
This set of mappings also leaves several classes as reserved for future This set of mappings also leaves several classes as reserved for
definition. future definition.
Note: this mapping does not dictate what mechanisms or algorithms a Note: this mapping does not dictate what mechanisms or algorithms
network element (e.g. an Ethernet switch) must perform to implement a network element (e.g., an Ethernet switch) must perform to
these mappings: this is an implementation choice and does not matter implement these mappings: this is an implementation choice and
so long as the requirements for the particular service model are does not matter so long as the requirements for the particular
met. service model are met.
Note: these mappings apply primarily to networks constructed from Note: these mappings apply primarily to networks constructed from
devices that implement the priority-scheduling behavior defined as devices that implement the priority-scheduling behavior defined as
the default in 802.1D. Some devices may implement more complex the default in 802.1D. Some devices may implement more complex
scheduling behaviors not based only on priority. In that scheduling behaviors not based only on priority. In that
circumstance these mappings might still be used, but other, more circumstance these mappings might still be used, but other, more
specialized mappings may be more appropriate. specialized mappings may be more appropriate.
3.3. Discussion 3.3. Discussion
The recommendation of classes 4, 5 and 6 for Delay Sensitive, Admission The recommendation of classes 4, 5 and 6 for Delay Sensitive,
Controlled flows is somewhat arbitrary; any classes with priorities Admission Controlled flows is somewhat arbitrary; any classes with
greater than that assigned to Best Effort can be used. Those proposed priorities greater than that assigned to Best Effort can be used.
here have the advantage that, for transit through 802.1D switches with Those proposed here have the advantage that, for transit through
only two-level strict priority queuing, all delay-sensitive traffic gets 802.1D switches with only two-level strict priority queuing, all
"high priority" treatment (the 802.1D default split is 0-3 and 4-7 for a delay-sensitive traffic gets "high priority" treatment (the 802.1D
device with 2 queues). 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 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 application mix, and might be retuned by a network manager facing a
widely different mix of user needs. The choice is potentially very widely different mix of user needs. The choice is potentially very
significant: wise choice can lead to a much more efficient allocation of significant: wise choice can lead to a much more efficient allocation
resources as well as greater (though still not very good) isolation of resources as well as greater (though still not very good)
between flows. isolation between flows.
Placing Network Control traffic at class 7 is necessary to protect Placing Network Control traffic at class 7 is necessary to protect
important traffic such as route updates and network management. important traffic such as route updates and network management.
Unfortunately, placing this traffic higher in the user_priority ordering Unfortunately, placing this traffic higher in the user_priority
causes it to have a direct effect on the ability of devices to provide ordering causes it to have a direct effect on the ability of devices
assurances to QoS controlled application traffic. Therefore, an estimate to provide assurances to QoS controlled application traffic.
of the amount of Network Control traffic must be made by any device that Therefore, an estimate of the amount of Network Control traffic must
is performing admission control (e.g. SBMs). This would be in terms of be made by any device that is performing admission control (e.g.,
the parameters that are normally taken into account by the admission SBMs). This would be in terms of the parameters that are normally
control algorithm. This estimate should be used in the admission control taken into account by the admission control algorithm. This estimate
decisions for the lower classes (the estimate is likely to be a should be used in the admission control decisions for the lower
configuration parameter of SBMs). 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 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 useful for devices that wish to dynamically "penalty tag" all of the
data of flows that are presently exceeding their allocation or Tspec. data of flows that are presently exceeding their allocation or Tspec.
This provides a way to isolate flows that are exceeding their service 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 limits from flows that are not, to avoid reducing the QoS delivered
flows that are within their contract. Data from such tagged flows might to flows that are within their contract. Data from such tagged flows
also be preferentially discarded by an overloaded downstream device. might also be preferentially discarded by an overloaded downstream
device.
A somewhat simpler approach would be to tag only the portion of a flow's A somewhat simpler approach would be to tag only the portion of a
packets that actually exceed the Tspec at any given instant as low flow's packets that actually exceed the Tspec at any given instant as
priority. However, it is often considered to be a bad idea to treat low priority. However, it is often considered to be a bad idea to
flows in this way as it will likely cause significant re-ordering of the treat flows in this way as it will likely cause significant re-
flow's packets, which is not desirable. Note that the default 802.1D ordering of the flow's packets, which is not desirable. Note that the
treatment of user_priorities 1 and 2 is "less than" the default class 0. 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 4. Computation of integrated services characterization parameters by
IEEE 802 devices IEEE 802 devices
The integrated service model requires that each network element that The integrated service model requires that each network element that
supports integrated services compute and make available certain supports integrated services compute and make available certain
"characterization parameters" describing the element's behavior. These "characterization parameters" describing the element's behavior.
parameters may be either generally applicable or specific to a These parameters may be either generally applicable or specific to a
particular QoS control service. These parameters may be computed by particular QoS control service. These parameters may be computed by
calculation, measurement, or estimation. When a network element cannot calculation, measurement, or estimation. When a network element
compute its own parameters (for example, a simple link), we assume that cannot compute its own parameters (for example, a simple link), we
the device sending onto or receiving data from the link will compute the assume that the device sending onto or receiving data from the link
link's parameters as well as it's own. The accuracy of calculation of will compute the link's parameters as well as it's own. The accuracy
these parameters may not be very critical; in some cases loose estimates of calculation of these parameters may not be very critical; in some
are all that is required to provide a useful service. This is important cases loose estimates are all that is required to provide a useful
in the IEEE 802 case, where it will be virtually impossible to compute service. This is important in the IEEE 802 case, where it will be
parameters accurately for certain topologies and switch technologies. virtually impossible to compute parameters accurately for certain
Indeed, it is an assumption of the use of this model by relatively topologies and switch technologies. Indeed, it is an assumption of
simple switches (see [5] for a discussion of the different types of the use of this model by relatively simple switches (see [IS802FRAME]
switch functionality that might be expected) that they merely provide for a discussion of the different types of switch functionality that
values to describe the device and admit flows conservatively. The might be expected) that they merely provide values to describe the
discussion below presents a general outline for the computation of these device and admit flows conservatively. The discussion below presents
parameters, and points out some cases where the parameters must be a general outline for the computation of these parameters, and points
computed accurately. Further specification of how to export these out some cases where the parameters must be computed accurately.
parameters is for further study. Further specification of how to export these parameters is for
further study.
4.1. General characterization parameters 4.1. General characterization parameters
There are some general parameters [9] that a device will need to use There are some general parameters [GENCHAR] that a device will need
and/or supply for all service types: to use and/or supply for all service types:
* Ingress link * Ingress link
* Egress links and their MTUs, framing overheads and minimum packet * Egress links and their MTUs, framing overheads and minimum packet
sizes (see media-specific information presented above). sizes (see media-specific information presented above).
* Available path bandwidth: updated hop-by-hop by any device along the * Available path bandwidth: updated hop-by-hop by any device along
path of the flow. the path of the flow.
* Minimum latency * Minimum latency
Of these parameters, the MTU and minimum packet size information must be Of these parameters, the MTU and minimum packet size information must
reported accurately. Also, the "break bits" must be set correctly, both be reported accurately. Also, the "break bits" must be set correctly,
the overall bit that indicates the existence of QoS control support and both the overall bit that indicates the existence of QoS control
the individual bits that specify support for a particular scheduling support and the individual bits that specify support for a particular
service. The available bandwidth should be reported as accurately as scheduling service. The available bandwidth should be reported as
possible, but very loose estimates are acceptable. The minimum latency accurately as possible, but very loose estimates are acceptable. The
parameter should be determined and reported as accurately as possible if minimum latency parameter should be determined and reported as
the element offers Guaranteed service, but may be loosely estimated or accurately as possible if the element offers Guaranteed service, but
reported as zero if the element offers only Controlled-Load service. may be loosely estimated or reported as zero if the element offers
only Controlled-Load service.
4.2. Parameters to implement Guaranteed Service 4.2. Parameters to implement Guaranteed Service
A network element supporting the Guaranteed Service must be able to A network element supporting the Guaranteed Service [GS] must be able
determine the following parameters [7]: to determine the following parameters:
* Constant delay bound through this device (in addition to any value * Constant delay bound through this device (in addition to any value
provided by "minimum latency" above) and up to the receiver at the 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 next network element for the packets of this flow if it were to be
admitted. This includes any access latency bound to the outgoing admitted. This includes any access latency bound to the outgoing
link as well as propagation delay across that link. This value is link as well as propagation delay across that link. This value is
advertised as the 'C' parameter of the Guaranteed Service. advertised as the 'C' parameter of the Guaranteed Service.
* Rate-proportional delay bound through this device and up to the * Rate-proportional delay bound through this device and up to the
receiver at the next network element for the packets of this flow if receiver at the next network element for the packets of this flow
it were to be admitted. This value is advertised as the 'D' if it were to be admitted. This value is advertised as the 'D'
parameter of the Guaranteed Service. parameter of the Guaranteed Service.
* Receive resources that would need to be associated with this flow * Receive resources that would need to be associated with this flow
(e.g. buffering, bandwidth) if it were to be admitted and not suffer (e.g., buffering, bandwidth) if it were to be admitted and not
packet loss if it kept within its supplied Tspec/Rspec. These values suffer packet loss if it kept within its supplied Tspec/Rspec.
are used by the admission control algorithm to decide whether a new These values are used by the admission control algorithm to decide
flow can be accepted by the device. whether a new flow can be accepted by the device.
* Transmit resources that would need to be associated with this flow * Transmit resources that would need to be associated with this flow
(e.g. buffering, bandwidth, constant- and rate-proportional delay (e.g., buffering, bandwidth, constant- and rate-proportional delay
bounds) if it were to be admitted. These values are used by the bounds) if it were to be admitted. These values are used by the
admission control algorithm to decide whether a new flow can be admission control algorithm to decide whether a new flow can be
accepted by the device. accepted by the device.
The exported characterization parameters for this service should be The exported characterization parameters for this service should be
reported as accurately as possible. If estimations or approximations are reported as accurately as possible. If estimations or approximations
used, they should err in whatever direction causes the user to receive are used, they should err in whatever direction causes the user to
better performance than requested. For example, the C and D error terms receive better performance than requested. For example, the C and D
should overestimate delay, rather than underestimate it. error terms should overestimate delay, rather than underestimate it.
4.3. Parameters to implement Controlled Load 4.3. Parameters to implement Controlled Load
A network element implementing the Controlled Load service must be able A network element implementing the Controlled Load service [CL] must
to determine the following [6]: be able to determine the following:
* Receive resources that would need to be associated with this flow * 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 (e.g., buffering) if it were to be admitted. These values are used
the admission control algorithm to decide whether a new flow can be by the admission control algorithm to decide whether a new flow
accepted by the device. can be accepted by the device.
* Transmit resources that would need to be associated with this flow * Transmit resources that would need to be associated with this flow
(e.g. buffering) if it were to be admitted. These values are used by (e.g., buffering) if it were to be admitted. These values are used
the admission control algorithm to decide whether a new flow can be by the admission control algorithm to decide whether a new flow
accepted by the device. can be accepted by the device.
The Controlled Load service does not export any service-specific The Controlled Load service does not export any service-specific
characterization parameters. Internal resource allocation estimates characterization parameters. Internal resource allocation estimates
should ensure that the service quality remains high when considering the should ensure that the service quality remains high when considering
statistical aggregation of Controlled Load flows into 802 traffic the statistical aggregation of Controlled Load flows into 802 traffic
classes. classes.
4.4. Parameters to implement Best Effort 4.4. Parameters to implement Best Effort
For a network element that implements only best effort service there are For a network element that implements only best effort service there
no explicit parameters that need to be characterized. Note that an are no explicit parameters that need to be characterized. Note that
integrated services aware network element that implements only best an integrated services aware network element that implements only
effort service will set the "break bit" described in [11]. best effort service will set the "break bit" described in
[RSVPINTSERV].
5. Merging of RSVP/SBM objects 5. Merging of RSVP/SBM objects
Where reservations that use the SBM protocol's TCLASS object [10] need Where reservations that use the SBM protocol's TCLASS object [SBM]
to be merged, an algorithm needs to be defined that is consistent with need to be merged, an algorithm needs to be defined that is
the mappings to individual user_priority values in use in the Layer-2 consistent with the mappings to individual user_priority values in
cloud. A merged reservation must receive at least as good a service as use in the Layer-2 cloud. A merged reservation must receive at least
the best of the component reservations. as good a service as the best of the component reservations.
There is no single merging rule that can prevent all of the following There is no single merging rule that can prevent all of the following
side-effects: side-effects:
* If a merger were to demote the existing branch of the flow into a * If a merger were to demote the existing branch of the flow into a
higher-delay traffic class then this is a denial of service to the higher-delay traffic class then this is a denial of service to the
existing flow which would likely receive worse service than before. existing flow which would likely receive worse service than
before.
* If a merger were to promote the existing branch of the flow into a * If a merger were to promote the existing branch of the flow into a
new, lower-delay, traffic class, this might then suffer either new, lower-delay, traffic class, this might then suffer either
admission control failures or may cost more in some sense than the admission control failures or may cost more in some sense than the
already-admitted flow. This can also be considered as a denial-of- already-admitted flow. This can also be considered as a denial-
service attack. of-service attack.
* Promotion of the new branch may lead to rejection of the request * Promotion of the new branch may lead to rejection of the request
because it has been re-assigned to a traffic class that has not because it has been re-assigned to a traffic class that has not
enough resources to accommodate it. enough resources to accommodate it.
Therefore, such a merger is declared to be illegal and the usual SBM Therefore, such a merger is declared to be illegal and the usual SBM
admission control failure rules are applied. Traffic class selection is admission control failure rules are applied. Traffic class selection
performed based on the TSpec information. When the first RESV for a flow is performed based on the TSpec information. When the first RESV for
arrives, a traffic class is chosen based on the request, an SBM TCLASS a flow arrives, a traffic class is chosen based on the request, an
object is inserted into the message and admission control for that SBM TCLASS object is inserted into the message and admission control
traffic class is done by the SBM. Reservation succeeds or fails as for that traffic class is done by the SBM. Reservation succeeds or
usual. fails as usual.
When a second RESV for the same flow arrives at a different egress point When a second RESV for the same flow arrives at a different egress
of the Layer-2 cloud the process starts to repeat. Eventually the SBM- point of the Layer-2 cloud the process starts to repeat. Eventually
augmented RESV may hit a switch with an existing reservation in place the SBM-augmented RESV may hit a switch with an existing reservation
for the flow i.e. an L2 branch point for the flow. If so, the traffic in place for the flow i.e., an L2 branch point for the flow. If so,
class chosen for the second reservation is checked against the first. If the traffic class chosen for the second reservation is checked
they are the same, the RESV requests are merged and passed on towards against the first. If they are the same, the RESV requests are merged
the sender(s). and passed on towards the sender(s).
If the second TCLASS would have been different, an RSVP/SBM ResvErr If the second TCLASS would have been different, an RSVP/SBM ResvErr
error is returned to the Layer-3 device that launched the second RESV error is returned to the Layer-3 device that launched the second RESV
request into the Layer-2 cloud. This device will then pass on the request into the Layer-2 cloud. This device will then pass on the
ResvErr to the original requester according to RSVP rules. ResvErr to the original requester according to RSVP rules. Detailed
processing rules are specified in [SBM].
6. 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) Switches using layer-2-only standards (e.g., 802.1D-1990, 802.1D-
need to inter-operate with routers and layer-3 switches. Wide deployment 1998) need to inter-operate with routers and layer-3 switches. Wide
of such 802.1D-1998 switches will occur in a number of roles in the deployment of such 802.1D-1998 switches will occur in a number of
network: "desktop switches" provide dedicated 10/100 Mbps links to end roles in the network: "desktop switches" provide dedicated 10/100
stations and high speed core switches often act as central campus Mbps links to end stations and high speed core switches often act as
switching points for layer-3 devices. Layer-2 devices will have to central campus switching points for layer-3 devices. Layer-2 devices
operate in all of the following scenarios: will have to operate in all of the following scenarios:
* every device along a network path is layer-3 capable and intrusive * every device along a network path is layer-3 capable and intrusive
into the full data stream into the full data stream
* only the edge devices are pure layer-2 * only the edge devices are pure layer-2
* 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 * most devices lack layer-3 functionality except for some key
points such as router firewalls, for example. 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.1D traffic management and which places Integrated Services or 802.1D traffic management and which places
all packets through the same queuing and overload-dropping paths, it all packets through the same queuing and overload-dropping paths,
is obvious that some of a flow's desired service parameters become it is obvious that some of a flow's desired service parameters
more difficult to support. In particular, the two integrated service become more difficult to support. In particular, the two
classes studied here, Controlled Load and Guaranteed Service, both integrated service classes studied here, Controlled Load and
assume that flows will be policed and kept "insulated" from Guaranteed Service, both assume that flows will be policed and
misbehaving other flows or from best effort traffic during their kept "insulated" from misbehaving other flows or from best effort
passage through the network. This cannot be done within an IEEE 802 traffic during their passage through the network. This cannot be
network using devices with the default user_priority function; in done within an IEEE 802 network using devices with the default
this case policing must be approximated at the network edges. user_priority function; in this case policing must be approximated
at the network edges.
In addition, in order to provide a Guaranteed Service, *all* In addition, in order to provide a Guaranteed Service, *all*
switching elements along the path must participate in special switching elements along the path must participate in special
treatment for packets in such flows: where there is a "break" in treatment for packets in such flows: where there is a "break" in
guaranteed service, all bets are off. Thus, a network path that guaranteed service, all bets are off. Thus, a network path that
includes even a single switch transmitting onto a shared or half- includes even a single switch transmitting onto a shared or half-
duplex LAN segment is unlikely to be able to provide a very good duplex LAN segment is unlikely to be able to provide a very good
approximation to Guaranteed Service. For Controlled Load service, approximation to Guaranteed Service. For Controlled Load service,
the requirements on the switches and link types are less stringent the requirements on the switches and link types are less stringent
although it is still necessary to provide differential queueing and although it is still necessary to provide differential queuing and
buffering in switches for CL flows over best effort in order to buffering in switches for CL flows over best effort in order to
approximate CL service. Note that users receive indication of such approximate CL service. Note that users receive indication of such
breaks in the path through the "break bits" described in [11]. These breaks in the path through the "break bits" described in y
bits must be correctly set when IEEE 802 devices that cannot provide [RSVPINTSERV]. These bits must be correctly set when IEEE 802
a specific service exist in a network. 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
about the capabilities of their neighbours and to route around non- switches about the capabilities of their neighbours and to route
QoS-capable switches: such methods are for further study. And of around non-QoS-capable switches: such methods are for further
course the easiest solution of all is to upgrade links and switches study. And of course the easiest solution of all is to upgrade
to higher capacities. links and switches to higher capacities.
7. References 7. References
[1] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993
[2] "Information technology - Telecommunications and information [802.1D-ORIG] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993
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/D16, March 1998
[3] Clark, D. et al. "Integrated Services in the Internet Architecture: [802.1D] "Information technology - Telecommunications and
an Overview" RFC1633, June 1994 information exchange between systems - Local and
metropolitan area networks - Common specifications -
Part 3: Media Access Control (MAC) Bridges: Revision.
This is a revision of ISO/IEC 10038: 1993, 802.1j-1992
and 802.6k-1992. It incorporates P802.11c, P802.1p and
P802.12e." ISO/IEC 15802-3:1998"
[4] Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource [INTSERV] Braden, R., Clark, D. and S. Shenker, "Integrated
Reservation Protocol (RSVP) - Version 1 Functional Specification", Services in the Internet Architecture: an Overview",
RFC 2205, September 1997 RFC 1633, June 1994.
[5] Ghanwani, A., Pace, W., Srinivasan, V., Smith, A., Seaman, M., "A [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Framework for Providing Integrated Services Over Shared and Jamin, "Resource Reservation Protocol (RSVP) - Version
Switched LAN Technologies", Internet Draft, May 1998 <draft-ietf- 1 Functional Specification", RFC 2205, September 1997.
issll-is802-framework-05>
[6] Wroclawski, J., "Specification of the Controlled-Load Network [CL] Wroclawski, J., "Specification of the Controlled-Load
Element Service", RFC 2211, September 1997 Network Element Service", RFC 2211, September 1997.
[7] Schenker, S., Partridge, C., Guerin, R., "Specification of [GS] Schenker, S., Partridge, C. and R. Guerin,
Guaranteed Quality of Service", RFC 2212 September 1997 "Specification of Guaranteed Quality of Service", RFC
2212 September 1997.
[8] "IEEE Standards for Local and Metropolitan Area Networks: for [802.1Q] ANSI/IEEE Standard 802.1Q-1998, "IEEE Standards for
Virtual Bridged Local Area Networks", July 1998, IEEE Draft Local and Metropolitan Area Networks: Virtual Bridged
Standard P802.1Q/D11 Local Area Networks", 1998.
[9] Shenker, S., Wroclawski, J., "General Characterization Parameters [GENCHAR] Shenker, S., and J. Wroclawski, "General
for Integrated Service Network Elements", RFC 2215, September 1997 Characterization Parameters for Integrated Service
Network Elements", RFC 2215, September 1997.
[10] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F., Speer, M., "SBM [IS802FRAME] Ghanwani, A., Pace, W., Srinivasan, V., Smith, A. and
(Subnet Bandwidth Manager): A Protocol for Admission Control over M. Seaman, "A Framework for Providing Integrated
IEEE 802-style Networks", Internet Draft, March 1998 <draft-ietf- Services Over Shared and Switched LAN Technologies",
issll-sbm-06> RFC 2816, May 2000.
[11] Wroclawski, J., "The use of RSVP with IETF Integrated Services", [SBM] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and M.
RFC 2210, September 1997. Speer, "SBM (Subnet Bandwidth Manager): A Protocol for
Admission Control over IEEE 802-style Networks", RFC
2814, May 2000.
[RSVPINTSERV] Wroclawski, J., "The use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[PROCESS] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
8. Security Considerations 8. Security Considerations
Any use of QoS requires examination of security considerations because Any use of QoS requires examination of security considerations
it leaves the possibility open for denial of service or theft of service because it leaves the possibility open for denial of service or theft
attacks. This document introduces no new security issues on top of those of service attacks. This document introduces no new security issues
discussed in the companion ISSLL documents [5] and [10]. Any use of on top of those discussed in the companion ISSLL documents
these service mappings assumes that all requests for service are [IS802FRAME] and [SBM]. Any use of these service mappings assumes
authenticated appropriately. that all requests for service are authenticated appropriately.
9. Acknowledgments 9. Acknowledgments
This document draws heavily on the work of the ISSLL WG of the IETF and This document draws heavily on the work of the ISSLL WG of the IETF
the IEEE P802.1 Interworking Task Group. and the IEEE P802.1 Interworking Task Group.
10. Authors' addresses 10. Authors' Addresses
Mick Seaman Mick Seaman
3Com Corp. Telseon
5400 Bayfront Plaza 480 S. California Ave
Santa Clara CA 95052-8145 Palo Alto, CA 94306
USA USA
+1 (408) 764 5000
mick_seaman@3com.com
Andrew Smith Email: mick@telseon.com
Extreme Networks
10460 Bandley Drive
Cupertino CA 95014
USA
+1 (408) 863 2821
andrew@extremenetworks.com
Eric Crawley Andrew Smith
Argon Networks Extreme Networks
25 Porter Rd. 3585 Monroe St.
Littleton MA 01460 Santa Clara, CA 95051
USA USA
+1 (508) 486 0665
esc@argon.com
John Wroclawski Phone: +1 408 579 2821
MIT Laboratory for Computer Science EMail: andrew@extremenetworks.com
545 Technology Sq.
Cambridge, MA 02139 Eric Crawley
USA Unisphere Solutions
+1 (617) 253 7885 5 Carlisle Rd.
jtw@lcs.mit.edu Westford, MA 01886
Table of Contents Phone: +1 978 692 1999
Email: esc@unispheresolutions.com
1 Introduction .................................................... 2 John Wroclawski
2 Flow Identification and Traffic Class Selection ................. 3 MIT Laboratory for Computer Science
3 Choosing a flow's IEEE 802 user_priority class .................. 5 545 Technology Sq.
3.1 Context of admission control and delay bounds ................. 6 Cambridge, MA 02139
3.2 Default service mappings ...................................... 7 USA
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 ..................................... 12
6 Applicability of these service mappings ......................... 13
7 References ...................................................... 14
8 Security Considerations ......................................... 16
9 Acknowledgments ................................................. 16
10 Authors' addresses ............................................. 16
Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished Phone: +1 617 253 7885
to others, and derivative works that comment on or otherwise EMail: jtw@lcs.mit.edu
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 Full Copyright Statement
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on Copyright (C) The Internet Society (2000). All Rights Reserved.
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR This document and translations of it may be copied and furnished to
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF others, and derivative works that comment on or otherwise explain it
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED or assist in its implementation may be prepared, copied, published
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 110 change blocks. 
586 lines changed or deleted 592 lines changed or added

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