Skip to main content

A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic
draft-aboulmagd-trtcm-inprofile-02

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4115.
Authors Sameh Rabie , Osama Aboul-Magd
Last updated 2013-03-02 (Latest revision 2004-11-30)
RFC stream Independent Submission
Intended RFC status Informational
Formats
Stream ISE state (None)
Consensus boilerplate Unknown
Document shepherd (None)
IESG IESG state Became RFC 4115 (Informational)
Action Holders
(None)
Telechat date (None)
Responsible AD Jon Peterson
Send notices to (None)
draft-aboulmagd-trtcm-inprofile-02
Network Working Group                             Osama Aboul-Magd 
   Internet Draft                                         Sameh Rabie 
   Expires: April 2005                                                
   Category: Informational                            Nortel Networks 
                                                                      
                                                        November 2004 
                                                                         
    
    A Differentiated Service Two Rate Three Color Marker for Efficient 
                      handling of in-Profile Traffic  
                  draft-aboulmagd-trTCM-inprofile-02.txt 
    
    
    
    
   Status of this Memo 
    
   By submitting this Internet-Draft, we represent that any applicable 
   patent or other IPR claims of which we are aware have been disclosed, 
   or will be disclosed, and any of which we are aware have been or will 
   be disclosed, and any of which we become aware will be disclosed in 
   accordance with RFC 3668. 
    
   This document is an Internet-Draft and is in full conformance with 
   Sections 5 and 6 of RFC 3667 and Section 5 of RFC 3668. 
    
   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. 
    
    
   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 of the in-profile traffic. 
   Furthermore this marker doesnÆt impose peak rate shaping 
   requirements on customer edge (CE) devices. 
    
    
    
     
   Aboul-Magd            Expires: April 2005                 [Page 1] 

   Internet Draft   draft-aboulmagd-trTCM-inprofile-02.txt   Nov. 2004 
    
    
 
    
   1.  
      Introduction 
    
   The differentiated service defines a quality of service (QoS) 
   architecture for the Internet [RFC2475]. Integral component of this 
   architecture are traffic metering and marking. This document 
   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 
   [RFC2697] and [RFC2698]. It is different from [RFC2697] in that it 
   is a two-rate, three-color marker. In contrast [RFC2697] is a single 
   rate marker. It is different from [RFC2698] 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 [RFC2698] 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 [RFC2698].  
    
 
   2.  
      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. 
    
    
   3.  
      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. 

    

     
   Aboul-Magd            Expires: April 2005                 [Page 2] 

   Internet Draft   draft-aboulmagd-trTCM-inprofile-02.txt   Nov. 2004 
    
    
   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 EBS. 
    
   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 
    
   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 
   [RFC2698] 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: 
    
    
    
    
    
     
   Aboul-Magd            Expires: April 2005                 [Page 3] 

   Internet Draft   draft-aboulmagd-trTCM-inprofile-02.txt   Nov. 2004 
    
                +---------------------------------+ 
                |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-) |     +---------------+ 
                       \----------------/ 
                               | 
                               | 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. 
    
 
   4.  
      Service Scenario 
    
   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 service rates, 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. 
    
   5.  
      Security Considerations 
    
   Security issues resulting from this document are similar to those 
   mentioned in RFC[2697] and RFC[2698]. 
    
    
     

   Aboul-Magd            Expires: April 2005                 [Page 4] 

   Internet Draft   draft-aboulmagd-trTCM-inprofile-02.txt   Nov. 2004 
    
   6.  
      Informative References 
    
   [RFC2475] "An Architecture for Differentiated Service", RFC 2475, 
   December 1998. 
    
   [RFC2697] "A Single Rate Three Color Marker", RFC 2697, September 
   1999. 
    
   [RFC2698] "A Two Rate Three Color Marker", RFC 2698, September 1999. 
    
   7.  
      Authors' Addresses 
    
   Osama Aboul-Magd 
   Nortel Networks 
   3500 Carling Ave 
   Ottawa, ON K2H8E9 
   Email: osama@nortelnetworks.com 
    
   Sameh Rabie 
   Nortel Networks 
   3500 Carling Ave 
   Ottawa, ON K2H8E9 
   Email: rabie@nortelnetworks.com       
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
     

   Aboul-Magd            Expires: April 2005                 [Page 5] 

   Internet Draft   draft-aboulmagd-trTCM-inprofile-02.txt   Nov. 2004 
    
    
    
   8.  
      Full Copyright Statement 
    
   Copyright (C) The Internet Society (2004). This document is subject 
   to the rights, licenses and restrictions contained in BCP 78 and 
   except as set forth therein, the authors retain all their rights. 
    
   This document and the information contained herein are provided on 
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    
    
   Intellectual Property 
    
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights. Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org. 
    
   Acknowledgement 
    
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 

    
     
   Aboul-Magd            Expires: April 2005                 [Page 6]