idnits 2.17.1 draft-ietf-pcn-baseline-encoding-06.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 : ---------------------------------------------------------------------------- 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, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (September 4, 2009) is 5341 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) == Outdated reference: A later version (-02) exists of draft-ietf-pcn-3-state-encoding-00 == Outdated reference: A later version (-10) exists of draft-ietf-tsvwg-ecn-tunnel-03 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Congestion and Pre Congestion T. Moncaster 3 Internet-Draft B. Briscoe 4 Intended status: Standards Track BT 5 Expires: March 8, 2010 M. Menth 6 University of Wuerzburg 7 September 4, 2009 9 Baseline Encoding and Transport of Pre-Congestion Information 10 draft-ietf-pcn-baseline-encoding-06 12 Status of This Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on March 8, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 The objective of the pre-congestion notification (PCN) architecture 59 is to protect the QoS of inelastic flows within a Diffserv domain. 60 It achieves this by marking packets belonging to PCN-flows when the 61 rate of traffic exceeds certain configured thresholds on links in the 62 domain. These marks can then be evaluated to determine how close the 63 domain is to being congested. This document specifies how such marks 64 are encoded into the IP header by redefining the Explicit Congestion 65 Notification (ECN) codepoints within such domains. The baseline 66 encoding described here provides only two PCN encoding states: not- 67 marked and PCN-marked. Future extensions to this encoding may be 68 needed in order to provide more than one level of marking severity. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 6 74 3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 6 75 3.1. List of Abbreviations . . . . . . . . . . . . . . . . . . 7 76 4. Encoding two PCN States in IP . . . . . . . . . . . . . . . . 7 77 4.1. Marking Packets . . . . . . . . . . . . . . . . . . . . . 8 78 4.2. Valid and Invalid Codepoint Transitions . . . . . . . . . 8 79 4.3. Rationale for Encoding . . . . . . . . . . . . . . . . . . 9 80 4.4. PCN-Compatible Diffserv Codepoints . . . . . . . . . . . . 10 81 4.4.1. Co-existence of PCN and not-PCN traffic . . . . . . . 10 82 5. Rules for Experimental Encoding Schemes . . . . . . . . . . . 11 83 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 11 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 88 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 13 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 91 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 92 Appendix A. PCN Deployment Considerations (Informational) . . . . 14 93 A.1. Choice of Suitable DSCPs . . . . . . . . . . . . . . . . . 14 94 A.2. Rationale for Using ECT(0) for Not-marked . . . . . . . . 15 96 1. Introduction 98 The objective of the Pre-Congestion Notification (PCN) Architecture 99 [RFC5559] is to protect the quality of service (QoS) of inelastic 100 flows within a Diffserv domain, in a simple, scalable and robust 101 fashion. The overall rate of the PCN-traffic is metered on every 102 link in the PCN-domain, and PCN-packets are appropriately marked when 103 certain configured rates are exceeded. These configured rates are 104 below the rate of the link thus providing notification before any 105 congestion occurs (hence "pre-congestion notification"). The level 106 of marking allows the boundary nodes to make decisions about whether 107 to admit or block a new flow request, and (in abnormal circumstances) 108 whether to terminate some of the existing flows, thereby protecting 109 the QoS of previously admitted flows. 111 This document specifies how these PCN-marks are encoded into the IP 112 header by re-using the bits of the Explicit Congestion Notification 113 (ECN) field [RFC3168]. It also describes how packets are identified 114 as belonging to a PCN-flow. Some deployment models require two PCN 115 encoding states, others require more. The baseline encoding 116 described here only provides for two PCN encoding states. However 117 the encoding can be easily extended to provide more states. Rules 118 for such extensions are given in Section 5. 120 Changes from previous drafts (to be removed by the RFC Editor): 122 From -05 to -06: 124 Extensive changes to the text following IETF Last Call and Gen-ART 125 review comments. 127 Abstract updated following mailing list discussions after Gen-ART 128 review by Spencer Dawkins. 130 Added list of abbreviations 132 New [section 4.1] added to explain the required action when a node 133 indicates the need to mark a packet. 135 Clarified text and Table 2 in Section 4.2. 137 Improved explanation of rules for experimental encoding schemes in 138 Section 5. Removed any ambiguity about meaning of PCN-marked in 139 such a context. Added requirements for experimental schemes to 140 define which meter causes which mark. 142 Clarified text in Section 6 relating to support for e2e ECN. 144 Added text in Section 8 relating to injection of PCN-marks into 145 the PCN-domain. 147 Changed text of Appendix A.1 to reflect comments from Spencer 148 Dawkins and Philip Eardey. 150 From -04 to -05: 152 Clarified throughout that the PCN WG is not requesting a specific 153 DSCP for PCN. Rather we are recommending a set of DSCPs that 154 might be suitable. Appendix A.1 has been re-written to reflect 155 this. References to maintaining a list of PCN-compatible DSCPs 156 have also been removed. 158 Last sentence of Section 6 altered. 160 Several spelling corrections. 162 References updated throughout. 164 From -03 to -04: 166 Major WGLC comments addressed: 168 * Added Section 4.4.1 to clarify why we need the not-PCN 169 codepoint. 171 * Stated that the PCN WG will maintain a list of PCN-compatible 172 DSCPs. This should help avoid inter-operability issues. 174 Also addressed a number of WGLC nits. 176 From -02 to -03: 178 Extensive changes to address comments made by Gorry Fairhurst 179 including: 181 * Abstract re-written. 183 * Clarified throughout that this re-uses the ECN bits in the IP 184 header. 186 * Re-arranged order of terminology section for clarity. 188 * Table 2 replaced with new table and text. 190 * Security considerations re-written. 192 * Appendixes re-written to improve clarity. 194 * Numerous minor nits and language changes throughout. 196 Extensive other minor changes throughout. 198 From -01 to -02: 200 Removed Appendix A and replaced with reference to 201 [I-D.ietf-tsvwg-ecn-tunnel] 203 Moved Appendix B into main body of text. 205 Changed Appendix C to give deployment advice. 207 Minor changes throughout including checking consistency of 208 capitalisation of defined terms. 210 Clarified that LU was deliberately excluded from encoding. 212 From -00 to -01: 214 Added section on restrictions for extension encoding schemes. 216 Included table in Appendix showing encoding transitions at 217 different PCN nodes. 219 Checked for consistency of terminology. 221 Minor language changes for clarity. 223 Changes from previous filename 225 Filename changed from draft-moncaster-pcn-baseline-encoding. 227 Terminology changed for clarity (PCN-compatible DSCP and PCN- 228 enabled packet). 230 Minor changes throughout. 232 Modified meaning of ECT(1) state to EXP. 234 Moved text relevant to behaviour of nodes into appendix for later 235 transfer to new document on edge behaviours. 237 From draft-moncaster -01 to -02: 239 Minor changes throughout including tightening up language to 240 remain consistent with the PCN Architecture terminology. 242 From draft-moncaster -00 to -01: 244 Change of title from "Encoding and Transport of (Pre-)Congestion 245 Information from within a Diffserv Domain to the Egress" 247 Extensive changes to Introduction and abstract. 249 Added a section on the implications of re-using a DSCP. 251 Added appendix listing possible operator scenarios for using this 252 baseline encoding. 254 Minor changes throughout. 256 2. Requirements notation 258 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 259 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 260 document are to be interpreted as described in [RFC2119]. 262 3. Terminology and Abbreviations 264 The following terms are defined in this document: 266 o PCN-compatible Diffserv codepoint - a Diffserv codepoint for which 267 the ECN field is used to carry PCN markings rather than [RFC3168] 268 markings. 270 o PCN-marked - codepoint indicating packets that have been marked at 271 a PCN-interior-node using some PCN marking behaviour 272 [I-D.ietf-pcn-marking-behaviour]. Abbreviated to PM. 274 o Not-marked - codepoint indicating packets that are PCN-capable, 275 but are not PCN-marked. Abbreviated to NM. 277 o PCN-enabled codepoints - collective term for all NM and PM 278 codepoints. By definition, packets carrying such codepoints are 279 PCN-packets. 281 o not-PCN - packets that are not PCN-enabled. 283 In addition, the document uses the terminology defined in [RFC5559]. 285 3.1. List of Abbreviations 287 The following abbreviations are used in this document: 289 o AF = Assured Forwarding [RFC2597] 291 o CE = Congestion Experienced [RFC3168] 293 o CS = Class Selector [RFC2474] 295 o DSCP = Diffserv codepoint 297 o ECN = Explicit Congestion Notification [RFC3168] 299 o ECT = ECN Capable Transport [RFC3168] 301 o EF = Expedited Forwarding [RFC3246] 303 o EXP = Experimental 305 o NM = Not-marked 307 o PCN = Pre-Congestion Notification 309 o PM = PCN-marked 311 4. Encoding two PCN States in IP 313 The PCN encoding states are defined using a combination of the DSCP 314 and ECN fields within the IP header. The baseline PCN encoding 315 closely follows the semantics of ECN [RFC3168]. It allows the 316 encoding of two PCN states: Not-marked and PCN-marked. It also 317 allows for traffic that is not PCN-capable to be marked as such (not- 318 PCN). Given the scarcity of codepoints within the IP header the 319 baseline encoding leaves one codepoint free for experimental use. 320 The following table defines how to encode these states in IP: 322 +---------------+-------------+-------------+-------------+---------+ 323 | ECN codepoint | Not-ECT | ECT(0) (10) | ECT(1) (01) | CE (11) | 324 | | (00) | | | | 325 +---------------+-------------+-------------+-------------+---------+ 326 | DSCP n | not-PCN | NM | EXP | PM | 327 +---------------+-------------+-------------+-------------+---------+ 329 Where DSCP n is a PCN-compatible Diffserv codepoint (see Section 4.4) 330 and EXP means available for Experimental use. N.B. we deliberately 331 reserve this codepoint for experimental use only (and not local use) 332 to prevent future compatibility issues. 334 Table 1: Encoding PCN in IP 336 The following rules apply to all PCN traffic: 338 o PCN-traffic MUST be marked with a PCN-compatible Diffserv 339 Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be 340 chosen that are already defined for use with admission controlled 341 traffic. Appendix A.1 gives guidance to implementors on suitable 342 DSCPs. Guidelines for mixing traffic-types within a PCN-domain 343 are given in [I-D.ietf-pcn-marking-behaviour]. 345 o Any packet that is not-PCN but which shares the same Diffserv 346 codepoint as PCN-enabled traffic MUST have its ECN field set to 347 00. 349 4.1. Marking Packets 351 [I-D.ietf-pcn-marking-behaviour] states that any encoding scheme 352 document must specify the required action to take if one of the 353 marking algorithms indicates that a packet needs to be marked. For 354 the baseline encoding scheme the required action is simply as 355 follows: 357 o If a marking algorithm indicates the need to mark a PCN-packet 358 then that packet MUST have its PCN codepoint set to 11, PCN- 359 marked. 361 4.2. Valid and Invalid Codepoint Transitions 363 A PCN-ingress-node MUST set the Not-marked (10) codepoint on any 364 arriving packet that belongs to a PCN-flow. It MUST set the not-PCN 365 (00) codepoint on all other packets sharing a PCN-compatible Diffserv 366 codepoint. 368 The only valid codepoint transitions within a PCN-interior-node are 369 from NM to PM (which should occur if either meter indicates a need to 370 PCN-mark a packet [I-D.ietf-pcn-marking-behaviour]) and from EXP to 371 PM. PCN-nodes that only implement the baseline encoding MUST be able 372 to PCN mark packets that arrive with the EXP codepoint. This should 373 ease the design of experimental schemes that want to allow partial 374 deployment of experimental nodes alongside nodes that only implement 375 the baseline encoding. The following table gives the full set of 376 valid and invalid codepoint transitions. 378 +-------------------------------------------------+ 379 | Codepoint Out | 380 +--------------+-------------+-----------+-----------+-----------+ 381 | Codepoint in | not-PCN(00) | NM(10) | EXP(01) | PM(11) | 382 +--------------+-------------+-----------+-----------+-----------+ 383 | not-PCN(00) | Valid | Not valid | Not valid | Not valid | 384 +--------------+-------------+-----------+-----------+-----------+ 385 | NM(10) | Not valid | Valid | Not valid | Valid | 386 +--------------+-------------+-----------+-----------+-----------+ 387 | EXP(01)* | Not valid | Not valid | Valid | Valid | 388 +--------------+-------------+-----------+-----------+-----------+ 389 | PM(11) | Not valid | Not valid | Not valid | Valid | 390 +--------------+-------------+-----------+-----------+-----------+ 391 * This MAY cause an alarm to be raised at a management layer. 392 See paragraph above for an explanation of this transition. 394 Table 2: Valid and Invalid Codepoint Transitions for PCN-packets 395 at PCN-interior-nodes 397 The codepoint transition constraints given here apply only to the 398 baseline encoding scheme. Constraints on codepoint transitions for 399 future experimental schemes are discussed in Section 5. 401 A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all 402 packets it forwards out of the PCN-domain. The only exception to 403 this is if the PCN-egress-node is certain that revealing other 404 codepoints outside the PCN-domain won't contravene the guidance given 405 in [RFC4774]. For instance if the PCN-ingress-node has explicitly 406 informed the PCN-egress-node that this flow is ECN-capable then it 407 might be safe to expose other codepoints. 409 4.3. Rationale for Encoding 411 The exact choice of encoding was dictated by the constraints imposed 412 by existing IETF RFCs, in particular [RFC3168], [RFC4301] and 413 [RFC4774]. One of the tightest constraints was the need for any PCN 414 encoding to survive being tunnelled through either an IP in IP tunnel 415 or an IPsec Tunnel. [I-D.ietf-tsvwg-ecn-tunnel] explains this in 416 more detail. The main effect of this constraint is that any PCN 417 marking has to carry the 11 codepoint in the ECN field since this is 418 the only codepoint that is guaranteed to be copied down into the 419 inner header upon decapsulation. An additional constraint is the 420 need to minimise the use of Diffserv codepoints because there is a 421 limited supply of standards track codepoints remaining. Section 4.4 422 explains how we have minimised this still further by reusing pre- 423 existing Diffserv codepoint(s) such that non-PCN traffic can still be 424 distinguished from PCN traffic. 426 There are a number of factors that were considered before choosing to 427 set 10 as the NM state instead of 01. These included similarity to 428 ECN, presence of tunnels within the domain, leakage into and out of 429 PCN-domain and incremental deployment (see Appendix A.2). 431 The encoding scheme above seems to meet all these constraints and 432 ends up looking very similar to ECN. This is perhaps not surprising 433 given the similarity in architectural intent between PCN and ECN. 435 4.4. PCN-Compatible Diffserv Codepoints 437 Equipment complying with the baseline PCN encoding MUST allow PCN to 438 be enabled for certain Diffserv codepoints. This document defines 439 the term "PCN-compatible Diffserv codepoint" for such a DSCP. To be 440 clear, any packets with such a DSCP will be PCN enabled only if they 441 are within a PCN-domain and have their ECN field set to indicate a 442 codepoint other than not-PCN. 444 Enabling PCN marking behaviour for a specific DSCP disables any other 445 marking behaviour (e.g. enabling PCN replaces the default ECN marking 446 behaviour introduced in [RFC3168]) with the PCN metering and marking 447 behaviours described in [I-D.ietf-pcn-marking-behaviour]). This 448 ensures compliance with the BCP guidance set out in [RFC4774]. 450 The PCN Working Group has chosen not to define a single DSCP for use 451 with PCN for several reasons. Firstly the PCN mechanism is 452 applicable to a variety of different traffic classes. Secondly 453 standards track DSCPs are in increasingly short supply. Thirdly PCN 454 is not a scheduling behaviour - rather it should be seen as being 455 essentially a marking behaviour similar to ECN but intended for 456 inelastic traffic. More details are given in the informational 457 Appendix A.1. 459 4.4.1. Co-existence of PCN and not-PCN traffic 461 The scarcity of pool 1 DSCPs coupled with the fact that PCN is 462 envisaged as a marking behaviour that could be applied to a number of 463 different DSCPs makes it essential that we provide a not-PCN state. 464 As stated above (and expanded in Appendix A.1) the aim is for PCN to 465 re-use existing DSCPs. Because PCN re-defines the meaning of the ECN 466 field for such DSCPs it is important to allow an operator to still 467 use the DSCP for traffic that isn't PCN-enabled. This is achieved by 468 providing a not-PCN state within the encoding scheme. S3.5 of 469 [RFC5559] discusses how competing-non-PCN-traffic should be handled. 471 5. Rules for Experimental Encoding Schemes 473 Any experimental encoding scheme MUST follow these rules to ensure 474 backward compatibility with this baseline scheme: 476 o All Interior-nodes within a PCN-domain MUST interpret the 00 477 codepoint in the ECN field as not-PCN and MUST NOT change it to 478 another value. Therefore an ingress node wishing to disable PCN 479 marking for a packet with a PCN-compatible Diffserv Codepoint MUST 480 set the ECN field to 00. 482 o The 11 codepoint in the ECN field MUST indicate that the packet 483 has been PCN-marked as the result of one or both of the meters 484 indicating a need to PCN-mark a packet 485 [I-D.ietf-pcn-marking-behaviour]. The experimental scheme MUST 486 define which meter(s) trigger this marking. 488 o The 01 Experimental codepoint in the ECN field MAY mean PCN-marked 489 or it MAY carry some other meaning. However any experimental 490 scheme MUST define its meaning in the context of that experiment. 492 o If both the 01 and 11 codepoints are being used to indicate PCN- 493 Marked then the 11 codepoint MUST be taken to be the more severe 494 marking and the choice of which meter sets which mark MUST be 495 defined. 497 o Once set, the 11 codepoint in the ECN field MUST NOT be changed to 498 any other codepoint. 500 o Any experimental scheme MUST include details of all valid and 501 invalid codepoint transitions at any PCN nodes. 503 6. Backwards Compatibility 505 BCP 124 [RFC4774] gives guidelines for specifying alternative 506 semantics for the ECN field. It sets out a number of factors to be 507 taken into consideration. It also suggests various techniques to 508 allow the co-existence of default ECN and alternative ECN semantics. 509 The baseline encoding specified in this document defines PCN- 510 compatible Diffserv codepoints as no longer supporting the default 511 ECN semantics. As such this document is compatible with BCP 124. 513 On its own, this baseline encoding cannot support both ECN marking 514 end to end and PCN marking within a PCN-domain. It is possible to do 515 this by carrying e2e ECN across a PCN domain within the inner header 516 of an IP in IP tunnel, or by using a richer encoding such as the 517 proposed experimental scheme in [I-D.ietf-pcn-3-state-encoding]. 519 7. IANA Considerations 521 This document makes no request to IANA. 523 8. Security Considerations 525 PCN-marking only carries a meaning within the confines of a PCN- 526 domain. This encoding document is intended to stand independently of 527 the architecture used to determine how specific packets are 528 authorised to be PCN-marked, which will be described in separate 529 documents on PCN-boundary-node behaviour. 531 This document assumes the PCN-domain to be entirely under the control 532 of a single operator, or a set of operators who trust each other. 533 However future extensions to PCN might include inter-domain versions 534 where trust cannot be assumed between domains. If such schemes are 535 proposed they must ensure that they can operate securely despite the 536 lack of trust. However such considerations are beyond the scope of 537 this document. 539 One potential security concern is the injection of spurious PCN-marks 540 into the PCN-domain. However these can only enter the domain if a 541 PCN-ingress-node is misconfigured. The precise impact of any such 542 misconfiguration will depend on which of the proposed PCN-boundary- 543 node behaviour schemes is used, but in general spurious marks will 544 lead to admitting fewer flows into the domain or potentially 545 terminating too many flows. In either case good management should be 546 able to quickly spot the problem since the overall utilisation of the 547 domain will rapidly fall. 549 9. Conclusions 551 This document defines the baseline PCN encoding utilising a 552 combination of a PCN-enabled DSCP and the ECN field in the IP header. 553 This baseline encoding allows the existence of two PCN encoding 554 states, not-Marked and PCN-marked. It also allows for the co- 555 existence of competing traffic within the same DSCP so long as that 556 traffic does not require ECN support within the PCN-domain. The 557 encoding scheme is conformant with [RFC4774]. The Working Group has 558 chosen not to define a single DSCP for use with PCN. The rationale 559 for this decision along with advice relating to choice of suitable 560 DSCPs can be found in Appendix A.1. 562 10. Acknowledgements 564 This document builds extensively on work done in the PCN working 565 group by Kwok Ho Chan, Georgios Karagiannis, Philip Eardley, Anna 566 Charny, Joe Babiarz and others. Thanks to Ruediger Geib and Gorry 567 Fairhurst for providing detailed comments on this document. 569 11. Comments Solicited 571 (To be removed by the RFC-Editor.) Comments and questions are 572 encouraged and very welcome. They can be addressed to the IETF 573 congestion and pre-congestion working group mailing list 574 , and/or to the authors. 576 12. References 578 12.1. Normative References 580 [I-D.ietf-pcn-marking-behaviour] Eardley, P., "Metering and marking 581 behaviour of PCN-nodes", 582 draft-ietf-pcn-marking-behaviour-05 583 (work in progress), August 2009. 585 [RFC2119] Bradner, S., "Key words for use in 586 RFCs to Indicate Requirement 587 Levels", BCP 14, RFC 2119, 588 March 1997. 590 [RFC3168] Ramakrishnan, K., Floyd, S., and D. 591 Black, "The Addition of Explicit 592 Congestion Notification (ECN) to 593 IP", RFC 3168, September 2001. 595 [RFC4774] Floyd, S., "Specifying Alternate 596 Semantics for the Explicit 597 Congestion Notification (ECN) 598 Field", BCP 124, RFC 4774, 599 November 2006. 601 12.2. Informative References 603 [I-D.ietf-pcn-3-state-encoding] Moncaster, T., Briscoe, B., and M. 604 Menth, "A PCN encoding using 2 605 DSCPs to provide 3 or more states", 606 draft-ietf-pcn-3-state-encoding-00 607 (work in progress), April 2009. 609 [I-D.ietf-tsvwg-ecn-tunnel] Briscoe, B., "Tunnelling of 610 Explicit Congestion Notification", 611 draft-ietf-tsvwg-ecn-tunnel-03 612 (work in progress), July 2009. 614 [RFC2474] Nichols, K., Blake, S., Baker, F., 615 and D. Black, "Definition of the 616 Differentiated Services Field (DS 617 Field) in the IPv4 and IPv6 618 Headers", RFC 2474, December 1998. 620 [RFC2597] Heinanen, J., Baker, F., Weiss, W., 621 and J. Wroclawski, "Assured 622 Forwarding PHB Group", RFC 2597, 623 June 1999. 625 [RFC3246] Davie, B., Charny, A., Bennet, J., 626 Benson, K., Le Boudec, J., 627 Courtney, W., Davari, S., Firoiu, 628 V., and D. Stiliadis, "An Expedited 629 Forwarding PHB (Per-Hop Behavior)", 630 RFC 3246, March 2002. 632 [RFC3540] Spring, N., Wetherall, D., and D. 633 Ely, "Robust Explicit Congestion 634 Notification (ECN) Signaling with 635 Nonces", RFC 3540, June 2003. 637 [RFC4301] Kent, S. and K. Seo, "Security 638 Architecture for the Internet 639 Protocol", RFC 4301, December 2005. 641 [RFC4594] Babiarz, J., Chan, K., and F. 642 Baker, "Configuration Guidelines 643 for DiffServ Service Classes", 644 RFC 4594, August 2006. 646 [RFC5127] Chan, K., Babiarz, J., and F. 647 Baker, "Aggregation of DiffServ 648 Service Classes", RFC 5127, 649 February 2008. 651 [RFC5559] Eardley, P., "Pre-Congestion 652 Notification (PCN) Architecture", 653 RFC 5559, June 2009. 655 Appendix A. PCN Deployment Considerations (Informational) 657 A.1. Choice of Suitable DSCPs 659 The PCN Working Group chose not to define a single DSCP for use with 660 PCN for several reasons. Firstly the PCN mechanism is applicable to 661 a variety of different traffic classes. Secondly standards track 662 DSCPs are in increasingly short supply. Thirdly PCN is not a 663 scheduling behaviour - rather it should be seen as being a marking 664 behaviour similar to ECN but intended for inelastic traffic. The 665 choice of which DSCP is most suitable for a given PCN-domain is 666 dependent on the nature of the traffic entering that domain and the 667 link rates of all the links making up that domain. In PCN-domains 668 with sufficient aggregation, the appropriate DSCPs would currently be 669 those for the Real Time Treatment Aggregate [RFC5127]. The PCN 670 Working Group suggests using admission control for the following 671 service classes (defined in [RFC4594]): 673 o Telephony (EF) 675 o Real-time interactive (CS4) 677 o Broadcast Video (CS3) 679 o Multimedia Conferencing (AF4) 681 CS5 is excluded from this list since PCN is not expected to be 682 applied to signalling traffic. 684 PCN marking is intended to provide a scalable admission control 685 mechanism for traffic with a high degree of statistical multiplexing. 686 PCN marking would therefore be appropriate to apply to traffic in the 687 above classes, but only within a PCN-domain containing sufficiently 688 aggregated traffic. In such cases, the above service classes may 689 well all be subject to a single forwarding treatment (treatment 690 aggregate [RFC5127]). However, this does not imply all such IP 691 traffic would necessarily be identified by one DSCP - each service 692 class might keep a distinct DSCP within the highly aggregated region 693 [RFC5127]. 695 Additional service classes may be defined for which admission control 696 is appropriate, whether through some future standards action or 697 through local use by certain operators, e.g. the Multimedia Streaming 698 service class (AF3). This document does not preclude the use of PCN 699 in more cases than those listed above. 701 NOTE: The above discussion is informative not normative, as operators 702 are ultimately free to decide whether to use admission control for 703 certain service classes and whether to use PCN as their mechanism of 704 choice. 706 A.2. Rationale for Using ECT(0) for Not-marked 708 The choice of which ECT codepoint to use for the Not-marked state was 709 based on the following considerations: 711 o [RFC3168] full functionality tunnel within the PCN-domain: Either 712 ECT is safe. 714 o Leakage of traffic into PCN-domain: because of the lack of take-up 715 of the ECN nonce [RFC3540], leakage of ECT(1) is less likely to 716 occur so might be considered safer. 718 o Leakage of traffic out of PCN-domain: Either ECT is equally unsafe 719 (since this would incorrectly indicate the traffic was ECN-capable 720 outside the controlled PCN-domain). 722 o Incremental deployment: Either codepoint is suitable providing 723 that the codepoints are used consistently. 725 o Conceptual consistency with other schemes: ECT(0) is conceptually 726 consistent with [RFC3168]. 728 Overall this seemed to suggest ECT(0) was most appropriate to use. 730 Authors' Addresses 732 Toby Moncaster 733 BT 734 B54/70, Adastral Park 735 Martlesham Heath 736 Ipswich IP5 3RE 737 UK 739 Phone: +44 1473 648734 740 EMail: toby.moncaster@bt.com 742 Bob Briscoe 743 BT 744 B54/77, Adastral Park 745 Martlesham Heath 746 Ipswich IP5 3RE 747 UK 749 Phone: +44 1473 645196 750 EMail: bob.briscoe@bt.com 751 Michael Menth 752 University of Wuerzburg 753 room B206, Institute of Computer Science 754 Am Hubland 755 Wuerzburg D-97074 756 Germany 758 Phone: +49 931 888 6644 759 EMail: menth@informatik.uni-wuerzburg.de