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

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