GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4115

Network Working Group O. Aboul-Magd Request for Comments: 4115 S. Rabie Category: Informational Nortel Networks

                                                             July 2005
     A Differentiated Service Two-Rate, Three-Color Marker with
             Efficient Handling of in-Profile Traffic

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).

IESG Note

 This RFC is not a candidate for any level of Internet Standard.  The
 IETF disclaims any knowledge of the fitness of this RFC for any
 purpose and in particular notes that the decision to publish is not
 based on IETF review for such things as security, congestion control,
 or inappropriate interaction with deployed protocols.  The RFC Editor
 has chosen to publish this document at its discretion.  Readers of
 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 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.

1. Introduction

 The differentiated service defines a quality-of-service (QoS)
 architecture for the Internet [RFC2475].  Two integral components of
 this architecture are traffic metering and marking.  This document
 describes a 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, 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.  The
 committed information rate (CIR) and the excess information rate
 (EIR).  CIR and EIR define 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 the incoming PDU.  The
 CIR and EIR are both measured in bits/s.  The CIR and EIR can be set
 independently of each other.  Alternatively, the 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 the rates, CIR and EIR, respectively,
 and maximum sizes 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 count
 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).

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

 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 described below.
 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
 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 from 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 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 mode
 of operation, the need to pass two conformance tests could make
 yellow traffic 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:
                 +---------------------------------+
                 |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 where different, decreasing levels of assurances (either
 absolute or relative) are given to packets that 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 [RFC2697] and [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.
 [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@nortel.com
 Sameh Rabie
 Nortel Networks
 3500 Carling Ave
 Ottawa, ON K2H8E9
 EMail: rabie@nortel.com

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

Full Copyright Statement

 Copyright (C) The Internet Society (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 & Rabie Informational [Page 6]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4115.txt · Last modified: 2005/07/01 22:16 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki