Network Working Group Arthur Lin
Internet Draft Cisco Systems, Inc.
Expiration Date: June 1997
Bruce Davie
Cisco Systems, Inc.
Fred Baker
Cisco Systems, Inc.
December 1996
Tag Switching Support for Classes of Service
draft-lin-tags-cos-00.txt
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
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.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
A tag switching architecture is described in [1]. This document
describes how classes of service can be provided in the tag switching
architecture. The cases of frame-based tag switching routers (TSRs)
and ATM-based TSRs are considered.
Lin, et al. [Page 1]
Internet Draft draft-lin-tags-cos-00.txt December 1996
1. Introduction
A tag switching architecture is described in [4]. This document
describes the support of class of service (COS) in a tag switched
network. COS is a relatively simple way to provide a range of
qualities of service. An alternative scheme involving RSVP is
described in [6].
The basic idea behind COS support is to sort traffic into a small
number of classes, e.g. premium and standard, and to tag the packets
appropriately. The tags are then used to determine the appropriate
handling for packets in different classes, so that different
qualities of service can be provided to each class.
The policies that are used to determine how packets are sorted into
the classes are largely outside the scope of this proposal, but we
provide some examples here for illustrative purposes. Some example
policies might be `all packets from customer X go in the premium
class' or `at most 1Mbps of traffic from customer Y goes in the
premium class'.
At any multiplexing point in the network (e.g. a switch or router),
the packet scheduling and dropping policies of switches or routers
are determined by the class to which packets belong. In the example
above, one would expect that the overall service given to packets in
the premium class would be `better' than that given to the standard
class; for example, the premium class might experience lower loss
rate or delay.
We propose the following process of providing different classes of
service in a network:
- classify packets according to some local policy as they enter
the network;
- identify the class of the packet in a way that switches and
routers will be readily able to use as the packets traverse the
network;
- use scheduling and buffer management algorithms in the switches
and routers that are dependent on the class of the packets.
Three main capabilities are required to support this process:
- a way to classify packets
Lin, et al. [Page 2]
Internet Draft draft-lin-tags-cos-00.txt December 1996
- a way to encode the class in the packet
- queueing disciplines.
Tag switching primarily helps us with the second. It also provides a
means by which we can take advantage of the queueing disciplines of
`layer 2' switches to support COS at layer 3.
The actual mechanisms used for scheduling and discarding packets are
largely orthogonal to the use of tag switching. By way of
illustration, we consider the example of class-based weighted fair
queuing (WFQ) - this is essentially the idea of controlled link-
sharing in [2]. Assume we have 2 classes again, and that the offered
load for premium traffic is less than that for standard traffic. We
could use class-based WFQ to assign 50% of the link bandwidth to each
class. Class-based WFQ ensures that, under congestion, each class
gets its allotted share of the link bandwidth, but it doesn't prevent
another class from using that capacity if it is available. The effect
during times of congestion is as if the premium traffic is running on
a more lightly loaded network.
Clearly the example above is rather simplistic. The network operator
would need to assign weights to the different classes based on offer
load for the classes. Assigning the weights is very similar to
engineering a single class network (there needs to be enough
bandwidth to carry the offered load at acceptable performance) which
is challenging, but moderately well understood. However, there are at
least two advantages in a multiple class network. First, it is much
easier to change the weight of a class (configuration rather than
trench digging). Also, it is possible to share bandwidth between the
classes - for example, the standard class can use 100% of the link if
there is no premium traffic at some point in time [2].
The major contribution of tag switching to the COS problem is to
provide a simple way to encode the class of a packet so that it can
be scheduled appropriately. In the following sections, we discuss two
cases of COS support which exhibit some significant differences:
frame-based tag switching routers (TSRs), and ATM TSRs.
Lin, et al. [Page 3]
Internet Draft draft-lin-tags-cos-00.txt December 1996
1.1. Definitions
A Tag Switching Router (TSR) is a device which implements the tag
switching control and forwarding components described in [4].
A tag switching controlled ATM (TC-ATM) interface is an ATM interface
controlled by the tag switching control component. Packets traversing
such an interface carry tags in the VCI and/or VPI field.
An ATM-TSR is a TSR with a number of TC-ATM interfaces which forwards
cells between these interfaces using tags carried in the VCI and/or
VPI field.
An ATM-TSR which is capable of taking cells from several incoming VCs
(tags) and transitting them on a single outgoing VC (tag) while
preserving correct packet boundaries is said to perform `VC-merge'.
An ATM-TSR cloud is a set of ATM-TSRs which are mutually
interconnected by TC-ATM interfaces.
A frame-based TSR is a TSR which forwards complete frames between its
interfaces. Note that such a TSR may have zero, one or more TC-ATM
interfaces.
2. Frame-based TSRs
For frame-based TSRs, the tag encapsulation includes a precedence or
class of service (COS) field [3]. Thus, it is simple to use this
field to represent the class of the packet and to perform appropriate
scheduling and buffer management on it.
Since it is not expected that tag switching will be universally
deployed, it is worth considering the case where tag switching is
deployed in some part of an IP network. Since the IP header contains
a precedence field that could also be used to convey the class of a
packet, it is possible that COS capabilities could be provided on
both the tag-switched and non-tag-switched parts of the network.
There are at least two cases to consider:
- IP Precedence is set before the packet arrives at an edge TSR
which will apply the first tag (i.e. the packet has already been
classified when it reaches the first TSR). In this case, it needs
to be possible to (a) copy the precedence value from the IP header
into the COS field of the tag header; (b) use the COS value in the
tag header and the IP precedence in identical ways to drive the
packet scheduling and buffer management mechanisms in the routers.
Lin, et al. [Page 4]
Internet Draft draft-lin-tags-cos-00.txt December 1996
- Classification is performed at the same router which is
applying the first tag. In this case, it is possible that one
would want to put the appropriate COS value in both the IP header
and the tag header, so that appropriate packet handling can be
performed after the tag is removed; alternatively, one might wish
to preserve the original precedence value in the IP header, which
may have meaning to the end systems. This would be an
administrative choice.
3. ATM Switches
There is a significant difference between ATM TSRs and frame-based
TSRs in the context of COS. This is because we cannot readily put a
precedence field in the tag header for ATM, the only useful space for
the tag header being the ATM VPI/VCI field. In addition, there may be
other differences depending on the scheduling and queue management
mechanisms that a switch can support. These two aspects are discussed
in the following sections.
3.1. Precedence encoding
The most straightforward way to encode precedence values in a tag-
switched ATM environment is to use multiple tags per destination
prefix. Note that in an ATM environment where the TSRs are not VC-
merge capable, tag allocation is driven primarily by routers or
frame-based TSRs at the edges of the ATM-TSR cloud (the `edge set' of
the cloud). While it would be possible to allocate 8 tags per prefix
corresponding to the 8 possible values of the COS field, it is
preferable to conserve tags by allocating only as many as are needed.
We propose two methods to conserve tag space:
1. The members of the edge set of the ATM-TSR cloud are configured
to support some number of COS classes (8 or fewer). Using the
downstream-on-demand allocation of tags [7], they will then
request an appropriate number of tags per destination prefix; this
will percolate though the ATM-TSR cloud, establishing the correct
number of tags at each ATM-TSR. No special configuration of the
ATM-TSRs is needed.
2. The members of the edge set of the ATM-TSR cloud request one
tag per destination prefix, as described in [7]. All traffic would
be initially forwarded using this tag, but the arrival of data
traffic with multiple COS values would cause the edge TSR to
request additional tags corresponding to the number of COS classes
Lin, et al. [Page 5]
Internet Draft draft-lin-tags-cos-00.txt December 1996
that are active.
In either approach, there is a need for TDP bind request messages and
the responses to include the precedence to which the tag will be
bound. This modification will be included in the next release of tag
distribution protocol internet draft [5].
3.2 COS mechanisms
Clearly the packet scheduling and buffer management mechanisms
available in an ATM-TSR will vary widely among implementations. Some
ATM switches may be able to support class-based WFQ as described
above. Note that the desired behavior for a ATM-TSR is to group all
the traffic of a particular precedence value together as a single WFQ
class. Thus, for example, in the 2-class example in which each class
has equal weight, we want to group all traffic with `premium' tags
together and make sure that, under congestion, this aggregate gets at
least 50% of the link. This is very different from the per-VC WFQ
provided in some switches.
4. Security Considerations
Security considerations are not addressed in this document.
5. References
[1] S. Floyd, V. Jacobsen, "Random Early Detection Gateways for
Congestion Avoidance," ftp://ftp.ee.lbl.gov/papers/early.ps.gz
[2] R. Braden, D. Clark, S. Shenker, "Integrated Services in the
Internet Architecture: an Overview", RFC 1633, June 1994.
[3] E. Rosen, et al., "Tag Switching: Tag Stack Encodings," draft-
rosen-tag-stack-00.txt.
[4] Y. Rekhter, et al., "Tag Switching Architecture Overview,"
draft-rfced-tag-switching-overview-00.txt.
[5] P. Doolan, et al., "Tag Distribution Protocol," draft-doolan-
tdp-spec-00.txt.
[6] F. Baker and Y. Rekhter. "Tag Switching with RSVP", draft-baker-
tags-rsvp-00.txt
Lin, et al. [Page 6]
Internet Draft draft-lin-tags-cos-00.txt December 1996
[7] B. Davie et al., "Use of Tag Switching With ATM", draft-davie-
tag-switching-atm-00.txt
6. Acknowledgments
Significant contributions to this work have been made by David
Hughes, Jeremy Lawrence, Joe Lawrence, and Eric Rosen.
7. Authors' Addresses
Arthur Lin
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA 95134
E-mail: alin@cisco.com
Bruce Davie
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
E-mail: bsd@cisco.com
Fred Baker
Cisco Systems, Inc.
519 Lado Drive
Santa Barbara, CA 93111
E-mail: fred@cisco.com
Lin, et al. [Page 7]