idnits 2.17.1 draft-babiarz-tsvwg-rtecn-04.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.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1253. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1230. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1243. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (July 16, 2005) is 6831 days in the past. Is this intentional? 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: '2' is defined on line 1123, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-tsvwg-diffserv-service-classes-01 -- No information found for draft-dudley-tsvwg-rtecn-simulation - is the name correct? == Outdated reference: A later version (-02) exists of draft-alexander-rtp-payload-for-ecn-probing-01 == Outdated reference: A later version (-02) exists of draft-floyd-ecn-alternates-01 == Outdated reference: A later version (-01) exists of draft-alexander-congestion-status-preconditions-00 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG J. Babiarz 3 Internet-Draft K. Chan 4 Expires: January 17, 2006 Nortel Networks 5 V. Firoiu 6 BAE Systems 7 July 16, 2005 9 Congestion Notification Process for Real-Time Traffic 10 draft-babiarz-tsvwg-rtecn-04 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 17, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document specifies the usage of Explicit Congestion Notification 44 (ECN) markings for real-time inelastic flows such as voice, video 45 conferencing, and multimedia streaming. We build on the principles 46 of RFC 3168, "The Addition of Explicit Congestion Notification to 47 IP", and apply them to real-time inelastic traffic in DiffServ 48 networks. Defined in this document are, new ECN semantics that 49 provide two levels of experienced congestion along the path for real- 50 time inelastic flows, the required ECN marking behavior in network 51 nodes, and state the required behavior of end-systems that support 52 this function with an explanation of how the two ECN schemes can co- 53 exist safely in the network. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1 Requirements Notation . . . . . . . . . . . . . . . . . . 4 59 1.2 Applicability and Operating Environment . . . . . . . . . 4 60 2. General Principles . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Definition of Congestion for Real-Time Traffic . . . . . . . . 5 62 3.1 Avoiding Congestion for Real-Time Traffic . . . . . . . . 6 63 3.2 Congestion Detection for Real-Time Traffic . . . . . . . . 7 64 3.3 Behavior of Meter and Marker . . . . . . . . . . . . . . . 8 65 3.4 Marking for Congestion Notification . . . . . . . . . . . 8 66 3.4.1 ECN Marking of Real-Time Inelastic Flows . . . . . . . 9 67 3.4.2 ECN Semantics for Real-Time Traffic . . . . . . . . . 10 68 3.5 End-System Behavior . . . . . . . . . . . . . . . . . . . 10 69 4. Detection of Inappropriate Changes to the ECN Field . . . . . 11 70 4.1 During Session Setup . . . . . . . . . . . . . . . . . . . 11 71 4.2 After Session is Established . . . . . . . . . . . . . . . 14 72 5. Network with DiffServ and Real-Time ECN Support . . . . . . . 16 73 5.1 Workable Approach for Co-existence of RT-ECN . . . . . . . 17 74 6. Discussion on Different Marking Approaches . . . . . . . . . . 18 75 6.1 Alternate RT-ECN marking . . . . . . . . . . . . . . . . . 18 76 6.2 Implication of this Marking . . . . . . . . . . . . . . . 19 77 6.3 Reason for Not Using this RT-ECN Marking . . . . . . . . . 19 78 7. Example of ECN usage for Admission Control . . . . . . . . . . 19 79 8. Non-compliance . . . . . . . . . . . . . . . . . . . . . . . . 20 80 9. Changes from Previous Version . . . . . . . . . . . . . . . . 21 81 10. Security Considerations . . . . . . . . . . . . . . . . . . 21 82 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 83 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 84 13. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 22 85 13.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 22 86 13.2 Meter Configuration . . . . . . . . . . . . . . . . . . . 22 87 13.3 Meter Behavior . . . . . . . . . . . . . . . . . . . . . . 23 88 13.4 Marking . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 13.5 Summary of the Behavior . . . . . . . . . . . . . . . . . 24 90 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 91 14.1 Normative References . . . . . . . . . . . . . . . . . . . 24 92 14.2 Informative References . . . . . . . . . . . . . . . . . . 25 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 94 Intellectual Property and Copyright Statements . . . . . . . . 27 96 1. Introduction 98 Proposed is an additional usage of Explicit Congestion Notification 99 (ECN) for real-time inelastic flows such as voice, video 100 conferencing, and multimedia streaming. RFC 3168 [7] specifies the 101 incorporation of ECN for IP, including ECN's use of two bits in the 102 IP header. This document builds on the concepts of RFC 3168, "The 103 Addition of Explicit Congestion Notification to IP", and applies them 104 to real-time inelastic flows in DiffServ enabled networks to perform 105 admission control and session preemption. 107 To address a wider usage of this mechanism, it is necessary to 108 introduce new semantics for the ECN field of the IP header (bits 6 109 and 7 of byte two in IPv4 header) that can provide two levels of 110 congestion indication for real-time inelastic flows. There are 111 applications and services that need to provide different treatment at 112 the application level based on the importance or precedence of the 113 flow for a given level of congestion experienced. For example, 114 situation critical or life threatening VoIP flows within a service 115 class used for real-time traffic may need to get priority access to 116 the network resources over regular VoIP traffic. In the 117 specification of the required behavior for network nodes and end- 118 systems that are configured to provide ECN-capability for real-time 119 flows, we factor in the requirements specified in Specifying 120 Alternate Semantics for the Explicit Congestion Notification (ECN) 121 Field [17]. 123 The operating environment is discussed first, and then functions are 124 defined that need to be performed in the network for real-time flows. 125 Specifically, this includes (1) congestion detection through the use 126 of flow measurement, (2) marking of ECN bits in the IP header of 127 real-time packets for a given DSCP-marked service class and (3) 128 actions that the end-systems needs to take based on the ECN bits 129 marking. Since real-time inelastic flows like voice and video 130 conferencing are very delay sensitive, a different method than what 131 is described in RFC 3168 for determining levels of congestion needs 132 to be used. 134 The proposal is to use ECN as a method to notify the end-systems that 135 packets flowing on this path are above the engineered capacity of the 136 service class that is used for real-time traffic in the network. 137 Based on this information, the end-system needs to take action to 138 reduce its sending rate by whatever means is appropriate; for example 139 stop sending packets, or reduce its rate, or not admit new flows 140 while the path remains congested. The detailed mechanism used in the 141 end-system to achieve the required behavior to the ECN marking is not 142 specified in this document as it will depend on the application. It 143 is left up to application designers to define how applications in 144 end-systems should perform the required actions to conform to ECN bit 145 marking in the network. It is expected that application specific 146 documents will be produced to explain the application's usage of this 147 real-time ECN mechanism, one such example is Real-time ECN Use Cases 148 [11] which defines admission control and preemption procedures for 149 VoIP flows. For illustration purposes, a high level example of 150 admission control is provided in this document. 152 1.1 Requirements Notation 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 [3]. 158 1.2 Applicability and Operating Environment 160 Networks that need to support real-time inelastic services may need 161 to provide a controlled environment that allows for a high level of 162 guarantees on the quality of service to be honored. We suggest the 163 use of DiffServ service classes [12] to separate the real-time 164 inelastic traffic from the other traffic for such a controlled 165 environment, and applying the Real-Time ECN process discussed in this 166 document. 168 This document addresses the use of the ECN markings in a DiffServ 169 controlled environment, with both marking as defined herein and in 170 RFC 3168 [7] co-existing in the same network but in different service 171 classes. As well, there may be network segments that do not deploy 172 any ECN processing at all, or there may be a router in the path that 173 does not support DiffServ but performs ECN marking as defined in RFC 174 3168. These operating environments are explored and discussed 175 herein. But in all cases, DiffServ separation of the real-time 176 inelastic traffic from the other traffic should be supported. With 177 the basic rules of: 179 o No mixing of Real-Time ECN and RFC 3168 ECN marking in the same 180 service class. 182 o Allow mixing of traffic from Real-Time ECN capable and incapable 183 end-systems in the same service class and using ECN bits to 184 provide the differentiation. 186 o Allow traffic from both Real-Time ECN capable and RFC 3168 187 conformant end-systems as long as the traffic is marked with 188 different DSCP values (using different service classes). 190 2. General Principles 192 In this section, some of the important design principles and 193 assumptions guiding the development of this proposal are described. 195 o Because ECN for real-time flows is likely to be adopted gradually 196 and selectively in nodes, accommodating migration and selective 197 deployment is essential. Some nodes may not be able to detect 198 congestion or mark the ECN bits within IP packet headers. Also 199 there may be parts of the network where congestion is very 200 unlikely and therefore there is no need for an ECN function. The 201 most viable strategy is one that accommodates selective or 202 incremental deployment in a network with both ECN-capable and non- 203 ECN-capable nodes. 205 o Asymmetric routing is likely to be a normal occurrence within IP 206 networks. That is, the path (the sequence of links and nodes) 207 taken by forward and reverse packet flows may be different. 209 o Many nodes process the "regular" header in IP packets more 210 efficiently than they process the header information in IP 211 options. This suggests that the ideal approach is to keep 212 "congestion experienced" information in the regular header of an 213 IP packet. 215 o A specific DiffServ service class would be implemented for real- 216 time traffic. The assumption is that a signaling protocol (SIP, 217 H.323, MGCP, H.248, etc.) will be used to determine if the end- 218 systems are capable of understanding ECN bit marking and thus, are 219 willing to participate in congestion control prior to marking 220 packets as ECN-Capable Transport (ECT). 222 o Flow measurement and marking of ECN bits as defined herein is 223 performed on flows from ECN-capable end-systems that is mapped to 224 a ECN-enabled service class, and may be performed on selected node 225 links in the network where congestion is likely to occur. Other 226 traffic flows are not affected by this function. Nodes that do 227 not support this function forward packets without modifying the 228 ECN field of the IP header. 230 o ECN procedure as defined in RFC 3168 [7] may also be applied to 231 DiffServ service classes in the IP network. Both methods may co- 232 exist in the network, but in different DiffServ service classes. 234 3. Definition of Congestion for Real-Time Traffic 236 Real-time traffic generated by applications such as voice, video 237 conferencing, and multimedia streaming have different performance 238 requirements when compared with non-real-time elastic applications 239 that use a protocol such as TCP. One such requirement is that end- 240 to-end delay be bounded to a small value, and that packets should not 241 be dropped. 243 It is generally accepted that such performance requirements can be 244 achieved when the real-time flows are serviced by the nodes in their 245 path through a real-time service class such as one based on the 246 Expedited Forwarding (EF) PHB [8] treatment. This treatment can be 247 provided only when the real-time service class is not overloaded 248 (i.e., when the aggregate of input traffic never exceeds the class' 249 capacity, and thus no congestion condition occurs). It should also 250 be noted that when the overloaded condition occurs, all real-time 251 traffic flows within the real-time service class at the congestion 252 point will be affected, not just the offending traffic flow. Hence, 253 it is desirable to avoid the overloaded condition as much as 254 possible. 256 With the above performance requirements for real-time inelastic 257 traffic in mind, "congestion of real-time inelastic traffic" is 258 defined to be the network condition when aggregated packet flows 259 within the service class exceed an engineered traffic level. The 260 engineering of the network is such that traffic exceeding this 261 engineered traffic level by a defined and limited amount does not 262 generally cause an increase in packet queuing or packet dropping 263 (service class overload) in the network. Instead, the ECN field is 264 used to provide an indication that traffic is above the engineered 265 traffic level. This can be viewed as explicit notification to 266 prevent congestion. However, uncontrolled or prolonged increase in 267 traffic above the defined amount may result in an increase in packet 268 queuing and/or packet dropping, and therefore may cause overload of 269 the real-time service class. 271 3.1 Avoiding Congestion for Real-Time Traffic 273 Congestion notification can be utilized in a flow admission control 274 scheme to ensure sufficient forwarding resources (bandwidth), hence 275 for Real-Time Traffic, ECN is used to prevent congestion. In this 276 scheme, a continuous process at selected link(s)/node(s) measures the 277 traffic going through a specified real-time service class and 278 indicates a level of congestion (such as "not congested", "mildly 279 congested" or "severely congested"). This congestion indication as 280 described in Section 3.4.2 is then used by the application to select 281 the action that will be taken by the application controlling the 282 service. The action could be to admit or not to admit a new flow 283 into that real-time service class in the network, or have the sending 284 rate of ECN marked flows reduced or stopped, or terminate a flow. 286 All with the effect of reducing level of offered traffic. Based on 287 the performance requirements of real-time traffic, it is desirable 288 that the measurement process indicate congestion of real-time traffic 289 before any significant packet accumulates in the queue occurs. This 290 is such that no significant queuing delay is added to existing real- 291 time flows' end-to-end delay. 293 An alternative method to avoid the overloaded condition of a service 294 class is through resource reservation and admission control. A 295 (centralized or distributed) database maintains a record of available 296 resources (bandwidth) for the real-time service class on each link in 297 the network and a new flow is admitted only if there are enough 298 resources on the links in its path so that the overloaded condition 299 is avoided. Checking for available resources can be done with a 300 reservation protocol or through a policy based protocol. An 301 important issue is that the maintenance and per-flow querying of the 302 resource database in conjunction with the routing database is an 303 important overhead that is undesirable in many implementations. 305 3.2 Congestion Detection for Real-Time Traffic 307 One of the goals is to keep the amount of processing that is 308 performed in the network to be very small and not require any other 309 computations or state information to be kept in network nodes. One 310 way to achieve this is through monitoring the aggregate rate of 311 traffic in the specified real-time service class and to indicate 312 congestion when a certain traffic threshold is exceeded. Hence the 313 network nodes need only to perform flow measurement of packets marked 314 with specific DS codepoint and with ECN indication that the end- 315 system is ECN-capable. Another policy that may be used is where 316 network nodes perform flow measurement of packets marked with a 317 specific DS codepoint and if the rate is exceeded, only ECN mark 318 packets that indicate that they are ECN-capable. The application 319 monitors the ECN field, and takes an appropriate action based on the 320 marking. 322 Figure 1 below shows a block diagram of the traffic measurement and 323 ECN marking function. 324 +------------+ 325 | Result | 326 | V 327 +-------+ +--------+ 328 | | | ECN | 329 Packet Stream ===>| Meter |===>| Marker |===> Marked Packet Stream 330 | | | | 331 +-------+ +--------+ 333 Figure 1: Block Diagram of Meter and Marker Function 335 The Meter meters each packet within the real-time service class and 336 passes the packet and the metering result to the ECN Marker. 338 The Marker sets the ECN congestion level for each packet that is 339 marked as ECN-capable within the real-time service class based on the 340 results of the Meter. 342 The traffic rate of the specified service class may be measured with 343 a simple token bucket meter, an exponentially weighted moving average 344 meter, or other methods. The goals of a rate measuring method are 345 simplicity and minimum or no added delay to traffic forwarding. 347 The specification of the traffic measurement mechanism is outside the 348 scope of this document. The intention is that an existing traffic 349 measurement mechanisms may be used. In Appendix A, an example of a 350 simple token bucket method for measurement and marking is provided. 352 3.3 Behavior of Meter and Marker 354 When the measured rate exceeds the engineered traffic level for ECN- 355 capable marked packets, the Meter sets its result flag and passes it 356 to the Marker. The Marker, sets the appropriate ECN value for all 357 ECN-capable marked packets belonging to the service class that is 358 measured until the result flag from the Meter is cleared. 360 When the measured traffic rate is reduced below the engineered rate 361 the Meter clears the result flag if set. The clearing of the result 362 flag output from the Meter stops marking ECN bits by the Marker. The 363 metering function has built-in hysteresis for setting and clearing 364 the result flag. The amount of hysteresis is controlled by the 365 configuration parameters (example size of the token bucket) of the 366 traffic measurement mechanism and should be configured to meet the 367 characteristics of the real-time inelastic traffic that is being 368 measured. See report, Simulation of RT-ECN based Admission Control 369 and Preemption [13] for results of the above metering and marking as 370 well analysis of different metering approaches in Discussion of 371 Congestion Marking with RT-ECN [14]. 373 3.4 Marking for Congestion Notification 375 Marking for Explicit Congestion Notifications is done through the use 376 of the two ECN bits in the IP header. 378 0 1 2 3 4 5 6 7 379 ----+----+----+----+----+----+----+---- 380 | DS FIELD, DSCP |ECN FIELD| 381 ----+----+----+----+----+----+----+---- 382 DSCP: Differentiated Services Codepoint 383 ECN: Explicit Congestion Notification 385 Figure 2: DS and ECN Fields in IP Header 387 Bits 6 and 7 in the IPv4 octet are designated as the ECN field. This 388 octet of the IPv4 header corresponds to the Traffic Class octet in 389 IPv6, and the ECN field is defined identically in both cases. The 390 definitions for the IPv4 TOS octet RFC 791 [1] and the IPv6 Traffic 391 Class octet have been superseded by the six-bit Differentiated 392 Services (DS) field RFC 2474 [4], RFC 2780 [6]. Bits 6 and 7 are 393 listed in RFC 2474 [4] as Currently Unused, and are specified in RFC 394 2780 as approved for experimental use for ECN. Finally, RFC 3168 [7] 395 standardizes the use of the ECN bits. 397 3.4.1 ECN Marking of Real-Time Inelastic Flows 399 Marking of ECN bits for real-time inelastic flows is defined so that 400 nodes in the path need only to perform an ECN set function when an 401 engineered rate is exceeded for packets that are marked as ECN- 402 capable. With this approach there is no need to perform a test to 403 determine the congestion level marking of the received packet before 404 a node performs ECN marking. Other approaches could be used, but for 405 simplicity we have chosen this one. In Section 6 we discuss the 406 different marking approaches that were studied. 408 Network nodes that are configured to support congestion notification 409 for real-time flows need to provide the following capability: 411 o Congestion detection of packets marked indicating that the end- 412 system is ECN-capable (ECT) SHOULD be performed using a real-time 413 measurement mechanism (e.g., flow metering). 415 o When the flow rate exceeds configured rate "A" (i.e., the first 416 level of congestion), ECN bit 7 of ECT marked packets is set to 417 '1'. 419 o When the flow rate exceeds configured rate "B" (i.e., the second 420 level of congestion), ECN bits 6 and 7 of ECT market packets are 421 set to '01'. 423 o Measured rate "B" SHOULD be greater than rate "A". 425 3.4.2 ECN Semantics for Real-Time Traffic 427 Some real-time applications or services need the indication of two 428 levels of congestion experienced, CE(1) and CE(2), for first and 429 second level respectively. Other applications may only need a single 430 indication. To address a wide range of usage, we have selected the 431 following ECN semantics for real-time inelastic traffic. 432 ECN Marking: 434 Bits 6 and 7 values 435 0 0 Not-ECT - End-system is Not ECN-Capable Transport 436 1 0 ECT(0) - End-system is ECN-Capable Transport 437 1 1 CE(1) - Congestion Experienced at 1st level 438 0 1 CE(2) - Congestion Experienced at 2nd level 440 Figure 3: ECN Semantics for Real-Time Flows 442 3.5 End-System Behavior 444 Listed below are reactions to ECN marking that needs to be supported 445 by end-systems that indicated that they are ECN-capable: 447 o Under normal (non emergency or situation critical) conditions 448 during new flow establishment, ECN-capable end-system that receive 449 packets marked indicating that congestion was experienced at 1st 450 level CE(1), SHOULD NOT proceed with the session setup. New flows 451 that indicate that they are "emergency or situation critical" 452 SHOULD be allowed admission at CE(1). The definition and 453 verification of what flow is classified as "emergency or situation 454 critical" is left up to the application. 456 o Once a flow has been admitted and the path experience 1st level of 457 congestion CE(1), ECN-capable end-systems that have ability to 458 dynamically react to ECN marking, SHOULD reduce their sending rate 459 as agreed to during session setup. 461 o During new flow establishment, ECN-capable end-systems that 462 receive packets marked indicating that congestion was experience 463 at 2nd level CE(2) SHOULD NOT proceed with session setup. 465 o Systems with established flows that experience the 2nd level of 466 congestion CE(2) SHOULD terminating sessions or reduce sending 467 rate in a controlled manner, and continue until the congestion 468 level drops below the 2nd level of congestion. 470 Generally, at 1st level of congestion, no additional traffic should 471 be added with the exception for flows that are identified as being 472 potentially life threatening i.e., E911 or situation critical. End- 473 systems that have the ability to reduce their sending rate should do 474 so. At 2nd level of congestion, no additional traffic is added to 475 the congested path plus selected flows on the congested path are 476 removed to reduce congestion below 2nd level. 478 4. Detection of Inappropriate Changes to the ECN Field 480 This section discusses in detail some of the possible inappropriate 481 changes to the ECN field in the network, such as reducing level of 482 congestion, falsely reporting no congestion, or modifying ECN bits to 483 indicate that the path is or is not Real-Time ECN compliant. 484 Reducing the level of congestion or falsely reporting no congestion 485 will be referred to here as "cheating". 487 The Real-Time ECN mechanism provides two levels of congestion 488 indication. Therefore, the cheating detection mechanism as defined 489 in RFC 3168 [7] and RFC 3540 [10] that uses ECT(0) and ECT(1) states 490 can not be used. Instead, the procedure outlined in this memo SHOULD 491 be used to detect if inappropriate changes to the ECN bits have 492 occurred between originator and receiver. The outlined procedure is 493 executed under the control of the application prior to admission of a 494 new real-time flow. The testing for conformance is performed between 495 the two Real-Time ECN-capable and conformant applications running in 496 the end-systems. These two end-systems will be referred to as sender 497 and receiver. 499 In the implementation of a Real-Time ECN mechanism in the network, 500 the network administrator through the use of policies or through the 501 use of signaling/control protocols such as SIP, can verify the 502 capabilities and conformance of the end-systems. As stated earlier, 503 only applications running in end-systems that are capable and 504 conformant to this Real-Time ECN mechanism may use it. End-systems 505 that are not Real-Time ECN-capable or conformant MUST set ECN field 506 to '00' when sending packets. 508 4.1 During Session Setup 510 During the admission of a new real-time flow, application signaling 511 is used to exchange end-system capabilities, including whether the 512 end-systems are Real-Time ECN capable. The Real-Time ECN mechanism 513 defined in this memo can be used to provide admission control 514 capabilities to end-systems. In order to provide this capability, 515 the signaling used by the end-systems requires a means to both 516 trigger the Real-Time ECN probing process as described in "RTP 517 Payload Format for ECN Probing" [15] and "Real-time ECN Use Cases" 518 [11], as well as to delay session setup; - specifically user 519 indication of a new session, i.e., ringing until an admission control 520 decision has been made. In the context of SIP, preconditions can be 521 used to accomplish both of these requirements. For more details, see 522 A Congestion Status Precondition for the Session Initiation Protocol 523 (SIP) [18]. 525 If signaling indicates that the destination end-system does not 526 support the Real-Time ECN mechanism, the originating end-system MAY 527 reattempt the session without stipulating the use of the Real-Time 528 ECN mechanism. While such a session would not undergo the Real-Time 529 ECN admission control tests, this does allow session creation between 530 end-systems that support the Real-Time ECN mechanism and those that 531 do not. 533 Prior to admission of a new real-time flow, the following procedure 534 SHOULD be used to detect inappropriate changes to ECN field. Note 535 that this procedure can be independent of an actual admission control 536 procedure. 538 Under the control of the application, the sender generates and sends 539 a stream of RTP-probe packets. This stream of RTP-probe packets is 540 specified as follows: 542 1. A random sequence of the four possible ECN bit combinations is 543 selected, and this sequence of values is used as the ECN field 544 values on the initial four RTP-probe packets. The ECN field 545 marking is also copied into the RTP-probe payload [15] and the 546 payload should be secured. SRTP RFC 3711 [9] is one mechanism 547 that can provide the necessary security for the probe packets. 549 2. After the sequence of four RTP-probe packets is sent, the sender 550 sends RTP-probe packets with randomly generated ECN bit of '10', 551 '11' and '01' until probing is stopped. As before, the ECN field 552 marking is also copied into the RTP-probe payload and the payload 553 should be secured. 555 The probing sequence just described is one method that can be 556 implemented for probing to detect inappropriate changes to the ECN 557 field. Because the ECN field marking on probe packets is always 558 copied into the RTP-probe payload, the receiving end-system is always 559 able to compare the received ECN value in the IP header with that in 560 the secured RTP-probe payload. Therefore the ability to detect 561 inappropriate changes to the ECN Field via probing is independent of 562 the ECN bit sequence used. 564 Upon reception of the RTP-probe packet, the receiver compares the 565 received ECN marking in the IP header to ECN marking in RTP-probe 566 payload. 568 A packet sent with ECN field '10' and received as indicated below 569 have the meanings as indicated: 571 o Received as '10': path is valid, no congestion. 573 o Received as '11': path is valid, congestion experienced at 1st 574 level. 576 o Received as '01': path is valid, congestion experienced at 2nd 577 level. 579 o Received as '00': path is not valid, device in path zeroed ECN 580 field. 582 Packet sent with ECN field '01' and received as indicated below have 583 the meanings as indicated: 585 o Received as '01': path is valid. 587 o Received as '11': path is not valid, device in path reduced 588 congestion experienced to 1st level, this could also mean that the 589 path is through a congested router that used RFC 3168 for ECN 590 marking of this flow. 592 o Received as '10': path is not valid, device in path cleared 593 indication of congestion experienced. 595 o Received as '00': path is not valid, device in path zeroed ECN 596 field. 598 Packet sent with ECN field '11' and received as indicated below have 599 the meanings as indicated: 601 o Received as '11': path is valid. 603 o Received as '01': path is valid, congestion experienced at 2nd 604 level. 606 o Received as '10': path is not valid, device in path cleared 607 indication of congestion experienced. 609 o Received as '00': path is not valid, device in path zeroed ECN 610 field. 612 Packet sent with ECN field '00' and received as indicated below have 613 the meanings as indicated: 615 o Received as '00': path is valid. 617 o Received other than '00':, path is not conformant. 619 The above mechanism will detect when a device in the path tries to 620 cheat by changing the ECN field to indicate no congestion, or reduce 621 the level of congestion, or incorrectly indicate a path is or is not 622 ECN capable. Due to the nature of the Real-time ECN process 623 described in this memo, it is not possible to detect the presence of 624 devices which raise the level of congestion in the ECN marking. 626 The detection of presence of devices that lower ECN marking is only 627 possible if there are no other Real-Time ECN capable routers down 628 stream from the cheating device along the network path legitimately 629 marking the ECN bits, masking out the cheating condition. However, 630 this is not a problem if the down steam router marks ECN back to the 631 appropriate congestion level, as the end-system will take the correct 632 action for that flow. 634 The outlined procedure for detection of inappropriate changes to the 635 ECN field is also applied to RTP-probe flow in the direction from 636 call originator to the far-end as outlined in Real-time ECN Use Cases 637 [11]. 639 During session setup phase, if it is determined that the path is 640 invalid, non-conformant or congested, the setup of the session SHOULD 641 be terminated with cause information provided to the user. 643 4.2 After Session is Established 645 Once a new real-time flow has been admitted, the following procedure 646 SHOULD be used to detect cheaters and routers that use ECN procedure 647 defined in RFC 3168: 649 o For real-time flow, the media packets are sent with an ECN value 650 of '10' set in the IP header. At random intervals, a single media 651 packet will be sent with '01' in order to detect the cheaters and 652 congested RFC 3168-capable routers. The receiver must be aware of 653 which packets the sender marked with '01', so that it does not 654 misinterpret such packets as indicating congestion. 656 o In order that both the sender and receiver are synchronized as to 657 which packets are marked '01', they will use a common function to 658 determine which packets are marked. The Mersenne Twister MT 19937 659 [16] random number generator, seeded with the initial RTP Sequence 660 Number used by the sender, is utilized in this synchronization 661 process. 663 o During the initial RTP-probe sequence [15] that was used to verify 664 conformance of path during session setup, the initial Sequence 665 Number used by the sender is sent to the receiver in the payload 666 of the probe packets. This value is used as a seed in a Mersenne 667 Twister MT 19937 random number generator in both the sender and 668 receiver. The sender begins sending media packets marked with 669 ECN '10'. The sender and receiver each use the MT 19937 function 670 to select the next pseudorandom number in the sequence, modulus 4, 671 to determine the next packet to mark with ECN '01'. The use of 672 modulus 4 is to keep the interval between packets used for 673 detection of cheaters, etc., bounded. 675 In the sender, the following steps describe this process: 677 1. During probing, send the Initial RTP Sequence Number (IRSN), in 678 the payload of the probe packet. 680 2. Seed the MT 19937 function with the initial sequence number: 681 MT19937.seed(IRSN). 683 3. Calculate N, the number of media packets to be marked with ECN 684 '10', before marking a single media packet with ECN '01', as 685 follows: N = (MT19937.next)(MOD 4) + 1. 687 4. Once the real-time flow begins, mark N packets with ECN '10'. 689 5. Send the next packet with ECN '01'. 691 6. Repeat starting with Step 3, until the real-time flow is 692 terminated. 694 In the receiver, the following steps describe this process: 696 1. During probing, pull the Initial RTP Sequence Number (IRSN) from 697 the payload of a received probe packet[15]. Initialize NSN 698 (described in Step 4 below): NSN = IRSN. 700 2. Seed the MT19937 function with the initial sequence number: 701 MT19937.seed(IRSN). 703 3. Calculate N, the number of media packets to be marked with ECN 704 '10', before marking a single media packet with ECN '01', as 705 follows: N = (MT19937.next)(MOD 4) + 1. 707 4. Calculate NSN, the sequence number of the next packet expected to 708 be marked with ECN '01': NSN = NSN + N. 710 5. Receive media packets, watching for a packet with a sequence 711 number equal to or greater than NSN, until the real-time flow is 712 terminated: 714 A. Packets with a sequence number less than NSN are used for 715 congestion detection. Repeat Step 5. 717 B. Packets with a sequence number equal to NSN are used for 718 detection of cheaters and congested RFC 3168-enabled routers. 719 If the ECN value of this packet is not '01', a cheater or 720 congested RFC 3168-enabled router is present along the 721 network path. Jump to Step 3 and repeat. 723 C. Packets with a sequence number greater than NSN should result 724 in calculation of a new NSN value. Jump to Step 3 and 725 repeat. 727 The previous algorithm is one that should be used. Other methods can 728 be used as long as both the sender and receiver agree to it. 730 Upon receipt of an RTP packet the receiver expects to be marked '01', 731 the end-system compares the received ECN field with the expected 732 value of '01', or CE(2). If a cheater is present, and is not being 733 overridden by marking of one or more Real-Time ECN capable routers 734 along the path through the network, the end-system detects the 735 presence of a cheater if the received ECN value is '10' or '11' or 736 '00', (ECT(0) or CE(1) or Not-ECT). Also, this procedure can be used 737 to detect the presence of congested routers that use RFC 3168 as its 738 ECN marking. A congested router that uses the ECN marking procedure 739 as defined in RFC 3168 will interpret ECN value '01' as ECT(1) and 740 change the marking to '11' (CE). 742 If after a session has been admitted it is detected that there is a 743 cheater or congested router that uses RFC 3168 for ECN marking of 744 real-time flows, the established session SHOULD be terminated with 745 cause information provided to the user. 747 5. Network with DiffServ and Real-Time ECN Support 749 The real-time ECN process requires that the real-time inelastic 750 traffic is separated from the other traffic. Within a DiffServ 751 network, it is perfectly fine to deploy RFC 3168 ECN marking for 752 service classes that are used for elastic TCP traffic and to deploy 753 Real-Time ECN marking as defined herein for service classes that are 754 used for inelastic real-time traffic. DiffServ is used to separate 755 the real-time traffic from the other traffic flows, and Real-Time ECN 756 processing is applied to this separated traffic to provide control 757 within the service class. Under this condition, the most optimal 758 deployment is to have all network segments support DiffServ, with 759 Real-Time ECN marking capability on selected nodes where congestion 760 within the real-time service class is likely. Over time, as traffic 761 levels within the real-time service class become complex and/or the 762 network topology becomes more complex, it may be preferable that 763 Real-Time ECN capability is extended to all or most network nodes. 765 This approach allows for incremental deployment of DiffServ and Real- 766 Time ECN. Specific network nodes where congestion is not likely to 767 occur may delay its use of DiffServ and ECN. 769 5.1 Workable Approach for Co-existence of RT-ECN 771 Routers need a method to understand which ECN mechanism should be 772 applied based on the traffic being forwarded. We believe DiffServ 773 architecture can provide this capability. The normal practice is to 774 segregate elastic and real-time inelastic flows into different 775 service classes that use different PHBs with the DS codepoint being 776 used as the indicator for selection of the PHB. Router can implement 777 both ECN procedures and use DS codepoint for indicating which ECN 778 mechanism applies to each packet. 780 The approach that we selected allows for two different ECN 781 mechanisms, one for elastic flows and the other for real-time 782 inelastic flows with the following rules for deployment: 784 1. ECN as per RFC 3168 applies to the Default Forwarding [4] PHB 785 '000000'. 787 2. In DiffServ enable networks, DS codepoints is used to indicate 788 the ECN mechanisms that may be supported. 790 A. ECN as per RFC 3168 should be used with the AF [5] PHBs. 792 B. RT-ECN should be used with EF [8] PHB. 794 C. Class Selector PHBs may use RFC 3168 or RT-ECN and should be 795 based on traffic characteristic assigned to the PHB. See 796 Configuration Guidelines for DiffServ Service Classes [12] 797 for guidance. 799 3. As RFC 3168 defines the default behavior, all other mechanisms 800 that are defined should not cause harm to the default ECN 801 behavior or network if the alternate ECN mechanism encounters RFC 802 3168 marking. 804 As stated in Specifying Alternate Semantics for the Explicit 805 Congestion Notification (ECN) Field [17] "that the default ECN 806 semantics defined in RFC 3168 are the current default semantics for 807 the ECN field, regardless of the contents of any other fields in the 808 IP header. In particular, the default ECN semantics apply for more 809 than best-effort traffic with a codepoint of '000000' for the 810 diffserv field - the default ECN semantics currently apply regardless 811 of the contents of the diffserv field." We propose that an amendment 812 to RFC 3168 be considered that would allow non default DS codepoints 813 to be used for indicating alternate ECN semantics with guidance as 814 stated above. 816 6. Discussion on Different Marking Approaches 818 In our analysis of ECN marking to address the needs of real-time 819 flows like voice and video conferencing, we look at different marking 820 schemes so that the ECN bit definition and meanings be closely 821 aligned with what is defined in RFC 3168. Below is one example worth 822 noting that was considered but rejected even if it uses the same ECN 823 semantics as what is defined in RFC 3168. 825 6.1 Alternate RT-ECN marking 827 During session setup (flow admission), end-system marks its' packets 828 with ECT(0) ECN='10' and once the flow is admitted the end-system 829 marks its' packets with ECT(1) ECN='01'. 831 With the following metering and marking policy in router, packets 832 that are marked as ECN-capable (ECN= 10, 11 or 01) are meter by both 833 meters: 835 o If traffic exceeds 1st threshold level, mark ECN-capable ECT(0) 836 '10' packets to indicate that congestion was experienced CE '11'. 838 o If traffic exceeds 2nd threshold level, mark ECN-capable ECT(1) 839 '01'packets to indicate that congestion was experienced CE '11'. 841 ECN Marking (identical to RFC 3168): 843 Bits 6 and 7 values 844 0 0 Not-ECT - End-system is Not ECN-capable 845 0 1 ECT(1) - End-system is ECT, once flow is admitted 846 1 0 ECT(0) - End-system is ECT, during flow admission 847 1 1 CE - Congestion Experienced 849 Figure 4: Alternate ECN Semantics for Real-Time Flows 851 6.2 Implication of this Marking 853 During session setup (admission control) end-systems send their 854 packets marked with ECT(0) '10' and once the flow is admitted, end- 855 systems mark their packets with ECT(1) '01'. Routers have a policy 856 that meters all ECN-capable traffic, packets marked with ECT(0) are 857 measured to the 1st threshold level and packets marked with ECT(1) 858 are measured against the 2nd threshold level. The receiving end- 859 system must be informed (some how) if the packet is ECT(0) or ECT(1), 860 during RTP-probing as well after, and there are methods to achieve 861 this. 863 6.3 Reason for Not Using this RT-ECN Marking 865 The concern that the authors of this draft had with the use of the 866 same ECN semantics for two different congestion control mechanism is 867 that there is no simple method for detection of the wrong ECN 868 behavior being applied by router in the path. As stated in 869 Specifying Alternate Semantics for the Explicit Congestion 870 Notification (ECN) Field [17] a method is needed for end-systems to 871 verify that routers are applying the compliant marking for safe co- 872 existence of alternate ECN behavior. For the proposed ECN semantics 873 (see Section 3.4.2), and Section 4 of this document defines a method 874 that can be used to detect the presence of congested routers that use 875 RFC 3168 for its ECN marking. As well, we would like to note that 876 the procedure outlined in RFC 3540 can be used to detect presence of 877 congested routers that use RT-ECN marking. 879 7. Example of ECN usage for Admission Control 881 Normally real-time VoIP bearer traffic is marked with EF DSCP and is 882 mapped into a DiffServ service class that produces very low latency, 883 jitter and packet loss when the traffic load is within the specified 884 parameters. Currently there is no method defined that can limit 885 (without dropping packets) the amount of traffic that can be 886 aggregated onto a link. As a result, controlling loads to within 887 engineered limits is difficult. To address this issue, we propose 888 that for real-time flows we use the metering and ECN marking method 889 defined in this document. 891 Here we describe how ECN can be used in real-time VoIP solution to 892 provide end-to-end admission of new media flows. This is only a 893 simple example of how admission control may be implemented using rate 894 metering and ECN bit marking in the network. Different applications 895 may use modified approaches to verify if there is sufficient 896 bandwidth before admitting a new flow. 898 Let us assume that the network is configured to mark real-time VoIP 899 payload packets with EF DSCP, and only this traffic is mapped into a 900 DiffServ service class referred to as Telephony service class. 901 Mapping of real-time traffic marked with other DSCP values is 902 possible but to keep this example simple we will only talk about EF 903 marked packets. 905 For example, before a session (i.e., a call) is established between 906 two clients, the two endpoints involved in the call will execute a 907 request/response transaction where the called party (Client B) sends 908 a Request probe packet to the calling party (Client A) and the 909 calling party correspondingly sends back a Response probe packet to 910 the called party. Probe packets are marked with EF DSCP and are 911 mapped into the Telephony service class. 913 A DiffServ style traffic conditioner, meter and ECN marker are used 914 on selected nodes in the network along the path to measure the 915 aggregated (real-time media and probe packets) flow rate of EF marked 916 packets. If the flow rate of the EF marked packets as measured by 917 the meter is greater than rate "A", bit 7 in the ECN field of IP 918 header is set to 1 and the packet is forwarded as usual. The 919 metering and marking of ECN bit only needs to be performed on 920 selected nodes where bandwidth constraints exist and where congestion 921 is likely to occur. 923 Upon receipt of the Request probe packet, the calling party generates 924 and sends a Response probe packet to the called party, echoing the 925 status of the received ECN bits in the Response probe packet. Again, 926 a DiffServ style traffic conditioner, meter and ECN marker are used 927 on selected nodes in the network along the reverse path to measure 928 the aggregated flow rate of EF marked packets. If the flow rate of 929 EF marked packets as measured by the meter is greater than rate "A", 930 bit 7 in ECN field of IP header is set to 1 and the packet is 931 forwarded as usual. On receipt of the Response probe packet, the 932 called party could send a notification with the ECN Status to relay 933 the ECN bit status results for the media path to a server in the 934 network where call admission control is performed. Based on the 935 received congestion status (bandwidth usage) for that path, the 936 admission control function will make a decision as to whether or not 937 to continue with call setup and admit this new real-time flow. 938 Should bandwidth usage parameters as indicated by ECN bit marking be 939 exceeded, then this new real-time flow will not be admitted. 941 8. Non-compliance 943 Because of the unstable history of the TOS octet, the use of the ECN 944 field as specified in this document cannot be guaranteed to be 945 backwards compatible with any past uses of these two bits that pre- 946 date ECN. The potential dangers of this lack of backwards 947 compatibility are discussed in RFC 3168 [7] Section 22. 949 9. Changes from Previous Version 951 NOTE TO RFC EDITOR: Please remove this section during the publication 952 process. 954 This version of the draft was rework to address the requirements 955 stated in Specifying Alternate Semantics for the Explicit Congestion 956 Notification (ECN) Field [17], updated section that define "Detection 957 of Inappropriate Changes to the ECN Field" and changes to Appendix A. 959 10. Security Considerations 961 This document discusses detection of congestion for real-time traffic 962 flows and also describes a common policy configuration, for the use 963 and application of ECN bit marking. If implemented as described, it 964 should require the network to do nothing that the network has not 965 already allowed. If that is the case, no new security issues should 966 arise from the use of such a policy. 968 It is possible for the policy to be applied incorrectly, or for a 969 wrong policy to be applied in the network for the defined congestion 970 detection point. In that case, a policy issue exists that the 971 network must detect, assess, and deal with. This is a known security 972 issue in any network dependent on policy-directed behavior. 974 A well known flaw appears when bandwidth is reserved or enabled for a 975 service (for example, voice transport) and another service or an 976 attacking traffic stream uses it. This possibility is inherent in 977 DiffServ technology, which depends on appropriate packet markings. 978 When bandwidth reservation or a priority queuing system is used in a 979 vulnerable network, the use of authentication and flow admission is 980 recommended. To the author's knowledge, there is no known technical 981 way to respond to or act upon a data stream that has been admitted 982 for service but that it is not intended for authenticated use. 984 11. IANA Considerations 986 To be completed. 988 12. Acknowledgements 990 The authors acknowledge a great many inputs, most notably from Sally 991 Floyd, Nabil Bitar, Hadriel Kaplan, David McDysan, Mike Pierce, Alia 992 Atlas, John Rutledge, Francois Audet, Tony MacDonald, Mary Barnes, 993 Greg Thor, Corey Alexander, Jeremy Matthews, Marvin Krym, Stephen 994 Dudley, Bob Briscoe, David Black, and Ralph Carsten. 996 13. Appendix A 998 Below is a description of a Single Rate Meters and ECN Marker. For 999 scenarios that require two traffic levels within a service class to 1000 be measured for congestion indication, two instances of the single 1001 rate meter can be used, one for configured rate "A" and the other for 1002 configured rate "B", with a single ECN marker. The meter parameters 1003 should be selected to meet the characteristics and performance 1004 requirements of traffic being measured. 1006 13.1 Introduction 1008 The Single Rate Meters and ECN Marker is configured by assigning 1009 values to four parameters: Committed Information Rate (CIR), Token 1010 Bucket Size (TBS), ECN set threshold 'm' as a percentage of TBS and 1011 ECN clear threshold 'n' as a percentage of TBS. The meter has an 1012 internal state "result flag" which when set indicates a condition 1013 where the measured traffic has exceeded the CIR and token in the 1014 token bucket where exhausted below 'm' threshold. When the rate 1015 decreases below CIR, token bucket is filled above 'n' threshold and 1016 the internal "result flag" is cleared. 1018 The Meter meters each packet within the real-time service class and 1019 passes the packet and the metering result to the Marker: 1021 +------------+ 1022 | Result | 1023 | V 1024 +-------+ +--------+ 1025 | | | | 1026 Packet Stream ===>| Meter |===>| Marker |===> Marked Packet Stream 1027 | | | | 1028 +-------+ +--------+ 1030 Figure 5: Block Diagram of Meter and Marker Function 1032 The Marker sets the ECN bit values for each packet within the real- 1033 time service class based on the results of the Meter. 1035 13.2 Meter Configuration 1037 The Single Rate Meter and ECN Marker is configured by assigning 1038 values to four traffic parameters: Committed Information Rate (CIR), 1039 Token Bucket Size (TBS), and values 'm' and 'n' representing 1040 percentage fullness of Token Bucket. CIR is measured in bytes of IP 1041 packets per second, i.e., it includes the IP header, but not link 1042 specific headers TBS is measured in bytes, and represents the 1043 variants of the rate being measured. 'm' and 'n' are percentages that 1044 change size of TBS depending on the state of the result flag. 1045 Normally, variable rate traffic will need larger token bucket than 1046 constant rate traffic, and the size will depend on the 1047 characteristics of traffic being measured. TBS should be configured 1048 such that traffic variation within the specified rate as measured at 1049 the node should not use up all the available tokens during a single 1050 measurement duration. 1052 13.3 Meter Behavior 1054 The behavior of the Meter is specified in terms of its Committed 1055 Information Rate (CIR), Token Bucket Size (TBS) and its ECN set and 1056 clear thresholds 'm' and 'n'. 1058 Initially (at time 0), token bucket (TBS) is full, i.e., the token 1059 count is represented by Tp. 1061 Where Tp(0) = TBS 1063 As well, the internal meter result flag (1st_result_flag) is 1064 cleared. 1066 When a packet of size B arrives at time t, the following happens: 1068 Tp = Tp(t) + (CIR x delta_t) //tokens added at CIR 1069 Tp = Min (Tp(t), TBS) //keep Tp from growing pass full 1070 Tp = Tp(t) - B //decrement Tp by B bytes 1071 Tp = Max (0,Tp(t)) //keep Tp from going negative 1072 if (1st_result_flag = = 0) //internal result_flag not set? 1073 if (Tp < TBS x m) //has traffic exceeded CIR? 1074 1st_result_flag = 1 //set internal result_flag 1075 Tp = 0 //set token bucket to zero 1076 else //if internal result_flag is set 1077 if (Tp > TBS x n) //is traffic below CIR? 1078 1st_result_flag = 0 //clear internal result_flag 1079 Tp = TBS //set Tp to TBS 1080 return 1082 Where m and n is 1-99% 1084 Notes: 1085 - delta_t is the elapsed time from the previous received packets. 1086 - m controls token bucket threshold for setting the result flag. 1087 - n controls token bucket threshold for clearing the result flag. 1089 A second instance of this single rate meter can be configured for 1090 measurement of rate "B" (the second rate). 1092 The actual implementation of a Meter doesn't need to be modeled 1093 according to the above formal specification. 1095 13.4 Marking 1097 The ECN Marker reflects the result flag setting received from the 1098 Meters. If 1st_result_flag is set, all packets indicating that the 1099 end-system is ECN-capable, have their ECN bit 7 set to '1'. If the 1100 2nd_result-flag is set, all packets indicating that the end-system is 1101 ECN-capable have their ECN bits 6 and 7 set to '01'. The ECN Marker 1102 sets the ECN bit of ECN-capable marked packets as long as the result 1103 flag(s) from the meters is set. 1105 13.5 Summary of the Behavior 1107 When the measured rate is exceeded (token bucket runs out of tokens) 1108 the meter sets the "result flag" and passes it to the ECN Marker. 1109 The ECN Marker, sets the ECN bit(s) of all ECN-capable marked packets 1110 marked with a specific DS codepoint flowing through the interface 1111 being measured until the traffic rate is reduced below the measuring 1112 threshold; thereby the token bucket becomes full. When the token 1113 bucket becomes full, the meter clears the "result flag". The 1114 clearing of the result flag output from the meter, stops marking of 1115 ECN bit by the Marker. 1117 14. References 1119 14.1 Normative References 1121 [1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 1123 [2] Bradner, S., "The Internet Standards Process -- Revision 3", 1124 BCP 9, RFC 2026, October 1996. 1126 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1127 Levels", BCP 14, RFC 2119, March 1997. 1129 [4] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of 1130 the Differentiated Services Field (DS Field) in the IPv4 and 1131 IPv6 Headers", RFC 2474, December 1998. 1133 [5] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured 1134 Forwarding PHB Group", RFC 2597, June 1999. 1136 [6] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1137 Values In the Internet Protocol and Related Headers", BCP 37, 1138 RFC 2780, March 2000. 1140 [7] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of 1141 Explicit Congestion Notification (ECN) to IP", RFC 3168, 1142 September 2001. 1144 [8] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., 1145 Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An 1146 Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, 1147 March 2002. 1149 [9] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1150 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1151 RFC 3711, March 2004. 1153 14.2 Informative References 1155 [10] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 1156 Congestion Notification (ECN) Signaling with Nonces", RFC 3540, 1157 June 2003. 1159 [11] Alexander, C., "Real-time ECN Use Cases", 1160 draft-alexander-rtecn-use-cases-00 , July 2005. 1162 [12] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines 1163 for DiffServ Service Classes", 1164 draft-ietf-tsvwg-diffserv-service-classes-01 , July 2005. 1166 [13] Dudley, S., "Simulation of RT-ECN based Admission Control and 1167 Preemption", draft-dudley-tsvwg-rtecn-simulation-00 , July 1168 2005. 1170 [14] Babiarz, J., Dudley, S., and K. Chan, "Discussion of Congestion 1171 Marking with RT-ECN", draft-babiarz-rtecn-marking-00 . 1173 [15] Alexander, C. and J. Babiarz, "RTP Payload Format for ECN 1174 Probing", draft-alexander-rtp-payload-for-ecn-probing-01 , 1175 July 2005. 1177 [16] Matsumoto, M. and T. Nishimura, "Mersenne Twister MT 19937", 1178 http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html 1179 http://en.wikipedia.org/wiki/Mersenne_twister, March 2004. 1181 [17] Floyd, S., "Specifying Alternate Semantics for the Explicit 1182 Congestion Notification (ECN) Field", 1183 draft-floyd-ecn-alternates-01 , July 2005. 1185 [18] Alexander, C. and J. Rutledge, "A Congestion Status 1186 Precondition for the Session Initiation Protocol (SIP)", 1187 draft-alexander-congestion-status-preconditions-00 , July 2005. 1189 Authors' Addresses 1191 Jozef Z. Babiarz 1192 Nortel Networks 1193 3500 Carling Avenue 1194 Ottawa, Ont K2H 8E9 1195 Canada 1197 Phone: +1-613-763-6098 1198 Fax: +1-613-768-2231 1199 Email: babiarz@nortel.com 1201 Kwok Ho Chan 1202 Nortel Networks 1203 600 Technology Park Drive 1204 Billerica, MA 01821 1205 US 1207 Phone: +1-978-288-8175 1208 Fax: +1-978-288-4690 1209 Email: khchan@nortel.com 1211 Victor Firoiu 1212 BAE Systems 1213 6 New England Executive Park 1214 Burlington, MA 01803 1215 US 1217 Phone: 1218 Fax: 1219 Email: victor.firoiu@baesystems.com 1221 Intellectual Property Statement 1223 The IETF takes no position regarding the validity or scope of any 1224 Intellectual Property Rights or other rights that might be claimed to 1225 pertain to the implementation or use of the technology described in 1226 this document or the extent to which any license under such rights 1227 might or might not be available; nor does it represent that it has 1228 made any independent effort to identify any such rights. Information 1229 on the procedures with respect to rights in RFC documents can be 1230 found in BCP 78 and BCP 79. 1232 Copies of IPR disclosures made to the IETF Secretariat and any 1233 assurances of licenses to be made available, or the result of an 1234 attempt made to obtain a general license or permission for the use of 1235 such proprietary rights by implementers or users of this 1236 specification can be obtained from the IETF on-line IPR repository at 1237 http://www.ietf.org/ipr. 1239 The IETF invites any interested party to bring to its attention any 1240 copyrights, patents or patent applications, or other proprietary 1241 rights that may cover technology that may be required to implement 1242 this standard. Please address the information to the IETF at 1243 ietf-ipr@ietf.org. 1245 Disclaimer of Validity 1247 This document and the information contained herein are provided on an 1248 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1249 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1250 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1251 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1252 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1253 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1255 Copyright Statement 1257 Copyright (C) The Internet Society (2005). This document is subject 1258 to the rights, licenses and restrictions contained in BCP 78, and 1259 except as set forth therein, the authors retain all their rights. 1261 Acknowledgment 1263 Funding for the RFC Editor function is currently provided by the 1264 Internet Society.