Internet DRAFT - draft-aboulmagd-trTCM-inprofile

draft-aboulmagd-trTCM-inprofile





Network Working Group                                 Osama Aboul-Magd 
Internet Draft                                             Sameh Rabie 
Document: draft-aboulmagd-trTCM-inprofile-00.txt                       
Category: Informational                                Nortel Networks 
                                                       September, 2003 


         Two Rate Three Color Marker for Efficient Handling of 
                           In-Profile Packets  


Status of this Memo 

   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [1].  

   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."  
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt  
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
    
1. Abstract 
    
   This document describes a two rate three color marker that has been 
   in use for data services including Frame Relay services. This marker 
   can be used for metering per-flow traffic in the emerging IP and L2 
   VPN services. The marker defined here is different from previously 
   defined markers in the handling and guarantee afforded to the in-
   profile traffic. Furthermore this marker doesnÆt impose peak rate 
   shaping requirements on customer edge (CE) devices. 
    
    
2. Conventions used in this document 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
   this document are to be interpreted as described in RFC-2119 [2]. 
    
    
3. Introduction 
    
   The differentiated service defines a quality of service (QoS) 
   architecture for the Internet [3]. Integral component of this 
   architecture are traffic metering and marking. This document 
 
Aboul-Magd               Expires April 2004                         1 
     Draft-aboulmagd-trTCM-inprofile-00.txt      September 2004 


   describes a two rate three color metering/marker algorithm that is 
   suitable for the differentiated service applications such as IP and 
   L2 VPNs. This algorithm has been in use for data services including 
   Frame Relay Service. 
    
   The metering/marker defined here is different from those in [4] and 
   [5]. It is different from [4] in that it is a two-rate, three-color 
   marker. In contrast [4] is a single rate marker. It is different 
   from [5] in the way its parameters are defined which allows a better 
   handling of in-profile traffic for predominant service scenarios 
   over a wider range of traffic parameters. 
    
   Furthermore the algorithm described here eliminates the need for the 
   CE to shape its traffic to a certain peak information rate (PIR) as 
   might be the case for the marker defined in [5] when the value for 
   the peak burst size (PBS) is smaller than that for the committed 
   burst size (CBS).  
    
   The marker described here operates for both color-blind and color-
   aware modes as defined in [5] 
    
    
4. Configuration 
    
   The operation of the marker is described by two rate values, those 
   are the committed information rate (CIR) and the excess information 
   rate (EIR). Each of CIR and EIR defines the token generation rate of 
   a token bucket with size that is equal to committed burst size (CBS) 
   and excess burst size (EBS) respectively. 
    
   The CBS and EBS are measured in bytes and must configure to be 
   greater than the expected maximum length of incoming PDU. Both CIR 
   and EIR are measured in bits/s. The CIR and EIR can be set 
   independent of each other. Alternatively CIR and EIR can be linked 
   together by defining a burst duration parameter T, where 
   T=CBS/CIR=EBS/EIR. 
    
5. Metering and Marking 
    
   The behavior of the meter is defined in terms of its mode and two 
   token buckets, C and E, with rate CIR and EIR respectively and 
   maximum size CBS and EBS. 
    
   The token buckets C and E are initially (at time 0) full, i.e. the 
   token count Tc(0) = CBS and Te(0) = EBS. Thereafter the token counts 
   Tc is incremented by one CIR times per second up to CBS and the 
   token count Te is incremented by one EIR times per second up to CBS. 
    
   In the color aware operation it is assumed that the algorithm can 
   recognize the color of the incoming packet (Green, yellow, or red). 
   The color-aware operation of the metering is: 
    
   When a green packet of size B arrives at time t, then 
 
Aboul-Magd               Expires April 2004                         2 
     Draft-aboulmagd-trTCM-inprofile-00.txt      September 2004 


    
   o if Tc(t)- B > 0, the packet is green and Tc(t) is decremented by      
     B, else 
    
   o if Te(t)- B > 0, the packet is yellow and Te(t) is decremented by 
     B, else 
    
   o the packet is red 
    
   When a yellow packet of size B arrives at time t, then 
    
   o if Te(t)- B > 0, the packet is yellow and Te(t) is decremented by 
     B, else 
    
   o the packet is red 
    
   Incoming red packets are not tested against any of the two token 
   buckets and remain red. 
    
   In the color blind operation the meter assumes that all incoming 
   packets are green. The operation of the meter is similar to that in 
   the color aware operation for green packets. 
    
   The salient feature of the algorithm described above is that traffic 
   that is within the defined CIR is colored green directly without the 
   need to pass additional conformance tests. This feature is the main 
   differentiator of this algorithm compared to that described in [5] 
   where traffic is marked green after it passes two conformance tests 
   (those for PIR and CIR). In either color blind or color aware modes 
   the need to pass two conformance tests could result in packets  
   being dropped at the PIR token bucket even though they are perfectly 
   within their CIR (in-profile traffic). Furthermore, in the color 
   aware mode of operation, the need to pass two conformance tests 
   could result in yellow traffic starving incoming in-profile green 
   packets. 
    
   The operation of the algorithm is illustrated in the flow chart 
   below: 
    
                +---------------------------------+ 
                |periodically every T sec.        | 
                | Tc(t+)=MIN(CBS, Tc(t-)+CIR*T)   | 
                | Te(t+)=MIN(EBS, Te(t-)+EIR*T)   | 
                +---------------------------------+ 
    
       Packet of size     
           B arrives   /----------------\              
      ---------------->|color-blind mode|      
                       |       OR       |YES  +---------------+ 
                       |  green packet  |---->|packet is green|  
                       |      AND       |     |Tc(t+)=Tc(t-)-B| 
                       |    B <= Tc(t-) |     +---------------+ 
                       \----------------/ 
 
Aboul-Magd               Expires April 2004                         3 
     Draft-aboulmagd-trTCM-inprofile-00.txt      September 2004 


                               | 
                               | NO 
                               v 
                       /----------------\              
                       |color-blind mode|      
                       |       OR       |YES  +----------------+ 
                       | NOT red packet |---->|packet is yellow|  
                       |      AND       |     |Te(t+)=Te(t-)-B | 
                       |    B <= Te(t-) |     +----------------+ 
                       \----------------/ 
                               | 
                               | NO 
                               v 
                       +---------------+ 
                       |packet is red  | 
                       +---------------+ 
    
               Figure 1: Traffic Metering/Marking Algorithm 
    
   In Figure 1, we have X(t-) and X(t+) to indicate the value of a 
   parameter X right before and right after time t. 
    
6. Service Scenarios 
    
   The described marker can be used to mark an IP packet stream in a 
   service, where different, decreasing levels of assurances (either 
   absolute or relative) are given to packets which are green, yellow, 
   or red. For example, a service may discard all red packets, because 
   they exceeded the peak rate, forward yellow packets as best effort, 
   and forward green packets with low drop probability. The marker 
   could also be used for metering L2 VPN services such as the emerging 
   Ethernet transport over IP networks. 
    
7. Security Considerations 

   The marker/metering algorithm described here has no known security 
   concerns. 
    
    
8. References 
    

   1  Bradner, S., æThe Internet Standards Process -- Revision 3Æ, BCP 
      9, RFC 2026, October 1996. 
    
   2  Bradner, S., æKey words for use in RFCs to Indicate Requirement 
      LevelsÆ, BCP 14, RFC 2119, March 1997 
    
   3  Blake, S., et. al., æAn Architecture for Differentiated 
      ServicesÆ, RFC 2475, December 1998. 
    

 
Aboul-Magd               Expires April 2004                         4 
     Draft-aboulmagd-trTCM-inprofile-00.txt      September 2004 



   4  Heinanen, J., and Guerin, R., æA Single Rate Three Color MarkerÆ, 
      RFC 2697, September 1999. 
    
   5  Heinanen, J., and Guerin, R., æA Two Rate Three Color MarkerÆ, 
      RFC 2698, September 1999. 
    
    

    
9. Author's Addresses 
    
   Osama Aboul-Magd 
   Nortel Networks 
   P.O. Box 3511, Station C 
   Ottawa, ONT, Canada 
   K1Y-4H7 
   Phone: +1 613 763 5827 
   E.mail : osama@nortelnetworks.com 
    
   Sameh Rabie 
   Nortel Networks 
   P.O. Box 3511, Station C 
   Ottawa, ONT, Canada 
   K1Y-4H7 
   Phone: +1 613 765 2587 
   E.mail : rabie@nortelnetworks.com  
    
 
Aboul-Magd               Expires April 2004                         5 
     Draft-aboulmagd-trTCM-inprofile-00.txt      September 2004 


    
Full Copyright Statement 

   "Copyright (C) The Internet Society (date). All Rights Reserved. 
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implmentation may be prepared, copied, 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. 
 
Aboul-Magd               Expires April 2004                         6