idnits 2.17.1 draft-ietf-pcn-3-in-1-encoding-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 21, 2011) is 4724 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) == Unused Reference: 'RFC4301' is defined on line 507, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 3540 ** Downref: Normative reference to an Informational RFC: RFC 4594 ** Downref: Normative reference to an Informational RFC: RFC 5559 ** Obsolete normative reference: RFC 5696 (Obsoleted by RFC 6660) == Outdated reference: A later version (-15) exists of draft-ietf-pcn-cl-edge-behaviour-08 == Outdated reference: A later version (-09) exists of draft-ietf-pcn-encoding-comparison-05 == Outdated reference: A later version (-12) exists of draft-ietf-pcn-sm-edge-behaviour-05 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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 Intended status: Standards Track Moncaster Internet Consulting 6 Expires: November 22, 2011 M. Menth 7 University of Tuebingen 8 May 21, 2011 10 Encoding 3 PCN-States in the IP header using a single DSCP 11 draft-ietf-pcn-3-in-1-encoding-05 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 On every link in the PCN domain, the overall rate of the PCN-traffic 18 is metered, and PCN-packets are appropriately marked when certain 19 configured rates are exceeded. Egress nodes provide decision points 20 with information about the PCN-marks of PCN-packets which allows them 21 to take decisions about whether to admit or block a new flow request, 22 and to terminate some already admitted flows during serious pre- 23 congestion. 25 This document specifies how PCN-marks are to be encoded into the IP 26 header by re-using the Explicit Congestion Notification (ECN) 27 codepoints within a PCN-domain. This encoding builds on the baseline 28 encoding of RFC5696 and provides for three different PCN marking 29 states using a single DSCP: not-marked (NM), threshold-marked (ThM) 30 and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN 31 encoding. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 22, 2011. 50 Copyright Notice 52 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Changes in This Version (to be removed by RFC Editor) . . 4 69 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 70 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Requirements for and Applicability of 3-in-1 PCN Encoding . . 5 72 3.1. PCN Requirements . . . . . . . . . . . . . . . . . . . . . 5 73 3.2. Requirements Imposed by Baseline Encoding . . . . . . . . 6 74 3.3. Applicability of 3-in-1 PCN Encoding . . . . . . . . . . . 7 75 4. Definition of 3-in-1 PCN Encoding . . . . . . . . . . . . . . 7 76 5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN 77 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 79 6.1. Backward Compatibility with Pre-existing PCN 80 Implementations . . . . . . . . . . . . . . . . . . . . . 9 81 6.2. Recommendations for the Use of PCN Encoding Schemes . . . 9 82 6.2.1. Use of Both Excess-Traffic-Marking and 83 Threshold-Marking . . . . . . . . . . . . . . . . . . 10 84 6.2.2. Unique Use of Excess-Traffic-Marking . . . . . . . . . 10 85 6.2.3. Unique Use of Threshold-Marking . . . . . . . . . . . 10 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 88 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 90 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 11 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 93 12.2. Informative References . . . . . . . . . . . . . . . . . . 12 94 Appendix A. Co-existence of ECN and PCN (informative) . . . . . . 13 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 97 1. Introduction 99 The objective of Pre-Congestion Notification (PCN) [RFC5559] is to 100 protect the quality of service (QoS) of inelastic flows within a 101 Diffserv domain, in a simple, scalable, and robust fashion. Two 102 mechanisms are used: admission control, to decide whether to admit or 103 block a new flow request, and flow termination to terminate some 104 existing flows during serious pre-congestion. To achieve this, the 105 overall rate of PCN-traffic is metered on every link in the domain, 106 and PCN-packets are appropriately marked when certain configured 107 rates are exceeded. These configured rates are below the rate of the 108 link thus providing notification to boundary nodes about overloads 109 before any real congestion occurs (hence "pre-congestion 110 notification"). 112 [RFC5670] provides for two metering and marking functions that are 113 configured with reference rates. Threshold-marking marks all PCN 114 packets once their traffic rate on a link exceeds the configured 115 reference rate (PCN-threshold-rate). Excess-traffic-marking marks 116 only those PCN packets that exceed the configured reference rate 117 (PCN-excess-rate). The PCN-excess-rate is typically larger than the 118 PCN-threshold-rate [RFC5559]. Egress nodes monitor the PCN-marks of 119 received PCN-packets and provide information about the PCN-marks to 120 decision points which take decisions about flow admission and 121 termination on this basis [I-D.ietf-pcn-cl-edge-behaviour], 122 [I-D.ietf-pcn-sm-edge-behaviour]. 124 The baseline encoding defined in [RFC5696] describes how two PCN 125 marking states (Not-marked and PCN-Marked) can be encoded using a 126 single Diffserv codepoint. It also provides an experimental 127 codepoint (EXP), along with guidelines for use of that codepoint. To 128 support the application of two different marking algorithms in a PCN- 129 domain, for example as required in [I-D.ietf-pcn-cl-edge-behaviour], 130 three PCN marking states are needed. This document describes an 131 extension to the baseline encoding that uses the EXP codepoint to 132 provide a third PCN marking state in the IP header, still using a 133 single Diffserv codepoint. This encoding scheme is called "3-in-1 134 PCN encoding". 136 This document only concerns the PCN wire protocol encoding for all IP 137 headers, whether IPv4 or IPv6. It makes no changes or 138 recommendations concerning algorithms for congestion marking or 139 congestion response. Other documents define the PCN wire protocol 140 for other header types. For example, the MPLS encoding is defined in 141 [RFC5129] and Appendix A of that document provides an informative 142 example for a mapping between the encodings in IP and in MPLS. 144 1.1. Changes in This Version (to be removed by RFC Editor) 146 From draft-ietf-pcn-3-in-1-encoding-04 to -05: 148 * Draft moved to standards track as per working group 149 discussions. 151 * Added Appendix A discussing ECN handling in the PCN-domain. 153 * Clarified that this document modifies [RFC5696]. 155 * ....... 157 From draft-ietf-pcn-3-in-1-encoding-03 to -04: 159 * Updated document to reflect RFC6040. 161 * Re-wrote introduction. 163 * Re-wrote section on applicability. 165 * Re-wrote section on choosing encoding scheme. 167 * Updated author details. 169 From draft-ietf-pcn-3-in-1-encoding-02 to -03: 171 * Corrected mistakes in introduction and improved overall 172 readability. 174 * Added new terminology. 176 * Rewrote a good part of Section 4 and 5 to achieve more clarity. 178 * Added appendix explaining when to use which encoding scheme and 179 how to encode them in MPLS shim headers. 181 * Added new co-author. 183 From draft-ietf-pcn-3-in-1-encoding-01 to -02: 185 * Corrected mistake in introduction, which wrongly stated that 186 the threshold-traffic rate is higher than the excess-traffic 187 rate. Other minor corrections. 189 * Updated acks & refs. 191 From draft-ietf-pcn-3-in-1-encoding-00 to -01: 193 * Altered the wording to make sense if 194 draft-ietf-tsvwg-ecn-tunnel moves to proposed standard. 196 * References updated 198 From draft-briscoe-pcn-3-in-1-encoding-00 to 199 draft-ietf-pcn-3-in-1-encoding-00: 201 * Filename changed to draft-ietf-pcn-3-in-1-encoding. 203 * Introduction altered to include new template description of 204 PCN. 206 * References updated. 208 * Terminology brought into line with [RFC5670]. 210 * Minor corrections. 212 2. Requirements Language 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 216 document are to be interpreted as described in [RFC2119]. 218 2.1. Terminology 220 General PCN-related terminology is defined in the PCN architecture 221 [RFC5559], and terminology specific to packet encoding is defined in 222 the PCN baseline encoding [RFC5696]. Additional terminology is 223 defined below. 225 PCN encoding: mapping of PCN marking states to specific codepoints 226 in the packet header. 228 3. Requirements for and Applicability of 3-in-1 PCN Encoding 230 3.1. PCN Requirements 232 In accordance with the PCN architecture [RFC5559], PCN-ingress-nodes 233 control packets entering a PCN-domain. Packets belonging to PCN- 234 controlled flows are subject to PCN-metering and -marking, and PCN- 235 ingress-nodes mark them as Not-marked (PCN-colouring). Any node in 236 the PCN-domain may perform PCN-metering and -marking and mark PCN- 237 packets if needed. There are two different metering and marking 238 schemes: threshold-marking and excess-traffic-marking [RFC5670]. 239 Some edge behaviors require only a single marking scheme 240 [I-D.ietf-pcn-sm-edge-behaviour], others require both 241 [I-D.ietf-pcn-cl-edge-behaviour]. In the latter case, three PCN 242 marking states are needed: not-marked (NM) to indicate not-marked 243 packets, threshold-marked (ThM) to indicate packets marked by the 244 threshold-marker, and excess-traffic-marked (ETM) to indicate packets 245 marked by the excess-traffic-marker [RFC5670]. Threshold-marking and 246 excess-traffic-marking are configured to start marking packets at 247 different load conditions, so one marking scheme indicates more 248 severe pre-congestion than the other. Therefore, a fourth PCN 249 marking state indicating that a packet is marked by both markers is 250 not needed. However a fourth codepoint is required to indicate 251 packets that are not PCN-capable (the not-PCN codepoint). 253 In all current PCN edge behaviors that use two marking schemes 254 [RFC5559], [I-D.ietf-pcn-cl-edge-behaviour], excess-traffic-marking 255 is configured with a larger reference rate than threshold-marking. 256 We take this as a rule and define excess-traffic-marked as a more 257 severe PCN-mark than threshold-marked. 259 3.2. Requirements Imposed by Baseline Encoding 261 The baseline encoding scheme [RFC5696] was defined so that it could 262 be extended to accommodate an additional marking state. It provides 263 rules to embed the encoding of two PCN states in the IP header. 264 Figure 1 shows the structure of the former type-of-service field. It 265 contains the 6-bit Differentiated Services (DS) field that holds the 266 DS codepoint (DSCP) [RFC2474] and the 2-bit ECN field [RFC3168]. 268 0 1 2 3 4 5 6 7 269 +-----+-----+-----+-----+-----+-----+-----+-----+ 270 | DS FIELD | ECN FIELD | 271 +-----+-----+-----+-----+-----+-----+-----+-----+ 273 Figure 1: Structure of the former type-of-service field in IP 275 Baseline encoding defines that the DSCP must be set to a PCN- 276 compatible DSCP n and the ECN-field [RFC3168] indicates the specific 277 PCN-mark. Baseline encoding offers four possible encoding states 278 within a single DSCP with the following restrictions. 280 o Codepoint `00' (not-ECT) is used to indicate non-PCN traffic as 281 "not-PCN". This allows both PCN and non-PCN traffic to use the 282 same DSCP. 284 o Codepoint `10' (ECT(0)) is used to indicate Not-marked PCN 285 traffic. 287 o Codepoint `11' (CE) is used to indicate the most severe PCN-mark. 289 o Codepoint `01' (ECT(1)) is available for experimental use and may 290 be re-used by other PCN encodings such as the presently defined 291 3-in-1 PCN encoding (subject to the rules defined in [RFC5696]). 293 [RFC6040] defines rules for the encapsulation and decapsulation of 294 ECN markings within IP-in-IP tunnels. This RFC removes some of the 295 constraints that existed when [RFC5696] was written. Happily the 296 rules for use of the EXP codepoint are fully compatible with 297 [RFC6040]. In particular, the relative severity of each marking is 298 the same: CE (PM) is more severe than ECT(1) (EXP) is more severe 299 than ECT(0) (NM). This is discussed in more detail in both the 300 baseline encoding document [RFC5696] and in 301 [I-D.ietf-pcn-encoding-comparison]. 303 3.3. Applicability of 3-in-1 PCN Encoding 305 The 3-in-1 encoding is applicable in situations where two marking 306 schemes are being used in the PCN-domain. In some circumstances it 307 can also be used in PCN-domains with only a single marking scheme in 308 use. Further guidance on choosing an encoding scheme can be found in 309 Section 6.2. All nodes within the PCN-domain MUST be fully compliant 310 with the ECN encapsulation rules set out in [RFC6040]. As such the 311 encoding is not applicable in situations where legacy tunnels might 312 exist. 314 4. Definition of 3-in-1 PCN Encoding 316 The 3-in-1 PCN encoding scheme is an extension of the baseline 317 encoding scheme defined in [RFC5696]. The PCN requirements and the 318 extension rules for baseline encoding presented in the previous 319 section determine how PCN encoding states are carried in the IP 320 headers. This is shown in Figure 2. 322 +--------+----------------------------------------------------+ 323 | | Codepoint in ECN field of IP header | 324 | DSCP | | 325 | +--------------+-------------+-------------+---------+ 326 | | 00 | 10 | 01 | 11 | 327 +--------+--------------+-------------+-------------+---------+ 328 | DSCP n | Not-PCN | NM | ThM | ETM | 329 +--------+--------------+-------------+-------------+---------+ 330 Figure 2: 3-in-1 PCN Encoding 332 Like baseline encoding, 3-in-1 PCN encoding also uses a PCN 333 compatible DSCP n and the ECN field for the encoding of PCN-marks. 334 The PCN-marks have the following meaning. 336 Not-PCN: indicates a non-PCN-packet, i.e., a packet that is not 337 subject to PCN metering and marking. 339 NM: Not-marked. Indicates a PCN-packet that has not yet been marked 340 by any PCN marker. 342 ThM: Threshold-marked. Indicates a PCN-packet that has been marked 343 by a threshold-marker [RFC5670]. 345 ETM: Excess-traffic-marked. Indicates a PCN-packet that has been 346 marked by an excess-traffic-marker [RFC5670]. 348 5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding 350 To be compliant with the 3-in-1 PCN Encoding, an PCN interior node 351 behaves as follows: 353 o It MUST change NM to ThM if the threshold-meter function indicates 354 a need to mark the packet; 356 o It MUST change NM or ThM to ETM if the excess-traffic-meter 357 function indicates a need to mark the packet; 359 o It MUST NOT change not-PCN to NM, ThM, or ETM; 361 o It MUST NOT change a NM, ThM, or ETM to not-PCN; 363 o It MUST NOT change ThM to NM; 365 o It MUST NOT change ETM to ThM or to NM; 367 In other words, a PCN interior node MUST NOT mark PCN-packets into 368 non-PCN packets and vice-versa, and it may increase the severity of 369 the PCN-mark of a PCN-packet, but it MUST NOT decrease it. 371 6. Backward Compatibility 373 Discussion of backward compatibility between PCN encoding schemes and 374 previous uses of the ECN field is given in Section 6 of [RFC5696]. 376 6.1. Backward Compatibility with Pre-existing PCN Implementations 378 This encoding complies with the rules for extending the baseline PCN 379 encoding schemes in Section 5 of [RFC5696]. 381 The term "compatibility" is meant in the following sense. It is 382 possible to operate nodes with baseline encoding [RFC5696] and 3-in-1 383 encoding in the same PCN domain. The nodes with baseline encoding 384 MUST perform excess-traffic-marking because the 11 codepoint of 385 3-in-1 encoding also means excess-traffic-marked. PCN-boundary-nodes 386 of such domains are required to interpret the full 3-in-1 encoding 387 and not just baseline encoding, otherwise they cannot interpret the 388 01 codepoint. 390 Using nodes that perform only excess-traffic-marking may make sense 391 in networks using the CL edge behavior 392 [I-D.ietf-pcn-cl-edge-behaviour]. Such nodes are able to notify the 393 egress only about severe pre-congestion when traffic needs to be 394 terminated. This seems reasonable for locations that are not 395 expected to see any pre-congestion, but excess-traffic-marking gives 396 them a means to terminate traffic if unexpected overload occurs. 398 6.2. Recommendations for the Use of PCN Encoding Schemes 400 NOTE: This sub-section is informative not normative. 402 When deciding which PCN encoding is suitable an operator needs to 403 take account of how many PCN states need to be encoded. The 404 following table gives guidelines on which encoding to use with either 405 threshold-marking, excess-traffic marking or both. 407 +------------------------+--------------------------------+ 408 | Marking schemes in use | Recommended encoding scheme | 409 +------------------------+--------------------------------+ 410 | Only threshold-marking | Baseline encoding [RFC5696] | 411 +------------------------+--------------------------------+ 412 | Only excess-traffic- | Baseline encoding [RFC5696] | 413 | marking | or 3-in-1 PCN encoding | 414 +------------------------+--------------------------------+ 415 | Threshold-marking and | 3-in-1 PCN encoding | 416 | excess-traffic-marking | | 417 +------------------------+--------------------------------+ 419 Figure 3: Guidelines for choosing PCN encoding schemes 421 6.2.1. Use of Both Excess-Traffic-Marking and Threshold-Marking 423 If both excess-traffic-marking and threshold-marking are enabled in a 424 PCN-domain, 3-in-1 encoding should be used as described in this 425 document. 427 6.2.2. Unique Use of Excess-Traffic-Marking 429 If only excess-traffic-marking is enabled in a PCN-domain, baseline 430 encoding or 3-in-1 encoding may be used. They lead to the same 431 encoding because PCN-boundary nodes will interpret baseline "PCN- 432 marked (PM)" as "excess-traffic-marked (ETM)". 434 6.2.3. Unique Use of Threshold-Marking 436 No scheme is currently proposed that solely uses threshold-marking. 437 If such a scheme is proposed, the choice of encoding scheme will 438 depend on whether nodes are compliant with [RFC6040] or not. Where 439 it is certain that all nodes in the PCN-domain are compliant then 440 either 3-in-1 encoding or baseline encoding are suitable. If legacy 441 tunnel decapsulators exist within the PCN-domain then baseline 442 encoding SHOULD be used. 444 7. IANA Considerations 446 This memo includes no request to IANA. 448 Note to RFC Editor: this section may be removed on publication as an 449 RFC. 451 8. Security Considerations 453 The security concerns relating to this extended PCN encoding are the 454 same as those in [RFC5696]. In summary, PCN-boundary nodes are 455 responsible for ensuring inappropriate PCN markings do not leak into 456 or out of a PCN domain, and the current phase of the PCN architecture 457 assumes that all the nodes of a PCN-domain are entirely under the 458 control of a single operator, or a set of operators who trust each 459 other. 461 Given the only difference between the baseline encoding and the 462 present 3-in-1 encoding is the use of the 01 codepoint, no new 463 security issues are raised, as this codepoint was already available 464 for experimental use in the baseline encoding. 466 9. Conclusions 468 The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field 469 to encode PCN-marks. One codepoint allows non-PCN traffic to be 470 carried with the same PCN-compatible DSCP and three other codepoints 471 support three PCN marking states with different levels of severity. 472 The use of this PCN encoding scheme presupposes that any tunnels in 473 the PCN region have been updated to comply with [RFC6040]. 475 10. Acknowledgements 477 Thanks to Phil Eardley, Teco Boot, Kwok Ho Chan and Georgios 478 Karaginannis for reviewing this document. 480 11. Comments Solicited 482 To be removed by RFC Editor: Comments and questions are encouraged 483 and very welcome. They can be addressed to the IETF Congestion and 484 Pre-Congestion working group mailing list , and/or to 485 the authors. 487 12. References 489 12.1. Normative References 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, March 1997. 494 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 495 "Definition of the Differentiated Services Field (DS 496 Field) in the IPv4 and IPv6 Headers", RFC 2474, 497 December 1998. 499 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 500 of Explicit Congestion Notification (ECN) to IP", 501 RFC 3168, September 2001. 503 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 504 Congestion Notification (ECN) Signaling with Nonces", 505 RFC 3540, June 2003. 507 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 508 Internet Protocol", RFC 4301, December 2005. 510 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 511 Guidelines for DiffServ Service Classes", RFC 4594, 512 August 2006. 514 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 515 Marking in MPLS", RFC 5129, January 2008. 517 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 518 Architecture", RFC 5559, June 2009. 520 [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- 521 Nodes", RFC 5670, November 2009. 523 [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline 524 Encoding and Transport of Pre-Congestion Information", 525 RFC 5696, November 2009. 527 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 528 Services Code Point (DSCP) for Capacity-Admitted Traffic", 529 RFC 5865, May 2010. 531 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 532 Notification", RFC 6040, November 2010. 534 12.2. Informative References 536 [I-D.ietf-pcn-cl-edge-behaviour] 537 Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. 538 Taylor, "PCN Boundary Node Behaviour for the Controlled 539 Load (CL) Mode of Operation", 540 draft-ietf-pcn-cl-edge-behaviour-08 (work in progress), 541 December 2010. 543 [I-D.ietf-pcn-encoding-comparison] 544 Karagiannis, G., Chan, K., Moncaster, T., Menth, M., 545 Eardley, P., and B. Briscoe, "Overview of Pre-Congestion 546 Notification Encoding", 547 draft-ietf-pcn-encoding-comparison-05 (work in progress), 548 April 2011. 550 [I-D.ietf-pcn-sm-edge-behaviour] 551 Charny, A., Karagiannis, G., Menth, M., and T. Taylor, 552 "PCN Boundary Node Behaviour for the Single Marking (SM) 553 Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-05 554 (work in progress), December 2010. 556 Appendix A. Co-existence of ECN and PCN (informative) 558 The PCN encoding described in this document re-uses the bits of the 559 ECN field in the IP header. Consequently, this disables ECN within 560 the PCN domain. Appendix B of [RFC5696] included advice on handling 561 ECN traffic within a PCN-domain. This appendix clarifies that 562 advice. 564 For the purposes of this appendix we define two forms of traffic that 565 might arrive at a PCN-ingress node. These are Admission-controlled 566 traffic and Non-admission-controlled traffic. 568 Admission-controlled traffic will be remarked to the PCN-compatible 569 DSCP by the PCN-ingress node. Two mechanisms can be used to identify 570 such traffic: 572 a. flow signalling associates a filterspec with a need for admission 573 control (e.g. through RSVP or some equivalent message down from a 574 SIP server to the ingress), and the PCN-ingress remarks traffic 575 matching that filterspec to a PCN-compatible DSCP, as its chosen 576 admission control mechanism. 578 b. Traffic arrives with a DSCP that implies it requires admission 579 control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time, 580 Broadcast TV when used for video on demand, and Multimedia 581 Conferencing [RFC4594][RFC5865]. 583 All other traffic can be thought of as Non-admission-controlled. 584 However such traffic may still need to share the same DSCP as the 585 Admission-controlled traffic. This may be due to policy (for 586 instance if it is high priority voice traffic), or may be because 587 there is a shortage of local DSCPs. 589 ECN [RFC3168] is an end-to-end congestion notification mechanism. As 590 such it is possible that some traffic entering the PCN-domain may 591 also be ECN capable The following lists the four cases for how e2e 592 ECN traffic may wish to be treated while crossing a PCN domain: 594 ECN capable traffic that does not require admission control and does 595 not carry a DSCP that the PCN-ingress is using for PCN-capable 596 traffic. This requires no action. 598 ECN capable traffic that does not require admission control but 599 carries a DSCP that the PCN-ingress is using for PCN-capable 600 traffic. There are two options. 602 * The ingress maps the DSCP to a local DSCP with the same 603 scheduling PHB as the original DSCP, and the egress re-maps it 604 to the original PCN-compatible DSCP. 606 * The ingress tunnels the traffic, setting not-PCN in the outer 607 header; note that this turns off ECN for this traffic within 608 the PCN domain. 610 The first option is recommended unless the operator is short of 611 local DSCPs. 613 ECN-capable Admission-controlled traffic: There are two options. 615 * The PCN-ingress places this traffic in a tunnel with a PCN- 616 compatible DSCP in the outer header. The PCN-egress zeroes the 617 ECN-field before decapsulation. 619 * The PCN-ingress drops CE-marked packets and the PCN-egress 620 zeros the ECN field of all PCN packets. 622 The second option is not recommended unless tunnelling is not 623 possible for some reason.. 625 ECN-capable Admission-controlled where the e2e transport somehow 626 indicates that it wants to see PCN marks: NOTE this is currently 627 experimental only. 629 Schemes have been suggested where PCN marks may be leaked out of 630 the PCN-domain and used by the end hosts to modify realtime data 631 rates. Currently all such schemes are experimental and the 632 following is for guidance only. 634 The PCN-ingress needs to tunnel the traffic using [RFC6040]. The 635 PCN-egress should not zero the ECN field, and the tunnel egress 636 should use [RFC6040] normal mode (preserving any PCN-marking). 637 Note that this may turn ECT(0) into ECT(1) and so is not 638 compatible with the experimental ECN nonce [RFC3540]. 640 In the list above any form of IP-in-IP tunnel can be used unless 641 specified otherwise. NB, We assume a logical separation of tunneling 642 and PCN actions in both PCN-ingress and PCN-egress nodes. That is, 643 any tunneling action happens wholly outside the PCN-domain as 644 illustrated in the following figure: 646 , . . . . . PCN-domain . . . . . . 647 . ,--------. ,--------. . 648 . _| PCN- |___________________| PCN- |_ . 649 . / | ingress | | egress | \ . 650 .| '---------' '--------' |. 651 | . . . . . . . . . . . . . . .| 652 ,--------. ,--------. 653 _____| Tunnel | | Tunnel |____ 654 | Ingress | - - ECN preserved inside tunnel - - | Egress | 655 '---------' '--------' 657 Figure 4: Separation of tunneling and PCN actions 659 Authors' Addresses 661 Bob Briscoe 662 BT 663 B54/77, Adastral Park 664 Martlesham Heath 665 Ipswich IP5 3RE 666 UK 668 Phone: +44 1473 645196 669 Email: bob.briscoe@bt.com 670 URI: http://bobbriscoe.net/ 672 Toby Moncaster 673 Moncaster Internet Consulting 674 Dukes 675 Layer Marney 676 Colchester CO5 9UZ 677 UK 679 Phone: +44 7764 185416 680 Email: toby@moncaster.com 681 URI: http://www.moncaster.com/ 682 Michael Menth 683 University of Tuebingen 684 Sand 13 685 Tuebingen 72076 686 Germany 688 Phone: +49 7071 2970505 689 Email: menth@informatik.uni-tuebingen.de