Internet Draft Mick Seaman
Expires May 1997 3Com Corp.
draft-ietf-issll-802-00.txt Andrew Smith
Extreme Networks
Eric Crawley
Bay Networks
November 1996
Integrated Services over IEEE 802.1D/802.1p 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."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Abstract
This document describes the support of IETF Integrated Services over
LANs built from IEEE 802 network segments which are interconnected by
standard IEEE 8021.D [1] switches.
It describes the practical capabilities and limitations of this
technology for supporting Controlled Load [8] and Guaranteed Service [9]
using the inherent capabilities the relevant 802 technologies [5],[6]
etc. and the proposed 802.1p queuing features in switches. It provides a
functional model for the layer 3 to layer 2 and user-to-network dialogue
which supports admission control and defines requirements for
interoperability between switches.
This scheme is consistent with the ISSLL over LANs framework discussed
at the October 1996 ISSLL interim meeting and described in [7].
Seaman, Smith, Crawley Expires May 1997 [Page 1]
INTERNET DRAFT Intserv over IEEE 802.1D/p November 1996
1. Introduction
The IEEE 802.1 Interworking Task Group is currently enhancing the basic
MAC Service provided in Bridged Local Area Networks (aka "switched
LANs"). As a supplement to the IEEE MAC Bridges standard [1] , P802.1p
[2], proposes differential traffic class queuing ("priorities") and
access to media on the basis of a "user_priority" signaled in frames.
In this document we
* review the meaning and use of user_priority in LANs and the frame
forwarding capabilities of a standard LAN switch.
* examine alternatives for identifying layer 2 traffic flows for
admission control.
* review the options available for policing traffic flows.
* derive requirements for consistent priority handling in a network of
switches and use these requirements to discuss priority queue
handling alternatives for 802.1p and the way in which these meet
administrative and interoperability goals.
* consider the benefits and limitations of this switched-based approach,
contrasting it with full router based RSVP implementation in terms of
complexity, utilisation of transmission resources and administrative
controls.
We then describe a model which:
* partitions the admission control process into two separable
operations:
* an interaction between the user of the integrated service and the
local network elements ("provision of the service" in the terms of
802.1D) to confirm the availability of transmission resources for
traffic to be introduced.
* selection of an appropriate user_priority for that traffic on the
basis of the service and service parameters to be supported.
* distinguishes between the user to network interface above and the
mechanisms used by the switches ("support of the service"). These
include communication between the switches (network to network
signaling).
* describes a simple architecture for the provision and support of these
services, broken down into components with functional and interface
descriptions:
* a single "user" component: a layer-3 to layer-2 negotiation and
translation component.
* bridge/switch processes to handle admission control and mapping
requests, including proposals for actual traffic mappings to
user_priority values.
* proposes a set of protocol exchange primitives based on the functions
introduced.
This document contains much background material that is used as
Seaman, Smith, Crawley Expires May 1997 [Page 2]
INTERNET DRAFT Intserv over IEEE 802.1D/p November 1996
justification for the approach taken. It is anticipated that much of
this material will not form a part of the final specification.
It will be noted that this document is written from the pragmatic
viewpoint that there will be a widely deployed network technology and we
are evaluating it for its ability to support some or all of the defined
IETF integrated services: this approach is intended to ensure
development of a system which can provide useful new capabilities in
existing (and soon to be deployed) network infrastructure.
2. Goals and Assumptions
It is assumed that the network is "switch-rich": that is to say all
communication between end stations using integrated services support
will pass through at least one switch. Perhaps the mechanisms and
protocols described will be trivially extensible to communicating
systems on the same shared media, but it is important not to allow
problem generalisation to complicate the practical application that we
target: the access characteristics of Ethernet are forcing a trend to
switch-rich topologies together with MAC enhancements to ensure access
predictability on half-duplex switch to switch links.
It is assumed that layer-3 entities, including end-stations, are running
the RSVP protocol in support of integrated services at that layer. No
extra modifications to this protocol are assumed.
There may be a heterogeneous mixture of switches with different
capabilities, all compliant with IEEE 802.1p, but implementing queuing
and forwarding mechanisms in a range from simple 2-queue per port,
strict priority, up to more complex multi-queue (maybe even one per-
flow) WFQ or other algorithms.
The problem is broken down into smaller independent pieces: this may
lead to sub-optimal usage of the network resources but we contend that
such benefits are often equivalent to very small improvements in network
efficiency in a LAN environment. Therefore, it is a goal that the
switches in the network operate using a much simpler set of information
than the RSVP engine in a router. In particular, it is assumed that such
switches do not need to implement per-flow queuing and policing.
One corollary is that no per-flow policing function need take place in
the switches: it is a fundamental part of the intserv model that flows
are isolated from each other throughout their transit across a network.
Intermediate queuing nodes are expected to police the traffic to ensure
that it conforms to the pre-agreed traffic flow specification. In the
architecture proposed here for mapping to layer-2, that policing
function is assumed to be implemented in the transmit schedulers of the
Seaman, Smith, Crawley Expires May 1997 [Page 3]
INTERNET DRAFT Intserv over IEEE 802.1D/p November 1996
layer-3 devices (end stations, routers): it is reasonable to assume that
end stations are "trusted" to adhere to their agreed contracts at the
inputs to the network and that we can afford to over-allocate resources
to compensate for the inevitable extra jitter/bunching introduced by the
switched network itself.
3. User Priority and Frame Forwarding
User_priority is a value associated with the transmission and reception
of all frames in the IEEE 802 service model: it is supplied by a sender
which is using the MAC service. It is provided to a receiver using the
MAC service. It may or may not be actually carried over the network:
Token-Ring/802.5 carries this value (encoded in its FC octet), basic
Ethernet/802.3 does not. 802.1p defines a way to carry this value over
the network in a similar way on Ethernet, Token Ring, FDDI or other MACs
using an extended frame format.
The "user_priority" or "traffic class" (the latter term is to be
preferred and it is the title of the 802.1p document) field in packets
is a simple label in the data stream enabling packets in different
classes to be discriminated by downstream nodes. Apart from making the
job of desktop or wiring-closet switches easier, it means they do not
have to change (hardware or software) as the rules for classifying
packets evolve (based on new protocols or new policies). Layer-3
switches do provide added value here by performing the classification
more accurately and, hence, utilising network resources more
efficiently: this appears to be a good economic choice since there are
likely to be very many more desktop/wiring closet switches in a network
than switches requiring layer 3 functionality.
The IEEE 802 specifications make no assumptions about how user_priority
is to be used by end stations or by the network, although the current
802.1p draft defines static priority queuing as the default mode of
operation of all switches (user_priority is defined as a 3-bit quantity
with value 7 = high priority, 0 = low priority). The switch algorithm in
this case is as follows: packets are placed onto a particular queue
based on the received user_priority (from the packet if a 802.1p header
or 802.5 network was used, invented according to some local policy if
not). The selection of queue is based on a mapping from user_priority
[0,1,2,3,4,5,6 or 7] onto the number of available queues - switches may
implement any number of queues from 1 upwards. On transmit, any/all
frames from a higher priority queue are sent first before transmitting
any from a lower priority queue.
In particular, IEEE makes no recommendations about how a sender should
select the value for user_priority: one of the main purposes of this
draft is to propose such usage rules.
Seaman, Smith, Crawley Expires May 1997 [Page 4]
INTERNET DRAFT Intserv over IEEE 802.1D/p November 1996
Additionally, there are no IEEE 802-defined rules for switches to agree
on how to treat frames with different user_priority values: later on in
this draft we make some recommendations as to what information needs to
be shared amongst switches.
4. Mapping of integrated services to layer-2 in layer-3 devices
The end-station or router itself is responsible for local admission
control and scheduling packets onto its link in accordance with the
service agreed. Just as in the intserv model, this involves per- flow
schedulers somewhere in every such data source: it is an implementation
issue whether there are separate schedulers for layer-3 and layer-2 or
whether these are combined.
5. Mapping of integrated services through layer-2 switches
5.1 Queuing
Connectionless packet-based networks in general and LAN switched
networks in particular, work today because of scaling choices in network
provisioning. Consciously or (more usually) unconsciously, enough excess
bandwidth and buffering is provisioned in the network to absorb the
traffic sourced by higher-layer protocols or cause their transmission
windows to run out, on a statistical basis, so that the network is only
overloaded for a short duration and the average expected loading is less
than 60% (usually much less).
With the advent of time-critical traffic such overprovisioning has
become far less easy to achieve. Time critical frames may find
themselves queued for annoyingly long periods of time behind temporary
bursts of file transfer traffic, particularly at network bottleneck
points, e.g. at the 100 Mb/s to 10 Mb/s transition that might occur
between the riser to the wiring closet and the final link to the user
from a desktop switch. In this case, however, if it is known (guaranteed
by application design, merely expected on the basis of statistics, or
just that this is all that the network guarantees to support) that the
time critical traffic is a small fraction of the total bandwidth, it
suffices to give it strict priority over the "normal" traffic. The worst
case delay experienced by the time critical traffic is roughly the
maximum transmission time of a maximum length non-time-critical frame -
less than a millisecond for 10 Mb/s Ethernet, and well below an end to
end budget based on human perception times.
When more than one "priority" service is to be offered by a network
element e.g. it supports controlled-load as well as Guaranteed Service,
the queuing discipline becomes more complex. In order to provide the
Seaman, Smith, Crawley Expires May 1997 [Page 5]
INTERNET DRAFT Intserv over IEEE 802.1D/p November 1996
required isolation between the service classes, it will probably be
necessary to queue them separately. There is then an issue of how to
service the queues - a combination of admission control and maybe
weighted fair queuing may be required in such cases. As with the service
specifications themselves, it is not the place for this document to
specify queuing algorithms, merely to observe that the external
behaviour meet the services' requirements.
5.2 Multicast Heterogeneity
IEEE 802.1D and 802.1p use a model for multicast whereby a switch
performs multicast routing decisions based on the destination address:
this would produce a list of output ports to which the packet should be
forwarded. In its default mode, such a switch would use any
user_priority value in received packets to enqueue the packets at each
output port.
At layer-3, the intserv model allows heterogeneous multicast flows where
different branches of a tree can have different types of reservations
for a given multicast destination, or even supports the notion that some
trees will have some branches with reserved flows and some using best
effort (default) service.
If a switch is selecting per-port output queues based only on the
incoming user_priority, it will have to treat all branches of all
multicast sessions within that user_priority class with the same queuing
mechanism: no heterogeneity is then possible (if it were to implement a
separate mapping at each output port then some limited form of
heterogeneity could be supported). It is proposed that per-
user_priority queuing support is adequate as minimum standard
functionality for systems *in a LAN environment*. Layer-3 switches
(a.k.a. routers) can be used if more flexible forms of heterogeneity are
considered necessary: their behaviour is well standardised.
6. Selecting User Priority classes
One fundamental question is "who gets to decide what the classes mean
and who gets access to them?" One approach would be for the meanings of
the classes to be "well-known": we would then need to standardise a set
of classes e.g. 1 = best effort, 2 = controlled- load, 3 = guaranteed
(loose delay bound, high bandwidth), 4 = guaranteed (slightly tighter
delay) etc. The values to encode in such a table in end stations, in
isolation from the network to which they are connected, is
problematical: the best we could probably do would be to define on
user_priority value per intserv service type and leave it at that
(reserving the rest of the combinations for future traffic classes -
there are sure to be plenty!).
Seaman, Smith, Crawley Expires May 1997 [Page 6]
INTERNET DRAFT Intserv over IEEE 802.1D/p November 1996
We propose a more flexible mapping: clients ask "the network" which
user_priority traffic class to use for a given traffic flow, as
categorised by its flow-spec and layer-2 endpoints. The network provides
a value back to the requester which is appropriate to the current
network topology, load conditions, other admitted flows etc. The task of
configuring switches with this mapping (e.g. through network management
or some other switch-switch protocol) is an order of magnitude less
complex than performing the same function in end stations. Also, when
new services (or other network reconfigurations) are added to such a
network, the network elements will typically be the ones to be upgraded
with new queuing algorithms etc. and can be provided with new mappings
at this time.
Given the need for a new session or "flow" requiring some QoS support, a
client then needs answers to the following questions:
1. which traffic class do I add this flow to?
The client needs to know how to label the packets of the flow as it
places them into the network.
2. who do I ask/tell?
The proposed model is that a client ask "the network" which
user_priority traffic class to use for a given traffic flow. This has
several benefits as compared to a model which allows clients to select
a class for themselves.
3. how do I ask/tell them?
A request/response protocol is needed between client and network: in
fact, the request can be piggy-backed onto an admission control request
and the response can be piggy-backed onto an admission control
acknowledgment.
The network (i.e. the first network element encountered downstream from
the client) must then answer the following questions:
1. which traffic class do I add this flow to?
This is a packing problem, difficult to solve in general, but many
simplifying assumptions can be made: presumably some simple form of
allocation can be done without a more complex scheme able to
dynamically shift flows around between classes.
2. which traffic class has worst-case parameters which meet the needs of
this flow?
This might be an ordering/comparison problem: which of two service
classes is "better" than another? Again, we can make this tractable by
observing that all of the current intserv classes can be ranked (best
effort <= Controlled Load <= Guaranteed Service) in a simple manner. If
any classes are implemented in the future that cannot be simply ranked
Seaman, Smith, Crawley Expires May 1997 [Page 7]
INTERNET DRAFT Intserv over IEEE 802.1D/p November 1996
then the issue can be finessed by either a priori knowledge about what
classes are supported or by configuration.
and return the chosen user_priority value to the client.
Note that the client may be either an end station, router or a first
switch which may be acting as a proxy for a client which does not
participate in these protocols for whatever reason. Note also that a
device e.g. a server or router, may choose to implement both the
"client" as well as the "network" portion of this model so that it can
select its own user_priority values: such an implementation is, however,
discouraged unless the device really does have a close tie-in with the
network topology and resource allocation policies.
7. Flow Identification
Several previous proposals for intserv over lower-layers have treated
switches very much as a special case of routers: in particular, that
switches along the data path will make packet handling decisions based
on the RSVP flow and filter specifications and use them to classify the
corresponding data packets. However, filtering to the per-flow level
becomes cost-prohibitive with increasing switch speed: devices with such
filtering capabilities are unlikely to have a very different
implementation cost to IP routers, in which case we must question
whether a specification oriented toward switched networks is of any
benefit at all.
This document proposes that "flow" identification based in user_priority
be the minimum required of switches.
8. Reserving Network Resources - Admission Control
So far we have not discussed admission control. In fact, without
admission control it is possible to scratchbuild a LAN network of some
size capable of supporting real-time services, providing that the
traffic fits within certain scaling constraints (relative link speeds,
numbers of ports etc. - see below). This is not surprising since it is
possible to run a fair approximation to real time services on small LANs
today with no admission control or help from encoded priority bits.
Imagine a campus network providing dedicated 10 Mbps connections to each
user. Each floor of each building supports up to 96 users, organized
into groups of 24, with each group being supported by a 100 Mbps
downlink to a basement switch which concentrates 5 floors (20 x 100
Mbps) and a data center (4 x 100 Mbps) to a 1 Gbps link to an 8 Gbps
central campus switch, which in turn hooks 6 buildings together (with 2
Seaman, Smith, Crawley Expires May 1997 [Page 8]
INTERNET DRAFT Intserv over IEEE 802.1D/p November 1996
x 1 Gbps full-duplex links to support a corporate server farm). Such a
network could support 1.5 Mb/s of voice/video from every user to any
other user or (for half the population) the server farm, provided the
video ran high priority: this gives 3000 users, all with desktop video
conferencing running along with file transfer/email etc. In such a
network RSVP's role would be limited to ensuring resource availability
at the communicating end stations and for connection to the wide area.
In such a network, a discussion as to the best service policy to apply
to high and low priority queues may prove academic: while it is true
that "normal" traffic may be delayed by bunches of high priority frames,
queuing theory tells us that the average queue occupancy in the high
priority queue at any switch port will be somewhat less than 1 (with
real user behaviour, i.e. not all watching video conferences all the
time) it should be far less. A cheaper alternative to buying equipment
with a fancy queue service policy may be to buy equipment with more
bandwidth to lower the average link utilisation by a few per cent.
In practice a number of objections can be made to such a simple
solution. There may be long established expensive equipment in the
network which does not provide all the bandwidth required. There will be
considerable concern over who is allowed to say what traffic is high
priority. There may be a wish to give some form of "prioritised" service
to crucial business applications, above that given to experimental
video-conferencing. The task that faces us is to provide a degree of
control without making that control so elaborate to implement that the
control oriented solution is not simply rejected in favor of providing
yet more bandwidth, at a lower cost.
The proposed admission control mechanism requires a query-response
interaction with the network returning a "YES/NO" answer and, if
successful, the user_priority value with which to tag the data frames of
this flow.
9. Client mapping to layer 2
We assume the same host model as intserv and RSVP: the client is running
an RSVP process which presents a session establishment interface to
applications, signals RSVP over the network, programs scheduler and
classifiers in the driver and interfaces to a policy control module. In
particular, RSVP also interfaces to a local admission control module: it
is this entity that we focus on here.
Seaman, Smith, Crawley Expires May 1997 [Page 9]
INTERNET DRAFT Intserv over IEEE 802.1D/p November 1996
The following diagram is taken from the RSVP spec:
_____________________________
| _______ |
| | | _______ |
| |Appli- | | | | RSVP
| | cation| | RSVP <--------------------
| | <-- | |
| | | |process| _____ |
| |_._____| | --Polcy||
| | |__.__._| |Cntrl||
| |data | | |_____||
|===|===========|==|==========|
| | --------| | _____ |
| | | | ----Admis||
| _V__V_ ___V____ |Cntrl||
| | | | | |_____||
| |Class-| | Packet | |
| | ifier|==Schedulr|====================
| |______| |________| | data
| |
|_____________________________|
Figure 1 - RSVP in Hosts
The local admission control entity (known as "TUTU") within a client is
responsible for mapping these layer-3 requests in TO layer TwO language.
The upper-layer entity requests from TUTU:
"May I reserve for traffic with <traffic characteristic with
<performance requirements from <here to <there and how
should I label it?"
where
<traffic characteristic = Flow Spec, Tspec, Rspec (e.g.
bandwidth, burstiness, MTU etc.)
<performance requirements = latency, jitter bounds etc.
<here = IP address(es)
<there = IP address(es) - may be multicast
The TUTU entity:
* maps the endpoints of the conversation to layer-2 addresses in the
LAN, so it can figure out what traffic is really going where.
* applies local admission control on outgoing link and driver (may have
some interaction with classifier and scheduler here e.g. to give
classifier information about which user_priority values to expect)
* formats a request to the network with the mapped addresses and flow
Seaman, Smith, Crawley Expires May 1997 [Page 10]
INTERNET DRAFT Intserv over IEEE 802.1D/p November 1996
specs
* receives response from the network and reports the YES/NO admission
control answer and, for successful requests, the resulting
user_priority back to the upper layer entity.
from IP from RSVP
____|____________|____________
| | | | |
| __V____ | ___V___ |
| | | | | | |
| | ARP | | | | | ISSLL signaling
| |protocl| | | TUTU |<------------------------
| | |<-| | |
| | | | | | |
| |_______| | | | |
| | | |_______| |
| |data | | | |
|====|===========|==|==========|
| | +--------| | _____ |
| | | | +-|Local| |
| __V__V_ ____V___ |Admis| |
| | | | | |Cntrl| |
| |Class-| | Packet | |_____| |
| | ifier|==Schedulr|======================
| |______| |________| | data
| |
|______________________________|
Figure 2 - ISSLL in Hosts
10. Switch Functions
10.1 Admission Control
For the sake of this discussion, we define the following entities within
a layer-2 switch:
* traffic class mapping authority - this holds the mapping table of
intserv classes to user_priority.
* reservation accountants - one of these on each port accounts for the
available bandwidth on that link. For half-duplex links, this
involves taking account of both transmit and receive flows. For
full-duplex the input port accountant's task is trivial.
* reservation propagators - these propagate requests that have passed
admission control at the input port's accountant to the relevant
output ports' accountants. This will require access to the switch's
forwarding table (layer-2 "routing table" - cf. RSVP model) and
spanning-tree state.
Seaman, Smith, Crawley Expires May 1997 [Page 11]
INTERNET DRAFT Intserv over IEEE 802.1D/p November 1996
These are shown by the following diagram:
_______________________________
| _____ ______ _____ |
| |Span | |filter| |traff| |
| |Tree |<-|data- | |class| |
| |Prot.| | base| |map | |
| |_____| |______| |_____| |
| ^ |
| _____ __|___ ______ |
ISSLL signaling | | in | | | | out | | ISSLL signaling
<------------------|resv |<-| resv |<-| resv |<----------------
| |acct.| | prop.| | acct.| |
| |_____| |______| /|______| |
| | \ / | |
|====|====\=========|======|====|
| __V__ | | __V__ |
| |Local| | | |Local| |
| |Admis| | | |Admis| |
| |Cntrl| | | |Cntrl| |
| |_____| | | |_____| |
| ____V_ __V____ |
| |Class-| | Packet | |
===============-| ifier|====Schedulr|===================
data | |______| |________| | data
| |
|_______________________________|
Figure 3 - ISSLL in Switches
On reception of an admission control request, a switch performs the
following actions:
* ingress bandwidth accountant observes the current state of allocation
of resources on the input port/link and then determines whether the
new allocation would be excessive. The request is passed to the
reservation propagator if accepted so far.
* reservation propagator relays the request to the bandwidth accountants
on each of the switch's outbound links to which this reservation
would apply (implied interface to routing/forwarding database).
* egress bandwidth accountant observes the current state of allocation
of queueing resources on its outbound port and bandwidth on the link
itself and determines whether the new allocation would be excessive.
Note that this is only the local decision of this switch hop: each
further layer-2 hop through the network gets a chance to veto the
request as it passes along.
* the request, if accepted by this switch, is then passed on down the
line on each output link selected.
* if this is the first switch in line, the traffic class mapping
authority selects a layer-2 traffic class which appears compatible
Seaman, Smith, Crawley Expires May 1997 [Page 12]
INTERNET DRAFT Intserv over IEEE 802.1D/p November 1996
with the request and whose use does not violate any administrative
policies in force. In effect, it matches up the requested service with
those available in each of the user_priority classes and chooses the
"best" one. It ensures that, if this reservation is successful, the
selected value is passed back to the client.
* if accepted, the switch must notify the client of the user_priority to
use for packets belonging to this flow. Note that this is a
"provisional YES" - we assume an optimistic approach here: later
switches can still say "NO" later.
* if this switch wishes to reject the request, it can do so by notifying
the original client (by means of its layer-2 address).
10.2 Mappings to IEEE 802 user_priority
There are several options available for mapping service models (Best
Effort, Controlled Load, and Guaranteed) to IEEE 802.1p user_priority
classes. The problem with making choices at this time is that we don't
have much experience with any particular mappings to help make a
determination as to the "best" mapping. So, the following options are
presented to stimulate discussion in this area. Note, this does not
dictate what mechanisms/algorithms a network element (e.g. an Ethernet
switch) needs to do implement these mappings: this is an implementation
choice and does not matter so long as the requirements for the
particular service model are met.
In order to reduce the administrative problems of maintaining such
mappings, such a mapping table is held by *switches* only (and routers
if desired) and is a read-write table. The values proposed below are
defaults and can be overridden by management control so long as all
switches agree to some extent (the required level of agreement requires
further thought).
Option A: The Simple Method
In this method, all traffic that uses a particular service model is
mapped to a single 802.1p user_priority. This is fine as long as all
traffic for a given service model does not exceed any capacity in the
802 device and fine control of delay is not needed. Here is an example:
Priority Service
0 "less than" Best Effort
1 Best Effort
2 reserved
3 reserved
4 Controlled Load
5 reserved
Seaman, Smith, Crawley Expires May 1997 [Page 13]
INTERNET DRAFT Intserv over IEEE 802.1D/p November 1996
6 Guaranteed Service
7 reserved
The "less than" best effort service is useful for devices that wish to
tag packets that are exceeding a committed network capacity and can be
optionally discarded by a downstream device. Note, this is not
necessarily incorporated in any current IntServ model.
The advantage of this mapping is that it leaves room for future service
models. The choices of priority 4 and priority 6 for Controlled Load
and Guaranteed Service, respectively, is somewhat arbitrary. Any two
priorities greater than Best Effort can be used as long as Guaranteed
Service is "greater" than Controlled Service although those proposed
here have the advantage that, for transit through 802.1p switches with
only two-level strict priority queuing, they both get "high priority"
treatment (the current 802.1p split is 0-3 and 4-7 for 2 queues).
One disadvantage to this mapping is that it ignores the delay
characteristics of the guaranteed service and groups all guaranteed
traffic, no matter what the delay bound, into the same priority.
Option B: Two Classes of Guaranteed Service
For this method, we expand the number of priorities assigned to the
Guaranteed Service:
Priority Service
0 "less than" Best Effort
1 Best Effort
2 reserved
3 reserved
4 Controlled Load
5 Guaranteed Service, 100ms bound
6 Guaranteed Service, 10ms bound
7 reserved
Again, the choices of the exact priorities are somewhat arbitrary as
long as they are increasing. Similarly, the choice of delay bound is
also arbitrary but potentially very significant. One of the key
differences is that now there is a bound on delay through the network
(and hence through each device) which may be much harder to implement
although it can lead to a much more efficient allocation of resources.
The advantage to this approach is that it puts some real delay bounds on
the Guaranteed Service without adding any additional complexity to the
other services. It still ignores the amount of *bandwidth* available
for each class.
Further derivations of this option could be made by dividing the
Seaman, Smith, Crawley Expires May 1997 [Page 14]
INTERNET DRAFT Intserv over IEEE 802.1D/p November 1996
Guaranteed Service classes into more levels with particular delay
bounds. Expanding the number of priorities for Controlled Load service
is not as appealing since there is no need to map to a particular delay
bound. There may be a cases where an administrator might map Controlled
Load to more priorities for particular bandwidths or policy levels. It
may also be necessary to further classify Controlled Load traffic in
cases and where the Controlled Load traffic is frequently non-conformant
for certain applications.
10.3 Policy
A policy agent may also be implemented by a switch. This determines, how
to interpret received user_priority values from packets, whether to
trust them and whether to map them to something else. The policies in
force may be configured by network management. Default is to use what is
received and pass it on unchanged.
11. Signaling protocol
It is not the intention to precisely define a protocol in this document
at this time. For now, we propose only some issues that such a protocol
should consider:
* need to tackle problem of reservation request crossing on a shared
medium ("collisions"): this needs some form of tie- breaker.
* failed reservation retry policy: may be a bad idea to retry but we
have to specify behaviour.
* one simple approach might be to avoid the election of any "master"
bandwidth arbiter on a segment: if we were to assume an optimistic
approach to reservations with later "veto" power by subsequent
switches or receivers then a large degree of complexity might be avoided.
* signaling protocol needs to be able to notify failure of admission
control back to client or back to previous switch hop.
12. Shared media
The astute reader will have noticed that we have not mentioned the
difficulty of dealing with allocation on a single shared CSMA/CD
segment: there are a number of reasons for this.
Firstly, we do not believe this is a truly solvable problem: it would
seem to require a new MAC protocol. Those who are interested in solving
this problem per se should probably be following the BLAM developments
in 802.3 but we would be suspicious of the interoperability
characteristics of a series of new software MACs running above the
traditional 802.3 MAC.
Seaman, Smith, Crawley Expires May 1997 [Page 15]
INTERNET DRAFT Intserv over IEEE 802.1D/p November 1996
Secondly, we are not convinced that it is really an interesting problem.
While not everyone in the world is buying desktop switches today and
there will be end stations living on repeated segments for some time to
come, the number of switches is going up and the number of stations on
repeated segments is going down. This trend is proceeding to the point
that we may be happy with a solution which assumes that any network
conversation requiring resource reservations will take place through at
least one switch (be it layer-2 or layer-3). Put another way, the
easiest QoS upgrade to a layer-2 network is to install segment
switching: only when has been done is it worthwhile to investigate more
complex solutions involving admission control.
Thirdly, in the core of the network (as opposed to at the edges), there
does not seem to be enough economic benefit for repeated segment
solutions as opposed to switched solutions. While repeated solutions
*may* be 50% cheaper, their cost impact on the entire network is
amortised across all of the edge ports. There may be special
circumstances in the future (e.g. Gigabit buffered repeaters) but these
have differing characteristics to existing CSMA/CD repeaters anyway.
13. Compatibility and Interoperability with existing equipment
Layer-2-only "standard" 802.1p switches will have to work together with
routers and layer-3 switches. Wide deployment of such 802.1p switches is
envisaged, in a number of roles in the network. "Desktop switches" will
provide dedicated 10/100 Mbps links to end stations at costs
comparable/compatible with NICs/adapter cards. Very high speed core
switches may act as central campus switching points for layer 3 devices.
Real network deployments provide a wide range of examples today. The
question is "what functionality beyond that of the basic 802.1D bridge
should such 802.1p switches provide?". In the abstract the answer is
"whatever they can do to broaden the applicability of the switching
solution while still being economically distinct from the layer 3
switches in their cost of acquisition, speed/bandwidth, cost of
ownership and administration". Broadening the applicability means both
addressing the needs of new traffic types and building larger switched
networks (or making larger portions of existing networks switched). Thus
one could imagine a network in which every device (along a network path)
was layer-3 capable/intrusive into the full data stream; or one in which
only the edge devices were pure layer-2; or one in which every alternate
device lacked layer-3 functionality; or most do - excluding some key
control points such as router firewalls, for example. Whatever the mix,
the solution has to interoperate with these layer-3 QoS-aware devices.
Of course, where intserv flows pass through equipment which is ignorant
of priority queuing and which places all packets through the same
queuing/overload-dropping path, it is obvious that some of the
Seaman, Smith, Crawley Expires May 1997 [Page 16]
INTERNET DRAFT Intserv over IEEE 802.1D/p November 1996
characteristics of the flow get more difficult to support. Suitable
courses of action in the cases where sufficient bandwidth or buffering
is not available are of the form:
(a) buy more (and bigger) routers
(b) buy more capable switches
(c) rearrange the network topology: 802.1Q VLANs may help here.
(d) buy more bandwidth: Gigabit Ethernet is nearly here.
It would also be possible 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.
14. Epilogue
An obvious comment is that this is all too complex, it's what RSVP is
doing already, why do we think we can do better by reinventing the
solution to this problem at layer-2?
The key is that we do not have to tackle the full problem space of RSVP:
there are a number of simple scenarios that cover a considerable
proportion of the real situations that occur: all we have to do here is
cover 99% of the territory at significantly lower cost and leave the
other applications to full RSVP running in strategically positioned
high-function switches or routers. This will allow a significant
reduction in overall network cost (equipment and ownership). This
approach does mean that we have to discuss real life situations instead
of abstract topologies that "could happen".
Sometimes, for example, simple bandwidth configuration in a few switches
e.g. to avoid overloading particular trunk links, can be used to
overcome bottlenecks due to the network topology: if there are issues
with overloading end station "last hops", RSVP in the end stations would
exert the correct controls simply by examining local resources without
much tie-in to the layer-2 topology. In this case there has been no need
to resort to any form of complex topology computation and much
complexity has been avoided.
In the more general case, there remains work to be done. This will need
to be done against the background constraint that the changing of queue
service policies and the addition of extra functionality to support new
service disciplines will proceed at the rate of hardware product
development cycles and advance implementations of new algorithms may be
pursued reluctantly or without the necessary 20-20 foresight.
Seaman, Smith, Crawley Expires May 1997 [Page 17]
INTERNET DRAFT Intserv over IEEE 802.1D/p November 1996
However, compared to the alternative of no traffic classes at all, there
is substantial benefit in even the simplest of approaches (e.g. 2-4
queues with straight priority), so there is significant reward for doing
something: wide acceptance of that "something" probably means that even
the simplest queue service disciplines will be provided for.
15. References
[1] ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC Bridges"
[2] "MAC Bridges - Traffic Classes and Dynamic Multicast Filtering
Services in Bridged Local Area Networks", October 1996
IEEE P802.1p/D4
[3] "Integrated Services in the Internet Architecture: an Overview"
RFC1633, June 1994
[4] "Resource Reservation Protocol (RSVP) - Version 1 Functional
Specification" Internet Draft, November 1996
<draft-ietf-rsvp-spec-14.ps
[5] "Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) Access Method and Physical Layer Specifications"
ANSI/IEEE Std 802.3-1985.
[6] "Token-Ring Media Access Control"
IEEE Std 802.5
[7] "A Framework for Providing Integrated Services Over Shared and
Switched LAN Technologies", Internet Draft, November 1996
<draft-ghanwani-framework-is-lan-01.txt
[8] "Specification of the Controlled-Load Network Element Service",
Internet Draft, August 1996,
<draft-ietf-intserv-ctrl-load-svc-03.txt
[9] "Specification of Guaranteed Quality of Service",
Internet Draft, August 1996,
<draft-ietf-intserv-guaranteed-svc-06.txt
16. Security Considerations
Security issues are not addressed in this memo.
Seaman, Smith, Crawley Expires May 1997 [Page 18]
INTERNET DRAFT Intserv over IEEE 802.1D/p November 1996
17. Authors' addresses
Mick Seaman
3Com Corp.
5400 Bayfront Plaza
Santa Clara CA 95052-8145
USA
+1 (408) 764 5000
mick_seaman@3com.com
Andrew Smith
Extreme Networks
1601 S De Anza Blvd. #220
Cupertino CA 95014
USA
+1 (408) 342 0999
andrew@extremenetworks.com
Eric Crawley
Bay Networks
3 Federal St.
Billerica MA 01821
USA
+1 (508) 670 8888
esc@baynetworks.com
Seaman, Smith, Crawley Expires May 1997 [Page 19]