idnits 2.17.1 draft-heinanen-diffserv-srtcm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2475,RFC2474]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 94: '...asured in bytes. The CBS and EBS MUST...' RFC 2119 keyword, line 96: '... RECOMMENDED that when the value of ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2474' is defined on line 187, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 191, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-heinanen-diffserv-trtcm (ref. 'Heinanen1') -- No information found for draft-ietf-diffserv-traffcon-format - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Nichols' ** Downref: Normative reference to an Informational RFC: RFC 2475 Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Juha Heinanen 2 INTERNET DRAFT Telia Finland 3 Expires November 1999 Roch Guerin 4 University of Pennsylvania 5 May, 1999 7 A Single Rate Three Color Marker 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Distribution of this memo is unlimited. 33 Abstract 35 This document defines a Single Rate Three Color Marker (srTCM), which 36 can be used as component in a Diffserv traffic conditioner [RFC2475, 37 RFC2474]. The srTCM meters a traffic stream and marks its packets 38 according to three traffic parameters, Committed Information Rate 39 (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), to be 40 either green, yellow, or red. A packet is marked green if it doesn't 41 exceed the CBS, yellow if it does exceed the CBS, but not the EBS, 42 and red otherwise. 44 1. Introduction 46 The Single Rate Three Color Marker (srTCM) meters an IP packet stream 47 and marks its packets either green, yellow, or red. Marking is based 48 on a Committed Information Rate (CIR) and two associated burst sizes, 49 a Committed Burst Size (CBS) and an Excess Burst Size (EBS). A 50 packet is marked green if it doesn't exceed the CBS, yellow if it 51 does exceed the CBS, but not the EBS, and red otherwise. The srTCM 52 is useful, for example, for ingress policing of a service, where only 53 the length, not the peak rate, of the burst determines service 54 eligibility. 56 The Meter meters each packet and passes the packet and the metering 57 result to the Marker: 59 +------------+ 60 | Result | 61 | V 62 +-------+ +--------+ 63 | | | | 64 Packet Stream ===>| Meter |===>| Marker |===> Marked Packet Stream 65 | | | | 66 +-------+ +--------+ 68 The Meter operates in one of two modes. In the Color-Blind mode, the 69 Meter assumes that the packet stream is uncolored. In the Color- 70 Aware mode the Meter assumes that some preceding entity has pre- 71 colored the incoming packet stream so that each packet is either 72 green, yellow, or red. The details of the pre-coloring process, 73 including handling of error scenarios, and how the Meter determines 74 the color of a pre-colored packet are DS domain specific and outside 75 the scope of this document. 77 The Marker (re)colors an IP packet according to the results of the 78 Meter. The color is coded in the DS field [Nichols] of the packet in 79 a PHB specific manner (see section 4 for an example). 81 A companion document [Heinanen1] describes another three color 82 marker, called a Two Rate Three Color Maker (trTCM), where packets 83 are marked based on two rates and two burst sizes. 85 2. Configuration 87 The srTCM is configured by setting its mode and by assigning values 88 to three traffic parameters: a Committed Information Rate (CIR), a 89 Committed Burst Size (CBS), and an Excess Burst Size (EBS). 91 The CIR is measured in bytes of IP packets per second, i.e., it 92 includes the IP header, but not link specific headers. 94 The CBS and the EBS and are measured in bytes. The CBS and EBS MUST 95 be configured so that at least one of them is larger than 0. It is 96 RECOMMENDED that when the value of the CBS or the EBS is larger than 97 0, it is larger than or equal to the size of the largest possible IP 98 packet in the stream. 100 3. Metering 102 The behavior of the Meter is specified in terms of its mode and two 103 token buckets, C and E, which both share the common rate CIR. The 104 maximum size of the token bucket C is CBS and the maximum size of the 105 token bucket E is EBS. 107 The token buckets C and E are initially (at time 0) full, i.e., the 108 token count Tc(0) = CBS and the token count Te(0) = EBS. Thereafter, 109 the token counts Tc and Te are updated CIR times per second as 110 follows: 112 o If Tc is less than CBS, Tc is incremented by one, else 114 o if Te is less then EBS, Te is incremented by one, else 116 o neither Tc nor Te is incremented. 118 When a packet of size B bytes arrives at time t, the following 119 happens if the srTCM is configured to operate in the Color-Blind 120 mode: 122 o If Tc(t)-B >= 0, the packet is green and Tc is decremented by B 123 down to the minimum value of 0, else 125 o if Te(t)-B >= 0, the packets is yellow and Te is decremented by B 126 down to the minimum value of 0, else 128 o the packet is red and neither Tc nor Te is decremented. 130 When a packet of size B bytes arrives at time t, the following 131 happens if the srTCM is configured to operate in the Color-Aware 132 mode: 134 o If the packet has been precolored as green and Tc(t)-B >= 0, the 135 packet is green and Tc is decremented by B down to the minimum 136 value of 0, else 138 o If the packet has been precolored as green or yellow and if 139 Te(t)-B >= 0, the packets is yellow and Te is decremented by B 140 down to the minimum value of 0, else 142 o the packet is red and neither Tc nor Te is decremented. 144 Note that according to the above rules, marking of a packet with a 145 given color requires that there be enough tokens of that color to 146 accommodate the entire packet. Other marking policies are clearly 147 possible. The above policy was chosen in order guarantee a 148 deterministic behavior where the volume of green packets is never 149 smaller than what has been determined by the CIR and CBS, i.e., 150 tokens of a given color are always spent on packets of that color. 152 The actual implementation of a Meter doesn't need to be modeled 153 according to the above formal specification. 155 4. Marking 157 The Marker reflects the metering result by setting the DS field of 158 the packet to a particular codepoint. In case of the AF PHB 159 [Heinanen2], the color can be coded as the drop precedence of the 160 packet. 162 5. Service Example 164 The srTCM can be used to mark a packet stream in a service, where 165 different, decreasing levels of assurances (either absolute or 166 relative) are given to packets which are green, yellow, or red. For 167 example, a service may discard all red packets, because they exceeded 168 both the committed and excess burst sizes, forward yellow packets as 169 best effort, and forward green packets with a low drop probability. 171 6. Security Concerns 173 The srTCM has no known security concerns. 175 7. References 177 [Heinanen1] J. Heinanen and R. Guerin, A Two Rate Three Color Marker. 178 Internet draft draft-heinanen-diffserv-trtcm-01.txt, May 1999. 180 [Heinanen2] J. Heinanen, et al., Assured Forwarding PHB Group. 181 Internet draft draft-ietf-diffserv-af-06.txt, February 1999. 183 [Nichols] K. Nichols and B. Carpenter, Format for Diffserv Working 184 Group Traffic Conditioner Drafts. Internet draft draft-ietf-diffserv- 185 traffcon-format-00.txt, February 1999. 187 [RFC2474] K. Nichols, et al., Definition of the Differentiated 188 Services Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474, 189 December 1998. 191 [RFC2475] S. Blake, et al., An Architecture for Differentiated 192 Services. RFC 2475, December 1998. 194 8. Author Addresses 196 Juha Heinanen 197 Telia Finland, Inc. 198 Myyrmaentie 2 199 01600 Vantaa, Finland 200 Email: jh@telia.fi 202 Roch Guerin 203 University of Pennsylvania 204 Department of Electrical Engineering, Rm 376 GRW 205 200 South 33rd Street 206 Philadelphia, PA 19104 207 Email: guerin@ee.upenn.edu