trTCM: A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic
A traffic marker that lets in-profile traffic straight through instead of testing it twice.
Aboul-Magd, O. and S. Rabie, "A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic", RFC 4115, DOI 10.17487/RFC4115, July 2005, <https://www.rfc-editor.org/info/rfc4115>.
@misc{rfc4115,
series = {Request for Comments},
number = 4115,
howpublished = {RFC 4115},
publisher = {RFC Editor},
doi = {10.17487/RFC4115},
url = {https://www.rfc-editor.org/info/rfc4115},
author = {O. Aboul-Magd and S. Rabie},
title = {{A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic}},
pagetotal = 6,
year = 2005,
month = jul,
} RFC text
Contents
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
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).
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.
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.
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
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.
ISO Plain Language
On this page
§1What This Marker Is For
The differentiated service defines a quality-of-service architecture for the Internet. Two integral components of that architecture are traffic metering and marking. RFC 4115 describes a two-rate, three-color metering and marker algorithm suitable for differentiated service applications such as IP and Layer 2 VPNs, an algorithm that has been in use for data services including Frame Relay service.
The marker defined here is different from those in RFC 2697 and RFC 2698. It is different from RFC 2697 in that it is a two-rate, three-color marker, where RFC 2697 is a single-rate marker. It is different from RFC 2698 in the way its parameters are defined, which allows better handling of in-profile traffic for predominant service scenarios over a wider range of traffic parameters.
Furthermore, the algorithm eliminates the need for the customer edge device to shape its traffic to a certain peak information rate, as might be the case for the marker defined in RFC 2698 when the value for the peak burst size is smaller than that for the committed burst size. The marker described here operates for both color-blind and color-aware modes, as defined in RFC 2698.
Networks that sell different levels of service need to measure each customer's traffic and say which packets meet the promise and which do not. This memo describes one way of doing that, and the reason it exists is a fairness problem: a packet that is well within the customer's rate should not be thrown away because of a second, higher test it did not need to pass.
| Aspect | RFC 2697 | RFC 2698 | This marker |
|---|---|---|---|
| Number of rates | One | Two: a peak information rate and a committed information rate | Two: a committed information rate and an excess information rate |
| Tests before a packet is green | One | Two, one for the peak rate and one for the committed rate | One, against the committed rate |
| Effect on in-profile traffic | Not described | Can be dropped at the peak rate bucket even though it is within the committed rate | Coloured green directly, with no second test |
| Shaping needed at the customer edge | Not described | May be needed when the peak burst size is smaller than the committed burst size | Not needed |
§2Configuration: Rates and Bursts
The operation of the marker is described by two rate values, the committed information rate and the excess information rate, and two burst sizes. The committed information rate and the excess information rate define the token generation rate of a token bucket whose size is equal to the committed burst size and the excess burst size respectively.
The burst sizes are measured in bytes and must be configured to be greater than the expected maximum length of the incoming PDU. The two rates are both measured in bits per second. They can be set independently of each other. Alternatively they can be linked together by defining a burst duration parameter T, where T equals CBS/CIR and also equals EBS/EIR.
Four numbers describe the marker. The committed rate is what the customer has paid for, the excess rate is what they may use beyond that, and the two burst sizes say how much of each may be sent in one go before the rate is enforced. The two rates can be set separately or tied together by a single burst duration.
- CIRThe committed information rate, in bits per second. The rate at which the C token bucket refills.
- EIRThe excess information rate, in bits per second. The rate at which the E token bucket refills. It can be set independently of the CIR.
- CBSThe committed burst size, in bytes. The maximum size of the C token bucket. It must be greater than the expected maximum length of the incoming PDU.
- EBSThe excess burst size, in bytes. The maximum size of the E token bucket, with the same requirement on the incoming PDU length.
- TThe burst duration, which links the two rates together: T equals CBS/CIR and also equals EBS/EIR.
§3Metering and Marking
The behaviour of the meter is defined in terms of its mode and two token buckets, C and E, with the rates CIR and EIR and maximum sizes CBS and EBS. The token buckets C and E are initially, at time 0, full, so the token count Tc(0) equals CBS and Te(0) equals 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. The memo's flow chart expresses this as a periodic update of Tc and Te every T seconds.
In the color-aware operation it is assumed that the algorithm can recognize the color of the incoming packet, which may be green, yellow or red. When a green packet of size B arrives at time t, then if Tc(t) minus B is greater than zero, the packet is green and Tc(t) is decremented by B; otherwise, if Te(t) minus B is greater than zero, the packet is yellow and Te(t) is decremented by B; otherwise the packet is red. When a yellow packet of size B arrives at time t, then if Te(t) minus B is greater than zero, the packet is yellow and Te(t) is decremented by B; otherwise the packet is red. Incoming red packets are not tested against either of the two token buckets and remain red.
In the color-blind operation the meter assumes that all incoming packets are green, and the operation is similar to that in the color-aware operation for green packets.
The salient feature of the algorithm is that traffic within the defined CIR is coloured green directly, without the need to pass additional conformance tests. That is the main differentiator from the algorithm in RFC 2698, 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, that is, in-profile traffic. Furthermore, in the color-aware mode, the need to pass two conformance tests could make yellow traffic starve incoming in-profile green packets.
Two counters fill up over time, one at the committed rate and one at the excess rate, and a packet has to fit in a counter to be coloured. The difference from the older marker is that only one counter has to be checked for the common case: a packet that fits the committed counter is green, immediately, and only the packets that do not fit go on to the second test.
- GreenWithin the committed rate — Tc(t) minus B is greater than zero, so the packet is green and Tc(t) is decremented by B.
- YellowBeyond the committed rate — Tc(t) minus B is not greater than zero but Te(t) minus B is, so the packet is yellow and Te(t) is decremented by B.
- RedBeyond both rates — Neither bucket has room for the packet, so it is red. Incoming red packets are not tested against either bucket and stay red.
§4The Service Scenario
The 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. The memo's example is a service that discards all red packets because they exceeded the service rates, forwards yellow packets as best effort, and forwards green packets with low drop probability. The marker could also be used for metering Layer 2 VPN services such as the emerging Ethernet transport over IP networks.
The colours are what the rest of the network acts on. A service might throw away everything red, treat yellow as best effort, and give green a low chance of being dropped. The marker itself only decides the colour; what each colour is worth is a decision for whoever is running the service.
§5Security Considerations
The memo says that the security issues resulting from this document are similar to those mentioned in RFC 2697 and RFC 2698.
The security questions here are the same ones that apply to the older markers, because this document does not introduce anything new in that area.