idnits 2.17.1 draft-ietf-pcn-baseline-encoding-07.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 25, 2009) is 5325 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 29, 2010 M. Menth 6 University of Wuerzburg 7 September 25, 2009 9 Baseline Encoding and Transport of Pre-Congestion Information 10 draft-ietf-pcn-baseline-encoding-07 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 29, 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 . . . . . . . . . . . . . . . . 8 77 4.1. Marking Packets . . . . . . . . . . . . . . . . . . . . . 9 78 4.2. Valid and Invalid Codepoint Transitions . . . . . . . . . 9 79 4.3. Rationale for Encoding . . . . . . . . . . . . . . . . . . 10 80 4.4. PCN-Compatible Diffserv Codepoints . . . . . . . . . . . . 10 81 4.4.1. Co-existence of PCN and not-PCN traffic . . . . . . . 11 82 5. Rules for Experimental Encoding Schemes . . . . . . . . . . . 11 83 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 88 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 13 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 91 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 92 Appendix A. PCN Deployment Considerations (Informational) . . . . 15 93 A.1. Choice of Suitable DSCPs . . . . . . . . . . . . . . . . . 15 94 A.2. Rationale for Using ECT(0) for Not-marked . . . . . . . . 16 95 Appendix B. Co-existence of PCN and ECN (Informational) . . . . . 17 97 1. Introduction 99 The objective of the Pre-Congestion Notification (PCN) Architecture 100 [RFC5559] is to protect the quality of service (QoS) of inelastic 101 flows within a Diffserv domain, in a simple, scalable and robust 102 fashion. The overall rate of the PCN-traffic is metered on every 103 link in the PCN-domain, and PCN-packets are appropriately marked when 104 certain configured rates are exceeded. These configured rates are 105 below the rate of the link thus providing notification before any 106 congestion occurs (hence "pre-congestion notification"). The level 107 of marking allows the boundary nodes to make decisions about whether 108 to admit or block a new flow request, and (in abnormal circumstances) 109 whether to terminate some of the existing flows, thereby protecting 110 the QoS of previously admitted flows. 112 This document specifies how these PCN-marks are encoded into the IP 113 header by re-using the bits of the Explicit Congestion Notification 114 (ECN) field [RFC3168]. It also describes how packets are identified 115 as belonging to a PCN-flow. Some deployment models require two PCN 116 encoding states, others require more. The baseline encoding 117 described here only provides for two PCN encoding states. However 118 the encoding can be easily extended to provide more states. Rules 119 for such extensions are given in Section 5. 121 Changes from previous drafts (to be removed by the RFC Editor): 123 From -06 to -07: 125 Changes made following IESG review comments. 127 Changed Section 4 and added Appendix B to clarify the correct 128 behaviour when handling packets that already have values other 129 than not-ECT in their ECN field. 131 Added paragraph to end of Section 6 clarifying that a PCN-domain 132 has "hard" edges. 134 From -05 to -06: 136 Extensive changes to the text following IETF Last Call and Gen-ART 137 review comments. 139 Abstract updated following mailing list discussions after Gen-ART 140 review by Spencer Dawkins. 142 Added list of abbreviations 144 New [section 4.1] added to explain the required action when a node 145 indicates the need to mark a packet. 147 Clarified text and Table 2 in Section 4.2. 149 Improved explanation of rules for experimental encoding schemes in 150 Section 5. Removed any ambiguity about meaning of PCN-marked in 151 such a context. Added requirements for experimental schemes to 152 define which meter causes which mark. 154 Clarified text in Section 6 relating to support for e2e ECN. 156 Added text in Section 8 relating to injection of PCN-marks into 157 the PCN-domain. 159 Changed text of Appendix A.1 to reflect comments from Spencer 160 Dawkins and Philip Eardley. 162 From -04 to -05: 164 Clarified throughout that the PCN WG is not requesting a specific 165 DSCP for PCN. Rather we are recommending a set of DSCPs that 166 might be suitable. Appendix A.1 has been re-written to reflect 167 this. References to maintaining a list of PCN-compatible DSCPs 168 have also been removed. 170 Last sentence of Section 6 altered. 172 Several spelling corrections. 174 References updated throughout. 176 From -03 to -04: 178 Major WGLC comments addressed: 180 * Added Section 4.4.1 to clarify why we need the not-PCN 181 codepoint. 183 * Stated that the PCN WG will maintain a list of PCN-compatible 184 DSCPs. This should help avoid inter-operability issues. 186 Also addressed a number of WGLC nits. 188 From -02 to -03: 190 Extensive changes to address comments made by Gorry Fairhurst 191 including: 193 * Abstract re-written. 195 * Clarified throughout that this re-uses the ECN bits in the IP 196 header. 198 * Re-arranged order of terminology section for clarity. 200 * Table 2 replaced with new table and text. 202 * Security considerations re-written. 204 * Appendixes re-written to improve clarity. 206 * Numerous minor nits and language changes throughout. 208 Extensive other minor changes throughout. 210 From -01 to -02: 212 Removed Appendix A and replaced with reference to 213 [I-D.ietf-tsvwg-ecn-tunnel] 215 Moved Appendix B into main body of text. 217 Changed Appendix C to give deployment advice. 219 Minor changes throughout including checking consistency of 220 capitalisation of defined terms. 222 Clarified that LU was deliberately excluded from encoding. 224 From -00 to -01: 226 Added section on restrictions for extension encoding schemes. 228 Included table in Appendix showing encoding transitions at 229 different PCN nodes. 231 Checked for consistency of terminology. 233 Minor language changes for clarity. 235 Changes from previous filename 237 Filename changed from draft-moncaster-pcn-baseline-encoding. 239 Terminology changed for clarity (PCN-compatible DSCP and PCN- 240 enabled packet). 242 Minor changes throughout. 244 Modified meaning of ECT(1) state to EXP. 246 Moved text relevant to behaviour of nodes into appendix for later 247 transfer to new document on edge behaviours. 249 From draft-moncaster -01 to -02: 251 Minor changes throughout including tightening up language to 252 remain consistent with the PCN Architecture terminology. 254 From draft-moncaster -00 to -01: 256 Change of title from "Encoding and Transport of (Pre-)Congestion 257 Information from within a Diffserv Domain to the Egress" 259 Extensive changes to Introduction and abstract. 261 Added a section on the implications of re-using a DSCP. 263 Added appendix listing possible operator scenarios for using this 264 baseline encoding. 266 Minor changes throughout. 268 2. Requirements notation 270 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 271 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 272 document are to be interpreted as described in [RFC2119]. 274 3. Terminology and Abbreviations 276 The following terms are defined in this document: 278 o PCN-compatible Diffserv codepoint - a Diffserv codepoint for which 279 the ECN field is used to carry PCN markings rather than [RFC3168] 280 markings. 282 o PCN-marked - codepoint indicating packets that have been marked at 283 a PCN-interior-node using some PCN marking behaviour 284 [I-D.ietf-pcn-marking-behaviour]. Abbreviated to PM. 286 o Not-marked - codepoint indicating packets that are PCN-capable, 287 but are not PCN-marked. Abbreviated to NM. 289 o PCN-enabled codepoints - collective term for all NM and PM 290 codepoints. By definition, packets carrying such codepoints are 291 PCN-packets. 293 o not-PCN - packets that are not PCN-enabled. 295 In addition, the document uses the terminology defined in [RFC5559]. 297 3.1. List of Abbreviations 299 The following abbreviations are used in this document: 301 o AF = Assured Forwarding [RFC2597] 303 o CE = Congestion Experienced [RFC3168] 305 o CS = Class Selector [RFC2474] 307 o DSCP = Diffserv codepoint 309 o ECN = Explicit Congestion Notification [RFC3168] 311 o ECT = ECN Capable Transport [RFC3168] 313 o EF = Expedited Forwarding [RFC3246] 315 o EXP = Experimental 317 o NM = Not-marked 319 o PCN = Pre-Congestion Notification 321 o PM = PCN-marked 323 4. Encoding two PCN States in IP 325 The PCN encoding states are defined using a combination of the DSCP 326 and ECN fields within the IP header. The baseline PCN encoding 327 closely follows the semantics of ECN [RFC3168]. It allows the 328 encoding of two PCN states: Not-marked and PCN-marked. It also 329 allows for traffic that is not PCN-capable to be marked as such (not- 330 PCN). Given the scarcity of codepoints within the IP header the 331 baseline encoding leaves one codepoint free for experimental use. 332 The following table defines how to encode these states in IP: 334 +---------------+-------------+-------------+-------------+---------+ 335 | ECN codepoint | Not-ECT | ECT(0) (10) | ECT(1) (01) | CE (11) | 336 | | (00) | | | | 337 +---------------+-------------+-------------+-------------+---------+ 338 | DSCP n | not-PCN | NM | EXP | PM | 339 +---------------+-------------+-------------+-------------+---------+ 341 Where DSCP n is a PCN-compatible Diffserv codepoint (see Section 4.4) 342 and EXP means available for Experimental use. N.B. we deliberately 343 reserve this codepoint for experimental use only (and not local use) 344 to prevent future compatibility issues. 346 Table 1: Encoding PCN in IP 348 The following rules apply to all PCN traffic: 350 o PCN-traffic MUST be marked with a PCN-compatible Diffserv 351 Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be 352 chosen that are already defined for use with admission controlled 353 traffic. Appendix A.1 gives guidance to implementors on suitable 354 DSCPs. Guidelines for mixing traffic-types within a PCN-domain 355 are given in [I-D.ietf-pcn-marking-behaviour]. 357 o Any packet arriving at the PCN-ingress that shares a PCN- 358 compatible DSCP and is not-PCN MUST be marked as not-PCN within 359 the PCN-domain. 361 o If a packet arrives at the PCN-ingress with its ECN field already 362 set to a value other than not-ECT, then appropriate action MUST be 363 taken to meet the requirements of [RFC3168]. The simplest 364 appropriate action is to just drop such packets. However this is 365 a drastic action that an operator may feel is undesirable. 366 Appendix B provides more information and summarises other 367 alternative actions that might be taken. 369 4.1. Marking Packets 371 [I-D.ietf-pcn-marking-behaviour] states that any encoding scheme 372 document must specify the required action to take if one of the 373 marking algorithms indicates that a packet needs to be marked. For 374 the baseline encoding scheme the required action is simply as 375 follows: 377 o If a marking algorithm indicates the need to mark a PCN-packet 378 then that packet MUST have its PCN codepoint set to 11, PCN- 379 marked. 381 4.2. Valid and Invalid Codepoint Transitions 383 A PCN-ingress-node MUST set the Not-marked (10) codepoint on any 384 arriving packet that belongs to a PCN-flow. It MUST set the not-PCN 385 (00) codepoint on all other packets sharing a PCN-compatible Diffserv 386 codepoint. 388 The only valid codepoint transitions within a PCN-interior-node are 389 from NM to PM (which should occur if either meter indicates a need to 390 PCN-mark a packet [I-D.ietf-pcn-marking-behaviour]) and from EXP to 391 PM. PCN-nodes that only implement the baseline encoding MUST be able 392 to PCN mark packets that arrive with the EXP codepoint. This should 393 ease the design of experimental schemes that want to allow partial 394 deployment of experimental nodes alongside nodes that only implement 395 the baseline encoding. The following table gives the full set of 396 valid and invalid codepoint transitions. 398 +-------------------------------------------------+ 399 | Codepoint Out | 400 +--------------+-------------+-----------+-----------+-----------+ 401 | Codepoint in | not-PCN(00) | NM(10) | EXP(01) | PM(11) | 402 +--------------+-------------+-----------+-----------+-----------+ 403 | not-PCN(00) | Valid | Not valid | Not valid | Not valid | 404 +--------------+-------------+-----------+-----------+-----------+ 405 | NM(10) | Not valid | Valid | Not valid | Valid | 406 +--------------+-------------+-----------+-----------+-----------+ 407 | EXP(01)* | Not valid | Not valid | Valid | Valid | 408 +--------------+-------------+-----------+-----------+-----------+ 409 | PM(11) | Not valid | Not valid | Not valid | Valid | 410 +--------------+-------------+-----------+-----------+-----------+ 411 * This MAY cause an alarm to be raised at a management layer. 412 See paragraph above for an explanation of this transition. 414 Table 2: Valid and Invalid Codepoint Transitions for PCN-packets 415 at PCN-interior-nodes 417 The codepoint transition constraints given here apply only to the 418 baseline encoding scheme. Constraints on codepoint transitions for 419 future experimental schemes are discussed in Section 5. 421 A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all 422 packets it forwards out of the PCN-domain. The only exception to 423 this is if the PCN-egress-node is certain that revealing other 424 codepoints outside the PCN-domain won't contravene the guidance given 425 in [RFC4774]. For instance if the PCN-ingress-node has explicitly 426 informed the PCN-egress-node that this flow is ECN-capable then it 427 might be safe to expose other codepoints. 429 4.3. Rationale for Encoding 431 The exact choice of encoding was dictated by the constraints imposed 432 by existing IETF RFCs, in particular [RFC3168], [RFC4301] and 433 [RFC4774]. One of the tightest constraints was the need for any PCN 434 encoding to survive being tunnelled through either an IP in IP tunnel 435 or an IPsec Tunnel. [I-D.ietf-tsvwg-ecn-tunnel] explains this in 436 more detail. The main effect of this constraint is that any PCN 437 marking has to carry the 11 codepoint in the ECN field since this is 438 the only codepoint that is guaranteed to be copied down into the 439 inner header upon decapsulation. An additional constraint is the 440 need to minimise the use of Diffserv codepoints because there is a 441 limited supply of standards track codepoints remaining. Section 4.4 442 explains how we have minimised this still further by reusing pre- 443 existing Diffserv codepoint(s) such that non-PCN traffic can still be 444 distinguished from PCN traffic. 446 There are a number of factors that were considered before choosing to 447 set 10 as the NM state instead of 01. These included similarity to 448 ECN, presence of tunnels within the domain, leakage into and out of 449 PCN-domain and incremental deployment (see Appendix A.2). 451 The encoding scheme above seems to meet all these constraints and 452 ends up looking very similar to ECN. This is perhaps not surprising 453 given the similarity in architectural intent between PCN and ECN. 455 4.4. PCN-Compatible Diffserv Codepoints 457 Equipment complying with the baseline PCN encoding MUST allow PCN to 458 be enabled for certain Diffserv codepoints. This document defines 459 the term "PCN-compatible Diffserv codepoint" for such a DSCP. To be 460 clear, any packets with such a DSCP will be PCN enabled only if they 461 are within a PCN-domain and have their ECN field set to indicate a 462 codepoint other than not-PCN. 464 Enabling PCN marking behaviour for a specific DSCP disables any other 465 marking behaviour (e.g. enabling PCN replaces the default ECN marking 466 behaviour introduced in [RFC3168]) with the PCN metering and marking 467 behaviours described in [I-D.ietf-pcn-marking-behaviour]). This 468 ensures compliance with the BCP guidance set out in [RFC4774]. 470 The PCN Working Group has chosen not to define a single DSCP for use 471 with PCN for several reasons. Firstly the PCN mechanism is 472 applicable to a variety of different traffic classes. Secondly 473 standards track DSCPs are in increasingly short supply. Thirdly PCN 474 is not a scheduling behaviour - rather it should be seen as being 475 essentially a marking behaviour similar to ECN but intended for 476 inelastic traffic. More details are given in the informational 477 Appendix A.1. 479 4.4.1. Co-existence of PCN and not-PCN traffic 481 The scarcity of pool 1 DSCPs coupled with the fact that PCN is 482 envisaged as a marking behaviour that could be applied to a number of 483 different DSCPs makes it essential that we provide a not-PCN state. 484 As stated above (and expanded in Appendix A.1) the aim is for PCN to 485 re-use existing DSCPs. Because PCN re-defines the meaning of the ECN 486 field for such DSCPs it is important to allow an operator to still 487 use the DSCP for traffic that isn't PCN-enabled. This is achieved by 488 providing a not-PCN state within the encoding scheme. S3.5 of 489 [RFC5559] discusses how competing-non-PCN-traffic should be handled. 491 5. Rules for Experimental Encoding Schemes 493 Any experimental encoding scheme MUST follow these rules to ensure 494 backward compatibility with this baseline scheme: 496 o All Interior-nodes within a PCN-domain MUST interpret the 00 497 codepoint in the ECN field as not-PCN and MUST NOT change it to 498 another value. Therefore an ingress node wishing to disable PCN 499 marking for a packet with a PCN-compatible Diffserv Codepoint MUST 500 set the ECN field to 00. 502 o The 11 codepoint in the ECN field MUST indicate that the packet 503 has been PCN-marked as the result of one or both of the meters 504 indicating a need to PCN-mark a packet 505 [I-D.ietf-pcn-marking-behaviour]. The experimental scheme MUST 506 define which meter(s) trigger this marking. 508 o The 01 Experimental codepoint in the ECN field MAY mean PCN-marked 509 or it MAY carry some other meaning. However any experimental 510 scheme MUST define its meaning in the context of that experiment. 512 o If both the 01 and 11 codepoints are being used to indicate PCN- 513 Marked then the 11 codepoint MUST be taken to be the more severe 514 marking and the choice of which meter sets which mark MUST be 515 defined. 517 o Once set, the 11 codepoint in the ECN field MUST NOT be changed to 518 any other codepoint. 520 o Any experimental scheme MUST include details of all valid and 521 invalid codepoint transitions at any PCN nodes. 523 6. Backwards Compatibility 525 BCP 124 [RFC4774] gives guidelines for specifying alternative 526 semantics for the ECN field. It sets out a number of factors to be 527 taken into consideration. It also suggests various techniques to 528 allow the co-existence of default ECN and alternative ECN semantics. 529 The baseline encoding specified in this document defines PCN- 530 compatible Diffserv codepoints as no longer supporting the default 531 ECN semantics. As such this document is compatible with BCP 124. 533 On its own, this baseline encoding cannot support both ECN marking 534 end to end and PCN marking within a PCN-domain. It is possible to do 535 this by carrying e2e ECN across a PCN domain within the inner header 536 of an IP in IP tunnel, or by using a richer encoding such as the 537 proposed experimental scheme in [I-D.ietf-pcn-3-state-encoding]. 539 In any PCN deployment, traffic can only enter the PCN-Domain through 540 PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress- 541 nodes ensure that any packets entering the PCN- domain have the ECN- 542 field in their outermost IP header set to the appropriate PCN 543 codepoint. PCN-egress-nodes then guarantee that the ECN-field of any 544 packet leaving the PCN-domain has the correct ECN semantics. This 545 prevents leakage of ECN marks into or out of the PCN-domain and thus 546 reduces backward compatibility issues. 548 7. IANA Considerations 550 This document makes no request to IANA. 552 8. Security Considerations 554 PCN-marking only carries a meaning within the confines of a PCN- 555 domain. This encoding document is intended to stand independently of 556 the architecture used to determine how specific packets are 557 authorised to be PCN-marked, which will be described in separate 558 documents on PCN-boundary-node behaviour. 560 This document assumes the PCN-domain to be entirely under the control 561 of a single operator, or a set of operators who trust each other. 562 However future extensions to PCN might include inter-domain versions 563 where trust cannot be assumed between domains. If such schemes are 564 proposed they must ensure that they can operate securely despite the 565 lack of trust. However such considerations are beyond the scope of 566 this document. 568 One potential security concern is the injection of spurious PCN-marks 569 into the PCN-domain. However these can only enter the domain if a 570 PCN-ingress-node is misconfigured. The precise impact of any such 571 misconfiguration will depend on which of the proposed PCN-boundary- 572 node behaviour schemes is used, but in general spurious marks will 573 lead to admitting fewer flows into the domain or potentially 574 terminating too many flows. In either case good management should be 575 able to quickly spot the problem since the overall utilisation of the 576 domain will rapidly fall. 578 9. Conclusions 580 This document defines the baseline PCN encoding utilising a 581 combination of a PCN-enabled DSCP and the ECN field in the IP header. 582 This baseline encoding allows the existence of two PCN encoding 583 states, not-Marked and PCN-marked. It also allows for the co- 584 existence of competing traffic within the same DSCP so long as that 585 traffic does not require ECN support within the PCN-domain. The 586 encoding scheme is conformant with [RFC4774]. The Working Group has 587 chosen not to define a single DSCP for use with PCN. The rationale 588 for this decision along with advice relating to choice of suitable 589 DSCPs can be found in Appendix A.1. 591 10. Acknowledgements 593 This document builds extensively on work done in the PCN working 594 group by Kwok Ho Chan, Georgios Karagiannis, Philip Eardley, Anna 595 Charny, Joe Babiarz and others. Thanks to Ruediger Geib and Gorry 596 Fairhurst for providing detailed comments on this document. 598 11. Comments Solicited 600 (To be removed by the RFC-Editor.) Comments and questions are 601 encouraged and very welcome. They can be addressed to the IETF 602 congestion and pre-congestion working group mailing list 603 , and/or to the authors. 605 12. References 606 12.1. Normative References 608 [I-D.ietf-pcn-marking-behaviour] Eardley, P., "Metering and marking 609 behaviour of PCN-nodes", 610 draft-ietf-pcn-marking-behaviour-05 611 (work in progress), August 2009. 613 [RFC2119] Bradner, S., "Key words for use in 614 RFCs to Indicate Requirement 615 Levels", BCP 14, RFC 2119, 616 March 1997. 618 [RFC3168] Ramakrishnan, K., Floyd, S., and D. 619 Black, "The Addition of Explicit 620 Congestion Notification (ECN) to 621 IP", RFC 3168, September 2001. 623 [RFC4774] Floyd, S., "Specifying Alternate 624 Semantics for the Explicit 625 Congestion Notification (ECN) 626 Field", BCP 124, RFC 4774, 627 November 2006. 629 12.2. Informative References 631 [I-D.ietf-pcn-3-state-encoding] Moncaster, T., Briscoe, B., and M. 632 Menth, "A PCN encoding using 2 633 DSCPs to provide 3 or more states", 634 draft-ietf-pcn-3-state-encoding-00 635 (work in progress), April 2009. 637 [I-D.ietf-tsvwg-ecn-tunnel] Briscoe, B., "Tunnelling of 638 Explicit Congestion Notification", 639 draft-ietf-tsvwg-ecn-tunnel-03 640 (work in progress), July 2009. 642 [RFC2474] Nichols, K., Blake, S., Baker, F., 643 and D. Black, "Definition of the 644 Differentiated Services Field (DS 645 Field) in the IPv4 and IPv6 646 Headers", RFC 2474, December 1998. 648 [RFC2597] Heinanen, J., Baker, F., Weiss, W., 649 and J. Wroclawski, "Assured 650 Forwarding PHB Group", RFC 2597, 651 June 1999. 653 [RFC3246] Davie, B., Charny, A., Bennet, J., 654 Benson, K., Le Boudec, J., 655 Courtney, W., Davari, S., Firoiu, 656 V., and D. Stiliadis, "An Expedited 657 Forwarding PHB (Per-Hop Behavior)", 658 RFC 3246, March 2002. 660 [RFC3540] Spring, N., Wetherall, D., and D. 661 Ely, "Robust Explicit Congestion 662 Notification (ECN) Signaling with 663 Nonces", RFC 3540, June 2003. 665 [RFC4301] Kent, S. and K. Seo, "Security 666 Architecture for the Internet 667 Protocol", RFC 4301, December 2005. 669 [RFC4594] Babiarz, J., Chan, K., and F. 670 Baker, "Configuration Guidelines 671 for DiffServ Service Classes", 672 RFC 4594, August 2006. 674 [RFC5127] Chan, K., Babiarz, J., and F. 675 Baker, "Aggregation of DiffServ 676 Service Classes", RFC 5127, 677 February 2008. 679 [RFC5559] Eardley, P., "Pre-Congestion 680 Notification (PCN) Architecture", 681 RFC 5559, June 2009. 683 Appendix A. PCN Deployment Considerations (Informational) 685 A.1. Choice of Suitable DSCPs 687 The PCN Working Group chose not to define a single DSCP for use with 688 PCN for several reasons. Firstly the PCN mechanism is applicable to 689 a variety of different traffic classes. Secondly standards track 690 DSCPs are in increasingly short supply. Thirdly PCN is not a 691 scheduling behaviour - rather it should be seen as being a marking 692 behaviour similar to ECN but intended for inelastic traffic. The 693 choice of which DSCP is most suitable for a given PCN-domain is 694 dependent on the nature of the traffic entering that domain and the 695 link rates of all the links making up that domain. In PCN-domains 696 with sufficient aggregation, the appropriate DSCPs would currently be 697 those for the Real Time Treatment Aggregate [RFC5127]. The PCN 698 Working Group suggests using admission control for the following 699 service classes (defined in [RFC4594]): 701 o Telephony (EF) 703 o Real-time interactive (CS4) 705 o Broadcast Video (CS3) 707 o Multimedia Conferencing (AF4) 709 CS5 is excluded from this list since PCN is not expected to be 710 applied to signalling traffic. 712 PCN marking is intended to provide a scalable admission control 713 mechanism for traffic with a high degree of statistical multiplexing. 714 PCN marking would therefore be appropriate to apply to traffic in the 715 above classes, but only within a PCN-domain containing sufficiently 716 aggregated traffic. In such cases, the above service classes may 717 well all be subject to a single forwarding treatment (treatment 718 aggregate [RFC5127]). However, this does not imply all such IP 719 traffic would necessarily be identified by one DSCP - each service 720 class might keep a distinct DSCP within the highly aggregated region 721 [RFC5127]. 723 Additional service classes may be defined for which admission control 724 is appropriate, whether through some future standards action or 725 through local use by certain operators, e.g. the Multimedia Streaming 726 service class (AF3). This document does not preclude the use of PCN 727 in more cases than those listed above. 729 NOTE: The above discussion is informative not normative, as operators 730 are ultimately free to decide whether to use admission control for 731 certain service classes and whether to use PCN as their mechanism of 732 choice. 734 A.2. Rationale for Using ECT(0) for Not-marked 736 The choice of which ECT codepoint to use for the Not-marked state was 737 based on the following considerations: 739 o [RFC3168] full functionality tunnel within the PCN-domain: Either 740 ECT is safe. 742 o Leakage of traffic into PCN-domain: because of the lack of take-up 743 of the ECN nonce [RFC3540], leakage of ECT(1) is less likely to 744 occur so might be considered safer. 746 o Leakage of traffic out of PCN-domain: Either ECT is equally unsafe 747 (since this would incorrectly indicate the traffic was ECN-capable 748 outside the controlled PCN-domain). 750 o Incremental deployment: Either codepoint is suitable providing 751 that the codepoints are used consistently. 753 o Conceptual consistency with other schemes: ECT(0) is conceptually 754 consistent with [RFC3168]. 756 Overall this seemed to suggest ECT(0) was most appropriate to use. 758 Appendix B. Co-existence of PCN and ECN (Informational) 760 This baseline encoding scheme redefines the ECN codepoints within the 761 PCN-domain. As packets with a PCN-compatible DSCP leave the PCN- 762 domain, their ECN field is reset to not-ECT (00). This is a problem 763 for the operator if packets with a PCN-compatible DSCP arrive at the 764 PCN-domain with any ECN codepoint other than not-ECN. If the ECN- 765 codepoint is ECT(0) (10) or ECT(1) (01), resetting the ECN field to 766 00 effectively turns off end-to-end ECN. This is undesirable as it 767 removes the benefits of ECN but [RFC3168] states it is no worse than 768 dropping the packet. However, if a packet was marked with CE (11), 769 resetting the ECN field to 00 at the PCN egress node violates the 770 rule that CE-marks must never be lost except as a result of packet 771 drop [RFC3168]. 773 A number of options exist to overcome this issue. The most 774 appropriate option will depend on the circumstances and has to be a 775 decision for the operator. The definition of the action is beyond 776 the scope of this document but we briefly explain the four broad 777 categories of solution below: tunnelling the packets, using an 778 extended encoding scheme, signalling to the end-systems to stop using 779 ECN or re-marking packets to a different DSCP. 781 o Tunnelling the packets across the PCN-domain (for instance in an 782 IP-in-IP tunnel from the PCN-ingress-node to the PCN-egress-node) 783 preserves the original ECN marking on the inner header. 785 o An extended encoding scheme can be designed that preserves the 786 original ECN codepoints. For instance if the PCN-egress-node can 787 determine from the PCN codepoint what the original ECN codepoint 788 was then it can reset the packet to that codepoint. 789 [I-D.ietf-pcn-3-state-encoding] partially achieves this but is 790 unable to recover ECN markings if the packet is PCN-marked in the 791 PCN-domain. 793 o Explicit signalling to the end systems can indicate to the source 794 that ECN cannot be used on this path (because it does not support 795 ECN & PCN at the same time). Dropping the packet can be thought 796 of as a form of silent signal to the source as it will see any 797 ECT-marked packets it sends being dropped. 799 o Packets that are not-PCN but which share a PCN-compatible DSCP can 800 be re-marked to a different local-use DSCP at the PCN-ingress-node 801 with the original DSCP restored at the PCN-egress. This preserves 802 the ECN codepoint on the packets, but it relies on there being 803 spare local-use DSCPs within the PCN-domain. 805 Authors' Addresses 807 Toby Moncaster 808 BT 809 B54/70, Adastral Park 810 Martlesham Heath 811 Ipswich IP5 3RE 812 UK 814 Phone: +44 1473 648734 815 EMail: toby.moncaster@bt.com 817 Bob Briscoe 818 BT 819 B54/77, Adastral Park 820 Martlesham Heath 821 Ipswich IP5 3RE 822 UK 824 Phone: +44 1473 645196 825 EMail: bob.briscoe@bt.com 827 Michael Menth 828 University of Wuerzburg 829 room B206, Institute of Computer Science 830 Am Hubland 831 Wuerzburg D-97074 832 Germany 834 Phone: +49 931 888 6644 835 EMail: menth@informatik.uni-wuerzburg.de