draft-aboulmagd-trtcm-inprofile-02.txt  -->   rfc4115.txt

view Side-By-Side changes






Network Working Group                             Osama                                      O. Aboul-Magd 
   Internet Draft                                         Sameh
Request for Comments: 4115                                      S. Rabie 
   Expires: April 2005
Category: Informational                                  Nortel Networks 
                                                                      
                                                        November 2004
                                                               July 2005


       A Differentiated Service Two Rate Three Color Two-Rate, Three-Color Marker for with
               Efficient 
                      handling Handling of in-Profile Traffic  
                  draft-aboulmagd-trTCM-inprofile-02.txt

Status of this 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

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of which we are aware have been or will 
   be disclosed, and any kind.  Distribution of which we become aware will be disclosed in 
   accordance with RFC 3668. 
    
   This document is an Internet-Draft and this
   memo is in full conformance with 
   Sections 5 and 6 of unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

IESG Note

   This RFC 3667 and Section 5 is not a candidate for any level of RFC 3668. 
    
   Internet-Drafts are working documents Internet Standard.  The
   IETF disclaims any knowledge 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 fitness of six months 
   and may be updated, replaced, or obsoleted by other documents at this RFC for any 
   time. It is inappropriate
   purpose and in particular notes that the decision to use Internet-Drafts publish is not
   based on IETF review for such things as reference 
   material security, congestion control,
   or to cite them other than as "work in progress." inappropriate interaction with deployed protocols.  The list of current Internet-Drafts can be accessed RFC Editor
   has chosen to publish this document at 
   http://www.ietf.org/ietf/1id-abstracts.txt. 
    
   The list its discretion.  Readers of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html.
   this document should exercise caution in evaluating its value for
   implementation and deployment.  See RFC 3932 for more information.

Abstract

   This document describes a two rate three color 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
   Furthermore, this marker doesnĘt doesn't impose peak rate 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 quality-of-service (QoS)
   architecture for the Internet [RFC2475]. Integral component  Two integral components of
   this architecture are traffic metering and marking.  This document
   describes a two rate three color two-rate, three-color metering/marker algorithm that is





Aboul-Magd & Rabie           Informational                      [Page 1]

RFC 4115        Efficient Handling of in-Profile Traffic       July 2005


   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, two-
   rate, three-color marker.  In contrast contrast, [RFC2697] is a single 
   rate single-rate
   marker.  It is different from [RFC2698] in the way its parameters are defined
   defined, which allows a better handling of in-profile traffic for
   predominant service scenarios over a wider range of traffic
   parameters. 
    
   Furthermore

   Furthermore, the algorithm described here eliminates the need for the
   CE to shape its traffic to a certain peak information rate (PIR) (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 modes, as defined in [RFC2698].

2.  Configuration

   The operation of the marker is described by two rate values, those 
   are the values.  The
   committed information rate (CIR) and the excess information rate
   (EIR). Each of  CIR and EIR defines define the token generation rate of a token
   bucket with size that is equal to committed burst size (CBS) and
   excess burst size (EBS) (EBS), respectively.

   The CBS and EBS are measured in bytes and must configure to be
   greater than the expected maximum length of the incoming PDU. Both  The
   CIR and EIR are both measured in bits/s.  The CIR and EIR can be set 
   independent
   independently of each other. Alternatively  Alternatively, the CIR and EIR can be
   linked together by defining a burst duration parameter 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 the rates, CIR and EIR respectively EIR, respectively,
   and maximum size sizes 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. full; i.e., the
   token count Tc(0) = CBS and Te(0) = EBS. Thereafter  Thereafter, the token counts count
   Tc is incremented by one CIR times per second up (up to CBS CBS), and the
   token count Te is incremented by one EIR times per second up (up to EBS.
   EBS).




Aboul-Magd & Rabie           Informational                      [Page 2]

RFC 4115        Efficient Handling of in-Profile Traffic       July 2005


   In the color aware operation color-aware operation, it is assumed that the algorithm can
   recognize the color of the incoming packet (Green, (green, yellow, or red).
   The color-aware operation of the metering is: is described below.

   When a green packet of size B arrives at time t, then

      o  if Tc(t)- B > 0, the packet is green green, and Tc(t) is decremented
         by      
     B, B; else

      o  if Te(t)- B > 0, the packet is yellow yellow, and Te(t) is decremented
         by 
     B, B; else

      o  the packet is red red.

   When a yellow packet of size B arrives at time t, then

      o  if Te(t)- B > 0, the packet is yellow yellow, and Te(t) is decremented
         by 
     B, B; else

      o  the packet is red red.

   Incoming red packets are not tested against any of the two token
   buckets and remain red.

   In the color blind operation 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 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 directly, without the need to
   pass additional conformance tests.  This feature is the main
   differentiator of this algorithm compared to from that described in 
   [RFC2698] [RFC2698],
   where traffic is marked green after it passes two conformance tests
   (those for PIR and CIR).  In either color blind color-blind or 
   color aware modes color-aware mode,
   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 color-aware mode
   of operation, the need to pass two conformance tests could result in make
   yellow traffic starving starve incoming in-profile green packets.












Aboul-Magd & Rabie           Informational                      [Page 3]

RFC 4115        Efficient Handling of in-Profile Traffic       July 2005


   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.













Aboul-Magd & Rabie           Informational                      [Page 4]

RFC 4115        Efficient Handling of in-Profile Traffic       July 2005


4.  Service Scenario

   The described marker can be used to mark an IP packet stream in a 
   service,
   service where different, decreasing levels of assurances (either
   absolute or relative) are given to packets which that are green, yellow, or
   red.  For example, a service may discard all red packets, 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] [RFC2697] and RFC[2698]. 
    
    
     
   Aboul-Magd            Expires: April 2005                 [Page 4] 
   Internet Draft   draft-aboulmagd-trTCM-inprofile-02.txt   Nov. 2004 [RFC2698].

6.  Informative References

   [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
             and W. Weiss, "An Architecture for Differentiated Service",
             RFC 2475, December 1998.

   [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
             Marker", RFC 2697, September 1999.

   [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color
             Marker", RFC 2698, September 1999. 
    
   7.

   [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents:
             Procedures", BCP 92, RFC 3932, October 2004.

Authors' Addresses

   Osama Aboul-Magd
   Nortel Networks
   3500 Carling Ave
   Ottawa, ON K2H8E9 
   Email: osama@nortelnetworks.com
   EMail: osama@nortel.com

   Sameh Rabie
   Nortel Networks
   3500 Carling Ave
   Ottawa, ON K2H8E9 
   Email: rabie@nortelnetworks.com
   EMail: rabie@nortel.com







Aboul-Magd            Expires: April 2005 & Rabie           Informational                      [Page 5] 
   Internet Draft   draft-aboulmagd-trTCM-inprofile-02.txt   Nov. 2004 
    
    
    
   8.

RFC 4115        Efficient Handling of in-Profile Traffic       July 2005


Full Copyright Statement

   Copyright (C) The Internet Society (2004). (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78 and at www.rfc-editor.org/copyright.html, 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 & Rabie           Informational                      [Page 6]

----