RFC 2697

A Single Rate Three Color Marker

📅 published September 1999, from ietf

RFC 2697: A Single Rate Three Color Marker ✨

Network Working Group 🎀 RFC 2697, published September 1999

  • Authors: J. Heinanen (Telia Finland) and R. Guerin (University of Pennsylvania) 💅
  • Category: Informational 🦋
  • Obsoletes/Updates: nothing listed here 🌸

Status of this Memo

okay so this memo is giving information for the Internet community 🧚 It doesn't specify an Internet standard of any kind, and distribution of it is unlimited 💖

Copyright (C) The Internet Society (1999). All Rights Reserved. 🔥

Abstract

okay bestie, this doc defines a Single Rate Three Color Marker (srTCM) ✨ It can be used as a component in a Diffserv traffic conditioner [RFC2475, RFC2474] 🫶

The srTCM meters a traffic stream and marks its packets as green, yellow, or red based on three traffic parameters: Committed Information Rate (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS) 💜 A packet is marked green if it doesn't exceed the CBS, yellow if it does exceed the CBS but not the EBS, and red otherwise 🍓

1. Introduction

so the srTCM meters an IP packet stream and marks each packet green, yellow, or red 🌈 The marking is based on a Committed Information Rate (CIR) and two burst sizes: a Committed Burst Size (CBS) and an Excess Burst Size (EBS) 💅 The rule is the same as in the Abstract: green if it doesn't exceed the CBS, yellow if it exceeds the CBS but not the EBS, red otherwise ✨ It's especially useful for ingress policing of a service, where only the length of the burst decides service eligibility, not the peak rate 🙈

The Meter meters each packet and passes the packet and the metering result to the Marker 🦋

                 +------------+
                 |   Result   |
                 |            V
             +-------+    +--------+
             |       |    |        |
  Packet Stream ===>| Meter |===>| Marker |===> Marked Packet Stream
             |       |    |        |
             +-------+    +--------+

The Meter runs in one of two modes 🎀 In Color-Blind mode, the Meter assumes the packet stream is uncolored 🫠 In Color-Aware mode, the Meter assumes some preceding entity has already pre-colored the incoming stream so each packet is green, yellow, or red 💖 The details of pre-coloring (including error handling) and how the Meter figures out a pre-colored packet's color are DS domain specific and outside the scope of this document 🌸

The Marker (re)colors an IP packet based on the Meter's results 🧚 The color is coded in the DS field [RFC2474] of the packet in a PHB specific manner (see section 4 for an example) ✨

A companion document [RFC2698] describes another three color marker, called a Two Rate Three Color Maker (trTCM), where packets are marked based on two rates and two burst sizes 👑

2. Configuration

the srTCM gets configured by setting its mode and assigning values to three traffic parameters: a Committed Information Rate (CIR), a Committed Burst Size (CBS), and an Excess Burst Size (EBS) 🎀

The CIR is measured in bytes of IP packets per second, so it includes the IP header but not link specific headers 🍓

The CBS and the EBS are measured in bytes. The CBS and EBS must be configured so that at least one of them is larger than 0 💅 It is recommended that when the value of the CBS or the EBS is larger than 0, it is larger than or equal to the size of the largest possible IP packet in the stream 🫶

3. Metering

the Meter's behavior is specified in terms of its mode and two token buckets, C and E, which both share the common rate CIR 🪣 The maximum size of token bucket C is CBS, and the maximum size of token bucket E is EBS 💜

The token buckets C and E start off full (at time 0), so Tc(0) = CBS and Te(0) = EBS ✨ After that, the token counts Tc and Te get updated CIR times per second like this 🌈

  • If Tc is less than CBS, Tc is incremented by one, else
  • if Te is less then EBS, Te is incremented by one, else
  • neither Tc nor Te is incremented.

When a packet of size B bytes arrives at time t, this happens if the srTCM is in Color-Blind mode 🦋

  • If Tc(t)-B >= 0, the packet is green and Tc is decremented by B down to the minimum value of 0, else
  • if Te(t)-B >= 0, the packets is yellow and Te is decremented by B down to the minimum value of 0, else
  • the packet is red and neither Tc nor Te is decremented.

When a packet of size B bytes arrives at time t, this happens if the srTCM is in Color-Aware mode 🫠

  • If the packet has been precolored as green and Tc(t)-B >= 0, the packet is green and Tc is decremented by B down to the minimum value of 0, else
  • If the packet has been precolored as green or yellow and if Te(t)-B >= 0, the packets is yellow and Te is decremented by B down to the minimum value of 0, else
  • the packet is red and neither Tc nor Te is decremented.
⚠️ bestie, note that under these rules, marking a packet with a given color requires enough tokens of that color to fit the entire packet. Other marking policies are clearly possible 🙈 This one was picked to guarantee deterministic behavior, where the volume of green packets is never smaller than what CIR and CBS determine. Tokens of a given color always get spent on packets of that color 💖

The actual implementation of a Meter doesn't need to be modeled on the formal spec above 🧚

4. Marking

the Marker reflects the metering result by setting the DS field of the packet to a particular codepoint 🌸 For the AF PHB [RFC2597], the color can be coded as the drop precedence of the packet 🍓

5. Service Example

okay, so the srTCM can mark a packet stream in a service where different, decreasing levels of assurance (absolute or relative) go to green, yellow, and red packets 💅 For example, a service might discard all red packets (they exceeded both the committed and excess burst sizes), forward yellow packets as best effort, and forward green packets with a low drop probability 👑

6. Security Considerations

ngl this one is short but iconic 💀 The srTCM has no known security concerns 🫶

7. References

  • [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, September 1999. 🦋
  • [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. 🌈
  • [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. 💜
  • [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. ✨

8. Authors' Addresses

Juha Heinanen Telia Finland, Inc. Myyrmaentie 2 01600 Vantaa, Finland

EMail: jh@telia.fi 🎀

Roch Guerin University of Pennsylvania Department of Electrical Engineering, Rm 376 GRW 200 South 33rd Street Philadelphia, PA 19104

EMail: guerin@ee.upenn.edu 🫶

Copyright (C) The Internet Society (1999). All Rights Reserved. 💖

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 🌸

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 🧚

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 😭

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. 🌈

📦 where this page comes from