trTCM: A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic
A two-rate, three-color traffic marker that sorts data packets by how much bandwidth they use.
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.
AI ELI5
On this page
§1What the Marker Does
The trTCM (two-rate, three-color marker) is an algorithm for metering and marking data packets in a computer network. It has been widely used in Frame Relay services and is now used in differentiated services (DiffServ) for IP and L2 VPN services. The marker measures each arriving packet against two rate limits and assigns it a color: green for packets within the committed rate, yellow for packets within an excess rate, and red for packets exceeding both rates.
The marker is different from earlier markers like RFC 2697 (single-rate, three-color) and RFC 2698 (two-rate, three-color). The trTCM improves on RFC 2698 by handling in-profile traffic more efficiently and not requiring customer edge devices to shape traffic to a peak rate.
A network device watches how fast data flows and stamps each packet with a color: green if it is within the customer's committed rate, yellow if it is within a higher excess rate, and red if it exceeds both.
§2Configuration Parameters
The marker is configured with four main parameters. The committed information rate (CIR) is the baseline rate at which tokens are added to a bucket. The committed burst size (CBS) is the maximum tokens that bucket can hold. The excess information rate (EIR) is a second, usually higher, rate at which a second bucket receives tokens. The excess burst size (EBS) is the maximum for that bucket.
CIR and EIR are measured in bits per second and can be set independently, or they can be linked by a burst duration parameter T, where T = CBS/CIR = EBS/EIR. CBS and EBS are measured in bytes and must be larger than the largest packet the marker will see.
You set a committed speed and burst amount for normal traffic, and a separate excess speed and burst amount for extra traffic.
§3How the Algorithm Works
The marker maintains two token buckets, C and E, that start full. Tokens flow in at rates CIR and EIR respectively, up to sizes CBS and EBS. When a packet arrives, the algorithm checks it in order.
In color-blind mode, all packets start as green. If the packet fits in bucket C, it is marked green and tokens are removed from C. If not, but it fits in bucket E, it is marked yellow and tokens are removed from E. If it fits neither, it is marked red. In color-aware mode, incoming packets that are already colored yellow or red are handled differently—a yellow packet only checks bucket E, and red packets skip all checks.
The key difference from RFC 2698 is that packets within the CIR are marked green immediately, without needing to pass a second test. This means in-profile traffic (traffic within the committed rate) is never dropped just to check a peak rate, making the marker simpler and fairer.
Two buckets of tokens fill up at different rates. Each packet dips into one bucket or the other. If both buckets are empty, the packet is marked red and might be dropped.
Packet of size B arrives
|
v
Is B <= Tc(t)?
|YES -> Mark GREEN, Tc -= B
|NO
v
Is B <= Te(t)?
|YES -> Mark YELLOW, Te -= B
|NO
v
Mark RED§4Color Meanings and Use
The three colors represent service priorities. Green packets are within the committed rate and should be forwarded with minimal loss. Yellow packets are between the committed and excess rates and might be forwarded as best effort or with higher drop probability. Red packets exceed both rates and may be discarded. Different services can use the colors differently: a premium service might discard all red and some yellow, while a best-effort service might discard only red.
The marker can be used in two modes. In color-blind mode, the algorithm assumes all arriving packets are green. In color-aware mode, the algorithm recognizes packets that already have a color from an earlier marking stage and respects that color when deciding which bucket to check.
Green packets get through easily, yellow packets might get dropped if the network is busy, and red packets usually get dropped. This lets the network manage congestion fairly.