idnits 2.17.1 draft-ietf-pcn-3-in-1-encoding-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (April 17, 2012) is 4391 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-14 -- Obsolete informational reference (is this intentional?): RFC 5696 (Obsoleted by RFC 6660) 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 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: October 19, 2012 University of Tuebingen 8 April 17, 2012 10 Encoding 3 PCN-States in the IP header using a single DSCP 11 draft-ietf-pcn-3-in-1-encoding-11 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. The PCN wire protocol for non-IP 27 protocol headers will need to be defined elsewhere. Nonetheless, 28 this document clarifies the PCN encoding for MPLS in an informational 29 Appendix. The encoding for IP provides for up to three different PCN 30 marking states using a single DSCP: Not-marked (NM), Threshold-marked 31 (ThM) and Excess-traffic-marked (ETM). Hence, it is called the 32 3-in-1 PCN encoding. This document obsoletes RFC5696. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 19, 2012. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 69 1.2. Changes in This Version (to be removed by RFC Editor) . . 5 70 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 8 71 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 72 2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 9 73 3. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 9 74 4. Requirements for and Applicability of 3-in-1 PCN Encoding . . 10 75 4.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 10 76 4.2. Requirements Imposed by Tunnelling . . . . . . . . . . . . 11 77 4.3. Applicable Environments for the 3-in-1 PCN Encoding . . . 12 78 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN 79 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 12 81 5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 15 82 5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 15 83 5.2.2. Behaviour of PCN-interior Nodes Using Two 84 PCN-markings . . . . . . . . . . . . . . . . . . . . . 15 85 5.2.3. Behaviour of PCN-interior Nodes Using One 86 PCN-marking . . . . . . . . . . . . . . . . . . . . . 16 87 5.3. PCN-egress Node Behaviour . . . . . . . . . . . . . . . . 17 88 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 17 89 6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 17 90 6.2. Backward Compatibility with the RFC5696 Encoding . . . . . 18 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 93 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 95 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 19 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 97 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 98 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 99 Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 22 100 Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 23 101 Appendix C. Example Mapping between Encoding of PCN-Marks in 102 IP and in MPLS Shim Headers . . . . . . . . . . . . . 26 103 Appendix D. Rationale for Difference Between the Schemes 104 using One PCN-Marking . . . . . . . . . . . . . . . . 27 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 encoding defined in [RFC5696] described how two PCN marking 134 states (Not-marked and PCN-Marked) could be encoded into the IP 135 header using a single Diffserv codepoint. It defined 01 as an 136 experimental codepoint (EXP), along with guidelines for its use. Two 137 PCN marking states are sufficient for the Single Marking edge 138 behaviour [I-D.ietf-pcn-sm-edge-behaviour]. However, PCN-domains 139 utilising the controlled load edge behaviour 140 [I-D.ietf-pcn-cl-edge-behaviour] require three PCN marking states. 141 This document extends the RFC5696 encoding by redefining the 142 experimental codepoint as a third PCN marking state in the IP header, 143 but still using a single Diffserv codepoint. This encoding scheme is 144 therefore called the "3-in-1 PCN encoding". It obsoletes the 145 [RFC5696] encoding, which provides only a sub-set of the same 146 capabilities. 148 The full version of the 3-in-1 encoding requires any tunnel endpoint 149 within the PCN-domain to support the normal tunnelling rules defined 150 in [RFC6040]. There is one limited exception to this constraint 151 where the PCN-domain only uses the excess-traffic-marking behaviour 152 and 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-10 to -11: 172 * Pointed out that any DSCP re-mapping must precede PCN-ingress 173 processing; 175 * Ingress behaviour for ECN-capable PCN-packets: allowed any PCN- 176 capable encapsulation, not just IP-in-IP tunnelling. Added 177 cautionary note about MPLS PHP; 179 * PCN-policing at ingress: 181 + Clarified what per-flow policing entails; 183 + Clarified that a DSCP of zero is '000000'; 185 + For policed packets, added SHOULD log, MAY alarm; 187 * Updated refs and acks. 189 From draft-ietf-pcn-3-in-1-encoding-09 to -10: 191 * Added cautionary management advice to S6.2 (backwards 192 compatibility with RFC5696) 194 * Removed "emphatically" from normative "NOT RECOMMENDED" text. 196 * Minor editoral changes. 198 From draft-ietf-pcn-3-in-1-encoding-08 to -09: 200 * Added note about fail-safe to protect other traffic in the 201 event of tunnel misconfiguration. 203 * Changed section heading to be about applicability of 204 environments to the encoding, rather than the encoding to the 205 environments. 207 * Completely re-wrote PCN-ingress Node Behaviour section. 209 * Changed PCN interior node to PCN-node where the term was 210 intended to include all PCN-nodes. 212 * Clarified status of ECN/PCN co-existence appendix. Removed 213 inconsistent assertion in this appendix that an admission- 214 control DSCP alone can indicate that arriving traffic is PCN- 215 traffic. 217 * A few clarifying editorial amendments and updated refs. 219 From draft-ietf-pcn-3-in-1-encoding-07 to -08: Editorial corrections 220 and clarifications. 222 From draft-ietf-pcn-3-in-1-encoding-06 to -07: 224 * Clarified that each operator not the IETF chooses which DSCP(s) 225 are PCN-compatible, and made it unambiguous that only PCN-nodes 226 recognise that PCN-compatible DSCPs enable the 3-in-1 encoding. 228 * Removed statements about the PCN working group, given RFCs are 229 meant to survive beyond the life of a w-g. 231 * Corrected the final para of "Rationale for Different Behaviours 232 in Schemes with Only One Marking" 234 From draft-ietf-pcn-3-in-1-encoding-05 to -06: 236 * Draft re-written to obsolete baseline encoding [RFC5696]. 238 * New section defining utilising this encoding for only one PCN- 239 Marking. Added an appendix explaining an apparent 240 inconsistency within this section. 242 * Moved (and updated) informative appendixes from [RFC5696] to 243 this document. Original Appendix C was omitted as it is now 244 redundant. 246 * Significant re-structuring of document. 248 From draft-ietf-pcn-3-in-1-encoding-04 to -05: 250 * Draft moved to standards track as per working group 251 discussions. 253 * Added Appendix B discussing ECN handling in the PCN-domain. 255 * Clarified that this document modifies [RFC5696]. 257 From draft-ietf-pcn-3-in-1-encoding-03 to -04: 259 * Updated document to reflect RFC6040. 261 * Re-wrote introduction. 263 * Re-wrote section on applicability. 265 * Re-wrote section on choosing encoding scheme. 267 * Updated author details. 269 From draft-ietf-pcn-3-in-1-encoding-02 to -03: 271 * Corrected mistakes in introduction and improved overall 272 readability. 274 * Added new terminology. 276 * Rewrote a good part of Section 4 and 5 to achieve more clarity. 278 * Added appendix explaining when to use which encoding scheme and 279 how to encode them in MPLS shim headers. 281 * Added new co-author. 283 From draft-ietf-pcn-3-in-1-encoding-01 to -02: 285 * Corrected mistake in introduction, which wrongly stated that 286 the threshold-traffic rate is higher than the excess-traffic 287 rate. Other minor corrections. 289 * Updated acks & refs. 291 From draft-ietf-pcn-3-in-1-encoding-00 to -01: 293 * Altered the wording to make sense if 294 draft-ietf-tsvwg-ecn-tunnel moves to proposed standard. 296 * References updated 298 From draft-briscoe-pcn-3-in-1-encoding-00 to 299 draft-ietf-pcn-3-in-1-encoding-00: 301 * Filename changed to draft-ietf-pcn-3-in-1-encoding. 303 * Introduction altered to include new template description of 304 PCN. 306 * References updated. 308 * Terminology brought into line with [RFC5670]. 310 * Minor corrections. 312 2. Definitions and Abbreviations 314 2.1. Terminology 316 The terms PCN-domain, PCN-node, PCN-interior-node, PCN-ingress-node, 317 PCN-egress-node, PCN-boundary-node, PCN-traffic, PCN-packets and PCN- 318 marking are used as defined in [RFC5559]. The following additional 319 terms are defined in this document: 321 PCN encoding: mapping of PCN marking states to specific codepoints 322 in the packet header. 324 PCN-compatible Diffserv codepoint: a Diffserv codepoint indicating 325 packets for which the ECN field carries PCN-markings rather than 326 [RFC3168] markings. Note that an operator configures PCN-nodes to 327 recognise PCN-compatible DSCPs, whereas the same DSCP has no PCN- 328 specific meaning to a node outside the PCN domain. 330 Threshold-marked codepoint: a codepoint that indicates a packet has 331 been threshold-marked; that is a packet that has been marked at a 332 PCN-interior-node as a result of an indication from the threshold- 333 metering function [RFC5670]. Abbreviated to ThM. 335 Excess-traffic-marked codepoint: a codepoint that indicates packets 336 that have been marked at a PCN-interior-node as a result of an 337 indication from the excess-traffic-metering function [RFC5670]. 338 Abbreviated to ETM. 340 Not-marked codepoint: a codepoint that indicates PCN-packets that 341 are not PCN-marked. Abbreviated to NM. 343 Not-PCN codepoint: a codepoint that indicates packets that are not 344 PCN-packets. 346 2.2. List of Abbreviations 348 The following abbreviations are used in this document: 350 o AF = Assured Forwarding [RFC2597] 352 o CE = Congestion Experienced [RFC3168] 354 o CS = Class Selector [RFC2474] 356 o DSCP = Diffserv codepoint 358 o e2e = end-to-end 360 o ECN = Explicit Congestion Notification [RFC3168] 362 o ECT = ECN Capable Transport [RFC3168] 364 o EF = Expedited Forwarding [RFC3246] 366 o ETM = Excess-traffic-marked 368 o EXP = Experimental 370 o NM = Not-marked 372 o PCN = Pre-Congestion Notification 374 o PHB = Per-hop behaviour [RFC2474] 376 o ThM = Threshold-marked 378 3. Definition of 3-in-1 PCN Encoding 380 The 3-in-1 PCN encoding scheme supports networks that need three PCN- 381 marking states to be encoded within the IP header, as well as those 382 that need only two. The full encoding is shown in Figure 1. 384 +--------+----------------------------------------------------+ 385 | | Codepoint in ECN field of IP header | 386 | DSCP | | 387 | +--------------+-------------+-------------+---------+ 388 | | 00 | 10 | 01 | 11 | 389 +--------+--------------+-------------+-------------+---------+ 390 | DSCP n | Not-PCN | NM | ThM | ETM | 391 +--------+--------------+-------------+-------------+---------+ 393 Figure 1: 3-in-1 PCN Encoding 395 A PCN-node will be configured to recognise certain DSCPs as PCN- 396 compatible. Appendix A discusses the choice of suitable DSCPs. In 397 Figure 1 'DSCP n' indicates such a PCN-compatible DSCP. In the PCN- 398 domain, any packet carrying a PCN-compatible DSCP and with the ECN- 399 field anything other than 00 (Not-PCN) is a PCN-packet as defined in 400 [RFC5559]. 402 PCN-nodes MUST interpret the ECN field of a PCN-packet using the 403 3-in-1 PCN encoding, rather than [RFC3168]. This does not change the 404 behaviour for any packet with a DSCP that is not PCN-compatible, or 405 for any node outside a PCN-domain. In all such cases the 3-in-1 406 encoding is not applicable and so by default the node will interpret 407 the ECN field using [RFC3168]. 409 When using the 3-in-1 encoding, the codepoints of the ECN field have 410 the following meanings: 412 Not-PCN: indicates a non-PCN-packet, i.e., a packet that uses a PCN- 413 compatible DSCP but is not subject to PCN metering and marking. 415 NM: Not-marked. Indicates a PCN-packet that has not yet been marked 416 by any PCN marker. 418 ThM: Threshold-marked. Indicates a PCN-packet that has been marked 419 by a threshold-marker [RFC5670]. 421 ETM: Excess-traffic-marked. Indicates a PCN-packet that has been 422 marked by an excess-traffic-marker [RFC5670]. 424 4. Requirements for and Applicability of 3-in-1 PCN Encoding 426 4.1. PCN Requirements 428 In accordance with the PCN architecture [RFC5559], PCN-ingress-nodes 429 control packets entering a PCN-domain. Packets belonging to PCN- 430 controlled flows are subject to PCN-metering and -marking, and PCN- 431 ingress-nodes mark them as Not-marked (PCN-colouring). All nodes in 432 the PCN-domain perform PCN-metering and PCN-mark PCN-packets if 433 needed. There are two different metering and marking behaviours: 434 threshold-marking and excess-traffic-marking [RFC5670]. Some edge 435 behaviours require only a single marking behaviour 436 [I-D.ietf-pcn-sm-edge-behaviour], others require both 437 [I-D.ietf-pcn-cl-edge-behaviour]. In the latter case, three PCN 438 marking states are needed: Not-marked (NM) to indicate not-marked 439 packets, Threshold-marked (ThM) to indicate packets marked by the 440 threshold-marker, and Excess-traffic-marked (ETM) to indicate packets 441 marked by the excess-traffic-marker [RFC5670]. Threshold-marking and 442 excess-traffic-marking are configured to start marking packets at 443 different load conditions, so one marking behaviour indicates more 444 severe pre-congestion than the other. Therefore, a fourth PCN 445 marking state indicating that a packet is marked by both markers is 446 not needed. However a fourth codepoint is required to indicate 447 packets that use a PCN-compatible DSCP but do not use PCN-marking 448 (the Not-PCN codepoint). 450 In all current PCN edge behaviours that use two marking behaviours 451 [RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking 452 is configured with a larger reference rate than threshold-marking. 453 We take this as a rule and define excess-traffic-marked as a more 454 severe PCN-mark than Threshold-marked. 456 4.2. Requirements Imposed by Tunnelling 458 [RFC6040] defines rules for the encapsulation and decapsulation of 459 ECN markings within IP-in-IP tunnels. The publication of RFC6040 460 removed the tunnelling constraints that existed when the encoding of 461 [RFC5696] was written (see Section 3.3.2 of 462 [I-D.ietf-pcn-encoding-comparison]). 464 Nonetheless, there is still a problem if there are any legacy (pre- 465 RFC6040) decapsulating tunnel endpoints within a PCN domain. If a 466 PCN-node Threshold-marks the outer header of a tunnelled packet that 467 has a Not-marked codepoint on the inner header, a legacy decapsulator 468 will forward the packet as Not-marked, losing the Threshold-marking. 469 The rules on applicability in Section 4.3 below are designed to avoid 470 this problem. 472 Even if an operator accidentally breaks these applicability rules, 473 the order of severity of the 3-in-1 codepoints was chosen to protect 474 other PCN or non-PCN traffic. Although legacy pre-RFC6040 tunnels 475 did not propagate '01', all tunnels pre-RFC6040 and post-RFC6040 have 476 always propagated '11' correctly. Therefore '11' was chosen to 477 signal the most severe pre-congestion (ETM), so it would act as a 478 reliable fail-safe even if an overlooked legacy tunnel was 479 suppressing 01 (ThM) signals. 481 4.3. Applicable Environments for the 3-in-1 PCN Encoding 483 The 3-in-1 encoding is applicable in situations where two marking 484 behaviours are being used in the PCN-domain. The 3-in-1 encoding can 485 also be used with only one marking behaviour, in which case one of 486 the codepoints MUST NOT be used anywhere in the PCN-domain (see 487 Section 5.2.3). 489 With one exception (see next paragraph), any tunnel endpoints 490 (IP-in-IP and IPsec) within the PCN-domain MUST comply with the ECN 491 encapsulation and decapsulation rules set out in [RFC6040] (see 492 Section 4.2). 494 Operators may not be able to upgrade every pre-RFC6040 tunnel 495 endpoint within a PCN-domain. In such circumstances a limited 496 version of the 3-in-1 encoding can still be used but only under the 497 following stringent condition. If any pre-RFC6040 tunnel 498 decapsulator exists within a PCN-domain then every PCN-node in the 499 PCN-domain MUST be configured so that it never sets the ThM 500 codepoint. PCN-interior-nodes in this case MUST solely use the 501 Excess-traffic-marking function, as defined in Section 5.2.3.1. In 502 all other situations where legacy tunnel decapsulators might be 503 present within the PCN domain, the 3-in-1 encoding is not applicable. 505 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding 507 Any tunnel endpoint implementation on a PCN-node MUST comply with 508 [RFC6040]. Since PCN is a new capability, this is considered a 509 reasonable requirement. 511 5.1. PCN-ingress Node Behaviour 513 If packets arrive from another Diffserv domain, any re-mapping of 514 Diffserv codepoints MUST happen before PCN-ingress processing. 516 At each logical ingress link into a PCN domain, each PCN-ingress node 517 will apply the four functions described in Section 4.2 of [RFC5559] 518 to arriving packets. These functions are applied in the following 519 order: PCN-classify, PCN-police, PCN-colour, PCN-rate-meter. This 520 section describes these four steps, but only the aspects relevant to 521 packet encoding: 523 1. PCN-classification: The PCN-ingress-node determines whether each 524 packet matches the filter spec of an admitted flow. Packets that 525 match are defined as PCN-packets. 527 1b. Extra step if ECN and PCN co-exist: If a packet classified as a 528 PCN-packet arrives with the ECN field already set to a value other 529 than Not-ECT (i.e. it is from an ECN-capable transport) then to 530 comply with BCP 124 [RFC4774] it MUST pass through one of the 531 following preparatory steps before the PCN-policing and PCN- 532 colouring steps. The choice between these four actions depends on 533 local policy: 535 * Encapsulate ECN-capable PCN-packets across the PCN-domain: 537 + either within another IP header using an RFC6040 tunnel; 539 + or within a lower layer protocol capable of being PCN 540 marked, such as MPLS (see Appendix C). 542 Encapsulation using either of these methods is the RECOMMENDED 543 policy for ECN-capable PCN-packets, and implementations SHOULD 544 use IP-in-IP tunnelling as the default. 546 If encapsulation is used, it MUST precede PCN-policing and PCN- 547 colouring so that the encapsulator and decapsulator are 548 logically outside the PCN domain (see Appendix B and 549 specifically Figure 2). 551 If MPLS encapsulation is used, note that penultimate hop 552 popping [RFC3031] is incompatible with PCN, unless the 553 penultimate hop applies the PCN-egress node behaviour before it 554 pops the PCN-capable MPLS label. 556 * If some form of encapsulation is not possible, the PCN-ingress- 557 node can allow through ECN-capable packets without 558 encapsulation, but it MUST drop CE-marked packets at this 559 stage. Failure to drop CE would risk congestion collapse, 560 because without encapsulation there is no mechanism to 561 propagate the CE markings across the PCN-domain (see 562 Appendix B). 564 This policy is NOT RECOMMENDED because there is no tunnel to 565 protect the e2e ECN capability, which is otherwise disabled 566 when the PCN-egress-node zeroes the ECN field. 568 * Drop the packet. 570 This policy is also NOT RECOMMENDED, because it precludes the 571 possibility that e2e ECN can co-exist with PCN as a means of 572 controlling congestion. 574 * Any other action that complies with [RFC4774] (see Appendix B 575 for an example). 577 Appendix B provides more information about the co-existence of PCN 578 and ECN. 580 2. PCN-Policing: The PCN-policing function only allows appropriate 581 packets into the PCN behaviour aggregate. Per-flow policing 582 actions may be required to block rejected flows and to rate-police 583 accepted flows, but these are specified in the relevant edge- 584 behaviour document, e.g. [I-D.ietf-pcn-sm-edge-behaviour], 585 [I-D.ietf-pcn-cl-edge-behaviour]. 587 Here we only specify packet-level PCN-policing, which prevents 588 packets that are not PCN-packets from being forwarded into the 589 PCN-domain if PCN-interior-nodes would otherwise mistake them for 590 PCN-packets. A non-PCN-packet will be confused with a PCN-packet 591 if on arrival it meets all three of the following conditions: 593 a) it is not classified as a PCN-packet 595 b) it already carries a PCN-compatible DSCP 597 c) its ECN field carries a codepoint other than Not-ECT. 599 The PCN-ingress-node MUST police packets that meet all three 600 conditions (a-c) by subjecting them to one of the following 601 treatments: 603 * re-mark the DSCP to a DSCP that is not PCN-compatible; 605 * tunnel the packet to the PCN-egress with a DSCP in the outer 606 header that is not PCN-compatible; 608 * drop the packet (NOT RECOMMENDED--see below). 610 The choice between these actions depends on local policy. In the 611 absence of any operator-specific configuration for this case, by 612 default an implementation SHOULD re-mark the DSCP to zero 613 (000000). 615 Whichever policing action is chosen, the PCN-ingress-node SHOULD 616 log the event and MAY also raise an alarm. Alarms SHOULD be rate- 617 limited so that the anomalous packets will not amplify into a 618 flood of alarm messages. 620 Rationale: Traffic that meets all three of the above conditions 621 (a-c) is not PCN-traffic, therefore ideally a PCN-ingress ought 622 not to interfere with it, but it has to do something to avoid 623 ambiguous packet markings. Clearing the ECN field is not an 624 appropriate policing action, because a network node ought not to 625 interfere with an e2e signal. Even if such packets seem like an 626 attack, drop would be overkill, because such an attack can be 627 neutralised by just re-marking the DSCP. And DSCP re-marking in 628 the network is legitimate, because the DSCP is not considered an 629 e2e signal. 631 3. PCN-colouring: If a packet has been classified as a PCN-packet, 632 once it has been policed, the PCN-ingress-node: 634 * MUST set a PCN-compatible Diffserv codepoint on all PCN- 635 packets. To conserve DSCPs, Diffserv codepoints SHOULD be 636 chosen that are already defined for use with admission- 637 controlled traffic. Appendix A gives guidance to implementors 638 on suitable DSCPs. 640 * MUST set the PCN codepoint of all PCN-packets to Not-marked 641 (NM). 643 4. PCN rate-metering: This fourth step may be necessary depending on 644 the edge-behaviour in force. It is listed for completeness, but 645 it is not relevant to this encoding document. 647 5.2. PCN-interior Node Behaviour 649 5.2.1. Behaviour Common to all PCN-interior Nodes 651 Interior nodes MUST NOT change Not-PCN to any other codepoint. 653 Interior nodes MUST NOT change NM to Not-PCN. 655 Interior nodes MUST NOT change ThM to NM or Not-PCN. 657 Interior nodes MUST NOT change ETM to any other codepoint. 659 5.2.2. Behaviour of PCN-interior Nodes Using Two PCN-markings 661 If the threshold-meter function indicates a need to mark a packet, 662 the PCN-interior-node MUST change NM to ThM. 664 If the excess-traffic-meter function indicates a need to mark a 665 packet: 667 o the PCN-interior-node MUST change NM to ETM; 668 o the PCN-interior-node MUST change ThM to ETM. 670 If both the threshold meter and the excess-traffic meter indicate the 671 need to mark a packet, the Excess-traffic-marking rules MUST take 672 precedence. 674 5.2.3. Behaviour of PCN-interior Nodes Using One PCN-marking 676 Some PCN edge behaviours require only one PCN-marking within the PCN- 677 domain. The Single Marking edge behaviour 678 [I-D.ietf-pcn-sm-edge-behaviour] requires PCN-interior-nodes to mark 679 packets using the excess-traffic-meter function [RFC5670]. It is 680 possible that future schemes may require only the threshold-meter 681 function. Appendix D explains the rationale for the behaviours 682 defined in this section. 684 5.2.3.1. Marking Using only the Excess-traffic-meter Function 686 The threshold-traffic-meter function SHOULD be disabled and MUST NOT 687 trigger any packet marking. 689 The PCN-interior-node SHOULD raise a management alarm if it receives 690 a ThM packet, but the frequency of such alarms SHOULD be limited. 692 If the excess-traffic-meter function indicates a need to mark the 693 packet: 695 o the PCN-interior-node MUST change NM to ETM; 697 o the PCN-interior-node MUST change ThM to ETM. It SHOULD also 698 raise an alarm as above. 700 5.2.3.2. Marking using only the Threshold-meter Function 702 The excess-traffic-meter function SHOULD be disabled and MUST NOT 703 trigger any packet marking. 705 The PCN-interior-node SHOULD raise a management alarm if it receives 706 an ETM packet, but the frequency of such alarms SHOULD be limited. 708 If the threshold-meter function indicates a need to mark the packet: 710 o the PCN-interior-node MUST change NM to ThM; 712 o the PCN-interior-node MUST NOT change ETM to any other codepoint. 713 It SHOULD raise an alarm as above if it encounters an ETM packet. 715 5.3. PCN-egress Node Behaviour 717 A PCN-egress-node SHOULD set the Not-PCN (00) codepoint on all 718 packets it forwards out of the PCN-domain. 720 The only exception to this is if the PCN-egress-node is certain that 721 revealing other codepoints outside the PCN-domain won't contravene 722 the guidance given in [RFC4774]. For instance, if the PCN-ingress- 723 node has explicitly informed the PCN-egress-node that this flow is 724 ECN-capable, then it might be safe to expose other ECN codepoints. 725 Appendix B gives details of how such schemes might work, but such 726 schemes are currently only tentative ideas. 728 If the PCN-domain is configured to use only Excess-traffic-marking, 729 the PCN-egress-node MUST treat ThM as ETM and, if only threshold- 730 marking is used, it SHOULD treat ETM as ThM. However it SHOULD raise 731 a management alarm in either case since this means there is some 732 misconfiguration in the PCN-domain. 734 6. Backward Compatibility 736 6.1. Backward Compatibility with ECN 738 BCP 124 [RFC4774] gives guidelines for specifying alternative 739 semantics for the ECN field. It sets out a number of factors to be 740 taken into consideration. It also suggests various techniques to 741 allow the co-existence of default ECN and alternative ECN semantics. 742 The encoding specified in this document uses one of those techniques; 743 it defines PCN-compatible Diffserv codepoints as no longer supporting 744 the default ECN semantics within a PCN domain. As such, this 745 document is compatible with BCP 124. 747 There is not enough space in one IP header for the 3-in-1 encoding to 748 support both ECN marking end-to-end and PCN-marking within a PCN- 749 domain. The non-normative Appendix B discusses possible ways to do 750 this, e.g. by carrying e2e ECN across a PCN-domain within the inner 751 header of an IP-in-IP tunnel. The normative text in Section 5.1 752 requires one of these methods to be configured at the PCN-ingress- 753 node and recommends that implementations offer tunnelling as the 754 default. 756 In any PCN deployment, traffic can only enter the PCN-domain through 757 PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress- 758 nodes ensure that any packets entering the PCN-domain have the ECN 759 field in their outermost IP header set to the appropriate codepoint. 760 PCN-egress-nodes then guarantee that the ECN field of any packet 761 leaving the PCN-domain has appropriate ECN semantics. This prevents 762 unintended leakage of ECN marks into or out of the PCN-domain, and 763 thus reduces backward-compatibility issues. 765 6.2. Backward Compatibility with the RFC5696 Encoding 767 Section 5.1 of the PCN architecture gives general guidance on fault 768 detection and diagnosis [RFC5559], including management analysis of 769 PCN markings arriving at PCN-egress nodes to detect early signs of 770 potential faults. Because the PCN encoding has gone through an 771 obsoleted earlier stage [RFC5696], misconfiguration mistakes may be 772 more likely. Therefore extra monitoring, such as in the following 773 example, may be necessary to detect and diagnose potential problems: 775 Informational example: In a controlled-load edge-behaviour 776 scenario it could be worth the PCN-egress node detecting the onset 777 of excess-traffic marking without any prior threshold-marking. 778 This might indicate that an interior node has been wrongly 779 configured to mark only ETM (which would have been correct for the 780 single-marking edge-behaviour). 782 A PCN-node implemented to use the obsoleted RFC5696 encoding could 783 conceivably have been configured so that the Threshold-meter function 784 marked what is now defined as the ETM codepoint in the 3-in-1 785 encoding. However, there is no known deployment of this rather 786 unlikely variant of RFC5696 and no reason to believe that such an 787 implementation would ever have been built. Therefore, it seems safe 788 to ignore this issue. 790 7. IANA Considerations 792 This memo includes no request to IANA. 794 Note to RFC Editor: this section may be removed on publication as an 795 RFC. 797 8. Security Considerations 799 PCN-marking only carries a meaning within the confines of a PCN- 800 domain. This encoding document is intended to stand independently of 801 the architecture used to determine how specific packets are 802 authorised to be PCN-marked, which will be described in separate 803 documents on PCN-boundary-node behaviour. 805 This document assumes the PCN-domain to be entirely under the control 806 of a single operator, or a set of operators who trust each other. 807 However, future extensions to PCN might include inter-domain versions 808 where trust cannot be assumed between domains. If such schemes are 809 proposed, they must ensure that they can operate securely despite the 810 lack of trust. However, such considerations are beyond the scope of 811 this document. 813 One potential security concern is the injection of spurious PCN-marks 814 into the PCN-domain. However, these can only enter the domain if a 815 PCN-ingress-node is misconfigured. The precise impact of any such 816 misconfiguration will depend on which of the proposed PCN-boundary- 817 node behaviours is used, but in general spurious marks will lead to 818 admitting fewer flows into the domain or potentially terminating too 819 many flows. In either case, good management should be able to 820 quickly spot the problem since the overall utilisation of the domain 821 will rapidly fall. 823 9. Conclusions 825 The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field 826 to encode PCN-marks. One codepoint allows non-PCN traffic to be 827 carried with the same PCN-compatible DSCP and three other codepoints 828 support three PCN marking states with different levels of severity. 829 In general, the use of this PCN encoding scheme presupposes that any 830 tunnel endpoints within the PCN-domain comply with [RFC6040]. 832 10. Acknowledgements 834 Many thanks to Philip Eardley for providing extensive feedback, 835 criticism and advice. Thanks also to Teco Boot, Kwok Ho Chan, 836 Ruediger Geib, Georgios Karagiannis, James Polk, Tom Taylor, Adrian 837 Farrel and everyone else who has commented on the document. 839 11. Comments Solicited 841 To be removed by RFC Editor: Comments and questions are encouraged 842 and very welcome. They can be addressed to the IETF Congestion and 843 Pre-Congestion working group mailing list , and/or to 844 the authors. 846 12. References 848 12.1. Normative References 850 [RFC2119] Bradner, S., "Key words for use 851 in RFCs to Indicate Requirement 852 Levels", BCP 14, RFC 2119, 853 March 1997. 855 [RFC2474] Nichols, K., Blake, S., Baker, 856 F., and D. Black, "Definition of 857 the Differentiated Services Field 858 (DS Field) in the IPv4 and IPv6 859 Headers", RFC 2474, 860 December 1998. 862 [RFC3168] Ramakrishnan, K., Floyd, S., and 863 D. Black, "The Addition of 864 Explicit Congestion Notification 865 (ECN) to IP", RFC 3168, 866 September 2001. 868 [RFC5559] Eardley, P., "Pre-Congestion 869 Notification (PCN) Architecture", 870 RFC 5559, June 2009. 872 [RFC5670] Eardley, P., "Metering and 873 Marking Behaviour of PCN-Nodes", 874 RFC 5670, November 2009. 876 [RFC6040] Briscoe, B., "Tunnelling of 877 Explicit Congestion 878 Notification", RFC 6040, 879 November 2010. 881 12.2. Informative References 883 [I-D.ietf-pcn-cl-edge-behaviour] Charny, A., Huang, F., 884 Karagiannis, G., Menth, M., and 885 T. Taylor, "PCN Boundary Node 886 Behaviour for the Controlled Load 887 (CL) Mode of Operation", draft- 888 ietf-pcn-cl-edge-behaviour-14 889 (work in progress), April 2012. 891 [I-D.ietf-pcn-encoding-comparison] Karagiannis, G., Chan, K., 892 Moncaster, T., Menth, M., 893 Eardley, P., and B. Briscoe, 894 "Overview of Pre-Congestion 895 Notification Encoding", draft- 896 ietf-pcn-encoding-comparison-09 897 (work in progress), March 2012. 899 [I-D.ietf-pcn-sm-edge-behaviour] Charny, A., Karagiannis, G., 900 Menth, M., and T. Taylor, "PCN 901 Boundary Node Behaviour for the 902 Single Marking (SM) Mode of 903 Operation", draft-ietf-pcn-sm- 904 edge-behaviour-12 (work in 905 progress), April 2012. 907 [RFC2597] Heinanen, J., Baker, F., Weiss, 908 W., and J. Wroclawski, "Assured 909 Forwarding PHB Group", RFC 2597, 910 June 1999. 912 [RFC3031] Rosen, E., Viswanathan, A., and 913 R. Callon, "Multiprotocol Label 914 Switching Architecture", 915 RFC 3031, January 2001. 917 [RFC3246] Davie, B., Charny, A., Bennet, 918 J., Benson, K., Le Boudec, J., 919 Courtney, W., Davari, S., Firoiu, 920 V., and D. Stiliadis, "An 921 Expedited Forwarding PHB (Per-Hop 922 Behavior)", RFC 3246, March 2002. 924 [RFC3540] Spring, N., Wetherall, D., and D. 925 Ely, "Robust Explicit Congestion 926 Notification (ECN) Signaling with 927 Nonces", RFC 3540, June 2003. 929 [RFC4594] Babiarz, J., Chan, K., and F. 930 Baker, "Configuration Guidelines 931 for DiffServ Service Classes", 932 RFC 4594, August 2006. 934 [RFC4774] Floyd, S., "Specifying Alternate 935 Semantics for the Explicit 936 Congestion Notification (ECN) 937 Field", BCP 124, RFC 4774, 938 November 2006. 940 [RFC5127] Chan, K., Babiarz, J., and F. 941 Baker, "Aggregation of DiffServ 942 Service Classes", RFC 5127, 943 February 2008. 945 [RFC5129] Davie, B., Briscoe, B., and J. 946 Tay, "Explicit Congestion Marking 947 in MPLS", RFC 5129, January 2008. 949 [RFC5462] Andersson, L. and R. Asati, 950 "Multiprotocol Label Switching 951 (MPLS) Label Stack Entry: "EXP" 952 Field Renamed to "Traffic Class" 953 Field", RFC 5462, February 2009. 955 [RFC5696] Moncaster, T., Briscoe, B., and 956 M. Menth, "Baseline Encoding and 957 Transport of Pre-Congestion 958 Information", RFC 5696, 959 November 2009. 961 [RFC5865] Baker, F., Polk, J., and M. 962 Dolly, "A Differentiated Services 963 Code Point (DSCP) for Capacity- 964 Admitted Traffic", RFC 5865, 965 May 2010. 967 Appendix A. Choice of Suitable DSCPs 969 This appendix is informative, not normative. 971 A single DSCP has not been defined for use with PCN for several 972 reasons. Firstly, the PCN mechanism is applicable to a variety of 973 different traffic classes. Secondly, Standards Track DSCPs are in 974 increasingly short supply. Thirdly, PCN is not a scheduling 975 behaviour -- rather, it should be seen as being a marking behaviour 976 similar to ECN but intended for inelastic traffic. The choice of 977 which DSCP is most suitable for a given PCN-domain is dependent on 978 the nature of the traffic entering that domain and the link rates of 979 all the links making up that domain. In PCN-domains with sufficient 980 aggregation, the appropriate DSCPs would currently be those for the 981 Real-Time Treatment Aggregate [RFC5127]. It is suggested that 982 admission control could be used for the following service classes 983 (defined in [RFC4594] unless otherwise stated): 985 o Telephony (EF) 987 o Real-time interactive (CS4) 989 o Broadcast Video (CS3) 991 o Multimedia Conferencing (AF4) 993 o the VOICE-ADMIT codepoint defined in [RFC5865]. 995 CS5 is excluded from this list since PCN is not expected to be 996 applied to signalling traffic. 998 PCN-marking is intended to provide a scalable admission-control 999 mechanism for traffic with a high degree of statistical multiplexing. 1000 PCN-marking would therefore be appropriate to apply to traffic in the 1001 above classes, but only within a PCN-domain containing sufficiently 1002 aggregated traffic. In such cases, the above service classes may 1003 well all be subject to a single forwarding treatment (treatment 1004 aggregate [RFC5127]). However, this does not imply all such IP 1005 traffic would necessarily be identified by one DSCP -- each service 1006 class might keep a distinct DSCP within the highly aggregated region 1007 [RFC5127]. 1009 Guidelines for conserving DSCPs by allowing non-admission-controlled- 1010 traffic to compete with PCN-traffic are given in Appendix B.1 of 1011 [RFC5670]. 1013 Additional service classes may be defined for which admission control 1014 is appropriate, whether through some future standards action or 1015 through local use by certain operators, e.g., the Multimedia 1016 Streaming service class (AF3). This document does not preclude the 1017 use of PCN in more cases than those listed above. 1019 Note: The above discussion is informative not normative, as operators 1020 are ultimately free to decide whether to use admission control for 1021 certain service classes and whether to use PCN as their mechanism of 1022 choice. 1024 Appendix B. Co-existence of ECN and PCN 1026 This appendix is informative, not normative. It collects together 1027 material relevant to co-existence of ECN and PCN, including that 1028 spread throughout the body of this specification. If this results in 1029 any conflict or ambiguity, the normative text in the body of the 1030 specification takes precedence. 1032 ECN [RFC3168] is an e2e congestion notification mechanism. As such 1033 it is possible that some traffic entering the PCN-domain may also be 1034 ECN-capable. The PCN encoding described in this document re-uses the 1035 bits of the ECN field in the IP header. Consequently, this disables 1036 ECN within the PCN domain. 1038 For the purposes of this appendix we define two forms of traffic that 1039 might arrive at a PCN-ingress-node. These are admission-controlled 1040 traffic (PCN-traffic) and non-admission-controlled traffic (non-PCN- 1041 traffic). 1043 Flow signalling identifies admission controlled traffic, by 1044 associating a filterspec with the need for admission control (e.g. 1045 through RSVP or some equivalent message, e.g. from a SIP server to 1046 the ingress or from a logically centralised network control system). 1047 The PCN-ingress-node re-marks admission-conrolled traffic matching 1048 that filterspec to a PCN-compatible DSCP. Note that the term flow 1049 need not imply just one microflow, but instead could match an 1050 aggregate and/or could depend on the incoming DSCP (see Appendix A). 1052 All other traffic can be thought of as non-admission-controlled (and 1053 therefore outside the scope of PCN). However such traffic may still 1054 need to share the same DSCP as the admission-controlled traffic. 1055 This may be due to policy (for instance if it is high priority voice 1056 traffic), or may be because there is a shortage of local DSCPs. 1058 Unless specified otherwise, for any of the cases in the list below, 1059 an IP-in-IP tunnel that complies with[RFC6040] can be used to 1060 preserve ECN markings across the PCN domain. The tunnelling action 1061 should be applied wholly outside the PCN-domain as illustrated in 1062 Figure 2. Then, by the rules of RFC6040, the tunnel egress 1063 propagates the ECN field from the inner header, because the PCN- 1064 egress will have zeroed the outer ECN field. 1066 , . . . . . PCN-domain . . . . . . 1067 . ,--------. ,--------. . 1068 . _| PCN- |___________________| PCN- |_ . 1069 . / | ingress | | egress | \ . 1070 .| '---------' '--------' |. 1071 | . . . . . . . . . . . . . . .| 1072 ,--------. ,--------. 1073 _____| Tunnel | | Tunnel |____ 1074 | Ingress | - - ECN preserved inside tunnel - - | Egress | 1075 '---------' '--------' 1077 Figure 2: Separation of tunnelling and PCN actions 1079 There are three cases for how e2e ECN traffic may wish to be treated 1080 while crossing a PCN domain: 1082 a) Traffic that does not require PCN admission control: 1083 For example, traffic that does not match flow signaling being used 1084 for admission control. In this case the e2e ECN traffic is not 1085 treated as PCN-traffic. There are two possible scenarios: 1087 * Arriving traffic does not carry a PCN-compatible DSCP: no 1088 action required. 1090 * Arriving traffic carries a DSCP that clashes with a PCN- 1091 compatible DSCP. There are two options: 1093 1. The ingress maps the DSCP to a local DSCP with the same 1094 scheduling PHB as the original DSCP, and the egress re-maps 1095 it to the original PCN-compatible DSCP. 1097 2. The ingress tunnels the traffic, setting the DSCP in the 1098 outer header to a local DSCP with the same scheduling PHB 1099 as the original DSCP. 1101 3. The ingress tunnels the traffic, using the original DSCP in 1102 the outer but setting Not-PCN in the outer header; note 1103 that this turns off ECN for this traffic within the PCN 1104 domain. 1106 The first or second options are recommended unless the operator 1107 is short of local DSCPs. 1109 b) Traffic that requires admission-control: 1110 In this case the e2e ECN traffic is treated as PCN-traffic across 1111 the PCN domain. There are two options. 1113 * The PCN-ingress-node places this traffic in a tunnel with a 1114 PCN-compatible DSCP in the outer header. The PCN-egress zeroes 1115 the ECN-field before decapsulation. 1117 * The PCN-ingress-node drops CE-marked packets and otherwise sets 1118 the ECN-field to NM and sets the DCSP to a PCN-compatible DSCP. 1119 The PCN-egress zeroes the ECN field of all PCN packets; note 1120 that this turns off e2e ECN. 1122 The second option is emphatically not recommended, unless perhaps 1123 as a last resort if tunnelling is not possible for some 1124 insurmountable reason. 1126 c) Traffic that requires PCN admission control where the endpoints 1127 ask to see PCN marks: 1128 Note that this scheme is currently only a tentative idea. 1130 For real-time data generated by an adaptive codec, schemes have 1131 been suggested where PCN marks may be leaked out of the PCN-domain 1132 so that end hosts can drop to a lower data-rate, thus deferring 1133 the need for admission control. Currently such schemes require 1134 further study and the following is for guidance only. 1136 The PCN-ingress-node needs to tunnel the traffic as in Figure 2, 1137 taking care to comply with [RFC6040]. In this case the PCN-egress 1138 does not zero the ECN field contrary to the recommendation in 1139 Section 5.3, so that the [RFC6040] tunnel egress will preserve any 1140 PCN-marking. Note that a PCN-interior-node may change the ECN- 1141 field from 10 to 01 (NM to ThM), which would be interpreted by the 1142 e2e ECN as a change from ECT(0) into ECT(1). This would not be 1143 compatible with the (currently experimental) ECN nonce [RFC3540]. 1145 Appendix C. Example Mapping between Encoding of PCN-Marks in IP and in 1146 MPLS Shim Headers 1148 This appendix is informative not normative. 1150 The 6 bits of the DS field in the IP header provide for 64 1151 codepoints. When encapsulating IP traffic in MPLS, it is useful to 1152 make the DS field information accessible in the MPLS header. 1153 However, the MPLS shim header has only a 3-bit traffic class (TC) 1154 field [RFC5462] providing for 8 codepoints. The operator has the 1155 freedom to define a site-local mapping of the 64 codepoints of the DS 1156 field onto the 8 codepoints in the TC field. 1158 [RFC5129] describes how ECN markings in the IP header can also be 1159 mapped to codepoints in the MPLS TC field. Appendix A of [RFC5129] 1160 gives an informative description of how to support PCN in MPLS by 1161 extending the way MPLS supports ECN. [RFC5129] was written while PCN 1162 specifications were in early draft stages. The following provides a 1163 clearer example of a mapping between PCN in IP and in MPLS using the 1164 PCN terminology and concepts that have since been specified. 1166 To support PCN in a MPLS domain, a PCN-compatible DSCP ('DSCP n') 1167 needs codepoints to be provided in the TC field for all the PCN-marks 1168 used. That means, when for instance only excess-traffic-marking is 1169 used for PCN purposes, the operator needs to define a site-local 1170 mapping to two codepoints in the MPLS TC field for IP headers with: 1172 o DSCP n and NM 1174 o DSCP n and ETM 1176 If both excess-traffic-marking and threshold-marking are used, the 1177 operator needs to define a site-local mapping to codepoints in the 1178 MPLS TC field for IP headers with all three of the 3-in-1 codepoints: 1180 o DSCP n and NM 1182 o DSCP n and ThM 1184 o DSCP n and ETM 1186 In either case, if the operator wishes to support the same Diffserv 1187 PHB but without PCN marking, it will also be necessary to define a 1188 site-local mapping to an MPLS TC codepoint for IP headers marked 1189 with: 1191 o DSCP n and Not-PCN 1192 The above sets of codepoints are required for every PCN-compatible 1193 DSCP. Clearly, given so few TC codepoints are available, it may be 1194 necessary to compromise by merging together some capabilities. 1195 Guidelines for conserving TC codepoints by allowing non-admission- 1196 controlled-traffic to compete with PCN-traffic are given in Appendix 1197 B.1 of [RFC5670]. 1199 Appendix D. Rationale for Difference Between the Schemes using One PCN- 1200 Marking 1202 Readers may notice a difference between the two behaviours in 1203 Section 5.2.3.1 and Section 5.2.3.2. With only Excess-traffic- 1204 marking enabled, an unexpected ThM packet can be re-marked to ETM. 1205 However, with only Threshold-marking, an unexpected ETM packet cannot 1206 be re-marked to ThM. 1208 This apparent inconsistency is deliberate. The behaviour with only 1209 Threshold-marking keeps to the rule of Section 5.2.1 that ETM is more 1210 severe and must never be changed to ThM even though ETM is not a 1211 valid marking in this case. Otherwise implementations would have to 1212 allow operators to configure an exception to this rule, which would 1213 not be safe practice and would require different code in the data- 1214 plane compared to the common behaviour. 1216 Authors' Addresses 1218 Bob Briscoe 1219 BT 1220 B54/77, Adastral Park 1221 Martlesham Heath 1222 Ipswich IP5 3RE 1223 UK 1225 Phone: +44 1473 645196 1226 EMail: bob.briscoe@bt.com 1227 URI: http://bobbriscoe.net/ 1228 Toby Moncaster 1229 Moncaster Internet Consulting 1230 Dukes 1231 Layer Marney 1232 Colchester CO5 9UZ 1233 UK 1235 Phone: +44 7764 185416 1236 EMail: toby@moncaster.com 1237 URI: http://www.moncaster.com/ 1239 Michael Menth 1240 University of Tuebingen 1241 Sand 13 1242 Tuebingen 72076 1243 Germany 1245 Phone: +49 7071 2970505 1246 EMail: menth@informatik.uni-tuebingen.de