idnits 2.17.1 draft-ietf-pcn-3-state-encoding-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- 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 (February 10, 2010) is 5189 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5696 (Obsoleted by RFC 6660) == Outdated reference: A later version (-11) exists of draft-ietf-pcn-3-in-1-encoding-01 == Outdated reference: A later version (-09) exists of draft-ietf-pcn-encoding-comparison-01 == Outdated reference: A later version (-02) exists of draft-ietf-pcn-psdm-encoding-00 == Outdated reference: A later version (-10) exists of draft-ietf-tsvwg-ecn-tunnel-06 == Outdated reference: A later version (-02) exists of draft-sarker-pcn-ecn-pcn-usecases-01 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Congestion and Pre Congestion B. Briscoe 3 Internet-Draft BT & UCL 4 Intended status: Experimental T. Moncaster 5 Expires: August 14, 2010 BT 6 M. Menth 7 University of Wuerzburg 8 February 10, 2010 10 A PCN encoding using 2 DSCPs to provide 3 or more states 11 draft-ietf-pcn-3-state-encoding-01 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 of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on August 14, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1. Changes from Previous Drafts (to be removed by the RFC 78 Editor) . . . . . . . . . . . . . . . . . . . . . . . . . 3 79 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 80 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 4. The Requirement for Three PCN Encoding States . . . . . . . . 5 82 5. Adding Limited End-to-End ECN Support to PCN . . . . . . . . . 5 83 6. Encoding Three PCN States in IP . . . . . . . . . . . . . . . 6 84 6.1. Basic Three State Encoding . . . . . . . . . . . . . . . . 6 85 6.2. Full Three State Encoding . . . . . . . . . . . . . . . . 6 86 6.3. Common Diffserv Per-Hop Behaviour . . . . . . . . . . . . 7 87 6.4. Valid and invalid codepoint transitions at 88 PCN-ingress-nodes . . . . . . . . . . . . . . . . . . . . 8 89 6.5. Valid and invalid codepoint transitions at 90 PCN-interior-nodes . . . . . . . . . . . . . . . . . . . . 8 91 6.6. Forwarding traffic out of the PCN-domain . . . . . . . . . 9 92 7. PCN-domain support for the PCN extension encoding . . . . . . 9 93 7.1. End-to-End transport behaviour compliant with the PCN 94 extension encoding . . . . . . . . . . . . . . . . . . . . 10 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 97 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 98 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 99 12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 11 100 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 101 13.1. Normative References . . . . . . . . . . . . . . . . . . . 11 102 13.2. Informative References . . . . . . . . . . . . . . . . . . 12 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 105 1. Introduction 107 The objective of Pre-Congestion Notification (PCN) [RFC5559] is to 108 protect the quality of service (QoS) of inelastic flows within a 109 Diffserv domain, in a simple, scalable and robust fashion. The 110 overall rate of the PCN-traffic is metered on every link in the PCN- 111 domain, and PCN-packets are appropriately marked when certain 112 configured rates are exceeded. These configured rates are below the 113 rate of the link thus providing notification before any congestion 114 occurs (hence "pre-congestion notification"). The level of marking 115 allows the boundary nodes to make decisions about whether to admit or 116 block a new flow request, and (in abnormal circumstances) whether to 117 terminate some of the existing flows, thereby protecting the QoS of 118 previously admitted flows. 120 The baseline encoding described in [RFC5696] provides for deployment 121 scenarios that only require two PCN encoding states. This document 122 describes an experimental extension to the base-encoding in the IP 123 header that adds two capabilities: 125 o the addition of a third PCN encoding state in the IP header 127 o preservation of the end-to-end semantics of the ECN field even 128 though PCN uses the field within a PCN-region that interrupts the 129 end-to-end path 131 The second of these capabilities is optional and the reasons for 132 doing it are discussed in Section 5. 134 As in the baseline encoding, this extension encoding re-uses the ECN 135 bits within the IP header within a controlled PCN-domain. This 136 extension requires the use of two DSCPs as described later in this 137 document. This experimental scheme is one of three that are being 138 proposed within the PCN working group. The aim is to allow 139 implementors to decide which scheme is most suitable for possible 140 future standardisation. 142 1.1. Changes from Previous Drafts (to be removed by the RFC Editor) 144 From draft-ietf-pcn-3-state-encoding-00 to 01: 146 o Removed text implying the two DSCPs have different priority and 147 added Section 6.3 specifying they must both have the same PHB. 149 o Made IANA considerations text more precise. 151 o Changed variable names for DSCP 1 & DSCP 2 to DSCP n & DSCP m to 152 be consistent with baseline encoding. 154 o Updated refs 156 From draft-moncaster-pcn-3-state-encoding-01 to 157 draft-ietf-pcn-3-state-encoding-00: 159 o Changed to WG draft. Title changed from "A three state extended 160 PCN encoding scheme" 162 o Imposed new structure on document. This structure is intended to 163 be followed by all extensions to the baseline PCN encoding scheme. 165 o Extensive changes throughout to ensure consistency with the 166 baseline PCN encoding scheme. 168 From draft-moncaster-pcn-3-state-encoding-00 to 01: 170 o Checked terminology for consistency with [RFC5696] 172 o Minor editorial changes. 174 2. Requirements notation 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119]. 180 3. Terminology 182 Most of the terminology used in this document is defined either in 183 [RFC5559] or in [RFC5696]. The following additional terms are 184 defined in this document: 186 o PCN-flow - a flow covered by a reservation but which hasn't 187 signalled that it requires end-to-end ECN support. 189 o PCN-enabled-ECN-flow - a flow covered by reservation and for which 190 the end-to-end transport has explicitly negotiated ECN support 191 from the PCN-boundary-nodes. 193 o Not-marked (xxx), where xxx represents a standard ECN codepoint - 194 packets that are PCN capable but carry no PCN mark. Abbreviated 195 as NM(xxx). The (xxx) represents the ECN codepoint that the 196 packet arrived with at the PCN-ingress-node e.g. NM(CE) 197 represents a PCN capable packet that has no PCN marking but which 198 arrived with the ECN bits set to congestion experienced. 200 4. The Requirement for Three PCN Encoding States 202 The PCN Marking Behaviours document [RFC5670] describes proposed PCN 203 schemes that require traffic to be metered and marked using both 204 Threshold and Excess Traffic schemes. In order to achieve this it is 205 necessary to allow for three PCN encoding states. The constraints 206 imposed by the way tunnels process the ECN field severely limit how 207 to encode these states as explained in [RFC5696] and 208 [I-D.ietf-tsvwg-ecn-tunnel]. The obvious way to provide one more 209 encoding state than the base encoding is through the use of an 210 additional PCN-compatible DiffServ codepoint. 212 One aim of this document is to allow for experiments to show whether 213 such schemes are better than those that only employ two PCN encoding 214 states. As such, the additional DSCP will be taken from the EXP/LU 215 pools defined in [RFC2474]. If the experiments demonstrate that PCN 216 schemes employing three encoding states are significantly better than 217 those only employing two, then at a later date IANA might be asked to 218 assign a new PCN enabled DSCP from pool 1. Note that there are other 219 experimental encoding schemes being considered which only use one 220 DSCP but require either alternative tunnel semantics 221 ([I-D.ietf-pcn-3-in-1-encoding]) or additional signalling 222 ([I-D.ietf-pcn-psdm-encoding])in order to work. 224 5. Adding Limited End-to-End ECN Support to PCN 226 [I-D.sarker-pcn-ecn-pcn-usecases] suggests a number of use-cases 227 where explicit preservation of end-to-end ECN semantics might be 228 needed across a PCN domain. One of the use-cases suggests that the 229 end-nodes might be running rate-adaptive codecs that would respond to 230 ECN marks by reducing their transmission rate. If the sending 231 transport sets the ECT codepoint, the setting of the ECN field as it 232 arrives at the PCN ingress node will need to be re-instated as it 233 leaves the PCN egress node. 235 If a PCN region is starting to suffer pre-congestion then it may make 236 sense to expose marks generated within the PCN region by forwarding 237 CE marks from the PCN egress to such a rate-adaptive endpoint. They 238 would be in addition to any CE marks generated elsewhere on the end- 239 to-end path. This would allow the endpoints to reduce the traffic 240 rate. This will in turn help to alleviate the pre-congestion, 241 potentially averting any need for call blocking or termination. 242 However, the 'leaking' of CE marks out of the PCN region is 243 potentially dangerous and could violate [RFC4774] if the end hosts 244 don't understand ECN (see section 18.1.4 of [RFC3168]). 246 Therefore, a PCN region can only support end-to-end ECN if the PCN- 247 boundary-nodes are sure that the end-to-end transport is ECN-capable. 248 That way the PCN-egress-nodes can ensure that they only expose CE 249 marks to those receivers that will correctly interpret them as a 250 notification of congestion. The end-points may indicate they are 251 ECN-capable through some higher-layer signalling process that sets up 252 their reservation with the PCN boundary nodes. The exact process of 253 negotiation is beyond the scope of this document but is likely to 254 involve explicit two way signalling between the end-host and the PCN- 255 domain. 257 In the absence of such signalling the default behaviour of the PCN 258 egress node will be to clear the ECN field to 00 as in the baseline 259 PCN encoding [RFC5696]. 261 6. Encoding Three PCN States in IP 263 The three state PCN encoding scheme is based closely on that defined 264 in [RFC5696] so that there will be no compatibility issues if a PCN- 265 domain changes from using the baseline encoding scheme to the 266 experimental scheme described here. There are two versions of the 267 scheme. The basic three state scheme allows for carrying both 268 Threshold-marked (ThM) and Excess-traffic-marked (ETM) traffic. The 269 full scheme additionally allows end-to-end ECN to be carried across 270 the PCN-domain. 272 6.1. Basic Three State Encoding 274 Table 1 below shows how to encode the three PCN states in IP. 276 +--------+--------------+-------------+-------------+---------+ 277 | DSCP | Not-ECT (00) | ECT(0) (10) | ECT(1) (01) | CE (11) | 278 +--------+--------------+-------------+-------------+---------+ 279 | DSCP n | Not-PCN | NM | CU | ThM | 280 | DSCP m | Not-PCN | CU | CU | ETM | 281 +--------+--------------+-------------+-------------+---------+ 283 (where DSCP n is a PCN-compatible DiffServ codepoint (see [RFC5696]) 284 and DSCP m is a PCN-compatible DSCP from the EXP/LU pools as defined 285 in [RFC2474]) 287 Table 1: Encoding three PCN states in IP 289 6.2. Full Three State Encoding 291 Table 2 shows how to additionally carry the end-to-end ECN state in 292 the IP header. 294 +--------+--------------+-------------+-------------+---------+ 295 | DSCP | Not-ECT (00) | ECT(0) (10) | ECT(1) (01) | CE (11) | 296 +--------+--------------+-------------+-------------+---------+ 297 | DSCP n | Not-PCN | NM(Not-ECT) | NM(CE) | ThM | 298 | DSCP m | Not-PCN | NM(ECT(0)) | NM(ECT(1)) | ETM | 299 +--------+--------------+-------------+-------------+---------+ 301 (where DSCP n is a PCN-compatible DiffServ codepoint (see [RFC5696]) 302 and DSCP m is a PCN-compatible DSCP from the EXP/LU pools as defined 303 in [RFC2474]) 305 Table 2: Encoding three PCN states in IP 307 The four different Not-marked (NM) states allow for the addition of 308 limited end-to-end ECN support as explained in the previous section. 310 Warning 312 In order to comply with this encoding all the nodes within the PCN- 313 domain MUST be configured with this encoding scheme. However there 314 may be operators who choose not to be fully compliant with the 315 scheme. If an operator chooses to leave some PCN-interior-nodes that 316 only support two marking states (the baseline encoding [RFC5696]), 317 then they must be aware of the following: Ideally such nodes would be 318 configured to indicate pre-congestion or congestion using the ETM 319 state since this would ensure they could notify worst-case 320 congestion, however this is not possible since it requires the 321 packets to be re-marked to DSCP m (hence altering the baseline 322 encoding). This means that such nodes will only be able to indicate 323 ThM traffic. 325 6.3. Common Diffserv Per-Hop Behaviour 327 Packets carrying Diffserv codepoint 'DSCP n' or 'DSCP m' MUST all be 328 treated with the same Diffserv PHB [RFC2474]. The choice of PHB is 329 discussed in [RFC5559] and [RFC5696]. 331 Two DSCPs are merely used to provide sufficient PCN encoding states, 332 there is no need or intention to provide different scheduling or drop 333 preference for each row in the table of PCN codepoints. 334 Specifically: 336 o Both DSCPs MUST be served in the same queue to prevent reordering 337 within an application flow. 339 o Both DSCPs MUST be assigned the same drop preference. Note that 340 [RFC5670] already provides for preferential drop of excess-rate- 341 marked packets, so assigning additional drop preference at the 342 coarser granularity of each DSCP would be incorrect. 344 6.4. Valid and invalid codepoint transitions at PCN-ingress-nodes 346 A PCN-ingress-node operating the Basic version of the 3-State 347 Encoding scheme MUST set the Not-marked codepoint on any arriving 348 packet that belongs to a PCN-flow. It MUST set the not-PCN codepoint 349 on any other packet. 351 A PCN-ingress-node operating the Full version of the 3-State Encoding 352 scheme MUST establish whether a packet is a member of a PCN-enabled- 353 ECN-flow. If it is, the PCN-ingress-node MUST set the appropriate 354 NM(xxx) codepoint depending on the value carried in the ECN field of 355 that packet. To be clear: 357 o A packet carrying the not-ECT codepoint in the ECN field MUST be 358 assigned the NM(not-ECT) codepoint 360 o A packet carrying the ECT(0) codepoint in the ECN field MUST be 361 assigned the NM(ECT(0)) codepoint 363 o A packet carrying the ECT(1) codepoint in the ECN field MUST be 364 assigned the NM(ECT(1)) codepoint 366 o A packet carrying the CE codepoint in the ECN field MUST be 367 assigned the NM(CE) codepoint 369 If it is not a member of such a flow then the behaviour MUST be the 370 same as for the Basic version of the Encoding scheme. 372 6.5. Valid and invalid codepoint transitions at PCN-interior-nodes 374 A PCN-interior-node MUST obey the following rules: 376 o It MUST NOT change the not-PCN codepoint to any other codepoint. 378 o It MAY change any Not-marked codepoint to either the Threshold- 379 marked or Excess-traffic-marked codepoints. 381 o It MUST NOT change a Not-marked codepoint to the not-PCN 382 codepoint. 384 o A Not-marked codepoint MUST NOT be changed to any other Not-marked 385 codepoint. 387 o It MAY change the ThM codepoint to the ETM codepoint but it MUST 388 NOT change the ThM codepoint to any other codepoint. 390 o It MUST NOT change the ETM codepoint to any other codepoint. 392 Obviously in every case a codepoint can remain unchanged. The 393 precise rules governing which valid transition to use are set out in 394 [RFC5670] 396 6.6. Forwarding traffic out of the PCN-domain 398 As each packet exits the PCN-domain, the PCN-egress-node MUST check 399 whether it belongs to a PCN-enabled-ECN-flow. If it belongs to such 400 a flow then the following rules dictate how the ECN field should be 401 reset: 403 o A packet carrying the not-PCN codepoint MUST be given the not-ECT 404 codepoint. 406 o A packet carrying the NM(not-ECT) codepoint MUST be assigned the 407 not-ECT codepoint. 409 o A packet carrying the NM(ECT(0)) codepoint MUST be assigned the 410 ECT(0) codepoint. 412 o A packet carrying the NM(ECT(1)) codepoint MUST be assigned the 413 ECT(1) codepoint. 415 o A packet carrying the NM(CE) codepoint MUST be assigned the CE 416 codepoint. 418 o A packet carrying the ThM codepoint MUST be assigned CE codepoint. 420 o A packet carrying the ETM codepoint MUST be assigned CE codepoint. 422 If the packet is part of a PCN-flow then it MUST be assigned the not- 423 ECT codepoint regardless of which PCN-codepoint it carried. 425 In addition all packets should have their DSCP reset to the 426 appropriate DSCP for the next hop. If the next hop is not another 427 PCN region this will not be a PCN-compatible DSCP, and by default 428 will be the best-efforts DSCP. Alterntively, higher layer signalling 429 mechanisms may allow the DSCP that packets entered the PCN-domain 430 with to be reinstated. 432 7. PCN-domain support for the PCN extension encoding 434 PCN traffic MUST be marked with a DiffServ codepoint that indicates 435 PCN is enabled. To comply with the PCN extension encoding, codepoint 436 'DSCP n' MUST be a PCN-compatible DSCP assigned by IANA for use with 437 the baseline PCN encoding [RFC5696] while 'DSCP m' can be a DSCP from 438 pools 2 or 3 for experimental and local use [RFC2474]. The exact 439 choice of DSCP may vary between PCN-domains but MUST be fixed within 440 each PCN-domain. 442 7.1. End-to-End transport behaviour compliant with the PCN extension 443 encoding 445 Transports wishing to use both PCN and end-to-end ECN MUST establish 446 that their path supports this combination. Support of end-to-end ECN 447 by PCN-boundary-nodes is OPTIONAL. Therefore transports MUST check 448 with both the PCN-ingress-node and PCN-egress-node for each flow. 449 The sending of such a request MUST NOT be taken to mean the request 450 has been granted. The PCN-boundary-nodes MAY choose to inform the 451 end-node of a successful request. The exact mechanism for such 452 negotiation is beyond the scope of this document. A transport that 453 receives no response or a negative response to a request to support 454 end-to-end ECN within a flow reservation MUST set the ECN field of 455 all subsequent packets in that flow to Not-ECT if it wishes to 456 guarantee that the flow will receive PCN treatment. 458 If a domain wishes to use the full scheme described in Table 2 all 459 nodes in that domain MUST be configured to understand the full 460 scheme. 462 If either of a PCN ingress-egress pair does not support end-to-end 463 ECN or if the end-to-end transport does not request support for end- 464 to-end ECN then the PCN-boundary-nodes MUST assume the packet belongs 465 to a PCN-flow. 467 8. IANA Considerations 469 This document asks IANA to assign one DiffServ codepoint from Pool 2 470 or Pool 3 (for experimental/local use)[RFC2474]. Should this 471 experimental PCN scheme prove sufficiently successful then IANA will 472 be requested in a later document to assign a dedicated DiffServ 473 codepoint from pool 1 for standards use and the experimental 474 codepoint will be returned to its IANA pool. 476 9. Security Considerations 478 The security concerns relating to this extended PCN encoding are 479 essentially the same as those in [RFC5696]. 481 This extension coding gives end-to-end support for the ECN nonce 482 [RFC3540], which is intended to protect the sender against the 483 receiver or against network elements concealing a congestion 484 experienced marking or a lost packet. PCN-based reservations 485 combined with end-to-end ECN are intended for partially inelastic 486 traffic using rate-adaptive codecs. Therefore the end-to-end 487 transport is unlikely to be TCP, but at this time the nonce has only 488 been defined for TCP transports. 490 10. Conclusions 492 This document describes an extended encoding scheme for PCN that 493 provides for three encoding states as well as optional support for 494 end-to-end ECN. The encoding scheme builds on the baseline encoding 495 described in [RFC5696]. Using this encoding scheme it is possible 496 for operators to conduct experiments to check whether the addition of 497 an extra encoding state will significantly improve the performance of 498 PCN. It will also allow experiments to determine whether there is a 499 need for end-to-end ECN support within the PCN-domain (as against 500 end-to-end ECN support through the use of IP-in-IP tunnelling or by 501 downgrading the traffic to a lower service class). 503 11. Acknowledgements 505 This document builds extensively on work done in the PCN working 506 group by Kwok Ho Chan, Georgios Karagiannis, Philip Eardley, Joe 507 Babiarz and others. Full details of alternative schemes that were 508 considered for adoption can be found in the document 509 [I-D.ietf-pcn-encoding-comparison]. 511 12. Comments Solicited 513 (Section to be removed by RFC_Editor) Comments and questions are 514 encouraged and very welcome. They can be addressed to the IETF 515 Transport Area working group mailing list , and/or to 516 the authors. 518 13. References 520 13.1. Normative References 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, March 1997. 525 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 526 Explicit Congestion Notification (ECN) Field", BCP 124, 527 RFC 4774, November 2006. 529 [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- 530 Nodes", RFC 5670, November 2009. 532 [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline 533 Encoding and Transport of Pre-Congestion Information", 534 RFC 5696, November 2009. 536 13.2. Informative References 538 [I-D.ietf-pcn-3-in-1-encoding] 539 Briscoe, B. and T. Moncaster, "PCN 3-State Encoding 540 Extension in a single DSCP", 541 draft-ietf-pcn-3-in-1-encoding-01 (work in progress), 542 February 2010. 544 [I-D.ietf-pcn-encoding-comparison] 545 Chan, K., Karagiannis, G., Moncaster, T., Menth, M., 546 Eardley, P., and B. Briscoe, "Pre-Congestion Notification 547 Encoding Comparison", 548 draft-ietf-pcn-encoding-comparison-01 (work in progress), 549 October 2009. 551 [I-D.ietf-pcn-psdm-encoding] 552 Menth, M., Babiarz, J., Moncaster, T., and B. Briscoe, 553 "PCN Encoding for Packet-Specific Dual Marking (PSDM)", 554 draft-ietf-pcn-psdm-encoding-00 (work in progress), 555 June 2009. 557 [I-D.ietf-tsvwg-ecn-tunnel] 558 Briscoe, B., "Tunnelling of Explicit Congestion 559 Notification", draft-ietf-tsvwg-ecn-tunnel-06 (work in 560 progress), December 2009. 562 [I-D.sarker-pcn-ecn-pcn-usecases] 563 Sarker, Z. and I. Johansson, "Usecases and Benefits of end 564 to end ECN support in PCN Domains", 565 draft-sarker-pcn-ecn-pcn-usecases-01 (work in progress), 566 May 2008. 568 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 569 "Definition of the Differentiated Services Field (DS 570 Field) in the IPv4 and IPv6 Headers", RFC 2474, 571 December 1998. 573 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 574 of Explicit Congestion Notification (ECN) to IP", 575 RFC 3168, September 2001. 577 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 578 Congestion Notification (ECN) Signaling with Nonces", 579 RFC 3540, June 2003. 581 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 582 Architecture", RFC 5559, June 2009. 584 Authors' Addresses 586 Bob Briscoe 587 BT & UCL 588 B54/77, Adastral Park 589 Martlesham Heath 590 Ipswich IP5 3RE 591 UK 593 Phone: +44 1473 645196 594 Email: bob.briscoe@bt.com 596 Toby Moncaster 597 BT 598 B54/70, Adastral Park 599 Martlesham Heath 600 Ipswich IP5 3RE 601 UK 603 Phone: +44 1473 648734 604 Email: toby.moncaster@bt.com 605 URI: http://www.cs.ucl.ac.uk/staff/B.Briscoe/ 607 Michael Menth 608 University of Wuerzburg 609 room B206, Institute of Computer Science 610 Am Hubland 611 Wuerzburg D-97074 612 Germany 614 Phone: +49 931 888 6644 615 Email: menth@informatik.uni-wuerzburg.de