Internet Draft 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]