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


. 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.


. 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.



. 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.



. Security Considerations

   Security considerations are not addressed in this document.


. References

   [] S. Floyd, V. Jacobsen, "Random Early Detection Gateways for
   Congestion Avoidance," ftp://ftp.ee.lbl.gov/papers/early.ps.gz

   [] R. Braden, D. Clark, S. Shenker, "Integrated Services in the
   Internet Architecture: an Overview", RFC 1633, June 1994.

   [] E. Rosen, et al., "Tag Switching: Tag Stack Encodings," draft-
   rosen-tag-stack-00.txt.

   [] Y. Rekhter, et al., "Tag Switching Architecture Overview,"
   draft-rfced-tag-switching-overview-00.txt.

   [] P. Doolan, et al., "Tag Distribution Protocol," draft-doolan-
   tdp-spec-00.txt.

   [] 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


   [] B. Davie et al., "Use of Tag Switching With ATM", draft-davie-
   tag-switching-atm-00.txt


. Acknowledgments

   Significant contributions to this work have been made by David
   Hughes, Jeremy Lawrence, Joe Lawrence, and Eric Rosen.


. 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]