idnits 2.17.1 draft-ietf-pcn-3-in-1-encoding-09.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 (March 11, 2012) is 4426 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-12 == Outdated reference: A later version (-12) exists of draft-ietf-pcn-sm-edge-behaviour-09 -- 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: September 12, 2012 University of Tuebingen 8 March 11, 2012 10 Encoding 3 PCN-States in the IP header using a single DSCP 11 draft-ietf-pcn-3-in-1-encoding-09 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 September 12, 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 . . . . . . . . . . . . . . . . 7 71 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 72 2.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . 10 77 4.3. Applicable Environments for the 3-in-1 PCN Encoding . . . 11 78 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN 79 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 5.1. PCN-ingress Node Behaviour . . . . . . . . . . . . . . . . 11 81 5.2. PCN-interior Node Behaviour . . . . . . . . . . . . . . . 14 82 5.2.1. Behaviour Common to all PCN-interior Nodes . . . . . . 14 83 5.2.2. Behaviour of PCN-interior Nodes Using Two 84 PCN-markings . . . . . . . . . . . . . . . . . . . . . 14 85 5.2.3. Behaviour of PCN-interior Nodes Using One 86 PCN-marking . . . . . . . . . . . . . . . . . . . . . 14 87 5.3. PCN-egress Node Behaviour . . . . . . . . . . . . . . . . 15 88 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 16 89 6.1. Backward Compatibility with ECN . . . . . . . . . . . . . 16 90 6.2. Backward Compatibility with the RFC5696 Encoding . . . . . 16 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 93 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 95 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 17 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 97 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 98 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 99 Appendix A. Choice of Suitable DSCPs . . . . . . . . . . . . . . 20 100 Appendix B. Co-existence of ECN and PCN . . . . . . . . . . . . . 21 101 Appendix C. Example Mapping between Encoding of PCN-Marks in 102 IP and in MPLS Shim Headers . . . . . . . . . . . . . 24 103 Appendix D. Rationale for Difference Between the Schemes 104 using One PCN-Marking . . . . . . . . . . . . . . . . 25 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-08 to -09: 172 * Added note about fail-safe to protect other traffic in the 173 event of tunnel misconfiguration. 175 * Changed section heading to be about applicability of 176 environments to the encoding, rather than the encoding to the 177 environments. 179 * Completely re-wrote PCN-ingress Node Behaviour section. 181 * Changed PCN interior node to PCN-node where the term was 182 intended to include all PCN-nodes. 184 * Clarified status of ECN/PCN co-existence appendix. Removed 185 inconsistent assertion in this appendix that an admission- 186 control DSCP alone can indicate that arriving traffic is PCN- 187 traffic. 189 * A few clarifying editorial amendments and updated refs. 191 From draft-ietf-pcn-3-in-1-encoding-07 to -08: Editorial corrections 192 and clarifications. 194 From draft-ietf-pcn-3-in-1-encoding-06 to -07: 196 * Clarified that each operator not the IETF chooses which DSCP(s) 197 are PCN-compatible, and made it unambiguous that only PCN-nodes 198 recognise that PCN-compatible DSCPs enable the 3-in-1 encoding. 200 * Removed statements about the PCN working group, given RFCs are 201 meant to survive beyond the life of a w-g. 203 * Corrected the final para of "Rationale for Different Behaviours 204 in Schemes with Only One Marking" 206 From draft-ietf-pcn-3-in-1-encoding-05 to -06: 208 * Draft re-written to obsolete baseline encoding [RFC5696]. 210 * New section defining utilising this encoding for only one PCN- 211 Marking. Added an appendix explaining an apparent 212 inconsistency within this section. 214 * Moved (and updated) informative appendixes from [RFC5696] to 215 this document. Original Appendix C was omitted as it is now 216 redundant. 218 * Significant re-structuring of document. 220 From draft-ietf-pcn-3-in-1-encoding-04 to -05: 222 * Draft moved to standards track as per working group 223 discussions. 225 * Added Appendix B discussing ECN handling in the PCN-domain. 227 * Clarified that this document modifies [RFC5696]. 229 From draft-ietf-pcn-3-in-1-encoding-03 to -04: 231 * Updated document to reflect RFC6040. 233 * Re-wrote introduction. 235 * Re-wrote section on applicability. 237 * Re-wrote section on choosing encoding scheme. 239 * Updated author details. 241 From draft-ietf-pcn-3-in-1-encoding-02 to -03: 243 * Corrected mistakes in introduction and improved overall 244 readability. 246 * Added new terminology. 248 * Rewrote a good part of Section 4 and 5 to achieve more clarity. 250 * Added appendix explaining when to use which encoding scheme and 251 how to encode them in MPLS shim headers. 253 * Added new co-author. 255 From draft-ietf-pcn-3-in-1-encoding-01 to -02: 257 * Corrected mistake in introduction, which wrongly stated that 258 the threshold-traffic rate is higher than the excess-traffic 259 rate. Other minor corrections. 261 * Updated acks & refs. 263 From draft-ietf-pcn-3-in-1-encoding-00 to -01: 265 * Altered the wording to make sense if 266 draft-ietf-tsvwg-ecn-tunnel moves to proposed standard. 268 * References updated 270 From draft-briscoe-pcn-3-in-1-encoding-00 to 271 draft-ietf-pcn-3-in-1-encoding-00: 273 * Filename changed to draft-ietf-pcn-3-in-1-encoding. 275 * Introduction altered to include new template description of 276 PCN. 278 * References updated. 280 * Terminology brought into line with [RFC5670]. 282 * Minor corrections. 284 2. Definitions and Abbreviations 286 2.1. Terminology 288 The terms PCN-domain, PCN-node, PCN-interior-node, PCN-ingress-node, 289 PCN-egress-node, PCN-boundary-node, PCN-traffic, PCN-packets and PCN- 290 marking are used as defined in [RFC5559]. The following additional 291 terms are defined in this document: 293 PCN encoding: mapping of PCN marking states to specific codepoints 294 in the packet header. 296 PCN-compatible Diffserv codepoint: a Diffserv codepoint indicating 297 packets for which the ECN field carries PCN-markings rather than 298 [RFC3168] markings. Note that an operator configures PCN-nodes to 299 recognise PCN-compatible DSCPs, whereas the same DSCP has no PCN- 300 specific meaning to a node outside the PCN domain. 302 Threshold-marked codepoint: a codepoint that indicates a packet has 303 been threshold-marked; that is a packet that has been marked at a 304 PCN-interior-node as a result of an indication from the threshold- 305 metering function [RFC5670]. Abbreviated to ThM. 307 Excess-traffic-marked codepoint: a codepoint that indicates packets 308 that have been marked at a PCN-interior-node as a result of an 309 indication from the excess-traffic-metering function [RFC5670]. 310 Abbreviated to ETM. 312 Not-marked codepoint: a codepoint that indicates PCN-packets that 313 are not PCN-marked. Abbreviated to NM. 315 Not-PCN codepoint: a codepoint that indicates packets that are not 316 PCN-packets. 318 2.2. List of Abbreviations 320 The following abbreviations are used in this document: 322 o AF = Assured Forwarding [RFC2597] 324 o CE = Congestion Experienced [RFC3168] 326 o CS = Class Selector [RFC2474] 328 o DSCP = Diffserv codepoint 330 o e2e = end-to-end 332 o ECN = Explicit Congestion Notification [RFC3168] 334 o ECT = ECN Capable Transport [RFC3168] 336 o EF = Expedited Forwarding [RFC3246] 338 o ETM = Excess-traffic-marked 340 o EXP = Experimental 342 o NM = Not-marked 343 o PCN = Pre-Congestion Notification 345 o ThM = Threshold-marked 347 3. Definition of 3-in-1 PCN Encoding 349 The 3-in-1 PCN encoding scheme supports networks that need three PCN- 350 marking states to be encoded within the IP header, as well as those 351 that need only two. The full encoding is shown in Figure 1. 353 +--------+----------------------------------------------------+ 354 | | Codepoint in ECN field of IP header | 355 | DSCP | | 356 | +--------------+-------------+-------------+---------+ 357 | | 00 | 10 | 01 | 11 | 358 +--------+--------------+-------------+-------------+---------+ 359 | DSCP n | Not-PCN | NM | ThM | ETM | 360 +--------+--------------+-------------+-------------+---------+ 362 Figure 1: 3-in-1 PCN Encoding 364 A PCN-node will be configured to recognise certain DSCPs as PCN- 365 compatible. Appendix A discusses the choice of suitable DSCPs. In 366 Figure 1 'DSCP n' indicates such a PCN-compatible DSCP. In the PCN- 367 domain, any packet carrying a PCN-compatible DSCP and with the ECN- 368 field anything other than 00 (Not-PCN) is a PCN-packet as defined in 369 [RFC5559]. 371 PCN-nodes MUST interpret the ECN field of a PCN-packet using the 372 3-in-1 PCN encoding, rather than [RFC3168]. This does not change the 373 behaviour for any packet with a DSCP that is not PCN-compatible, or 374 for any node outside a PCN-domain. In all such cases the 3-in-1 375 encoding is not applicable and so by default the node will interpret 376 the ECN field using [RFC3168]. 378 When using the 3-in-1 encoding, the codepoints of the ECN field have 379 the following meanings: 381 Not-PCN: indicates a non-PCN-packet, i.e., a packet that uses a PCN- 382 compatible DSCP but is not subject to PCN metering and marking. 384 NM: Not-marked. Indicates a PCN-packet that has not yet been marked 385 by any PCN marker. 387 ThM: Threshold-marked. Indicates a PCN-packet that has been marked 388 by a threshold-marker [RFC5670]. 390 ETM: Excess-traffic-marked. Indicates a PCN-packet that has been 391 marked by an excess-traffic-marker [RFC5670]. 393 4. Requirements for and Applicability of 3-in-1 PCN Encoding 395 4.1. PCN Requirements 397 In accordance with the PCN architecture [RFC5559], PCN-ingress-nodes 398 control packets entering a PCN-domain. Packets belonging to PCN- 399 controlled flows are subject to PCN-metering and -marking, and PCN- 400 ingress-nodes mark them as Not-marked (PCN-colouring). All nodes in 401 the PCN-domain perform PCN-metering and PCN-mark PCN-packets if 402 needed. There are two different metering and marking behaviours: 403 threshold-marking and excess-traffic-marking [RFC5670]. Some edge 404 behaviours require only a single marking behaviour 405 [I-D.ietf-pcn-sm-edge-behaviour], others require both 406 [I-D.ietf-pcn-cl-edge-behaviour]. In the latter case, three PCN 407 marking states are needed: Not-marked (NM) to indicate not-marked 408 packets, Threshold-marked (ThM) to indicate packets marked by the 409 threshold-marker, and Excess-traffic-marked (ETM) to indicate packets 410 marked by the excess-traffic-marker [RFC5670]. Threshold-marking and 411 excess-traffic-marking are configured to start marking packets at 412 different load conditions, so one marking behaviour indicates more 413 severe pre-congestion than the other. Therefore, a fourth PCN 414 marking state indicating that a packet is marked by both markers is 415 not needed. However a fourth codepoint is required to indicate 416 packets that use a PCN-compatible DSCP but do not use PCN-marking 417 (the Not-PCN codepoint). 419 In all current PCN edge behaviours that use two marking behaviours 420 [RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking 421 is configured with a larger reference rate than threshold-marking. 422 We take this as a rule and define excess-traffic-marked as a more 423 severe PCN-mark than Threshold-marked. 425 4.2. Requirements Imposed by Tunnelling 427 [RFC6040] defines rules for the encapsulation and decapsulation of 428 ECN markings within IP-in-IP tunnels. The publication of RFC6040 429 removed the tunnelling constraints that existed when the encoding of 430 [RFC5696] was written (see section 3.3.2 of 431 [I-D.ietf-pcn-encoding-comparison]). 433 Nonetheless, there is still a problem if there are any legacy (pre- 434 RFC6040) decapsulating tunnel endpoints within a PCN domain. If a 435 PCN-node Threshold-marks the outer header of a tunnelled packet that 436 has a Not-marked codepoint on the inner header, a legacy decapsulator 437 will forward the packet as Not-marked, losing the Threshold-marking. 439 The rules on applicability in Section 4.3 below are designed to avoid 440 this problem. 442 Even if an operator accidentally breaks these applicability rules, 443 the order of severity of the 3-in-1 codepoints was chosen to protect 444 other PCN or non-PCN traffic. Although legacy pre-RFC6040 tunnels 445 did not propagate '01', all tunnels pre-RFC6040 and post-RFC6040 have 446 always propagated '11' correctly. Therefore '11' was chosen to 447 signal the most severe pre-congestion (ETM), so it would act as a 448 reliable fail-safe even if an overlooked legacy tunnel was 449 suppressing 01 (ThM) signals. 451 4.3. Applicable Environments for the 3-in-1 PCN Encoding 453 The 3-in-1 encoding is applicable in situations where two marking 454 behaviours are being used in the PCN-domain. The 3-in-1 encoding can 455 also be used with only one marking behaviour, in which case one of 456 the codepoints MUST NOT be used anywhere in the PCN-domain (see 457 Section 5.2.3). 459 With one exception (see next paragraph), any tunnel endpoints 460 (IP-in-IP and IPsec) within the PCN-domain MUST comply with the ECN 461 encapsulation and decapsulation rules set out in [RFC6040] (see 462 Section 4.2). 464 Operators may not be able to upgrade every pre-RFC6040 tunnel 465 endpoint within a PCN-domain. In such circumstances a limited 466 version of the 3-in-1 encoding can still be used but only under the 467 following stringent condition. If any pre-RFC6040 tunnel 468 decapsulator exists within a PCN-domain then every PCN-node in the 469 PCN-domain MUST be configured so that it never sets the ThM 470 codepoint. PCN-interior-nodes in this case MUST solely use the 471 Excess-traffic-marking function, as defined in Section 5.2.3.1. In 472 all other situations where legacy tunnel decapsulators might be 473 present within the PCN domain, the 3-in-1 encoding is not applicable. 475 5. Behaviour of a PCN-node to Comply with the 3-in-1 PCN Encoding 477 Any tunnel endpoint implementation on a PCN-node MUST comply with 478 [RFC6040]. Since PCN is a new capability, this is considered a 479 reasonable requirement. 481 5.1. PCN-ingress Node Behaviour 483 Each ingress link into a PCN domain will apply the four functions 484 described in section 4.2 of [RFC5559] to arriving packets. These 485 functions are applied in the following order: classify, police, PCN- 486 colour, meter. This section describes these four steps, but only the 487 aspects relevant to packet encoding: 489 1. Packet classification: The PCN-ingress-node determines whether 490 each packet matches the filter spec of an admitted flow. Packets 491 that match are defined as PCN-packets. 493 1b. Extra step if ECN and PCN co-exist: If a packet classified as a 494 PCN-packet arrives with the ECN field already set to a value other 495 than Not-ECT (i.e. it is from an ECN-capable transport) then to 496 comply with BCP 124 [RFC4774] it MUST pass through one of the 497 following preparatory steps before the PCN-policing and PCN- 498 colouring steps. The choice between these four actions depends on 499 local policy: 501 * Tunnel ECN-capable PCN-packets across the PCN-domain, using an 502 RFC6040 tunnel. This tunnelling step MUST precede PCN-policing 503 and PCN-colouring so that the tunnel is logically outside the 504 PCN domain (see Appendix B and specifically Figure 2). 506 This tunnelling policy is the RECOMMENDED choice, and 507 implementations SHOULD use it as the default. 509 * If tunnelling is not possible, the PCN-ingress-node can allow 510 through ECN-capable packets without tunnelling, but it MUST 511 drop CE-marked packets at this stage. Failure to drop CE would 512 risk congestion collapse, because without a tunnel there is no 513 mechanism to propagate the CE markings across the PCN-domain 514 (see Appendix B). 516 This policy is emphatically NOT RECOMMENDED because there is no 517 tunnel to protect the e2e ECN capability, which is otherwise 518 disabled when the PCN-egress-node zeroes the ECN field. 520 * Drop the packet. 522 This policy is also emphatically NOT RECOMMENDED, because it 523 precludes the possibility that e2e ECN can co-exist with PCN as 524 a means of controlling congestion. 526 * Any other action that complies with [RFC4774] (see Appendix B 527 for an example). 529 Appendix B provides more information about the co-existence of PCN 530 and ECN. 532 2. PCN-Policing: The PCN-policing function only allows appropriate 533 packets into the PCN behaviour aggregate. Per-flow policing 534 actions may be required, but these are specified in the relevant 535 edge-behaviour document, e.g. [I-D.ietf-pcn-sm-edge-behaviour], 536 [I-D.ietf-pcn-cl-edge-behaviour]. 538 Here we only specify packet-level PCN-policing, which prevents 539 packets that are not PCN-packets from being forwarded into the 540 PCN-domain if PCN-interior-nodes would otherwise mistake them for 541 PCN-packets. A non-PCN-packet will be confused with a PCN-packet 542 if on arrival it meets all three of the following conditions: 544 a) it is not classified as a PCN-packet 546 b) it already carries a PCN-compatible DSCP 548 c) its ECN field carries a codepoint other than Not-ECT. 550 The PCN-ingress-node MUST police packets that meet all three 551 conditions (a-c) by subjecting them to one of the following 552 treatments: 554 * re-mark the DSCP to a DSCP that is not PCN-compatible; 556 * tunnel the packet to the PCN-egress with a DSCP in the outer 557 header that is not PCN-compatible; 559 * drop the packet (NOT RECOMMENDED--see below). 561 The choice between these actions depends on local policy. In the 562 absence of any operator-specific configuration for this case, by 563 default an implementation SHOULD re-mark the DSCP to zero. 565 Traffic that meets all three of the above conditions (a-c) is not 566 PCN-traffic, therefore ideally a PCN-ingress ought not to 567 interfere with it, but it has to do something to avoid ambiguous 568 packet markings. Clearing the ECN field is not an appropriate 569 policing action, because a network node ought not to interfere 570 with an e2e signal. Even if such packets seem like an attack, 571 drop would be overkill, because such an attack can be neutralised 572 by just re-marking the DSCP. And DSCP re-marking in the network 573 is legitimate, because the DSCP is not considered an e2e signal. 575 3. PCN-colouring: If a packet has been classified as a PCN-packet, 576 once it has been policed, the PCN-ingress-node: 578 * MUST set a PCN-compatible Diffserv codepoint on all PCN- 579 packets. To conserve DSCPs, Diffserv codepoints SHOULD be 580 chosen that are already defined for use with admission- 581 controlled traffic. Appendix A gives guidance to implementors 582 on suitable DSCPs. 584 * MUST set the PCN codepoint of all PCN-packets to Not-marked 585 (NM). 587 4. PCN rate-metering: This fourth step may be necessary depending on 588 the edge-behaviour in force. It is listed for completeness, but 589 it is not relevant to this encoding document. 591 5.2. PCN-interior Node Behaviour 593 5.2.1. Behaviour Common to all PCN-interior Nodes 595 Interior nodes MUST NOT change Not-PCN to any other codepoint. 597 Interior nodes MUST NOT change NM to Not-PCN. 599 Interior nodes MUST NOT change ThM to NM or Not-PCN. 601 Interior nodes MUST NOT change ETM to any other codepoint. 603 5.2.2. Behaviour of PCN-interior Nodes Using Two PCN-markings 605 If the threshold-meter function indicates a need to mark a packet, 606 the PCN-interior-node MUST change NM to ThM. 608 If the excess-traffic-meter function indicates a need to mark a 609 packet: 611 o the PCN-interior-node MUST change NM to ETM; 613 o the PCN-interior-node MUST change ThM to ETM. 615 If both the threshold meter and the excess-traffic meter indicate the 616 need to mark a packet, the Excess-traffic-marking rules MUST take 617 precedence. 619 5.2.3. Behaviour of PCN-interior Nodes Using One PCN-marking 621 Some PCN edge behaviours require only one PCN-marking within the PCN- 622 domain. The Single Marking edge behaviour 623 [I-D.ietf-pcn-sm-edge-behaviour] requires PCN-interior-nodes to mark 624 packets using the excess-traffic-meter function [RFC5670]. It is 625 possible that future schemes may require only the threshold-meter 626 function. Appendix D explains the rationale for the behaviours 627 defined in this section. 629 5.2.3.1. Marking Using only the Excess-traffic-meter Function 631 The threshold-traffic-meter function SHOULD be disabled and MUST NOT 632 trigger any packet marking. 634 The PCN-interior-node SHOULD raise a management alarm if it receives 635 a ThM packet, but the frequency of such alarms SHOULD be limited. 637 If the excess-traffic-meter function indicates a need to mark the 638 packet: 640 o the PCN-interior-node MUST change NM to ETM; 642 o the PCN-interior-node MUST change ThM to ETM. It SHOULD also 643 raise an alarm as above. 645 5.2.3.2. Marking using only the Threshold-meter Function 647 The excess-traffic-meter function SHOULD be disabled and MUST NOT 648 trigger any packet marking. 650 The PCN-interior-node SHOULD raise a management alarm if it receives 651 an ETM packet, but the frequency of such alarms SHOULD be limited. 653 If the threshold-meter function indicates a need to mark the packet: 655 o the PCN-interior-node MUST change NM to ThM; 657 o the PCN-interior-node MUST NOT change ETM to any other codepoint. 658 It SHOULD raise an alarm as above if it encounters an ETM packet. 660 5.3. PCN-egress Node Behaviour 662 A PCN-egress-node SHOULD set the Not-PCN (00) codepoint on all 663 packets it forwards out of the PCN-domain. 665 The only exception to this is if the PCN-egress-node is certain that 666 revealing other codepoints outside the PCN-domain won't contravene 667 the guidance given in [RFC4774]. For instance, if the PCN-ingress- 668 node has explicitly informed the PCN-egress-node that this flow is 669 ECN-capable, then it might be safe to expose other ECN codepoints. 670 Appendix B gives details of how such schemes might work, but such 671 schemes are currently only tentative ideas. 673 If the PCN-domain is configured to use only Excess-traffic-marking, 674 the PCN-egress-node MUST treat ThM as ETM and, if only threshold- 675 marking is used, it SHOULD treat ETM as ThM. However it SHOULD raise 676 a management alarm in either case since this means there is some 677 misconfiguration in the PCN-domain. 679 6. Backward Compatibility 681 6.1. Backward Compatibility with ECN 683 BCP 124 [RFC4774] gives guidelines for specifying alternative 684 semantics for the ECN field. It sets out a number of factors to be 685 taken into consideration. It also suggests various techniques to 686 allow the co-existence of default ECN and alternative ECN semantics. 687 The encoding specified in this document uses one of those techniques; 688 it defines PCN-compatible Diffserv codepoints as no longer supporting 689 the default ECN semantics within a PCN domain. As such, this 690 document is compatible with BCP 124. 692 There is not enough space in one IP header for the 3-in-1 encoding to 693 support both ECN marking end-to-end and PCN-marking within a PCN- 694 domain. The non-normative Appendix B discusses possible ways to do 695 this, e.g. by carrying e2e ECN across a PCN-domain within the inner 696 header of an IP-in-IP tunnel. The normative text in Section 5.1 697 requires one of these methods to be configured at the PCN-ingress- 698 node and recommends that implementations offer tunnelling as the 699 default. 701 In any PCN deployment, traffic can only enter the PCN-domain through 702 PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress- 703 nodes ensure that any packets entering the PCN-domain have the ECN 704 field in their outermost IP header set to the appropriate codepoint. 705 PCN-egress-nodes then guarantee that the ECN field of any packet 706 leaving the PCN-domain has appropriate ECN semantics. This prevents 707 unintended leakage of ECN marks into or out of the PCN-domain, and 708 thus reduces backward-compatibility issues. 710 6.2. Backward Compatibility with the RFC5696 Encoding 712 A PCN-node implemented to use the obsoleted RFC5696 encoding could 713 conceivably have been configured so that the Threshold-meter function 714 marked what is now defined as the ETM codepoint in the 3-in-1 715 encoding. However, there is no known deployment of this rather 716 unlikely variant of RFC5696 and no reason to believe that such an 717 implementation would ever have been built. Therefore, it seems safe 718 to ignore this issue. 720 7. IANA Considerations 722 This memo includes no request to IANA. 724 Note to RFC Editor: this section may be removed on publication as an 725 RFC. 727 8. Security Considerations 729 PCN-marking only carries a meaning within the confines of a PCN- 730 domain. This encoding document is intended to stand independently of 731 the architecture used to determine how specific packets are 732 authorised to be PCN-marked, which will be described in separate 733 documents on PCN-boundary-node behaviour. 735 This document assumes the PCN-domain to be entirely under the control 736 of a single operator, or a set of operators who trust each other. 737 However, future extensions to PCN might include inter-domain versions 738 where trust cannot be assumed between domains. If such schemes are 739 proposed, they must ensure that they can operate securely despite the 740 lack of trust. However, such considerations are beyond the scope of 741 this document. 743 One potential security concern is the injection of spurious PCN-marks 744 into the PCN-domain. However, these can only enter the domain if a 745 PCN-ingress-node is misconfigured. The precise impact of any such 746 misconfiguration will depend on which of the proposed PCN-boundary- 747 node behaviours is used, but in general spurious marks will lead to 748 admitting fewer flows into the domain or potentially terminating too 749 many flows. In either case, good management should be able to 750 quickly spot the problem since the overall utilisation of the domain 751 will rapidly fall. 753 9. Conclusions 755 The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field 756 to encode PCN-marks. One codepoint allows non-PCN traffic to be 757 carried with the same PCN-compatible DSCP and three other codepoints 758 support three PCN marking states with different levels of severity. 759 In general, the use of this PCN encoding scheme presupposes that any 760 tunnel endpoints within the PCN-domain comply with [RFC6040]. 762 10. Acknowledgements 764 Many thanks to Philip Eardley for providing extensive feedback, 765 criticism and advice. Thanks also to Teco Boot, Kwok Ho Chan, 766 Ruediger Geib, Georgios Karagiannis, Adrian Farrel and everyone else 767 who has commented on the document. 769 11. Comments Solicited 771 To be removed by RFC Editor: Comments and questions are encouraged 772 and very welcome. They can be addressed to the IETF Congestion and 773 Pre-Congestion working group mailing list , and/or to 774 the authors. 776 12. References 778 12.1. Normative References 780 [RFC2119] Bradner, S., "Key words for use 781 in RFCs to Indicate Requirement 782 Levels", BCP 14, RFC 2119, 783 March 1997. 785 [RFC2474] Nichols, K., Blake, S., Baker, 786 F., and D. Black, "Definition of 787 the Differentiated Services Field 788 (DS Field) in the IPv4 and IPv6 789 Headers", RFC 2474, 790 December 1998. 792 [RFC3168] Ramakrishnan, K., Floyd, S., and 793 D. Black, "The Addition of 794 Explicit Congestion Notification 795 (ECN) to IP", RFC 3168, 796 September 2001. 798 [RFC5559] Eardley, P., "Pre-Congestion 799 Notification (PCN) Architecture", 800 RFC 5559, June 2009. 802 [RFC5670] Eardley, P., "Metering and 803 Marking Behaviour of PCN-Nodes", 804 RFC 5670, November 2009. 806 [RFC6040] Briscoe, B., "Tunnelling of 807 Explicit Congestion 808 Notification", RFC 6040, 809 November 2010. 811 12.2. Informative References 813 [I-D.ietf-pcn-cl-edge-behaviour] Charny, A., Huang, F., 814 Karagiannis, G., Menth, M., and 815 T. Taylor, "PCN Boundary Node 816 Behaviour for the Controlled Load 817 (CL) Mode of Operation", draft- 818 ietf-pcn-cl-edge-behaviour-12 819 (work in progress), 820 February 2012. 822 [I-D.ietf-pcn-encoding-comparison] Karagiannis, G., Chan, K., 823 Moncaster, T., Menth, M., 824 Eardley, P., and B. Briscoe, 825 "Overview of Pre-Congestion 826 Notification Encoding", draft- 827 ietf-pcn-encoding-comparison-09 828 (work in progress), March 2012. 830 [I-D.ietf-pcn-sm-edge-behaviour] Charny, A., Karagiannis, G., 831 Menth, M., and T. Taylor, "PCN 832 Boundary Node Behaviour for the 833 Single Marking (SM) Mode of 834 Operation", draft-ietf-pcn-sm- 835 edge-behaviour-09 (work in 836 progress), February 2012. 838 [RFC2597] Heinanen, J., Baker, F., Weiss, 839 W., and J. Wroclawski, "Assured 840 Forwarding PHB Group", RFC 2597, 841 June 1999. 843 [RFC3246] Davie, B., Charny, A., Bennet, 844 J., Benson, K., Le Boudec, J., 845 Courtney, W., Davari, S., Firoiu, 846 V., and D. Stiliadis, "An 847 Expedited Forwarding PHB (Per-Hop 848 Behavior)", RFC 3246, March 2002. 850 [RFC3540] Spring, N., Wetherall, D., and D. 851 Ely, "Robust Explicit Congestion 852 Notification (ECN) Signaling with 853 Nonces", RFC 3540, June 2003. 855 [RFC4594] Babiarz, J., Chan, K., and F. 856 Baker, "Configuration Guidelines 857 for DiffServ Service Classes", 858 RFC 4594, August 2006. 860 [RFC4774] Floyd, S., "Specifying Alternate 861 Semantics for the Explicit 862 Congestion Notification (ECN) 863 Field", BCP 124, RFC 4774, 864 November 2006. 866 [RFC5127] Chan, K., Babiarz, J., and F. 867 Baker, "Aggregation of DiffServ 868 Service Classes", RFC 5127, 869 February 2008. 871 [RFC5129] Davie, B., Briscoe, B., and J. 872 Tay, "Explicit Congestion Marking 873 in MPLS", RFC 5129, January 2008. 875 [RFC5462] Andersson, L. and R. Asati, 876 "Multiprotocol Label Switching 877 (MPLS) Label Stack Entry: "EXP" 878 Field Renamed to "Traffic Class" 879 Field", RFC 5462, February 2009. 881 [RFC5696] Moncaster, T., Briscoe, B., and 882 M. Menth, "Baseline Encoding and 883 Transport of Pre-Congestion 884 Information", RFC 5696, 885 November 2009. 887 [RFC5865] Baker, F., Polk, J., and M. 888 Dolly, "A Differentiated Services 889 Code Point (DSCP) for Capacity- 890 Admitted Traffic", RFC 5865, 891 May 2010. 893 Appendix A. Choice of Suitable DSCPs 895 This appendix is informative, not normative. 897 A single DSCP has not been defined for use with PCN for several 898 reasons. Firstly, the PCN mechanism is applicable to a variety of 899 different traffic classes. Secondly, Standards Track DSCPs are in 900 increasingly short supply. Thirdly, PCN is not a scheduling 901 behaviour -- rather, it should be seen as being a marking behaviour 902 similar to ECN but intended for inelastic traffic. The choice of 903 which DSCP is most suitable for a given PCN-domain is dependent on 904 the nature of the traffic entering that domain and the link rates of 905 all the links making up that domain. In PCN-domains with sufficient 906 aggregation, the appropriate DSCPs would currently be those for the 907 Real-Time Treatment Aggregate [RFC5127]. It is suggested that 908 admission control could be used for the following service classes 909 (defined in [RFC4594] unless otherwise stated): 911 o Telephony (EF) 913 o Real-time interactive (CS4) 915 o Broadcast Video (CS3) 917 o Multimedia Conferencing (AF4) 918 o the VOICE-ADMIT codepoint defined in [RFC5865]. 920 CS5 is excluded from this list since PCN is not expected to be 921 applied to signalling traffic. 923 PCN-marking is intended to provide a scalable admission-control 924 mechanism for traffic with a high degree of statistical multiplexing. 925 PCN-marking would therefore be appropriate to apply to traffic in the 926 above classes, but only within a PCN-domain containing sufficiently 927 aggregated traffic. In such cases, the above service classes may 928 well all be subject to a single forwarding treatment (treatment 929 aggregate [RFC5127]). However, this does not imply all such IP 930 traffic would necessarily be identified by one DSCP -- each service 931 class might keep a distinct DSCP within the highly aggregated region 932 [RFC5127]. 934 Guidelines for conserving DSCPs by allowing non-admission-controlled- 935 traffic to compete with PCN-traffic are given in Appendix B.1 of 936 [RFC5670]. 938 Additional service classes may be defined for which admission control 939 is appropriate, whether through some future standards action or 940 through local use by certain operators, e.g., the Multimedia 941 Streaming service class (AF3). This document does not preclude the 942 use of PCN in more cases than those listed above. 944 Note: The above discussion is informative not normative, as operators 945 are ultimately free to decide whether to use admission control for 946 certain service classes and whether to use PCN as their mechanism of 947 choice. 949 Appendix B. Co-existence of ECN and PCN 951 This appendix is informative, not normative. It collects together 952 material relevant to co-existence of ECN and PCN, including that 953 spread throughout the body of this specification. If this results in 954 any conflict or ambiguity, the normative text in the body of the 955 specification takes precedence. 957 ECN [RFC3168] is an e2e congestion notification mechanism. As such 958 it is possible that some traffic entering the PCN-domain may also be 959 ECN-capable. The PCN encoding described in this document re-uses the 960 bits of the ECN field in the IP header. Consequently, this disables 961 ECN within the PCN domain. 963 For the purposes of this appendix we define two forms of traffic that 964 might arrive at a PCN-ingress-node. These are admission-controlled 965 traffic (PCN-traffic) and non-admission-controlled traffic (non-PCN- 966 traffic). 968 Flow signalling identifies admission controlled traffic, by 969 associating a filterspec with the need for admission control (e.g. 970 through RSVP or some equivalent message, e.g. from a SIP server to 971 the ingress or from a logically centralised network control system). 972 The PCN-ingress-node re-marks admission-conrolled traffic matching 973 that filterspec to a PCN-compatible DSCP. Note that the term flow 974 need not imply just one microflow, but instead could match an 975 aggregate and/or could depend on the incoming DSCP (see Appendix A). 977 All other traffic can be thought of as non-admission-controlled (and 978 therefore outside the scope of PCN). However such traffic may still 979 need to share the same DSCP as the admission-controlled traffic. 980 This may be due to policy (for instance if it is high priority voice 981 traffic), or may be because there is a shortage of local DSCPs. 983 Unless specified otherwise, for any of the cases in the list below, 984 an IP-in-IP tunnel that complies with[RFC6040] can be used to 985 preserve ECN markings across the PCN domain. The tunnelling action 986 should be applied wholly outside the PCN-domain as illustrated in 987 Figure 2. Then, by the rules of RFC6040, the tunnel egress 988 propagates the ECN field from the inner header, because the PCN- 989 egress will have zeroed the outer ECN field. 991 , . . . . . PCN-domain . . . . . . 992 . ,--------. ,--------. . 993 . _| PCN- |___________________| PCN- |_ . 994 . / | ingress | | egress | \ . 995 .| '---------' '--------' |. 996 | . . . . . . . . . . . . . . .| 997 ,--------. ,--------. 998 _____| Tunnel | | Tunnel |____ 999 | Ingress | - - ECN preserved inside tunnel - - | Egress | 1000 '---------' '--------' 1002 Figure 2: Separation of tunnelling and PCN actions 1004 There are three cases for how e2e ECN traffic may wish to be treated 1005 while crossing a PCN domain: 1007 a) Traffic that does not require PCN admission control: 1008 For example, traffic that does not match flow signaling being used 1009 for admission control. In this case the e2e ECN traffic is not 1010 treated as PCN-traffic. There are two possible scenarios: 1012 * Arriving traffic does not carry a PCN-compatible DSCP: no 1013 action required. 1015 * Arriving traffic carries a DSCP that clashes with a PCN- 1016 compatible DSCP. There are two options: 1018 1. The ingress maps the DSCP to a local DSCP with the same 1019 scheduling PHB as the original DSCP, and the egress re-maps 1020 it to the original PCN-compatible DSCP. 1022 2. The ingress tunnels the traffic, setting the DSCP in the 1023 outer header to a local DSCP with the same scheduling PHB 1024 as the original DSCP. 1026 3. The ingress tunnels the traffic, using the original DSCP in 1027 the outer but setting Not-PCN in the outer header; note 1028 that this turns off ECN for this traffic within the PCN 1029 domain. 1031 The first or second options are recommended unless the operator 1032 is short of local DSCPs. 1034 b) Traffic that requires admission-control: 1035 In this case the e2e ECN traffic is treated as PCN-traffic across 1036 the PCN domain. There are two options. 1038 * The PCN-ingress-node places this traffic in a tunnel with a 1039 PCN-compatible DSCP in the outer header. The PCN-egress zeroes 1040 the ECN-field before decapsulation. 1042 * The PCN-ingress-node drops CE-marked packets and otherwise sets 1043 the ECN-field to NM and sets the DCSP to a PCN-compatible DSCP. 1044 The PCN-egress zeroes the ECN field of all PCN packets; note 1045 that this turns off e2e ECN. 1047 The second option is emphatically not recommended, unless perhaps 1048 as a last resort if tunnelling is not possible for some 1049 insurmountable reason. 1051 c) Traffic that requires PCN admission control where the endpoints 1052 ask to see PCN marks: 1053 Note that this scheme is currently only a tentative idea. 1055 For real-time data generated by an adaptive codec, schemes have 1056 been suggested where PCN marks may be leaked out of the PCN-domain 1057 so that end hosts can drop to a lower data-rate, thus deferring 1058 the need for admission control. Currently such schemes require 1059 further study and the following is for guidance only. 1061 The PCN-ingress-node needs to tunnel the traffic as in Figure 2, 1062 taking care to comply with [RFC6040]. In this case the PCN-egress 1063 does not zero the ECN field contrary to the recommendation in 1064 Section 5.3, so that the [RFC6040] tunnel egress will preserve any 1065 PCN-marking. Note that a PCN-interior-node may change the ECN- 1066 field from 10 to 01 (NM to ThM), which would be interpreted by the 1067 e2e ECN as a change from ECT(0) into ECT(1). This would not be 1068 compatible with the (currently experimental) ECN nonce [RFC3540]. 1070 Appendix C. Example Mapping between Encoding of PCN-Marks in IP and in 1071 MPLS Shim Headers 1073 This appendix is informative not normative. 1075 The 6 bits of the DS field in the IP header provide for 64 1076 codepoints. When encapsulating IP traffic in MPLS, it is useful to 1077 make the DS field information accessible in the MPLS header. 1078 However, the MPLS shim header has only a 3-bit traffic class (TC) 1079 field [RFC5462] providing for 8 codepoints. The operator has the 1080 freedom to define a site-local mapping of the 64 codepoints of the DS 1081 field onto the 8 codepoints in the TC field. 1083 [RFC5129] describes how ECN markings in the IP header can also be 1084 mapped to codepoints in the MPLS TC field. Appendix A of [RFC5129] 1085 gives an informative description of how to support PCN in MPLS by 1086 extending the way MPLS supports ECN. [RFC5129] was written while PCN 1087 specifications were in early draft stages. The following provides a 1088 clearer example of a mapping between PCN in IP and in MPLS using the 1089 PCN terminology and concepts that have since been specified. 1091 To support PCN in a MPLS domain, a PCN-compatible DSCP ('DSCP n') 1092 needs codepoints to be provided in the TC field for all the PCN-marks 1093 used. That means, when for instance only excess-traffic-marking is 1094 used for PCN purposes, the operator needs to define a site-local 1095 mapping to two codepoints in the MPLS TC field for IP headers with: 1097 o DSCP n and NM 1099 o DSCP n and ETM 1101 If both excess-traffic-marking and threshold-marking are used, the 1102 operator needs to define a site-local mapping to codepoints in the 1103 MPLS TC field for IP headers with all three of the 3-in-1 codepoints: 1105 o DSCP n and NM 1107 o DSCP n and ThM 1109 o DSCP n and ETM 1110 In either case, if the operator wishes to support the same Diffserv 1111 PHB but without PCN marking, it will also be necessary to define a 1112 site-local mapping to an MPLS TC codepoint for IP headers marked 1113 with: 1115 o DSCP n and Not-PCN 1117 The above sets of codepoints are required for every PCN-compatible 1118 DSCP. Clearly, given so few TC codepoints are available, it may be 1119 necessary to compromise by merging together some capabilities. 1120 Guidelines for conserving TC codepoints by allowing non-admission- 1121 controlled-traffic to compete with PCN-traffic are given in Appendix 1122 B.1 of [RFC5670]. 1124 Appendix D. Rationale for Difference Between the Schemes using One PCN- 1125 Marking 1127 Readers may notice a difference between the two behaviours in 1128 Section 5.2.3.1 and Section 5.2.3.2. With only Excess-traffic- 1129 marking enabled, an unexpected ThM packet can be re-marked to ETM. 1130 However, with only Threshold-marking, an unexpected ETM packet cannot 1131 be re-marked to ThM. 1133 This apparent inconsistency is deliberate. The behaviour with only 1134 Threshold-marking keeps to the rule of Section 5.2.1 that ETM is more 1135 severe and must never be changed to ThM even though ETM is not a 1136 valid marking in this case. Otherwise implementations would have to 1137 allow operators to configure an exception to this rule, which would 1138 not be safe practice and would require different code in the data- 1139 plane compared to the common behaviour. 1141 Authors' Addresses 1143 Bob Briscoe 1144 BT 1145 B54/77, Adastral Park 1146 Martlesham Heath 1147 Ipswich IP5 3RE 1148 UK 1150 Phone: +44 1473 645196 1151 EMail: bob.briscoe@bt.com 1152 URI: http://bobbriscoe.net/ 1153 Toby Moncaster 1154 Moncaster Internet Consulting 1155 Dukes 1156 Layer Marney 1157 Colchester CO5 9UZ 1158 UK 1160 Phone: +44 7764 185416 1161 EMail: toby@moncaster.com 1162 URI: http://www.moncaster.com/ 1164 Michael Menth 1165 University of Tuebingen 1166 Sand 13 1167 Tuebingen 72076 1168 Germany 1170 Phone: +49 7071 2970505 1171 EMail: menth@informatik.uni-tuebingen.de