idnits 2.17.1 draft-alexander-rtecn-admission-control-use-case-00.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 777. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 754. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 767. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [1]), 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 171: '...rol, the endpoints involved SHOULD NOT...' RFC 2119 keyword, line 192: '... the IP header MUST be set to 10, in...' RFC 2119 keyword, line 193: '...he Version field MUST be set appropria...' RFC 2119 keyword, line 194: '...remaining fields SHOULD be set to zero...' RFC 2119 keyword, line 272: '...field in the IP headers MUST be set to...' (4 more instances...) 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 (February 11, 2005) is 7013 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) == Missing Reference: '9' is mentioned on line 143, but not defined == Unused Reference: '3' is defined on line 710, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-babiarz-tsvwg-rtecn-03 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-02) exists of draft-alexander-rtp-payload-for-ecn-probing-00 -- Possible downref: Normative reference to a draft: ref. '2' Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Alexander, Ed. 3 Internet-Draft J. Babiarz 4 Expires: August 15, 2005 J. Matthews 5 Nortel 6 February 11, 2005 8 Admission Control Use Case for Real-time ECN 9 draft-alexander-rtecn-admission-control-use-case-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 15, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document describes Admission Control as a use case for the 45 mechanisms described in "Congestion Notification Process for 46 Real-Time Traffic" [1] and the RTP payload format defined in "RTP 47 Payload Format for ECN Probing" [2]. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3. Admission Control . . . . . . . . . . . . . . . . . . . . . . 6 54 3.1 Probing Mechanism . . . . . . . . . . . . . . . . . . . . 6 55 3.2 Usage Examples . . . . . . . . . . . . . . . . . . . . . . 6 56 3.2.1 One-way Mechanism without Cheater Detection . . . . . 6 57 3.2.2 Two-way/Loop-back Mechanism without Cheater 58 Detection . . . . . . . . . . . . . . . . . . . . . . 8 59 3.2.3 One-way Mechanism with Cheater Detection . . . . . . . 11 60 3.2.4 Two-way/Loop-back Mechanism with Cheater Detection . . 13 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 63 6. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 20 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 66 8.1 Normative References . . . . . . . . . . . . . . . . . . . 22 67 8.2 Informative References . . . . . . . . . . . . . . . . . . 22 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 69 Intellectual Property and Copyright Statements . . . . . . . . 24 71 1. Introduction 73 Converged networks that are configured to provide multi-services 74 normally are engineered to provide the required quality of service 75 using Diffserv technologies. Real-time inelastic traffic (e.g. 76 voice) normally is configured to use Expedited Forwarding (EF) PHB to 77 provide very low delay, loss and jitter transport. To stay within 78 that engineered quality of service, and to ensure a quality of 79 service level for that traffic, some type of admission control 80 mechanism is necessary. Due to the sensitive nature of voice and 81 other telephony applications (video conferencing, multi-media 82 streaming), freely allowing these types of sessions onto a network 83 where resources are limited can quickly lead to degradation of 84 service that users may not tolerate. And in a packet based network, 85 the degradation is not limited to the offending flows, which the 86 provider may not tolerate. 88 This document proposes an admission control solution based on 89 "Congestion Notification Process for Real-Time Traffic" [1] and "RTP 90 Payload Format for ECN Probing" [2]. The gist of the solution is 91 that nodes at selected points in the network, where congestion is 92 most likely to occur, measure traffic flow per service class and mark 93 the ECN bits in the IP header based on observed traffic level(s). 94 During session setup a probing mechanism is used between endpoints to 95 verify traffic level (or congestion) along the path. The probing 96 travels along the media path between the endpoints, where the 97 endpoints are on either side of one or more bandwidth constrained 98 links. At the links, ECN-capable nodes are provisioned with 99 congestion thresholds based on a traffic type's real-time service 100 class. The nodes mark the ECN bits in the IP headers of the probe 101 packets according to the nodes' experienced level of congestion for 102 the particular service class. As packets arrive, the ECN-capable 103 endpoints recognize any ECN markings and make an admission control 104 decision according to the indicated congestion level and session 105 precedence. 107 The Real-Time ECN process offers two levels of congestion indication. 108 There is an intermediate congestion indication in addition to a 109 maximum congestion indication. This adds flexibility to admission 110 control decisions. The intermediate congestion indication 111 essentially warns endpoint applications that network congestion is 112 relatively high but that there is still some available bandwidth. 113 Using this information, applications can possibly decide to filter 114 out certain types of sessions for admission in favor of other types. 115 Applications demanding a large amount of bandwidth like video 116 conferencing might be denied, while less bandwidth-intensive voice 117 sessions could be admitted. Whatever the admission control basis, 118 Real-Time ECN enables some discernment in the decision making rather 119 than wholesale denial of sessions. 121 Also, Real-Time ECN does not introduce a significant amount of 122 overhead to the network. Not every node in the network needs to be 123 ECN-capable. Only those nodes located at congestion points need the 124 capability. At the nodes, ECN metering and marking is quick. There 125 is practically no real-time hit to the routing. An ECN node does not 126 maintain flow state and does not add delay with any intricate policy 127 decisions. It's impact on the network is very low. 129 The remainder of this memo provides four examples depicting ECN-based 130 probing for admission control. While the examples provided are 131 protocol-agnostic, general recommendations are provided as to how the 132 payload format defined in [2] should be used in the context of 133 admission control. No protocol-specific signaling is defined or 134 suggested herein to show how to use the payload while admitting a new 135 session. 137 2. Terminology 139 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 140 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 141 and "OPTIONAL" are to be interpreted as described in RFC 2119 [9] and 142 indicate requirement levels for compliant implementations. 144 3. Admission Control 146 Admission control can use a probing mechanism to determine whether 147 there is available bandwidth for a session. The endpoints of a 148 session perform this probing which occurs during session setup. 149 Depending upon results of the probing mechanism, the session will be 150 either admitted or denied. This decision can be made within an 151 endpoint, or by a session server. 153 3.1 Probing Mechanism 155 The probing mechanism makes use of "Congestion Notification Process 156 for Real-Time Traffic" [1] and "RTP Payload Format for ECN Probing" 157 [2]. It can be either uni-directional or bi-directional, but in 158 either case is end-to-end. 160 3.2 Usage Examples 162 Four usage examples are provided. These cover use of the RTP payload 163 format in [2] in both one-way and two-way loop-back mechanisms, both 164 with and without detection of Cheaters along the media path. The 165 terminology used is defined in [2], as well. 167 All examples presume that probing starts at a point during session 168 setup when the Responder endpoint addressing information is known by 169 the Sender, and the dynamic payload type used for the packets 170 carrying the payload has been determined. As the immediate 171 application is admission control, the endpoints involved SHOULD NOT 172 begin alerting or otherwise notifying the user of a new session until 173 the admission control procedures determine whether to admit the new 174 session. 176 All examples list the relevant field contents where necessary. In a 177 real implementation, it is recommended that the payload be secured. 179 In order to ensure there is no confusion between different versions 180 of the referenced drafts, the following ECN bit definitions are used 181 in the four examples: 183 00 Not ECN-capable 184 10 ECN-capable, with no congestion experienced 185 11 ECN-capable, with congestion experienced at the first level 186 01 ECN-capable, with congestion experienced at the second level 188 3.2.1 One-way Mechanism without Cheater Detection 190 A one-way probing mechanism without cheater detection is the simplest 191 possible use of the payload format defined in [2]. The ECN field in 192 the IP header MUST be set to 10, indicating that the endpoint is 193 ECN-capable. The Version field MUST be set appropriately, i.e., for 194 this memo, to zero. The remaining fields SHOULD be set to zero. If 195 the session for which admission control is two-way, then two of these 196 one-way mechanisms can be used for admission control, one in each 197 direction. 199 (1) (3) 200 +------+ +----------+ +------+ 201 | | | | | | 202 | EP A | ----> | Router A | ----> + EP B | (5) 203 | | | | | | 204 +------+ +----------+ +------+ 205 (2) (4) 207 Figure 1: One-way Mechanism without Cheater Detection 209 1. Endpoint (EP) A starts the process. It creates a Request Probe 210 Packet and sends it to the address and port it has for EP B. 212 IP Header: 213 DSCP: 214 ECN: 10, indicating endpoint is ECN-capable 215 RTP Header: 216 Payload Type: 217 admcntl Payload: 218 Version: 0000 219 SCI: 00 220 RCI: 00 221 SCI Sequence Number: 0000 0000 0000 0000 222 Reserved: 0000 0000 224 2. Router A receives the Request Probe Packet, and factors it into 225 the methods described in [1] for real-time inelastic traffic. 227 3. Router A re-marks the ECN field in the IP header of the Request 228 Probe Packet as described in [1], then forwards the packet. 230 IP Header: 231 DSCP: 232 ECN: 234 RTP Header: 235 Payload Type: 236 admcntl Payload: 238 Version: 0000 239 SCI: 00 240 RCI: 00 241 SCI Sequence Number: 0000 0000 0000 0000 242 Reserved: 0000 0000 244 4. EP B receives the Request Probe Packet. The ECN value, ReqECN, 245 in the IP header indicates the highest level of congestion on the 246 path towards EP B. 248 IP Header: 249 DSCP: 250 ECN: 252 RTP Header: 253 Payload Type: 254 admcntl Payload: 255 Version: 0000 256 SCI: 00 257 RCI: 00 258 SCI Sequence Number: 0000 0000 0000 0000 259 Reserved: 0000 0000 261 5. EP B inspects the ECN value, ReqECN, in the IP header, then knows 262 the highest level of congestion on the path towards EP B. Based 263 on this, EP B can determine whether the session should be 264 admitted. 266 3.2.2 Two-way/Loop-back Mechanism without Cheater Detection 268 The two-way probing mechanism without cheater detection is not that 269 much more complicated than the one-way probing mechanism, although it 270 does utilize one additional payload field. The most noticable 271 difference is that a Response Probe Packet is sent in response to the 272 Request Probe Packet. The ECN field in the IP headers MUST be set to 273 10, indicating that the endpoints are ECN-capable. The Version field 274 MUST be set appropriately, i.e., for this memo, to zero. The SCI 275 field in the Request Probe Packet SHOULD be set to zero, and in the 276 Response Probe Packet should be set to the ECN value in the IP header 277 of the associated Request Probe Packet. The remaining fields SHOULD 278 be set to zero. 280 With a two-way/loop-back probing mechanism, the congestion indication 281 for both the upstream and downstream packet flows can be determined 282 with a single procedure, as illustrated by this example. 284 (1) (2) (3) (4) 285 +------+ +----------+ +------+ 286 | | ----> | Router A | ----> | | 287 | | +----------+ | | 288 (9) | EP A | | EP B | 289 | | +----------+ | | 290 | | <---- | Router B | <---- | | 291 +------+ +----------+ +------+ 292 (8) (7) (6) (5) 294 Figure 2: Two-way/Loop-back Mechanism without Cheater Detection 296 1. Endpoint (EP) A starts the process. It creates a Request Probe 297 Packet and sends it to the address and port it has for EP B. 299 IP Header: 300 DSCP: 301 ECN: 10, indicating endpoint is ECN-capable 302 RTP Header: 303 Payload Type: 304 admcntl Payload: 305 Version: 0000 306 SCI: 00 307 RCI: 00 308 SCI Sequence Number: 0000 0000 0000 0000 309 Reserved: 0000 0000 311 2. Router A receives the Request Probe Packet, and factors it into 312 the methods described in [1] for real-time inelastic traffic. 314 3. Router A re-marks the ECN field in the IP header of the Request 315 Probe Packet as described in [1], then forwards the packet. 317 IP Header: 318 DSCP: 319 ECN: 321 RTP Header: 322 Payload Type: 323 admcntl Payload: 324 Version: 0000 325 SCI: 00 326 RCI: 00 327 SCI Sequence Number: 0000 0000 0000 0000 328 Reserved: 0000 0000 330 4. EP B receives the Request Probe Packet. The ECN value, ReqECN, 331 in the IP header indicates the highest level of congestion on the 332 path towards EP B. This completes the first half of the 333 two-way/loop-back probe. 335 IP Header: 336 DSCP: 337 ECN: 339 RTP Header: 340 Payload Type: 341 admcntl Payload: 342 Version: 0000 343 SCI: 00 344 RCI: 00 345 SCI Sequence Number: 0000 0000 0000 0000 346 Reserved: 0000 0000 348 5. EP B creates a Response Probe Packet and sends it to the address 349 and port it has for EP A. Note the payload difference between 350 the Request Probe Packet sent by EP A and the Response Probe 351 Packet sent by EP B. First, the SCI field contains the ReqECN 352 value from the Request Probe Packet. Second, the SCI Sequence 353 Number field contains the value of the Sequence Number field in 354 the RTP header of the Request Probe Packet. 356 IP Header: 357 DSCP: 358 ECN: 10, indicating endpoint is ECN-capable 359 RTP Header: 360 Payload Type: 361 admcntl Payload: 362 Version: 0000 363 SCI: 365 RCI: 00 366 SCI Sequence Number: 368 Reserved: 0000 0000 370 6. Router B receives the Response Probe Packet, and factors it into 371 the methods described in [1] for real-time inelastic traffic. 373 7. Router B re-marks the ECN field in the IP header of the Response 374 Probe Packet as described in [1], then forwards the packet. 376 IP Header: 378 DSCP: 379 ECN: 381 RTP Header: 382 Payload Type: 383 admcntl Payload: 384 Version: 0000 385 SCI: 387 RCI: 00 388 SCI Sequence Number: 390 Reserved: 0000 0000 392 8. EP A receives the Response Probe Packet. The ECN value, RspECN, 393 in the IP header indicates the highest level of congestion on 394 path towards EP A. This completes the second half of the 395 two-way/loop-back probe. 397 IP Header: 398 DSCP: 399 ECN: 401 RTP Header: 402 Payload Type: 403 admcntl Payload: 404 Version: 0000 405 SCI: 407 RCI: 00 408 SCI Sequence Number: 410 Reserved: 0000 0000 412 9. EP A inspects the two ECN values, RspECN (in the IP header) and 413 ReqECN (in the admcntl payload), then knows the highest level of 414 congestion on the paths between EP A and EP B. Based on this, EP 415 A can determine whether the session should be admitted. 417 3.2.3 One-way Mechanism with Cheater Detection 419 A one-way probing mechanism with cheater detection differs from the 420 first example in two respects. First, the SCI field in the Request 421 Probe Packet contains the ECN value set in the ECN field in the IP 422 header. Second, additional processing in EP B is necessary to 423 determine if there are Cheaters present on the path towards EP B. In 424 order to perform Cheater detection, more than one Request Probe 425 Packet must be sent, each with different ECN values in the IP header, 426 as described in [1]. 428 (1) (3) 429 +------+ +----------+ +------+ 430 | | | | | | 431 | EP A | ----> | Router A | ----> + EP B | (5) 432 | | | | | | 433 +------+ +----------+ +------+ 434 (2) (4) 436 Figure 3: One-way Mechanism with Cheater Detection 438 1. Endpoint (EP) A starts the process. It creates a Request Probe 439 Packet and sends it to the address and port it has for EP B. At 440 least three Request Probe Packets are sent. A random ordering of 441 the three ECN value 10, 11, or 01 is chosen, and these values are 442 used in sequential Request Probe Packets for the ECN value in the 443 IP header and the SCI field in the admcntl payload. Refer to [1] 444 for additional details. At least three Request Probe Packets are 445 needed so that three sequential packets are received by the 446 Responder in order to determine the actual marking from the 447 routers along the network path. 449 IP Header: 450 DSCP: 451 ECN: <10, 11, or 01; Refer to [1] for details> 452 RTP Header: 453 Payload Type: 454 admcntl Payload: 455 Version: 0000 456 SCI: 458 RCI: 00 459 SCI Sequence Number: 0000 0000 0000 0000 460 Reserved: 0000 0000 462 2. Router A receives the Request Probe Packet, and factors it into 463 the methods described in [1] for real-time inelastic traffic. 465 3. Router A re-marks the ECN field in the IP header of the Request 466 Probe Packet as described in [1], then forwards the packet. 468 IP Header: 469 DSCP: 470 ECN: 472 RTP Header: 473 Payload Type: 474 admcntl Payload: 475 Version: 0000 476 SCI: 478 RCI: 00 479 SCI Sequence Number: 0000 0000 0000 0000 480 Reserved: 0000 0000 482 4. EP B receives the Request Probe Packet. EP B tracks the ECN 483 value, ReqECN, from the IP header, and the SCI value from the 484 admcntl payload until it receives at least three out of four 485 sequential Request Probe Packets. 487 IP Header: 488 DSCP: 489 ECN: 491 RTP Header: 492 Payload Type: 493 admcntl Payload: 494 Version: 0000 495 SCI: 497 RCI: 00 498 SCI Sequence Number: 0000 0000 0000 0000 499 Reserved: 0000 0000 501 5. Once EP B has received three sequential Request Probe Packets, it 502 can follow the steps described in [1] to both detect if Cheaters 503 are present on the path towards EP B, and to filter out the 504 highest actual level of congestion on path towards EP B. The 505 decision to admit is made based on whether Cheaters are present 506 and the level of congestion indicated by the ECN markings. 508 3.2.4 Two-way/Loop-back Mechanism with Cheater Detection 510 The two-way probing mechanism with cheater detection differs from the 511 second example mainly with respect to the content of the admcntl 512 fields in the Response Probe Packet. In the Response Probe Packet, 513 the SCI field contains the ECN value in the IP header of the 514 associated Request Probe Packet. The SCI Sequence Number field 515 contains the sequence number from the RTP header of the associated 516 Request Probe Packet. 518 In the Request Probe Packet, all admcntl payload fields SHOULD be set 519 to zero. 521 (1) (2) (3) (4) 522 +------+ +----------+ +------+ 523 | | ----> | Router A | ----> | | 524 | | +----------+ | | 525 (9) | EP A | | EP B | 526 | | +----------+ | | 527 | | <---- | Router B | <---- | | 528 +------+ +----------+ +------+ 529 (8) (7) (6) (5) 531 Figure 4: Two-way/Loop-back Mechanism with Cheater Detection 533 1. Endpoint (EP) A starts the process. It creates a Request Probe 534 Packet and sends it to the address and port it has for EP B. At 535 least three Request Probe Packets are sent. A random ordering of 536 the three ECN value 10, 11, or 01 is chosen, and these values are 537 used in sequential Request Probe Packets for the ECN value in the 538 IP header and the SCI field in the admcntl payload. Refer to [1] 539 for additional details. At least three Request Probe Packets are 540 needed so that three sequential packets are received by the 541 Responder in order to determine the actual marking from the 542 routers along the network path. EP A must track the ECN value 543 used by sequence number for use in steps 8 and 9 below. Refer to 544 [1] for additional details. All other admcntl fields are zero 546 IP Header: 547 DSCP: 548 ECN: <10, 11, or 01; Refer to [1] for details> 549 RTP Header: 550 Payload Type: 551 admcntl Payload: 552 Version: 0000 553 SCI: 00 554 RCI: 00 555 SCI Sequence Number: 0000 0000 0000 0000 556 Reserved: 0000 0000 558 2. Router A receives the Request Probe Packet, and factors it into 559 the methods described in [1] for real-time inelastic traffic. 561 3. Router A re-marks the ECN field in the IP header of the Request 562 Probe Packet as described in [1], then forwards the packet. 564 IP Header: 565 DSCP: 566 ECN: 568 RTP Header: 569 Payload Type: 570 admcntl Payload: 571 Version: 0000 572 SCI: 00 573 RCI: 00 574 SCI Sequence Number: 0000 0000 0000 0000 575 Reserved: 0000 0000 577 4. EP B receives the Request Probe Packet. The ECN value, ReqECN, 578 in the IP header indicates the highest level of congestion on the 579 path towards EP B. This completes the first half of the 580 two-way/loop-back probe. 582 IP Header: 583 DSCP: 584 ECN: 586 RTP Header: 587 Payload Type: 588 admcntl Payload: 589 Version: 0000 590 SCI: 00 591 RCI: 00 592 SCI Sequence Number: 0000 0000 0000 0000 593 Reserved: 0000 0000 595 5. EP B creates a Response Probe Packet and sends it to the address 596 and port it has for EP A. Note the payload difference between 597 the Request Probe Packet sent by EP A and the Response Probe 598 Packet sent by EP B. First, the SCI field contains the ReqECN 599 value from the Request Probe Packet. Second, the SCI Sequence 600 Number field contains the value of the Sequence Number field in 601 the RTP header of the Request Probe Packet. Similar to the 602 Request Probe Packet, the ECN value in the IP header of the 603 Response Probe Packet and the SCI field in the admcntl payload 604 are set with one of 10, 11, or 01. 606 IP Header: 607 DSCP: 608 ECN: <10, 11, or 01; Refer to [1] for details> 609 RTP Header: 610 Payload Type: 611 admcntl Payload: 612 Version: 0000 613 SCI: 615 RCI: 617 SCI Sequence Number: 619 Reserved: 0000 0000 621 6. Router B receives the Response Probe Packet, and factors it into 622 the methods described in [1] for real-time inelastic traffic. 624 7. Router B re-marks the ECN field in the IP header of the Response 625 Probe Packet as described in [1], then forwards the packet. 627 IP Header: 628 DSCP: 629 ECN: 631 RTP Header: 632 Payload Type: 633 admcntl Payload: 634 Version: 0000 635 SCI: 637 RCI: 639 SCI Sequence Number: 641 Reserved: 0000 0000 643 8. EP A receives the Response Probe Packet. EP A tracks the ECN 644 values ReqECN (from the SCI field in the admcntl payload), RspECN 645 (from the ECN field in the IP header of the Response Probe 646 Packet), and RCI from the admcntl payload. It uses the SCI 647 Sequence Number value to associate these three values with the 648 appropriate ECN value used step 1 above. It tracks these values 649 until it receives at least three sequential Request Probe 650 Packets. 652 IP Header: 654 DSCP: 655 ECN: 657 RTP Header: 658 Payload Type: 659 admcntl Payload: 660 Version: 0000 661 SCI: 663 RCI: 665 SCI Sequence Number: 667 Reserved: 0000 0000 669 9. Once EP A has received three sequential Response Probe Packets, 670 it can follow the steps described in [1] to both detect if 671 Cheaters are present on both of the paths, towards EP B and 672 towards EP B, and to filter out the highest actual level of 673 congestion on both of the paths. The decision to admit is made 674 based on whether Cheaters are present and the level of congestion 675 indicated by the ECN markings. 677 4. Security Considerations 679 Refer to "Congestion Notification Process for Real-Time Traffic" [1] 680 and "RTP Payload Format for ECN Probing" [2] for security-related 681 considerations. 683 5. IANA Considerations 685 There are no IANA considerations. 687 6. IAB Considerations 689 There are no IAB considerations. 691 7. Acknowledgements 693 The authors acknowledge a great many inputs, including the following: 694 John Rutledge, Marvin Krym, Stephen Dudley, and Kwok Ho Chan. 696 8. References 698 8.1 Normative References 700 [1] Babiarz, J., Chan, K. and V. Firoiu, "Congestion Notification 701 Process for Real-Time Traffic, draft-babiarz-tsvwg-rtecn-03", 702 Internet-Draft Work in Progress, February 2005. 704 [2] Alexander, C., Ed. and J. Babiarz, "RTP Payload Format for ECN 705 Probing, draft-alexander-rtp-payload-for-ecn-probing-00", 706 Internet-Draft Work in Progress, February 2005. 708 8.2 Informative References 710 [3] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of 711 Explicit Congestion Notification (ECN) to IP", RFC 3168, 712 September 2001. 714 Authors' Addresses 716 Corey W. Alexander (editor) 717 Nortel 718 MS 08704A30 719 2370 Performance Drive 720 Richardson, TX 75287 721 USA 723 Phone: +1 972 684-8320 724 Email: coreya@nortel.com 726 Jozef Z. Babiarz 727 Nortel 728 MS 04331C04 729 3500 Carling Avenue 730 Nepean, Ontario K2H 8E9 731 Canada 733 Phone: +1 613 763-6098 734 Email: babiarz@nortel.com 735 Jeremy P. Matthews 736 Nortel 737 MS 08704A30 738 2370 Performance Drive 739 Richardson, TX 75082 740 USA 742 Phone: +1 972 684-0336 743 Email: jeremym@nortel.com 745 Intellectual Property Statement 747 The IETF takes no position regarding the validity or scope of any 748 Intellectual Property Rights or other rights that might be claimed to 749 pertain to the implementation or use of the technology described in 750 this document or the extent to which any license under such rights 751 might or might not be available; nor does it represent that it has 752 made any independent effort to identify any such rights. Information 753 on the procedures with respect to rights in RFC documents can be 754 found in BCP 78 and BCP 79. 756 Copies of IPR disclosures made to the IETF Secretariat and any 757 assurances of licenses to be made available, or the result of an 758 attempt made to obtain a general license or permission for the use of 759 such proprietary rights by implementers or users of this 760 specification can be obtained from the IETF on-line IPR repository at 761 http://www.ietf.org/ipr. 763 The IETF invites any interested party to bring to its attention any 764 copyrights, patents or patent applications, or other proprietary 765 rights that may cover technology that may be required to implement 766 this standard. Please address the information to the IETF at 767 ietf-ipr@ietf.org. 769 Disclaimer of Validity 771 This document and the information contained herein are provided on an 772 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 773 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 774 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 775 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 776 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 777 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 779 Copyright Statement 781 Copyright (C) The Internet Society (2005). This document is subject 782 to the rights, licenses and restrictions contained in BCP 78, and 783 except as set forth therein, the authors retain all their rights. 785 Acknowledgment 787 Funding for the RFC Editor function is currently provided by the 788 Internet Society.