idnits 2.17.1 draft-aboulmagd-trtcm-inprofile-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 240. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 251. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 264. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Bad filename characters: the document name given in the document, 'draft-aboulmagd-trTCM-inprofile-02', contains other characters than digits, lowercase letters and dash. == Mismatching filename: the document gives the document name as 'draft-aboulmagd-trTCM-inprofile-02', but the file name used is 'draft-aboulmagd-trtcm-inprofile-02' == There is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 abstract seems to contain references ([RFC2475], [2697], [RFC2697], [2698], [RFC2698]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (November 2004) is 7102 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2697' on line 200 -- Looks like a reference, but probably isn't: '2698' on line 200 Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Osama Aboul-Magd 2 Internet Draft Sameh Rabie 3 Expires: April 2005 4 Category: Informational Nortel Networks 6 November 2004 8 A Differentiated Service Two Rate Three Color Marker for Efficient 9 handling of in-Profile Traffic 10 draft-aboulmagd-trTCM-inprofile-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, we represent that any applicable 15 patent or other IPR claims of which we are aware have been disclosed, 16 or will be disclosed, and any of which we are aware have been or will 17 be disclosed, and any of which we become aware will be disclosed in 18 accordance with RFC 3668. 20 This document is an Internet-Draft and is in full conformance with 21 Sections 5 and 6 of RFC 3667 and Section 5 of RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document describes a two rate three color marker that has been 41 in use for data services including Frame Relay services. This marker 42 can be used for metering per-flow traffic in the emerging IP and L2 43 VPN services. The marker defined here is different from previously 44 defined markers in the handling of the in-profile traffic. 45 Furthermore this marker doesn�t impose peak rate shaping 46 requirements on customer edge (CE) devices. 48 1. 49 Introduction 51 The differentiated service defines a quality of service (QoS) 52 architecture for the Internet [RFC2475]. Integral component of this 53 architecture are traffic metering and marking. This document 54 describes a two rate three color metering/marker algorithm that is 55 suitable for the differentiated service applications such as IP and 56 L2 VPNs. This algorithm has been in use for data services including 57 Frame Relay Service. 59 The metering/marker defined here is different from those in 60 [RFC2697] and [RFC2698]. It is different from [RFC2697] in that it 61 is a two-rate, three-color marker. In contrast [RFC2697] is a single 62 rate marker. It is different from [RFC2698] in the way its 63 parameters are defined which allows a better handling of in-profile 64 traffic for predominant service scenarios over a wider range of 65 traffic parameters. 67 Furthermore the algorithm described here eliminates the need for the 68 CE to shape its traffic to a certain peak information rate (PIR) as 69 might be the case for the marker defined in [RFC2698] when the value 70 for the peak burst size (PBS) is smaller than that for the committed 71 burst size (CBS). 73 The marker described here operates for both color-blind and color- 74 aware modes as defined in [RFC2698]. 76 2. 77 Configuration 79 The operation of the marker is described by two rate values, those 80 are the committed information rate (CIR) and the excess information 81 rate (EIR). Each of CIR and EIR defines the token generation rate of 82 a token bucket with size that is equal to committed burst size (CBS) 83 and excess burst size (EBS) respectively. 85 The CBS and EBS are measured in bytes and must configure to be 86 greater than the expected maximum length of incoming PDU. Both CIR 87 and EIR are measured in bits/s. The CIR and EIR can be set 88 independent of each other. Alternatively CIR and EIR can be linked 89 together by defining a burst duration parameter T, where 90 T=CBS/CIR=EBS/EIR. 92 3. 93 Metering and Marking 95 The behavior of the meter is defined in terms of its mode and two 96 token buckets, C and E, with rate CIR and EIR respectively and 97 maximum size CBS and EBS. 99 The token buckets C and E are initially (at time 0) full, i.e. the 100 token count Tc(0) = CBS and Te(0) = EBS. Thereafter the token counts 101 Tc is incremented by one CIR times per second up to CBS and the 102 token count Te is incremented by one EIR times per second up to EBS. 104 In the color aware operation it is assumed that the algorithm can 105 recognize the color of the incoming packet (Green, yellow, or red). 106 The color-aware operation of the metering is: 108 When a green packet of size B arrives at time t, then 110 o if Tc(t)- B > 0, the packet is green and Tc(t) is decremented by 111 B, else 113 o if Te(t)- B > 0, the packet is yellow and Te(t) is decremented by 114 B, else 116 o the packet is red 118 When a yellow packet of size B arrives at time t, then 120 o if Te(t)- B > 0, the packet is yellow and Te(t) is decremented by 121 B, else 123 o the packet is red 125 Incoming red packets are not tested against any of the two token 126 buckets and remain red. 128 In the color blind operation the meter assumes that all incoming 129 packets are green. The operation of the meter is similar to that in 130 the color aware operation for green packets. 132 The salient feature of the algorithm described above is that traffic 133 that is within the defined CIR is colored green directly without the 134 need to pass additional conformance tests. This feature is the main 135 differentiator of this algorithm compared to that described in 136 [RFC2698] where traffic is marked green after it passes two 137 conformance tests (those for PIR and CIR). In either color blind or 138 color aware modes the need to pass two conformance tests could 139 result in packets being dropped at the PIR token bucket even though 140 they are perfectly within their CIR (in-profile traffic). 141 Furthermore, in the color aware mode of operation, the need to pass 142 two conformance tests could result in yellow traffic starving 143 incoming in-profile green packets. 145 The operation of the algorithm is illustrated in the flow chart 146 below: 148 +---------------------------------+ 149 |periodically every T sec. | 150 | Tc(t+)=MIN(CBS, Tc(t-)+CIR*T) | 151 | Te(t+)=MIN(EBS, Te(t-)+EIR*T) | 152 +---------------------------------+ 154 Packet of size 155 B arrives /----------------\ 156 ---------------->|color-blind mode| 157 | OR |YES +---------------+ 158 | green packet |---->|packet is green| 159 | AND | |Tc(t+)=Tc(t-)-B| 160 | B <= Tc(t-) | +---------------+ 161 \----------------/ 162 | 163 | NO 164 v 165 /----------------\ 166 |color-blind mode| 167 | OR |YES +----------------+ 168 | NOT red packet |---->|packet is yellow| 169 | AND | |Te(t+)=Te(t-)-B | 170 | B <= Te(t-) | +----------------+ 171 \----------------/ 172 | 173 | NO 174 v 175 +---------------+ 176 |packet is red | 177 +---------------+ 179 Figure 1: Traffic Metering/Marking Algorithm 181 In Figure 1, we have X(t-) and X(t+) to indicate the value of a 182 parameter X right before and right after time t. 184 4. 185 Service Scenario 187 The described marker can be used to mark an IP packet stream in a 188 service, where different, decreasing levels of assurances (either 189 absolute or relative) are given to packets which are green, yellow, 190 or red. For example, a service may discard all red packets, because 191 they exceeded the service rates, forward yellow packets as best 192 effort, and forward green packets with low drop probability. The 193 marker could also be used for metering L2 VPN services such as the 194 emerging Ethernet transport over IP networks. 196 5. 197 Security Considerations 199 Security issues resulting from this document are similar to those 200 mentioned in RFC[2697] and RFC[2698]. 202 6. 203 Informative References 205 [RFC2475] "An Architecture for Differentiated Service", RFC 2475, 206 December 1998. 208 [RFC2697] "A Single Rate Three Color Marker", RFC 2697, September 209 1999. 211 [RFC2698] "A Two Rate Three Color Marker", RFC 2698, September 1999. 213 7. 214 Authors' Addresses 216 Osama Aboul-Magd 217 Nortel Networks 218 3500 Carling Ave 219 Ottawa, ON K2H8E9 220 Email: osama@nortelnetworks.com 222 Sameh Rabie 223 Nortel Networks 224 3500 Carling Ave 225 Ottawa, ON K2H8E9 226 Email: rabie@nortelnetworks.com 227 8. 228 Full Copyright Statement 230 Copyright (C) The Internet Society (2004). This document is subject 231 to the rights, licenses and restrictions contained in BCP 78 and 232 except as set forth therein, the authors retain all their rights. 234 This document and the information contained herein are provided on 235 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 236 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 237 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 238 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 239 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 240 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 242 Intellectual Property 244 The IETF takes no position regarding the validity or scope of any 245 Intellectual Property Rights or other rights that might be claimed to 246 pertain to the implementation or use of the technology described in 247 this document or the extent to which any license under such rights 248 might or might not be available; nor does it represent that it has 249 made any independent effort to identify any such rights. Information 250 on the procedures with respect to rights in RFC documents can be 251 found in BCP 78 and BCP 79. 253 Copies of IPR disclosures made to the IETF Secretariat and any 254 assurances of licenses to be made available, or the result of an 255 attempt made to obtain a general license or permission for the use of 256 such proprietary rights by implementers or users of this 257 specification can be obtained from the IETF on-line IPR repository at 258 http://www.ietf.org/ipr. 260 The IETF invites any interested party to bring to its attention any 261 copyrights, patents or patent applications, or other proprietary 262 rights that may cover technology that may be required to implement 263 this standard. Please address the information to the IETF at ietf- 264 ipr@ietf.org. 266 Acknowledgement 268 Funding for the RFC Editor function is currently provided by the 269 Internet Society.