idnits 2.17.1 draft-ietf-pcn-3-state-encoding-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (March 12, 2012) is 4427 days in the past. Is this intentional? Checking references for intended status: Historic ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5696 (Obsoleted by RFC 6660) == Outdated reference: A later version (-11) exists of draft-ietf-pcn-3-in-1-encoding-09 == Outdated reference: A later version (-02) exists of draft-ietf-pcn-psdm-encoding-01 Summary: 1 error (**), 0 flaws (~~), 4 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 University of Cambridge 4 Intended status: Historic B. Briscoe 5 Expires: September 13, 2012 BT 6 M. Menth 7 University of Tuebingen 8 March 12, 2012 10 A PCN encoding using 2 DSCPs to provide 3 or more states 11 draft-ietf-pcn-3-state-encoding-02 13 Abstract 15 Pre-congestion notification (PCN) is a mechanism designed to protect 16 the Quality of Service of inelastic flows within a controlled domain. 17 It does this by marking packets when traffic load on a link is 18 approaching or has exceeded a threshold below the physical link rate. 19 This experimental encoding scheme specifies how three encoding states 20 can be carried in the IP header using a combination of two DSCPs and 21 the ECN bits. The Basic scheme only allows for three encoding 22 states. The Full scheme provides 6 states, enough for limited end- 23 to-end support for ECN as well. 25 Status 27 Since its original publication, the baseline encoding (RFC5696) on 28 which this document depends has become obsolete. The PCN working 29 Group has chosen to publish this as a historical document to preserve 30 the details of the encoding and to allow it to be cited in other 31 documents. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 13, 2012. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1. Changes from Previous Drafts (to be removed by the RFC 81 Editor) . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 83 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 84 4. The Requirement for Three PCN Encoding States . . . . . . . . 6 85 5. Adding Limited End-to-End ECN Support to PCN . . . . . . . . . 7 86 6. Encoding Three PCN States in IP . . . . . . . . . . . . . . . 7 87 6.1. Basic Three State Encoding . . . . . . . . . . . . . . . . 8 88 6.2. Full Three State Encoding . . . . . . . . . . . . . . . . 8 89 6.3. Common Diffserv Per-Hop Behaviour . . . . . . . . . . . . 9 90 6.4. Valid and invalid codepoint transitions at 91 PCN-ingress-nodes . . . . . . . . . . . . . . . . . . . . 9 92 6.5. Valid and invalid codepoint transitions at 93 PCN-interior-nodes . . . . . . . . . . . . . . . . . . . . 10 94 6.6. Forwarding traffic out of the PCN-domain . . . . . . . . . 10 95 7. PCN-domain support for the PCN extension encoding . . . . . . 11 96 7.1. End-to-End transport behaviour compliant with the PCN 97 extension encoding . . . . . . . . . . . . . . . . . . . . 11 98 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 100 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 101 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 102 12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 13 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 104 13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 105 13.2. Informative References . . . . . . . . . . . . . . . . . . 13 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 108 1. Introduction 110 The objective of Pre-Congestion Notification (PCN) [RFC5559] is to 111 protect the quality of service (QoS) of inelastic flows within a 112 Diffserv domain, in a simple, scalable and robust fashion. The 113 overall rate of the PCN-traffic is metered on every link in the PCN- 114 domain, and PCN-packets are appropriately marked when certain 115 configured rates are exceeded. These configured rates are below the 116 rate of the link thus providing notification before any congestion 117 occurs (hence "pre-congestion notification"). The level of marking 118 allows the boundary nodes to make decisions about whether to admit or 119 block a new flow request, and (in abnormal circumstances) whether to 120 terminate some of the existing flows, thereby protecting the QoS of 121 previously admitted flows. 123 The baseline encoding described in [RFC5696] provides for deployment 124 scenarios that only require two PCN encoding states. This document 125 describes an experimental extension to the base-encoding in the IP 126 header that adds two capabilities: 128 o the addition of a third PCN encoding state in the IP header 130 o preservation of the end-to-end semantics of the ECN field even 131 though PCN uses the field within a PCN-region that interrupts the 132 end-to-end path 134 The second of these capabilities is optional and the reasons for 135 doing it are discussed in Section 5. 137 As in the baseline encoding, this extension encoding re-uses the ECN 138 bits within the IP header within a controlled PCN-domain. This 139 extension requires the use of two DSCPs as described later in this 140 document. This experimental scheme is one of three that are being 141 proposed within the PCN working group. The aim is to allow 142 implementors to decide which scheme is most suitable for possible 143 future standardisation. 145 Following the publication of new rules relating to the tunnelling of 146 ECN marks [RFC6040], the PCN workign group decided to obsolete 147 [RFC5696] in favour of the 3-in-1 encoding 148 [I-D.ietf-pcn-3-in-1-encoding]. A side-effect of this decision was 149 to make the encoding described in this document obsolete. However 150 the PCN working group feels it is useful to have a formal historical 151 record of this encoding. This ensures details of the encoding are 152 not lost and also allows it to be cited in other documents. 154 1.1. Changes from Previous Drafts (to be removed by the RFC Editor) 156 From draft-ietf-pcn-3-state-encoding-01 to 02: 158 o Changed the document from teh experimental to the historic track 160 o Added notes to the Introduciton and Abstract explaining the change 161 to historical 163 o Updated refs 165 From draft-ietf-pcn-3-state-encoding-00 to 01: 167 o Removed text implying the two DSCPs have different priority and 168 added Section 6.3 specifying they must both have the same PHB. 170 o Made IANA considerations text more precise. 172 o Changed variable names for DSCP 1 & DSCP 2 to DSCP n & DSCP m to 173 be consistent with baseline encoding. 175 o Updated refs 177 From draft-moncaster-pcn-3-state-encoding-01 to 178 draft-ietf-pcn-3-state-encoding-00: 180 o Changed to WG draft. Title changed from "A three state extended 181 PCN encoding scheme" 183 o Imposed new structure on document. This structure is intended to 184 be followed by all extensions to the baseline PCN encoding scheme. 186 o Extensive changes throughout to ensure consistency with the 187 baseline PCN encoding scheme. 189 From draft-moncaster-pcn-3-state-encoding-00 to 01: 191 o Checked terminology for consistency with [RFC5696] 193 o Minor editorial changes. 195 2. Requirements notation 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in [RFC2119]. 201 3. Terminology 203 Most of the terminology used in this document is defined either in 204 [RFC5559] or in [RFC5696]. The following additional terms are 205 defined in this document: 207 o PCN-flow - a flow covered by a reservation but which hasn't 208 signalled that it requires end-to-end ECN support. 210 o PCN-enabled-ECN-flow - a flow covered by reservation and for which 211 the end-to-end transport has explicitly negotiated ECN support 212 from the PCN-boundary-nodes. 214 o Not-marked (xxx), where xxx represents a standard ECN codepoint - 215 packets that are PCN capable but carry no PCN mark. Abbreviated 216 as NM(xxx). The (xxx) represents the ECN codepoint that the 217 packet arrived with at the PCN-ingress-node e.g. NM(CE) 218 represents a PCN capable packet that has no PCN marking but which 219 arrived with the ECN bits set to congestion experienced. 221 4. The Requirement for Three PCN Encoding States 223 The PCN Marking Behaviours document [RFC5670] describes proposed PCN 224 schemes that require traffic to be metered and marked using both 225 Threshold and Excess Traffic schemes. In order to achieve this it is 226 necessary to allow for three PCN encoding states. The constraints 227 imposed by the way tunnels process the ECN field severely limit how 228 to encode these states as explained in [RFC5696] and [RFC6040]. The 229 obvious way to provide one more encoding state than the base encoding 230 is through the use of an additional PCN-compatible DiffServ 231 codepoint. 233 One aim of this document is to allow for experiments to show whether 234 such schemes are better than those that only employ two PCN encoding 235 states. As such, the additional DSCP will be taken from the EXP/LU 236 pools defined in [RFC2474]. If the experiments demonstrate that PCN 237 schemes employing three encoding states are significantly better than 238 those only employing two, then at a later date IANA might be asked to 239 assign a new PCN enabled DSCP from pool 1. Note that there are other 240 experimental encoding schemes being considered which only use one 241 DSCP but require either alternative tunnel semantics 242 ([I-D.ietf-pcn-3-in-1-encoding]) or additional signalling 243 ([I-D.ietf-pcn-psdm-encoding])in order to work. 245 5. Adding Limited End-to-End ECN Support to PCN 247 There are a number of use-cases where explicit preservation of end- 248 to-end ECN semantics might be needed across a PCN domain. One of the 249 use-cases suggests that the end-nodes might be running rate-adaptive 250 codecs that would respond to ECN marks by reducing their transmission 251 rate. If the sending transport sets the ECT codepoint, the setting 252 of the ECN field as it arrives at the PCN ingress node will need to 253 be re-instated as it leaves the PCN egress node. 255 If a PCN region is starting to suffer pre-congestion then it may make 256 sense to expose marks generated within the PCN region by forwarding 257 CE marks from the PCN egress to such a rate-adaptive endpoint. They 258 would be in addition to any CE marks generated elsewhere on the end- 259 to-end path. This would allow the endpoints to reduce the traffic 260 rate. This will in turn help to alleviate the pre-congestion, 261 potentially averting any need for call blocking or termination. 262 However, the 'leaking' of CE marks out of the PCN region is 263 potentially dangerous and could violate [RFC4774] if the end hosts 264 don't understand ECN (see section 18.1.4 of [RFC3168]). 266 Therefore, a PCN region can only support end-to-end ECN if the PCN- 267 boundary-nodes are sure that the end-to-end transport is ECN-capable. 268 That way the PCN-egress-nodes can ensure that they only expose CE 269 marks to those receivers that will correctly interpret them as a 270 notification of congestion. The end-points may indicate they are 271 ECN-capable through some higher-layer signalling process that sets up 272 their reservation with the PCN boundary nodes. The exact process of 273 negotiation is beyond the scope of this document but is likely to 274 involve explicit two way signalling between the end-host and the PCN- 275 domain. 277 In the absence of such signalling the default behaviour of the PCN 278 egress node will be to clear the ECN field to 00 as in the baseline 279 PCN encoding [RFC5696]. 281 6. Encoding Three PCN States in IP 283 The three state PCN encoding scheme is based closely on that defined 284 in [RFC5696] so that there will be no compatibility issues if a PCN- 285 domain changes from using the baseline encoding scheme to the 286 experimental scheme described here. There are two versions of the 287 scheme. The basic three state scheme allows for carrying both 288 Threshold-marked (ThM) and Excess-traffic-marked (ETM) traffic. The 289 full scheme additionally allows end-to-end ECN to be carried across 290 the PCN-domain. 292 6.1. Basic Three State Encoding 294 Table 1 below shows how to encode the three PCN states in IP. 296 +--------+--------------+-------------+-------------+---------+ 297 | DSCP | Not-ECT (00) | ECT(0) (10) | ECT(1) (01) | CE (11) | 298 +--------+--------------+-------------+-------------+---------+ 299 | DSCP n | Not-PCN | NM | CU | ThM | 300 | DSCP m | Not-PCN | CU | CU | ETM | 301 +--------+--------------+-------------+-------------+---------+ 303 (where DSCP n is a PCN-compatible DiffServ codepoint (see [RFC5696]) 304 and DSCP m is a PCN-compatible DSCP from the EXP/LU pools as defined 305 in [RFC2474]) 307 Table 1: Encoding three PCN states in IP 309 6.2. Full Three State Encoding 311 Table 2 shows how to additionally carry the end-to-end ECN state in 312 the IP header. 314 +--------+--------------+-------------+-------------+---------+ 315 | DSCP | Not-ECT (00) | ECT(0) (10) | ECT(1) (01) | CE (11) | 316 +--------+--------------+-------------+-------------+---------+ 317 | DSCP n | Not-PCN | NM(Not-ECT) | NM(CE) | ThM | 318 | DSCP m | Not-PCN | NM(ECT(0)) | NM(ECT(1)) | ETM | 319 +--------+--------------+-------------+-------------+---------+ 321 (where DSCP n is a PCN-compatible DiffServ codepoint (see [RFC5696]) 322 and DSCP m is a PCN-compatible DSCP from the EXP/LU pools as defined 323 in [RFC2474]) 325 Table 2: Encoding three PCN states in IP 327 The four different Not-marked (NM) states allow for the addition of 328 limited end-to-end ECN support as explained in the previous section. 330 WARNING: In order to comply with this encoding all the nodes within 331 the PCN-domain MUST be configured with this encoding scheme. 332 However there may be operators who choose not to be fully 333 compliant with the scheme. If an operator chooses to leave some 334 PCN-interior-nodes that only support two marking states (the 335 baseline encoding [RFC5696]), then they must be aware of the 336 following: Ideally such nodes would be configured to indicate pre- 337 congestion or congestion using the ETM state since this would 338 ensure they could notify worst-case congestion, however this is 339 not possible since it requires the packets to be re-marked to DSCP 340 m (hence altering the baseline encoding). This means that such 341 nodes will only be able to indicate ThM traffic. 343 6.3. Common Diffserv Per-Hop Behaviour 345 Packets carrying Diffserv codepoint 'DSCP n' or 'DSCP m' MUST all be 346 treated with the same Diffserv PHB [RFC2474]. The choice of PHB is 347 discussed in [RFC5559] and [RFC5696]. 349 Two DSCPs are merely used to provide sufficient PCN encoding states, 350 there is no need or intention to provide different scheduling or drop 351 preference for each row in the table of PCN codepoints. 352 Specifically: 354 o Both DSCPs MUST be served in the same queue to prevent reordering 355 within an application flow. 357 o Both DSCPs MUST be assigned the same drop preference. Note that 358 [RFC5670] already provides for preferential drop of excess-rate- 359 marked packets, so assigning additional drop preference at the 360 coarser granularity of each DSCP would be incorrect. 362 6.4. Valid and invalid codepoint transitions at PCN-ingress-nodes 364 A PCN-ingress-node operating the Basic version of the 3-State 365 Encoding scheme MUST set the Not-marked codepoint on any arriving 366 packet that belongs to a PCN-flow. It MUST set the not-PCN codepoint 367 on any other packet. 369 A PCN-ingress-node operating the Full version of the 3-State Encoding 370 scheme MUST establish whether a packet is a member of a PCN-enabled- 371 ECN-flow. If it is, the PCN-ingress-node MUST set the appropriate 372 NM(xxx) codepoint depending on the value carried in the ECN field of 373 that packet. To be clear: 375 o A packet carrying the not-ECT codepoint in the ECN field MUST be 376 assigned the NM(not-ECT) codepoint 378 o A packet carrying the ECT(0) codepoint in the ECN field MUST be 379 assigned the NM(ECT(0)) codepoint 381 o A packet carrying the ECT(1) codepoint in the ECN field MUST be 382 assigned the NM(ECT(1)) codepoint 384 o A packet carrying the CE codepoint in the ECN field MUST be 385 assigned the NM(CE) codepoint 387 If it is not a member of such a flow then the behaviour MUST be the 388 same as for the Basic version of the Encoding scheme. 390 6.5. Valid and invalid codepoint transitions at PCN-interior-nodes 392 A PCN-interior-node MUST obey the following rules: 394 o It MUST NOT change the not-PCN codepoint to any other codepoint. 396 o It MAY change any Not-marked codepoint to either the Threshold- 397 marked or Excess-traffic-marked codepoints. 399 o It MUST NOT change a Not-marked codepoint to the not-PCN 400 codepoint. 402 o A Not-marked codepoint MUST NOT be changed to any other Not-marked 403 codepoint. 405 o It MAY change the ThM codepoint to the ETM codepoint but it MUST 406 NOT change the ThM codepoint to any other codepoint. 408 o It MUST NOT change the ETM codepoint to any other codepoint. 410 Obviously in every case a codepoint can remain unchanged. The 411 precise rules governing which valid transition to use are set out in 412 [RFC5670] 414 6.6. Forwarding traffic out of the PCN-domain 416 As each packet exits the PCN-domain, the PCN-egress-node MUST check 417 whether it belongs to a PCN-enabled-ECN-flow. If it belongs to such 418 a flow then the following rules dictate how the ECN field should be 419 reset: 421 o A packet carrying the not-PCN codepoint MUST be given the not-ECT 422 codepoint. 424 o A packet carrying the NM(not-ECT) codepoint MUST be assigned the 425 not-ECT codepoint. 427 o A packet carrying the NM(ECT(0)) codepoint MUST be assigned the 428 ECT(0) codepoint. 430 o A packet carrying the NM(ECT(1)) codepoint MUST be assigned the 431 ECT(1) codepoint. 433 o A packet carrying the NM(CE) codepoint MUST be assigned the CE 434 codepoint. 436 o A packet carrying the ThM codepoint MUST be assigned CE codepoint. 438 o A packet carrying the ETM codepoint MUST be assigned CE codepoint. 440 If the packet is part of a PCN-flow then it MUST be assigned the not- 441 ECT codepoint regardless of which PCN-codepoint it carried. 443 In addition all packets should have their DSCP reset to the 444 appropriate DSCP for the next hop. If the next hop is not another 445 PCN region this will not be a PCN-compatible DSCP, and by default 446 will be the best-efforts DSCP. Alterntively, higher layer signalling 447 mechanisms may allow the DSCP that packets entered the PCN-domain 448 with to be reinstated. 450 7. PCN-domain support for the PCN extension encoding 452 PCN traffic MUST be marked with a DiffServ codepoint that indicates 453 PCN is enabled. To comply with the PCN extension encoding, codepoint 454 'DSCP n' MUST be a PCN-compatible DSCP assigned by IANA for use with 455 the baseline PCN encoding [RFC5696] while 'DSCP m' can be a DSCP from 456 pools 2 or 3 for experimental and local use [RFC2474]. The exact 457 choice of DSCP may vary between PCN-domains but MUST be fixed within 458 each PCN-domain. 460 7.1. End-to-End transport behaviour compliant with the PCN extension 461 encoding 463 Transports wishing to use both PCN and end-to-end ECN MUST establish 464 that their path supports this combination. Support of end-to-end ECN 465 by PCN-boundary-nodes is OPTIONAL. Therefore transports MUST check 466 with both the PCN-ingress-node and PCN-egress-node for each flow. 467 The sending of such a request MUST NOT be taken to mean the request 468 has been granted. The PCN-boundary-nodes MAY choose to inform the 469 end-node of a successful request. The exact mechanism for such 470 negotiation is beyond the scope of this document. A transport that 471 receives no response or a negative response to a request to support 472 end-to-end ECN within a flow reservation MUST set the ECN field of 473 all subsequent packets in that flow to Not-ECT if it wishes to 474 guarantee that the flow will receive PCN treatment. 476 If a domain wishes to use the full scheme described in Table 2 all 477 nodes in that domain MUST be configured to understand the full 478 scheme. 480 If either of a PCN ingress-egress pair does not support end-to-end 481 ECN or if the end-to-end transport does not request support for end- 482 to-end ECN then the PCN-boundary-nodes MUST assume the packet belongs 483 to a PCN-flow. 485 8. IANA Considerations 487 This document asks IANA to assign one DiffServ codepoint from Pool 2 488 or Pool 3 (for experimental/local use)[RFC2474]. Should this 489 experimental PCN scheme prove sufficiently successful then IANA will 490 be requested in a later document to assign a dedicated DiffServ 491 codepoint from pool 1 for standards use and the experimental 492 codepoint will be returned to its IANA pool. 494 9. Security Considerations 496 The security concerns relating to this extended PCN encoding are 497 essentially the same as those in [RFC5696]. 499 This extension coding gives end-to-end support for the ECN nonce 500 [RFC3540], which is intended to protect the sender against the 501 receiver or against network elements concealing a congestion 502 experienced marking or a lost packet. PCN-based reservations 503 combined with end-to-end ECN are intended for partially inelastic 504 traffic using rate-adaptive codecs. Therefore the end-to-end 505 transport is unlikely to be TCP, but at this time the nonce has only 506 been defined for TCP transports. 508 10. Conclusions 510 This document describes an extended encoding scheme for PCN that 511 provides for three encoding states as well as optional support for 512 end-to-end ECN. The encoding scheme builds on the baseline encoding 513 described in [RFC5696]. Using this encoding scheme it is possible 514 for operators to conduct experiments to check whether the addition of 515 an extra encoding state will significantly improve the performance of 516 PCN. It will also allow experiments to determine whether there is a 517 need for end-to-end ECN support within the PCN-domain (as against 518 end-to-end ECN support through the use of IP-in-IP tunnelling or by 519 downgrading the traffic to a lower service class). 521 11. Acknowledgements 523 This document builds extensively on work done in the PCN working 524 group by Kwok Ho Chan, Georgios Karagiannis, Philip Eardley, Joe 525 Babiarz and others. Full details of alternative schemes that were 526 considered for adoption can be found in the document 528 [I-D.ietf-pcn-encoding-comparison]. 530 12. Comments Solicited 532 (Section to be removed by RFC_Editor) Comments and questions are 533 encouraged and very welcome. They can be addressed to the IETF 534 Transport Area working group mailing list , and/or to 535 the authors. 537 13. References 539 13.1. Normative References 541 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 542 Requirement Levels", BCP 14, RFC 2119, March 1997. 544 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 545 Explicit Congestion Notification (ECN) Field", BCP 124, 546 RFC 4774, November 2006. 548 [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- 549 Nodes", RFC 5670, November 2009. 551 [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline 552 Encoding and Transport of Pre-Congestion Information", 553 RFC 5696, November 2009. 555 13.2. Informative References 557 [I-D.ietf-pcn-3-in-1-encoding] 558 Briscoe, B., Moncaster, T., and M. Menth, "Encoding 3 PCN- 559 States in the IP header using a single DSCP", 560 draft-ietf-pcn-3-in-1-encoding-09 (work in progress), 561 March 2012. 563 [I-D.ietf-pcn-encoding-comparison] 564 Karagiannis, G., Chan, K., Moncaster, T., Menth, M., 565 Eardley, P., and B. Briscoe, "Overview of Pre-Congestion 566 Notification Encoding", 567 draft-ietf-pcn-encoding-comparison-09 (work in progress), 568 March 2012. 570 [I-D.ietf-pcn-psdm-encoding] 571 Menth, M., Babiarz, J., Moncaster, T., and B. Briscoe, 572 "PCN Encoding for Packet-Specific Dual Marking (PSDM 573 Encoding)", draft-ietf-pcn-psdm-encoding-01 (work in 574 progress), March 2010. 576 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 577 "Definition of the Differentiated Services Field (DS 578 Field) in the IPv4 and IPv6 Headers", RFC 2474, 579 December 1998. 581 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 582 of Explicit Congestion Notification (ECN) to IP", 583 RFC 3168, September 2001. 585 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 586 Congestion Notification (ECN) Signaling with Nonces", 587 RFC 3540, June 2003. 589 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 590 Architecture", RFC 5559, June 2009. 592 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 593 Notification", RFC 6040, November 2010. 595 Authors' Addresses 597 Toby Moncaster 598 University of Cambridge 599 Computer Laboratory 600 JJ Thomson Avenue 601 Cambridge CB3 0FD 602 UK 604 Phone: +44 1223 763654 605 Email: toby@moncaster.com 607 Bob Briscoe 608 BT 609 B54/77, Adastral Park 610 Martlesham Heath 611 Ipswich IP5 3RE 612 UK 614 Phone: +44 1473 645196 615 Email: bob.briscoe@bt.com 616 URI: http://www.bobbriscoe.net 617 Michael Menth 618 University of Tuebingen 619 Department of Computer Science 620 Sand 13 621 Tuebingen D-72076 622 Germany 624 Phone: +49 07071 29 70505 625 Email: menth@informatik.uni-tuebingen.de 626 URI: http://www.kn.inf.uni-tuebingen.de