idnits 2.17.1 draft-ietf-pcn-3-state-encoding-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-pcn-baseline-encoding]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 8, 2009) is 5497 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-pcn-marking-behaviour-02 == Outdated reference: A later version (-07) exists of draft-ietf-pcn-baseline-encoding-03 == Outdated reference: A later version (-10) exists of draft-ietf-tsvwg-ecn-tunnel-02 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Congestion and Pre Congestion T. Moncaster 3 Internet-Draft BT 4 Intended status: Experimental B. Briscoe 5 Expires: October 10, 2009 BT & UCL 6 M. Menth 7 University of Wuerzburg 8 April 8, 2009 10 A PCN encoding using 2 DSCPs to provide 3 or more states 11 draft-ietf-pcn-3-state-encoding-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on October 10, 2009. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 Pre-congestion notification (PCN) is a mechanism designed to protect 60 the Quality of Service of inelastic flows within a controlled domain. 61 It does this by marking packets when traffic load on a link is 62 approaching or has exceeded a threshold below the physical link rate. 63 This experimental encoding scheme specifies how three encoding states 64 can be carried in the IP header using a combination of two DSCPs and 65 the ECN bits. The Basic scheme only allows for three encoding 66 states. The Full scheme additionally provides limited end-to-end 67 support for ECN. 69 Status (to be removed by RFC Editor) 71 This memo is posted as an Internet-Draft with an intent to eventually 72 be published as an experimental RFC. The PCN Working Group will be 73 asked to adopt this memo as a Working Group document describing one 74 of several possible experimental PCN encoding schemes. The intention 75 is that the title of this document will change to avoid confusion 76 with the three state marking scheme. 78 Changes from previous drafts 80 From draft-moncaster-pcn-3-state-encoding-01: 82 o Changed to WG draft. Title changed from "A three state extended 83 PCN encoding scheme" 85 o Imposed new structure on document. This structure is intended to 86 be followed by all extensions to the baseline PCN encoding scheme. 88 o Extensive changes throughout to ensure consistency with the 89 baseline PCN encoding scheme. 91 From 00 to 01: 93 o Checked terminology for consistency with 94 [I-D.ietf-pcn-baseline-encoding] 96 o Minor editorial changes. 98 Table of Contents 100 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 101 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 102 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 103 4. The Requirement for Three PCN Encoding States . . . . . . . . 5 104 5. Adding Limited End-to-End ECN Support to PCN . . . . . . . . . 6 105 6. Encoding Three PCN States in IP . . . . . . . . . . . . . . . 6 106 6.1. Basic Three State Encoding . . . . . . . . . . . . . . . . 7 107 6.2. Full Three State Encoding . . . . . . . . . . . . . . . . 7 108 6.3. Valid and invalid codepoint transitions at 109 PCN-ingress-nodes . . . . . . . . . . . . . . . . . . . . 8 110 6.4. Valid and invalid codepoint transitions at 111 PCN-interior-nodes . . . . . . . . . . . . . . . . . . . . 8 112 6.5. Forwarding traffic out of the PCN-domain . . . . . . . . . 9 113 7. PCN-domain support for the PCN extension encoding . . . . . . 10 114 7.1. End-to-End transport behaviour compliant with the PCN 115 extension encoding . . . . . . . . . . . . . . . . . . . . 10 116 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 117 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 118 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 119 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 120 12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 11 121 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 122 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 123 13.2. Informative References . . . . . . . . . . . . . . . . . . 12 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 126 1. Introduction 128 The objective of Pre-Congestion Notification (PCN) 129 [I-D.ietf-pcn-architecture] is to protect the quality of service 130 (QoS) of inelastic flows within a Diffserv domain, in a simple, 131 scalable and robust fashion. The overall rate of the PCN-traffic is 132 metered on every link in the PCN-domain, and PCN-packets are 133 appropriately marked when certain configured rates are exceeded. 134 These configured rates are below the rate of the link thus providing 135 notification before any congestion occurs (hence "pre-congestion 136 notification"). The level of marking allows the boundary nodes to 137 make decisions about whether to admit or block a new flow request, 138 and (in abnormal circumstances) whether to terminate some of the 139 existing flows, thereby protecting the QoS of previously admitted 140 flows. 142 The baseline encoding described in [I-D.ietf-pcn-baseline-encoding] 143 provides for deployment scenarios that only require two PCN encoding 144 states. This document describes an experimental extension to the 145 base-encoding in the IP header that adds two capabilities: 147 o the addition of a third PCN encoding state in the IP header 149 o preservation of the end-to-end semantics of the ECN field even 150 though PCN uses the field within a PCN-region that interrupts the 151 end-to-end path 153 The second of these capabilities is optional and the reasons for 154 doing it are discussed in Section 5. 156 As in the baseline encoding, this extension encoding re-uses the ECN 157 bits within the IP header within a controlled PCN-domain. This 158 extension requires the use of two DSCPs as described later in this 159 document. This experimental scheme is one of three that are being 160 proposed within the PCN working group. The aim is to allow 161 implementors to decide which scheme is most suitable for possible 162 future standardisation. 164 2. Requirements notation 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119]. 170 3. Terminology 172 Most of the terminology used in this document is defined either in 173 [I-D.ietf-pcn-architecture] or in [I-D.ietf-pcn-baseline-encoding]. 174 The following additional terms are defined in this document: 176 o PCN-flow - a flow covered by a reservation but which hasn't 177 signalled that it requires end-to-end ECN support. 179 o PCN-enabled-ECN-flow - a flow covered by reservation and for which 180 the end-to-end transport has explicitly negotiated ECN support 181 from the PCN-boundary-nodes. 183 o Not-marked (xxx), where xxx represents a standard ECN codepoint - 184 packets that are PCN capable but carry no PCN mark. Abbreviated 185 as NM(xxx). The (xxx) represents the ECN codepoint that the 186 packet arrived with at the PCN-ingress-node e.g. NM(CE) 187 represents a PCN capable packet that has no PCN marking but which 188 arrived with the ECN bits set to congestion experienced. 190 4. The Requirement for Three PCN Encoding States 192 The PCN Marking Behaviours document [I-D.ietf-pcn-marking-behaviour] 193 describes proposed PCN schemes that require traffic to be metered and 194 marked using both Threshold and Excess Traffic schemes. In order to 195 achieve this it is necessary to allow for three PCN encoding states. 196 The constraints imposed by the way tunnels process the ECN field 197 severely limit how to encode these states as explained in 198 [I-D.ietf-pcn-baseline-encoding] and [I-D.ietf-tsvwg-ecn-tunnel]. 199 The obvious way to provide one more encoding state than the base 200 encoding is through the use of an additional PCN-compatible DiffServ 201 codepoint. 203 One aim of this document is to allow for experiments to show whether 204 such schemes are better than those that only employ two PCN encoding 205 states. As such, the additional DSCP will be taken from the EXP/LU 206 pools defined in [RFC2474]. If the experiments demonstrate that PCN 207 schemes employing three encoding states are significantly better than 208 those only employing two then at a later date IANA might be asked to 209 assign a new PCN enabled DSCP from pool 1. Note that there are other 210 experimental encoding schemes being considered which only use one 211 DSCP but require either alternative tunnel semantics 212 ([I-D.briscoe-pcn-3-in-1-encoding]) or additional signalling 213 ([I-D.menth-pcn-psdm-encoding])in order to work. 215 5. Adding Limited End-to-End ECN Support to PCN 217 [I-D.sarker-pcn-ecn-pcn-usecases] suggests a number of use-cases 218 where explicit preservation of end-to-end ECN semantics might be 219 needed across a PCN domain. One of the use-cases suggests that the 220 end-nodes might be running rate-adaptive codecs that would respond to 221 ECN marks by reducing their transmission rate. If the sending 222 transport sets the ECT codepoint, the setting of the ECN field as it 223 arrives at the PCN ingress node will need to be re-instated as it 224 leaves the PCN egress node. 226 If a PCN region is starting to suffer pre-congestion then it may make 227 sense to expose marks generated within the PCN region by forwarding 228 CE marks from the PCN egress to such a rate-adaptive endpoint. They 229 would be in addition to any CE marks generated elsewhere on the end- 230 to-end path. This would allow the endpoints to reduce the traffic 231 rate. This will in turn help to alleviate the pre-congestion, 232 potentially averting any need for call blocking or termination. 233 However, the 'leaking' of CE marks out of the PCN region is 234 potentially dangerous and could violate [RFC4774] if the end hosts 235 don't understand ECN (see section 18.1.4 of [RFC3168]). 237 Therefore, a PCN region can only support end-to-end ECN if the PCN- 238 boundary-nodes are sure that the end-to-end transport is ECN-capable. 239 That way the PCN-egress-nodes can ensure that they only expose CE 240 marks to those receivers that will correctly interpret them as a 241 notification of congestion. The end-points may indicate they are 242 ECN-capable through some higher-layer signalling process that sets up 243 their reservation with the PCN boundary nodes. The exact process of 244 negotiation is beyond the scope of this document but is likely to 245 involve explicit two way signalling between the end-host and the PCN- 246 domain. 248 In the absence of such signalling the default behaviour of the PCN 249 egress node will be to clear the ECN field to 00 as in the baseline 250 PCN encoding [I-D.ietf-pcn-baseline-encoding]. 252 6. Encoding Three PCN States in IP 254 The three state PCN encoding scheme is based closely on that defined 255 in [I-D.ietf-pcn-baseline-encoding] so that there will be no 256 compatibility issues if a PCN-domain changes from using the baseline 257 encoding scheme to the experimental scheme described here. There are 258 two versions of the scheme. The basic three state scheme allows for 259 carrying both Threshold-marked (ThM) and Excess-traffic-marked (ETM) 260 traffic. The full scheme additionally allows end-to-end ECN to be 261 carried across the PCN-domain. 263 6.1. Basic Three State Encoding 265 The following table shows how to encode the three PCN states in IP. 266 The authors spent some time trying to establish which way round to 267 put the two marked states before settling on this. Because it is 268 envisaged that DSCP 2 will be of lower priority than DSCP 1 the 269 change in marking from Threshold to Excess Traffic involves 270 downgrading the traffic which seems to be consistent with the 271 requirement that such changes should not be reversed. 273 +--------+--------------+-------------+-------------+---------+ 274 | DSCP | Not-ECT (00) | ECT(0) (10) | ECT(1) (01) | CE (11) | 275 +--------+--------------+-------------+-------------+---------+ 276 | DSCP 1 | Not-PCN | NM | CU | ThM | 277 | DSCP 2 | Not-PCN | CU | CU | ETM | 278 +--------+--------------+-------------+-------------+---------+ 280 (where DSCP 1 is a PCN-compatible DiffServ codepoint (see 281 [I-D.ietf-pcn-baseline-encoding]) and DSCP 2 is a PCN-compatible DSCP 282 from the EXP/LU pools as defined in [RFC2474]) 284 Table 1: Encoding three PCN states in IP 286 6.2. Full Three State Encoding 288 Table 2 shows how to additionally carry the end-to-end ECN state in 289 the IP header. 291 +--------+--------------+-------------+-------------+---------+ 292 | DSCP | Not-ECT (00) | ECT(0) (10) | ECT(1) (01) | CE (11) | 293 +--------+--------------+-------------+-------------+---------+ 294 | DSCP 1 | Not-PCN | NM(Not-ECT) | NM(CE) | ThM | 295 | DSCP 2 | Not-PCN | NM(ECT(0)) | NM(ECT(1)) | ETM | 296 +--------+--------------+-------------+-------------+---------+ 298 (where DSCP 1 is a PCN-compatible DiffServ codepoint (see 299 [I-D.ietf-pcn-baseline-encoding]) and DSCP 2 is a PCN-compatible DSCP 300 from the EXP/LU pools as defined in [RFC2474]) 302 Table 2: Encoding three PCN states in IP 304 The four different Not-marked (NM) states allow for the addition of 305 limited end-to-end ECN support as explained in the previous section. 307 Warning 309 In order to comply with this encoding all the nodes within the PCN- 310 domain MUST be configured with this encoding scheme. However there 311 may be operators who choose not to be fully compliant with the 312 scheme. If an operator chooses to leave some PCN-interior-nodes that 313 only support two marking states (the base encoding), then they must 314 be aware of the following: Ideally such nodes would be configured to 315 indicate pre-congestion or congestion using the ETM state since this 316 would ensure they could notify worst-case congestion, however this is 317 not possible since it requires the packets to be re-marked to DSCP 2 318 (hence altering the baseline encoding). This means that such nodes 319 will only be able to indicate ThM traffic. 321 6.3. Valid and invalid codepoint transitions at PCN-ingress-nodes 323 A PCN-ingress-node operating the Basic version of the 3-State 324 Encoding scheme MUST set the Not-marked codepoint on any arriving 325 packet that belongs to a PCN-flow. It MUST set the not-PCN codepoint 326 on any other packet. 328 A PCN-ingress-node operating the Full version of the 3-State Encoding 329 scheme MUST establish whether a packet is a member of a PCN-enabled- 330 ECN-flow. If it is, the PCN-ingress-node MUST set the appropriate 331 NM(xxx) codepoint depending on the value carried in the ECN field of 332 that packet. To be clear: 334 o A packet carrying the not-ECT codepoint in the ECN field MUST be 335 assigned the NM(not-ECT) codepoint 337 o A packet carrying the ECT(0) codepoint in the ECN field MUST be 338 assigned the NM(ECT(0)) codepoint 340 o A packet carrying the ECT(1) codepoint in the ECN field MUST be 341 assigned the NM(ECT(1)) codepoint 343 o A packet carrying the CE codepoint in the ECN field MUST be 344 assigned the NM(CE) codepoint 346 If it is not a member of such a flow then the behaviour MUST be the 347 same as for the Basic version of the Encoding scheme. 349 6.4. Valid and invalid codepoint transitions at PCN-interior-nodes 351 A PCN-interior-node MUST obey the following rules: 353 o It MUST NOT change the not-PCN codepoint to any other codepoint. 355 o It MAY change any Not-marked codepoint to either the Threshold- 356 marked or Excess-traffic-marked codepoints. 358 o It MUST NOT change a Not-marked codepoint to the not-PCN 359 codepoint. 361 o A Not-marked codepoint MUST NOT be changed to any other Not-marked 362 codepoint. 364 o It MAY change the ThM codepoint to the ETM codepoint but it MUST 365 NOT change the ThM codepoint to any other codepoint. 367 o It MUST NOT change the ETM codepoint to any other codepoint. 369 Obviously in every case a codepoint can remain unchanged. The 370 precise rules governing which valid transition to use are set out in 371 [I-D.ietf-pcn-marking-behaviour] 373 6.5. Forwarding traffic out of the PCN-domain 375 As each packet exits the PCN-domain, the PCN-egress-node MUST check 376 whether it belongs to a PCN-enabled-ECN-flow. If it belongs to such 377 a flow then the following rules dictate how the ECN field should be 378 reset: 380 o A packet carrying the not-PCN codepoint MUST be given the not-ECT 381 codepoint. 383 o A packet carrying the NM(not-ECT) codepoint MUST be assigned the 384 not-ECT codepoint. 386 o A packet carrying the NM(ECT(0)) codepoint MUST be assigned the 387 ECT(0) codepoint. 389 o A packet carrying the NM(ECT(1)) codepoint MUST be assigned the 390 ECT(1) codepoint. 392 o A packet carrying the NM(CE) codepoint MUST be assigned the CE 393 codepoint. 395 o A packet carrying the ThM codepoint MUST be assigned CE codepoint. 397 o A packet carrying the ETM codepoint MUST be assigned CE codepoint. 399 If the packet is part of a PCN-flow then it MUST be assigned the not- 400 ECT codepoint regardless of which PCN-codepoint it carried. 402 In addition all packets should have their DSCP reset to the 403 appropriate DSCP for the next hop. If the next hop is not another 404 PCN region this will not be a PCN-compatible DSCP, and by default 405 will be the best-efforts DSCP. Alterntively, higher layer signalling 406 mechanisms may allow the DSCP that packets entered the PCN-domain 407 with to be reinstated. 409 7. PCN-domain support for the PCN extension encoding 411 PCN traffic MUST be marked with a DiffServ codepoint that indicates 412 PCN is enabled. To comply with the PCN extension encoding, this 413 codepoint is either a PCN-compatible DSCP assigned by IANA for use 414 with the baseline PCN encoding [I-D.ietf-pcn-baseline-encoding] or a 415 DSCP from pools 2 or 3 for experimental and local use [RFC2474]. The 416 exact choice of DSCP may vary between PCN-domains but MUST be fixed 417 within each PCN-domain. 419 7.1. End-to-End transport behaviour compliant with the PCN extension 420 encoding 422 Transports wishing to use both PCN and end-to-end ECN MUST establish 423 that their path supports this combination. Support of end-to-end ECN 424 by PCN-boundary-nodes is OPTIONAL. Therefore transports MUST check 425 with both the PCN-ingress-node and PCN-egress-node for each flow. 426 The sending of such a request MUST NOT be taken to mean the request 427 has been granted. The PCN-boundary-nodes MAY choose to inform the 428 end-node of a successful request. The exact mechanism for such 429 negotiation is beyond the scope of this document. A transport that 430 receives no response or a negative response to a request to support 431 end-to-end ECN within a flow reservation MUST set the ECN field of 432 all subsequent packets in that flow to Not-ECT if it wishes to 433 guarantee that the flow will receive PCN treatment. 435 If a domain wishes to use the full scheme described in Table 2 all 436 nodes in that domain MUST be configured to understand the full 437 scheme. 439 If either of a PCN ingress-egress pair does not support end-to-end 440 ECN or if the end-to-end transport does not request support for end- 441 to-end ECN then the PCN-boundary-nodes MUST assume the packet belongs 442 to a PCN-flow. 444 8. IANA Considerations 446 This document asks IANA to assign one DiffServ codepoint from Pool 2 447 or Pool 3 (for experimental/local use)[RFC2474]. Should any of the 448 three encoding state experimental PCN schemes prove sufficiently 449 successful then IANA will be requested in a later document to assign 450 a dedicated DiffServ codepoint from pool 1 for standards use. 452 9. Security Considerations 454 The security concerns relating to this extended PCN encoding are 455 essentially the same as those in [I-D.ietf-pcn-baseline-encoding]. 457 This extension coding gives end-to-end support for the ECN nonce 458 [RFC3540], which is intended to protect the sender against the 459 receiver or against network elements concealing a congestion 460 experienced marking or a lost packet. PCN-based reservations 461 combined with end-to-end ECN are intended for partially inelastic 462 traffic using rate-adaptive codecs. Therefore the end-to-end 463 transport is unlikely to be TCP, but at this time the nonce has only 464 been defined for TCP transports. 466 10. Conclusions 468 This document describes an extended encoding scheme for PCN that 469 provides for three encoding states as well as optional support for 470 end-to-end ECN. The encoding scheme builds on the baseline encoding 471 described in [I-D.ietf-pcn-baseline-encoding]. Using this encoding 472 scheme it is possible for operators to conduct experiments to check 473 whether the addition of an extra encoding state will significantly 474 improve the performance of PCN. It will also allow experiments to 475 determine whether there is a need for end-to-end ECN support within 476 the PCN-domain (as against end-to-end ECN support through the use of 477 IP-in-IP tunnelling or by downgrading the traffic to a lower service 478 class). 480 11. Acknowledgements 482 This document builds extensively on work done in the PCN working 483 group by Kwok Ho Chan, Georgios Karagiannis, Philip Eardley, Joe 484 Babiarz and others. Full details of alternative schemes that were 485 considered for adoption can be found in the document 486 [I-D.chan-pcn-encoding-comparison]. 488 12. Comments Solicited 490 (Section to be removed by RFC_Editor) Comments and questions are 491 encouraged and very welcome. They can be addressed to the IETF 492 Transport Area working group mailing list , and/or to 493 the authors. 495 13. References 496 13.1. Normative References 498 [I-D.ietf-pcn-marking-behaviour] 499 Eardley, P., "Marking behaviour of PCN-nodes", 500 draft-ietf-pcn-marking-behaviour-02 (work in progress), 501 March 2009. 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, March 1997. 506 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 507 Explicit Congestion Notification (ECN) Field", BCP 124, 508 RFC 4774, November 2006. 510 13.2. Informative References 512 [I-D.briscoe-pcn-3-in-1-encoding] 513 Briscoe, B., "PCN 3-State Encoding Extension in a single 514 DSCP", draft-briscoe-pcn-3-in-1-encoding-00 (work in 515 progress), October 2008. 517 [I-D.chan-pcn-encoding-comparison] 518 Chan, K., Karagiannis, G., Moncaster, T., Menth, M., 519 Eardley, P., and B. Briscoe, "Pre-Congestion Notification 520 Encoding Comparison", 521 draft-chan-pcn-encoding-comparison-04 (work in progress), 522 March 2009. 524 [I-D.ietf-pcn-architecture] 525 Eardley, P., "Pre-Congestion Notification (PCN) 526 Architecture", draft-ietf-pcn-architecture-11 (work in 527 progress), April 2009. 529 [I-D.ietf-pcn-baseline-encoding] 530 Moncaster, T., Briscoe, B., and M. Menth, "Baseline 531 Encoding and Transport of Pre-Congestion Information", 532 draft-ietf-pcn-baseline-encoding-03 (work in progress), 533 April 2009. 535 [I-D.ietf-tsvwg-ecn-tunnel] 536 Briscoe, B., "Tunnelling of Explicit Congestion 537 Notification", draft-ietf-tsvwg-ecn-tunnel-02 (work in 538 progress), March 2009. 540 [I-D.menth-pcn-psdm-encoding] 541 Menth, M., Babiarz, J., Moncaster, T., and B. Briscoe, 542 "PCN Encoding for Packet-Specific Dual Marking (PSDM)", 543 draft-menth-pcn-psdm-encoding-00 (work in progress), 544 July 2008. 546 [I-D.sarker-pcn-ecn-pcn-usecases] 547 Sarker, Z. and I. Johansson, "Usecases and Benefits of end 548 to end ECN support in PCN Domains", 549 draft-sarker-pcn-ecn-pcn-usecases-02 (work in progress), 550 November 2008. 552 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 553 "Definition of the Differentiated Services Field (DS 554 Field) in the IPv4 and IPv6 Headers", RFC 2474, 555 December 1998. 557 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 558 of Explicit Congestion Notification (ECN) to IP", 559 RFC 3168, September 2001. 561 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 562 Congestion Notification (ECN) Signaling with Nonces", 563 RFC 3540, June 2003. 565 Authors' Addresses 567 Toby Moncaster 568 BT 569 B54/70, Adastral Park 570 Martlesham Heath 571 Ipswich IP5 3RE 572 UK 574 Phone: +44 1473 648734 575 Email: toby.moncaster@bt.com 576 URI: http://www.cs.ucl.ac.uk/staff/B.Briscoe/ 578 Bob Briscoe 579 BT & UCL 580 B54/77, Adastral Park 581 Martlesham Heath 582 Ipswich IP5 3RE 583 UK 585 Phone: +44 1473 645196 586 Email: bob.briscoe@bt.com 587 Michael Menth 588 University of Wuerzburg 589 room B206, Institute of Computer Science 590 Am Hubland 591 Wuerzburg D-97074 592 Germany 594 Phone: +49 931 888 6644 595 Email: menth@informatik.uni-wuerzburg.de