idnits 2.17.1 draft-ietf-pcn-3-in-1-encoding-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 10, 2011) is 4674 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) ** Downref: Normative reference to an Informational RFC: RFC 5559 == Outdated reference: A later version (-15) exists of draft-ietf-pcn-cl-edge-behaviour-09 == Outdated reference: A later version (-09) exists of draft-ietf-pcn-encoding-comparison-06 == Outdated reference: A later version (-12) exists of draft-ietf-pcn-sm-edge-behaviour-06 -- Obsolete informational reference (is this intentional?): RFC 5696 (Obsoleted by RFC 6660) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Congestion and Pre-Congestion B. Briscoe 3 Notification BT 4 Internet-Draft T. Moncaster 5 Obsoletes: 5696 (if approved) Moncaster Internet Consulting 6 Intended status: Standards Track M. Menth 7 Expires: January 11, 2012 University of Tuebingen 8 July 10, 2011 10 Encoding 3 PCN-States in the IP header using a single DSCP 11 draft-ietf-pcn-3-in-1-encoding-06 13 Abstract 15 The objective of Pre-Congestion Notification (PCN) is to protect the 16 quality of service (QoS) of inelastic flows within a Diffserv domain. 17 The overall rate of the PCN-traffic is metered on every link in the 18 PCN domain, and PCN-packets are appropriately marked when certain 19 configured rates are exceeded. Egress nodes pass information about 20 these PCN-marks to decision points which then decide whether to admit 21 or block new flow requests or to terminate some already-admitted 22 flows during serious pre-congestion. 24 This document specifies how PCN-marks are to be encoded into the IP 25 header by re-using the Explicit Congestion Notification (ECN) 26 codepoints within a PCN-domain. This encoding provides for up to 27 three different PCN marking states using a single DSCP: not-marked 28 (NM), threshold-marked (ThM) and excess-traffic-marked (ETM). Hence, 29 it is called the 3-in-1 PCN encoding. This document obsoletes 30 RFC5696. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 11, 2012. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 68 1.2. Changes in This Version (to be removed by RFC Editor) . . 5 69 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 7 70 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 7 72 3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 8 73 4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 9 74 4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 9 75 4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 9 76 4.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 10 77 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN 78 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 10 80 5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 11 81 5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 11 82 5.2.2. Behaviour of PCN-interior Nodes Using Two 83 PCN-markings . . . . . . . . . . . . . . . . . . . . . 11 84 5.2.3. Behaviour of PCN-interior Nodes Using One 85 PCN-marking . . . . . . . . . . . . . . . . . . . . . 11 86 5.3. Behaviour of PCN-egress Nodes . . . . . . . . . . . . . . 12 87 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13 88 6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 13 89 6.2. Backward Compatibility with the Baseline Encoding . . . . 13 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 92 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 94 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 15 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 97 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 98 Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 16 99 Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 18 100 Appendix C. Example Mapping between Encoding of PCN-Marks in 101 IP and in MPLS Shim Headers . . . . . . . . . . . . . 20 102 Appendix D. Rationale for different behaviours for single 103 marking schemes . . . . . . . . . . . . . . . . . . . 21 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 106 1. Introduction 108 The objective of Pre-Congestion Notification (PCN) [RFC5559] is to 109 protect the quality of service (QoS) of inelastic flows within a 110 Diffserv domain, in a simple, scalable, and robust fashion. Two 111 mechanisms are used: admission control, to decide whether to admit or 112 block a new flow request, and flow termination to terminate some 113 existing flows during serious pre-congestion. To achieve this, the 114 overall rate of PCN-traffic is metered on every link in the domain, 115 and PCN-packets are appropriately marked when certain configured 116 rates are exceeded. These configured rates are below the rate of the 117 link thus providing notification to boundary nodes about overloads 118 before any real congestion occurs (hence "pre-congestion 119 notification"). 121 [RFC5670] provides for two metering and marking functions that are 122 generally configured with different reference rates. Threshold- 123 marking marks all PCN packets once their traffic rate on a link 124 exceeds the configured reference rate (PCN-threshold-rate). Excess- 125 traffic-marking marks only those PCN packets that exceed the 126 configured reference rate (PCN-excess-rate). The PCN-excess-rate is 127 typically larger than the PCN-threshold-rate [RFC5559]. Egress nodes 128 monitor the PCN-marks of received PCN-packets and pass information 129 about these PCN-marks to decision points which then decide whether to 130 admit new flows or terminate existing flows 131 [I-D.ietf-pcn-cl-edge-behaviour], [I-D.ietf-pcn-sm-edge-behaviour]. 133 The baseline encoding defined in [RFC5696] described how two PCN 134 marking states (Not-marked and PCN-Marked) could be encoded into the 135 IP header using a single Diffserv codepoint. It also provided an 136 experimental codepoint (EXP), along with guidelines for the use of 137 that codepoint. Two PCN marking states are sufficient for the Single 138 Marking edge behaviour [I-D.ietf-pcn-sm-edge-behaviour]. However, 139 PCN-domains utilising the controlled load edge behaviour 140 [I-D.ietf-pcn-cl-edge-behaviour] require three PCN marking states. 141 This document extends the baseline encoding by redefining the EXP 142 codepoint to provide a third PCN marking state in the IP header, 143 still using a single Diffserv codepoint. This encoding scheme is 144 therefore called the "3-in-1 PCN encoding". It obsoletes the 145 baseline encoding [RFC5696], which provides only a sub-set of the 146 same capabilities. 148 The full version of this encoding requires any tunnel endpoint within 149 the PCN-domain to support the normal tunnelling rules defined in 150 [RFC6040]. There is one limited exception to this constraint where 151 the PCN-domain only uses the excess-traffic-marking behaviour and 152 where the threshold-marking behaviour is deactivated. This is 153 discussed in Section 5.2.3.1. 155 This document only concerns the PCN wire protocol encoding for IP 156 headers, whether IPv4 or IPv6. It makes no changes or 157 recommendations concerning algorithms for congestion marking or 158 congestion response. Other documents will define the PCN wire 159 protocol for other header types. Appendix C discusses a possible 160 mapping between IP and MPLS. 162 1.1. Requirements Language 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 1.2. Changes in This Version (to be removed by RFC Editor) 170 From draft-ietf-pcn-3-in-1-encoding-05 to -06: 172 * Draft re-written to obsolete baseline encoding [RFC5696]. 174 * New section defining utilising this encoding for single 175 marking. Added an appendix explaining an apparent 176 inconsistency relating to single marking. 178 * Moved (and updated) informative appendixes from [RFC5696] to 179 this document. Original Appendix C was omitted as it is now 180 redundant. 182 * Significant re-structuring of document. 184 From draft-ietf-pcn-3-in-1-encoding-04 to -05: 186 * Draft moved to standards track as per working group 187 discussions. 189 * Added Appendix B discussing ECN handling in the PCN-domain. 191 * Clarified that this document modifies [RFC5696]. 193 From draft-ietf-pcn-3-in-1-encoding-03 to -04: 195 * Updated document to reflect RFC6040. 197 * Re-wrote introduction. 199 * Re-wrote section on applicability. 201 * Re-wrote section on choosing encoding scheme. 203 * Updated author details. 205 From draft-ietf-pcn-3-in-1-encoding-02 to -03: 207 * Corrected mistakes in introduction and improved overall 208 readability. 210 * Added new terminology. 212 * Rewrote a good part of Section 4 and 5 to achieve more clarity. 214 * Added appendix explaining when to use which encoding scheme and 215 how to encode them in MPLS shim headers. 217 * Added new co-author. 219 From draft-ietf-pcn-3-in-1-encoding-01 to -02: 221 * Corrected mistake in introduction, which wrongly stated that 222 the threshold-traffic rate is higher than the excess-traffic 223 rate. Other minor corrections. 225 * Updated acks & refs. 227 From draft-ietf-pcn-3-in-1-encoding-00 to -01: 229 * Altered the wording to make sense if 230 draft-ietf-tsvwg-ecn-tunnel moves to proposed standard. 232 * References updated 234 From draft-briscoe-pcn-3-in-1-encoding-00 to 235 draft-ietf-pcn-3-in-1-encoding-00: 237 * Filename changed to draft-ietf-pcn-3-in-1-encoding. 239 * Introduction altered to include new template description of 240 PCN. 242 * References updated. 244 * Terminology brought into line with [RFC5670]. 246 * Minor corrections. 248 2. Definitions and Abbreviations 250 2.1. Terminology 252 The terms PCN-domain, PCN-node, PCN-interior-node, PCN-ingress-node, 253 PCN-egress-node, PCN-boundary-node, PCN-traffic, PCN-packets and PCN- 254 marking are used as defined in [RFC5559]. The following additional 255 terms are defined in this document: 257 PCN encoding: mapping of PCN marking states to specific codepoints 258 in the packet header. 260 PCN-compatible Diffserv codepoint: a Diffserv codepoint indicating 261 packets for which the ECN field is used to carry PCN-markings 262 rather than [RFC3168] markings (see Appendix A). 264 Threshold-marked codepoint: a codepoint that indicates packets that 265 have been marked at a PCN-interior-node as a result of an 266 indication from the threshold-metering function [RFC5670]. 267 Abbreviated to ThM. 269 Excess-traffic-marked codepoint: a codepoint that indicates packets 270 that have been marked at a PCN-interior-node as a result of an 271 indication from the excess-traffic-metering function [RFC5670]. 272 Abbreviated to ETM. 274 Not-marked codepoint: a codepoint that indicates PCN-packets but 275 that are not PCN-marked. Abbreviated to NM. 277 not-PCN codepoint: a codepoint that indicates packets that are not 278 PCN-packets. 280 2.2. List of Abbreviations 282 The following abbreviations are used in this document: 284 o AF = Assured Forwarding [RFC2597] 286 o CE = Congestion Experienced [RFC3168] 288 o CS = Class Selector [RFC2474] 290 o DSCP = Diffserv codepoint 292 o ECN = Explicit Congestion Notification [RFC3168] 294 o ECT = ECN Capable Transport [RFC3168] 295 o EF = Expedited Forwarding [RFC3246] 297 o ETM = Excess-traffic-marked 299 o EXP = Experimental 301 o IP = Internet protocol 303 o NM = Not-marked 305 o PCN = Pre-Congestion Notification 307 o ThM = Threshold-marked 309 3. Definition of 3-in-1 PCN Encoding 311 The 3-in-1 PCN encoding scheme allows for two or three PCN-marking 312 states to be encoded within the IP header. The full encoding is 313 shown in Figure 1. 315 +--------+----------------------------------------------------+ 316 | | Codepoint in ECN field of IP header | 317 | DSCP | | 318 | +--------------+-------------+-------------+---------+ 319 | | 00 | 10 | 01 | 11 | 320 +--------+--------------+-------------+-------------+---------+ 321 | DSCP n | Not-PCN | NM | ThM | ETM | 322 +--------+--------------+-------------+-------------+---------+ 324 Figure 1: 3-in-1 PCN Encoding 326 As mentioned above, the 3-in-1 PCN encoding is an extension of the 327 baseline encoding [RFC5696]. Like the baseline encoding it uses a 328 combination of a PCN-compatible DSCP (DSCP n in Figure 1) and the ECN 329 field for the encoding of PCN-marks. Appendix A discusses the choice 330 of suitable DSCPs. The PCN-marks have the following meaning. 332 Not-PCN: indicates a non-PCN-packet, i.e., a packet that is not 333 subject to PCN metering and marking. 335 NM: Not-marked. Indicates a PCN-packet that has not yet been marked 336 by any PCN marker. 338 ThM: Threshold-marked. Indicates a PCN-packet that has been marked 339 by a threshold-marker [RFC5670]. 341 ETM: Excess-traffic-marked. Indicates a PCN-packet that has been 342 marked by an excess-traffic-marker [RFC5670]. 344 4. Requirements for and Applicability of 3-in-1 PCN Encoding 346 4.1. PCN Requirements 348 In accordance with the PCN architecture [RFC5559], PCN-ingress-nodes 349 control packets entering a PCN-domain. Packets belonging to PCN- 350 controlled flows are subject to PCN-metering and -marking, and PCN- 351 ingress-nodes mark them as Not-marked (PCN-colouring). Any node in 352 the PCN-domain may perform PCN-metering and -marking and mark PCN- 353 packets if needed. There are two different metering and marking 354 behaviours: threshold-marking and excess-traffic-marking [RFC5670]. 355 Some edge behaviors require only a single marking behaviour 356 [I-D.ietf-pcn-sm-edge-behaviour], others require both 357 [I-D.ietf-pcn-cl-edge-behaviour]. In the latter case, three PCN 358 marking states are needed: not-marked (NM) to indicate not-marked 359 packets, threshold-marked (ThM) to indicate packets marked by the 360 threshold-marker, and excess-traffic-marked (ETM) to indicate packets 361 marked by the excess-traffic-marker [RFC5670]. Threshold-marking and 362 excess-traffic-marking are configured to start marking packets at 363 different load conditions, so one marking behaviour indicates more 364 severe pre-congestion than the other. Therefore, a fourth PCN 365 marking state indicating that a packet is marked by both markers is 366 not needed. However a fourth codepoint is required to indicate 367 packets that do not use PCN (the not-PCN codepoint). 369 In all current PCN edge behaviors that use two marking behaviours 370 [RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking 371 is configured with a larger reference rate than threshold-marking. 372 We take this as a rule and define excess-traffic-marked as a more 373 severe PCN-mark than threshold-marked. 375 4.2. Requirements Imposed by Tunnelling 377 [RFC6040] defines rules for the encapsulation and decapsulation of 378 ECN markings within IP-in-IP tunnels. The publication of RFC6040 379 removed the tunnelling constraints that existed when the baseline 380 encoding [RFC5696] was written (see section 3.3.2 of 381 [I-D.ietf-pcn-encoding-comparison]). 383 Nonetheless, there is still a problem if there are any legacy (pre- 384 RFC6040) decapsulating tunnel endpoints within a PCN domain. If a 385 PCN node Threshold-marks the outer header of a tunnelled packet with 386 a Not-marked codepoint on the inner header, the legacy decapsulator 387 will revert the Threshold-marking to Not-marked. The rules on 388 applicability in Section 4.3 below are designed to avoid this 389 problem. 391 4.3. Applicability of 3-in-1 PCN Encoding 393 The 3-in-1 encoding is applicable in situations where two marking 394 behaviours are being used in the PCN-domain. The 3-in-1 encoding can 395 also be used with only one marking behaviour, in which case one of 396 the codepoints MUST NOT be used throughout the PCN-domain (see 397 Section 5.2.3). 399 For the full 3-in-1 encoding to apply, any tunnel endpoints (IP-in-IP 400 and IPsec) within the PCN-domain MUST comply with the ECN 401 encapsulation and decapsulation rules set out in [RFC6040] (see 402 Section 4.2). There is one exception to this rule outlined next. 404 It may not be possible to upgrade every pre-RFC6040 tunnel endpoint 405 within a PCN-domain. In such cirsumstances a limited version of the 406 3-in-1 encoding can still be used but only under the following 407 stringent condition. If any pre-RFC6040 tunnel endpoint exists 408 within a PCN-domain then every PCN-node in the PCN-domain MUST be 409 configured so that it never sets the ThM codepoint. The behaviour of 410 PCN-interior nodes in this case is defined in Section 5.2.3.1. In 411 all other situations where legacy tunnel endpoints might be present 412 within the PCN domain, the 3-in-1 encoding is not applicable. 414 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding 416 As mentioned in Section 4.3 above, all PCN-nodes MUST comply with 417 [RFC6040]. 419 5.1. PCN-ingress Node Behaviour 421 PCN-traffic MUST be marked with a PCN-compatible Diffserv codepoint. 422 To conserve DSCPs, Diffserv codepoints SHOULD be chosen that are 423 already defined for use with admission-controlled traffic. 424 Appendix A gives guidance to implementors on suitable DSCPs. 425 Guidelines for mixing traffic types within a PCN-domain are given in 426 [RFC5670]. 428 If a packet arrives at the PCN-ingress-node that shares a PCN- 429 compatible DSCP and is not a PCN-packet, the PCN-ingress MUST mark it 430 as not-PCN. 432 If a PCN-packet arrives at the PCN-ingress-node, the PCN-ingress MUST 433 change the PCN codepoint to Not-marked. 435 If a PCN-packet arrives at the PCN-ingress-node with its ECN field 436 already set to a value other than not-ECT, then appropriate action 437 MUST be taken to meet the requirements of [RFC4774]. The simplest 438 appropriate action is to just drop such packets. However, this is a 439 drastic action that an operator may feel is undesirable. Appendix B 440 provides more information and summarises other alternative actions 441 that might be taken. 443 5.2. PCN-interior Node Behaviour 445 5.2.1. Behaviour Common to all PCN-interior Nodes 447 Interior nodes MUST NOT change not-PCN to any other codepoint. 449 Interior nodes MUST NOT change NM to not-PCN. 451 Interior nodes MUST NOT change ThM to NM or not-PCN. 453 Interior nodes MUST NOT change ETM to any other codepoint. 455 5.2.2. Behaviour of PCN-interior Nodes Using Two PCN-markings 457 If the threshold-meter function indicates a need to mark the packet, 458 the PCN-interior node MUST change NM to ThM. 460 If the excess-traffic-meter function indicates a need to mark the 461 packet: 463 o the PCN-interior node MUST change NM to ETM; 465 o the PCN-interior node MUST change ThM to ETM. 467 If both the threshold meter and the excess-traffic meter indicate the 468 need to mark a packet, the excess traffic marking rules MUST take 469 priority. 471 5.2.3. Behaviour of PCN-interior Nodes Using One PCN-marking 473 Some PCN edge behaviours require only one PCN-marking within the PCN- 474 domain. The Single Marking edge behaviour 475 [I-D.ietf-pcn-sm-edge-behaviour] requires PCN-interior nodes to mark 476 packets using the excess-traffic-meter function [RFC5670]. It is 477 possible that future schemes may require only the threshold-meter 478 function. Observant readers may spot an apparent inconsistency 479 between the two following cases. Appendix D explains the rationale 480 behind this inconsistency. 482 5.2.3.1. Marking using only the Excess-traffic-meter Function 484 The threshold-traffic-meter function SHOULD be disabled and MUST NOT 485 trigger any packet marking. 487 The PCN-interior node SHOULD raise a management alarm if it receives 488 a ThM packet, but the frequency of such alarms SHOULD be limited. 490 If the excess-traffic-meter function indicates a need to mark the 491 packet: 493 o the PCN-interior node MUST change NM to ETM; 495 o the PCN-interior node MUST change ThM to ETM. It SHOULD also 496 raise an alarm as above. 498 5.2.3.2. Marking using only the Threshold-meter Function 500 The excess-traffic-meter function SHOULD be disabled and MUST NOT 501 trigger any packet marking. 503 The PCN-interior node SHOULD raise a management alarm if it receives 504 an ETM packet, but the frequency of such alarms SHOULD be limited. 506 If the threshold-meter function indicates a need to mark the packet: 508 o the PCN-interior node MUST change NM to ThM; 510 o the PCN-interior node MUST NOT change ETM to any other codepoint. 511 It SHOULD raise an alarm as above. 513 5.3. Behaviour of PCN-egress Nodes 515 A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all 516 packets it forwards out of the PCN-domain. 518 The only exception to this is if the PCN-egress-node is certain that 519 revealing other codepoints outside the PCN-domain won't contravene 520 the guidance given in [RFC4774]. For instance, if the PCN-ingress- 521 node has explicitly informed the PCN-egress-node that this flow is 522 ECN-capable, then it might be safe to expose other codepoints. 523 Appendix B gives details of how such schemes might work, but such 524 schemes are currently experimental. 526 If the PCN-domain is configured to use only excess-traffic marking, 527 the PCN-egress node MUST treat ThM as ETM and if only threshold- 528 marking is used it should treat ETM as ThM. However it SHOULD raise 529 a management alarm in either instance since this means there is some 530 misconfiguration in the PCN-domain. 532 6. Backward Compatibility 534 6.1. Backward Compatibility with ECN 536 BCP 124 [RFC4774] gives guidelines for specifying alternative 537 semantics for the ECN field. It sets out a number of factors to be 538 taken into consideration. It also suggests various techniques to 539 allow the co-existence of default ECN and alternative ECN semantics. 540 The encoding specified in this document uses one of those techniques; 541 it defines PCN-compatible Diffserv codepoints as no longer supporting 542 the default ECN semantics. As such, this document is compatible with 543 BCP 124. 545 On its own, the 3-in-1 encoding cannot support both ECN marking end- 546 to-end (e2e) and PCN-marking within a PCN-domain. Appendix B 547 discusses possible ways to do this, e.g. by carrying e2e ECN across a 548 PCN-domain within the inner header of an IP-in-IP tunnel. Although 549 Appendix B recommends various approaches over others, it is merely 550 informative and all such schemes are beyond the normative scope of 551 this document. 553 In any PCN deployment, traffic can only enter the PCN-domain through 554 PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress- 555 nodes ensure that any packets entering the PCN-domain have the ECN 556 field in their outermost IP header set to the appropriate PCN 557 codepoint. PCN-egress-nodes then guarantee that the ECN field of any 558 packet leaving the PCN-domain has appropriate ECN semantics. This 559 prevents unintended leakage of ECN marks into or out of the PCN- 560 domain, and thus reduces backward-compatibility issues. 562 6.2. Backward Compatibility with the Baseline Encoding 564 A PCN node implemented to use the obsoleted baseline encoding could 565 conceivably have been configured so that the Threshold-meter function 566 marked what is now defined as the ETM codepoint in the 3-in-1 567 encoding. However, thre is no known deployment of such an 568 implementation and no reason to believe that such an implementation 569 would ever have been built. Therefore, it seems safe to ignore this 570 issue. 572 7. IANA Considerations 574 This memo includes no request to IANA. 576 Note to RFC Editor: this section may be removed on publication as an 577 RFC. 579 8. Security Considerations 581 PCN-marking only carries a meaning within the confines of a PCN- 582 domain. This encoding document is intended to stand independently of 583 the architecture used to determine how specific packets are 584 authorised to be PCN-marked, which will be described in separate 585 documents on PCN-boundary-node behaviour. 587 This document assumes the PCN-domain to be entirely under the control 588 of a single operator, or a set of operators who trust each other. 589 However, future extensions to PCN might include inter-domain versions 590 where trust cannot be assumed between domains. If such schemes are 591 proposed, they must ensure that they can operate securely despite the 592 lack of trust. However, such considerations are beyond the scope of 593 this document. 595 One potential security concern is the injection of spurious PCN-marks 596 into the PCN-domain. However, these can only enter the domain if a 597 PCN-ingress-node is misconfigured. The precise impact of any such 598 misconfiguration will depend on which of the proposed PCN-boundary- 599 node behaviours is used, but in general spurious marks will lead to 600 admitting fewer flows into the domain or potentially terminating too 601 many flows. In either case, good management should be able to 602 quickly spot the problem since the overall utilisation of the domain 603 will rapidly fall. 605 9. Conclusions 607 The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field 608 to encode PCN-marks. One codepoint allows non-PCN traffic to be 609 carried with the same PCN-compatible DSCP and three other codepoints 610 support three PCN marking states with different levels of severity. 611 In general, the use of this PCN encoding scheme presupposes that any 612 tunnel endpoints within the PCN-domain comply with [RFC6040]. 614 10. Acknowledgements 616 Many thanks to Phil Eardley for providing extensive feedback, 617 critcism and advice. Thanks also to Teco Boot, Kwok Ho Chan, 618 Ruediger Geib, Georgios Karaginannis and everyone else who has 619 commented on the document. 621 11. Comments Solicited 623 To be removed by RFC Editor: Comments and questions are encouraged 624 and very welcome. They can be addressed to the IETF Congestion and 625 Pre-Congestion working group mailing list , and/or to 626 the authors. 628 12. References 630 12.1. Normative References 632 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 633 Requirement Levels", BCP 14, RFC 2119, March 1997. 635 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 636 "Definition of the Differentiated Services Field (DS 637 Field) in the IPv4 and IPv6 Headers", RFC 2474, 638 December 1998. 640 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 641 of Explicit Congestion Notification (ECN) to IP", 642 RFC 3168, September 2001. 644 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 645 Architecture", RFC 5559, June 2009. 647 [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- 648 Nodes", RFC 5670, November 2009. 650 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 651 Notification", RFC 6040, November 2010. 653 12.2. Informative References 655 [I-D.ietf-pcn-cl-edge-behaviour] 656 Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. 657 Taylor, "PCN Boundary Node Behaviour for the Controlled 658 Load (CL) Mode of Operation", 659 draft-ietf-pcn-cl-edge-behaviour-09 (work in progress), 660 June 2011. 662 [I-D.ietf-pcn-encoding-comparison] 663 Karagiannis, G., Chan, K., Moncaster, T., Menth, M., 664 Eardley, P., and B. Briscoe, "Overview of Pre-Congestion 665 Notification Encoding", 666 draft-ietf-pcn-encoding-comparison-06 (work in progress), 667 June 2011. 669 [I-D.ietf-pcn-sm-edge-behaviour] 670 Charny, A., Karagiannis, G., Menth, M., and T. Taylor, 671 "PCN Boundary Node Behaviour for the Single Marking (SM) 672 Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-06 673 (work in progress), June 2011. 675 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 676 "Assured Forwarding PHB Group", RFC 2597, June 1999. 678 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 679 J., Courtney, W., Davari, S., Firoiu, V., and D. 680 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 681 Behavior)", RFC 3246, March 2002. 683 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 684 Congestion Notification (ECN) Signaling with Nonces", 685 RFC 3540, June 2003. 687 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 688 Guidelines for DiffServ Service Classes", RFC 4594, 689 August 2006. 691 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 692 Explicit Congestion Notification (ECN) Field", BCP 124, 693 RFC 4774, November 2006. 695 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 696 DiffServ Service Classes", RFC 5127, February 2008. 698 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 699 Marking in MPLS", RFC 5129, January 2008. 701 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 702 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 703 Class" Field", RFC 5462, February 2009. 705 [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline 706 Encoding and Transport of Pre-Congestion Information", 707 RFC 5696, November 2009. 709 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 710 Services Code Point (DSCP) for Capacity-Admitted Traffic", 711 RFC 5865, May 2010. 713 Appendix A. Choice of Suitable DSCPs 715 This appendix is informative, not normative. 717 The PCN working group chose not to define a single DSCP for use with 718 PCN for several reasons. Firstly, the PCN mechanism is applicable to 719 a variety of different traffic classes. Secondly, Standards Track 720 DSCPs are in increasingly short supply. Thirdly, PCN is not a 721 scheduling behaviour -- rather, it should be seen as being a marking 722 behaviour similar to ECN but intended for inelastic traffic. The 723 choice of which DSCP is most suitable for a given PCN-domain is 724 dependent on the nature of the traffic entering that domain and the 725 link rates of all the links making up that domain. In PCN-domains 726 with sufficient aggregation, the appropriate DSCPs would currently be 727 those for the Real-Time Treatment Aggregate [RFC5127]. The PCN 728 working group suggests using admission control for the following 729 service classes (defined in [RFC4594]): 731 o Telephony (EF) 733 o Real-time interactive (CS4) 735 o Broadcast Video (CS3) 737 o Multimedia Conferencing (AF4) 739 CS5 is excluded from this list since PCN is not expected to be 740 applied to signalling traffic. PCN can also be applied to the VOICE- 741 ADMIT codepoint defined in [RFC5865]. 743 PCN-marking is intended to provide a scalable admission-control 744 mechanism for traffic with a high degree of statistical multiplexing. 745 PCN-marking would therefore be appropriate to apply to traffic in the 746 above classes, but only within a PCN-domain containing sufficiently 747 aggregated traffic. In such cases, the above service classes may 748 well all be subject to a single forwarding treatment (treatment 749 aggregate [RFC5127]). However, this does not imply all such IP 750 traffic would necessarily be identified by one DSCP -- each service 751 class might keep a distinct DSCP within the highly aggregated region 752 [RFC5127]. 754 Additional service classes may be defined for which admission control 755 is appropriate, whether through some future standards action or 756 through local use by certain operators, e.g., the Multimedia 757 Streaming service class (AF3). This document does not preclude the 758 use of PCN in more cases than those listed above. 760 Note: The above discussion is informative not normative, as operators 761 are ultimately free to decide whether to use admission control for 762 certain service classes and whether to use PCN as their mechanism of 763 choice. 765 Appendix B. Co-existence of ECN and PCN 767 This appendix is informative, not normative. 769 The PCN encoding described in this document re-uses the bits of the 770 ECN field in the IP header. Consequently, this disables ECN within 771 the PCN domain. Appendix B of [RFC5696] (obsoleted) included advice 772 on handling ECN traffic within a PCN-domain. This appendix 773 reiterates and clarifies that advice. 775 For the purposes of this appendix we define two forms of traffic that 776 might arrive at a PCN-ingress node. These are Admission-controlled 777 traffic and Non-admission-controlled traffic. 779 Admission-controlled traffic will be remarked to a PCN-compatible 780 DSCP by the PCN-ingress node. Two mechanisms can be used to identify 781 such traffic: 783 a. flow signalling associates a filterspec with a need for admission 784 control (e.g. through RSVP or some equivalent message, e.g. from 785 a SIP server to the ingress), and the PCN-ingress remarks traffic 786 matching that filterspec to a PCN-compatible DSCP, as its chosen 787 admission control mechanism. 789 b. Traffic arrives with a DSCP that implies it requires admission 790 control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time, 791 Broadcast TV when used for video on demand, and Multimedia 792 Conferencing [RFC4594][RFC5865]. 794 All other traffic can be thought of as Non-admission-controlled (and 795 therefore outside the scope of PCN). However such traffic may still 796 need to share the same DSCP as the Admission-controlled traffic. 797 This may be due to policy (for instance if it is high priority voice 798 traffic), or may be because there is a shortage of local DSCPs. 800 ECN [RFC3168] is an end-to-end congestion notification mechanism. As 801 such it is possible that some traffic entering the PCN-domain may 802 also be ECN capable. 804 Unless specified otherwise, for any of the cases in the list below, 805 an IP-in-IP tunnel can be used to preserve ECN markings across the 806 PCN domain. However the tunnelling action should be applied wholly 807 outside the PCN-domain as illustrated in the following figure: 809 , . . . . . PCN-domain . . . . . . 810 . ,--------. ,--------. . 811 . _| PCN- |___________________| PCN- |_ . 812 . / | ingress | | egress | \ . 813 .| '---------' '--------' |. 814 | . . . . . . . . . . . . . . .| 815 ,--------. ,--------. 816 _____| Tunnel | | Tunnel |____ 817 | Ingress | - - ECN preserved inside tunnel - - | Egress | 818 '---------' '--------' 820 Figure 2: Separation of tunneling and PCN actions 822 There are four cases for how e2e ECN traffic may wish to be treated 823 while crossing a PCN domain: 825 ECN capable traffic that does not require admission control and does 826 not carry a DSCP that the PCN-ingress is using for PCN-capable 827 traffic. This requires no action. 829 ECN capable traffic that does not require admission control but 830 carries a DSCP that the PCN-ingress is using for PCN-capable 831 traffic. There are two options. 833 * The ingress maps the DSCP to a local DSCP with the same 834 scheduling PHB as the original DSCP, and the egress re-maps it 835 to the original PCN-compatible DSCP. 837 * The ingress tunnels the traffic, setting not-PCN in the outer 838 header; note that this turns off ECN for this traffic within 839 the PCN domain. 841 The first option is recommended unless the operator is short of 842 local DSCPs. 844 ECN-capable Admission-controlled traffic: There are two options. 846 * The PCN-ingress places this traffic in a tunnel with a PCN- 847 compatible DSCP in the outer header. The PCN-egress zeroes the 848 ECN-field before decapsulation. 850 * The PCN-ingress drops CE-marked packets and the PCN-egress 851 zeros the ECN field of all PCN packets. 853 The second option is emphatically not recommended, unless perhaps 854 as a last resort if tunnelling is not possible for some 855 insurmountable reason. 857 ECN-capable Admission-controlled traffic where the e2e transport 858 somehow indicates that it wants to see PCN marks: NOTE this is 859 currently tentative only. 861 Schemes have been suggested where PCN marks may be leaked out of 862 the PCN-domain and used by the end hosts to modify realtime data 863 rates. Currently all such schemes require further study and the 864 following is for guidance only. 866 The PCN-ingress needs to tunnel the traffic, taking care to comply 867 with [RFC6040]. In this case the PCN-egress should not zero the 868 ECN field, and then the [RFC6040] tunnel egress will preserve any 869 PCN-marking. Note that a PCN interior node may turn ECT(0) into 870 ECT(1), which would not be compatible with the (currently 871 experimental) ECN nonce [RFC3540]. 873 Appendix C. Example Mapping between Encoding of PCN-Marks in IP and in 874 MPLS Shim Headers 876 This appendix is informative not normative. 878 The 6 bits of the DS field in the IP header provide for 64 879 codepoints. When encapsulating IP traffic in MPLS, it is useful to 880 make the DS field information accessible in the MPLS header. 881 However, the MPLS shim header has only a 3-bit traffic class (TC) 882 field [RFC5462] providing for 8 codepoints. The operator has the 883 freedom to define a site-local mapping of a subset of the 64 884 codepoints of the DS field to the 8 codepoints in the TC field. 886 [RFC5129] describes how ECN markings in the IP header can also be 887 mapped to codepoints in the MPLS TC field. Appendix A of [RFC5129] 888 gives an informative description of how to support PCN in MPLS by 889 extending the way MPLS supports ECN. But [RFC5129] was written while 890 PCN specifications were in early draft stages. The following 891 provides a clearer example of a mapping between PCN in IP and in MPLS 892 using the PCN terminology and concepts that have since been 893 specified. 895 To support PCN in a MPLS domain, codepoints for all used PCN-marks 896 need to be provided in the TC field. That means, when e.g. only 897 excess-traffic-marking is used for PCN purposes, the operator needs 898 to define a site-local mapping to codepoints in the MPLS TC field for 899 IP headers with: 901 o DSCP n and ECT(0) 903 o DSCP n and CE 905 If both excess-traffic-marking and threshold-marking are used, the 906 operator needs to define a site-local mapping to codepoints in the 907 MPLS TC field for IP headers with all three of the 3-in-1 codepoints: 909 o DSCP n and ECT(0) 911 o DSCP n and ECT(1) 913 o DSCP n and CE 915 In either case, if the operator wishes to support the same Diffserv 916 PHB but without PCN marking, it will also be necessary to define a 917 site-local mapping to an MPLS TC codepoint for IP headers marked 918 with: 920 o DSCP n and Not-ECT 922 Appendix D. Rationale for different behaviours for single marking 923 schemes 925 Readers may notice an apparent discrepancy between the two single 926 marking behaviours in Section 5.2.3.1 and Section 5.2.3.2. For the 927 excess-traffic only marking an unexpected ThM marked packet is 928 remarked as ETM. For the threshold only marking, an unexpected ETM 929 marked packet is simply ignored (apart from an optional management 930 alarm). 932 There are two reasons for having these seemingly contradictory 933 requirements. Firstly these behaviours conform with the expected 934 behaviour where both metering functions are being used for marking-- 935 ETM is always a more severe marking than ThM and so should never be 936 re-marked. Secondly the threshold-metering behaviour in [RFC5670] 937 uses the current marking state of the arriving packet to determine 938 what action to take. Consequently, in the ETM only marking it would 939 be potentially unsafe to allow ThM packets to propagate forward in 940 the network as they may adversely affect the threshold-metering 941 function. 943 Authors' Addresses 945 Bob Briscoe 946 BT 947 B54/77, Adastral Park 948 Martlesham Heath 949 Ipswich IP5 3RE 950 UK 952 Phone: +44 1473 645196 953 Email: bob.briscoe@bt.com 954 URI: http://bobbriscoe.net/ 956 Toby Moncaster 957 Moncaster Internet Consulting 958 Dukes 959 Layer Marney 960 Colchester CO5 9UZ 961 UK 963 Phone: +44 7764 185416 964 Email: toby@moncaster.com 965 URI: http://www.moncaster.com/ 967 Michael Menth 968 University of Tuebingen 969 Sand 13 970 Tuebingen 72076 971 Germany 973 Phone: +49 7071 2970505 974 Email: menth@informatik.uni-tuebingen.de