idnits 2.17.1 draft-ietf-pcn-encoding-comparison-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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 08, 2012) is 4404 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == 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 == Outdated reference: A later version (-11) exists of draft-ietf-pcn-3-in-1-encoding-08 == Outdated reference: A later version (-02) exists of draft-ietf-pcn-3-state-encoding-01 == Outdated reference: A later version (-02) exists of draft-ietf-pcn-psdm-encoding-01 -- Obsolete informational reference (is this intentional?): RFC 5696 (Obsoleted by RFC 6660) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCN G. Karagiannis 2 Internet-Draft University of Twente 3 Intended status: Informational K. Chan 4 Expires: September 08, 2012 Consultant 5 T. Moncaster 6 University of Cambridge 7 M. Menth 8 University of Tuebingen 9 P. Eardley 10 B. Briscoe 11 BT 12 March 08, 2012 14 Overview of Pre-Congestion Notification Encoding 15 draft-ietf-pcn-encoding-comparison-09 17 Abstract 19 The objective of Pre-Congestion Notification (PCN) is to protect the 20 quality of service (QoS) of inelastic flows within a Diffserv domain. 21 On every link in the PCN domain, the overall rate of the PCN-traffic 22 is metered, and PCN-packets are appropriately marked when certain 23 configured rates are exceeded. Egress nodes provide decision points 24 with information about the PCN-marks of PCN-packets which allows them 25 to take decisions about whether to admit or block a new flow request, 26 and to terminate some already admitted flows during serious pre- 27 congestion. 29 The PCN Working Group explored a number of approaches for encoding 30 this pre-congestion information into the IP header. This document 31 provides details of all those approaches along with an explanation of 32 the constraints that had to be met by any solution. 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." 49 This Internet-Draft will expire on September 08, 2012. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. General PCN Encoding Requirements . . . . . . . . . . . . . . 4 70 2.1. Metering and Marking Algorithms . . . . . . . . . . . . . 5 71 2.2. Approaches for PCN Based Admission Control and Flow 72 Termination . . . . . . . . . . . . . . . . . . . . . . . 5 73 2.2.1. Dual Marking (DM) . . . . . . . . . . . . . . . . . . 5 74 2.2.2. Single Marking (SM) . . . . . . . . . . . . . . . . . 6 75 2.2.3. Packet Specific Dual Marking (PSDM) . . . . . . . . . 7 76 2.2.4. Preferential Packet Dropping . . . . . . . . . . . . . 8 77 3. Encoding Constraints . . . . . . . . . . . . . . . . . . . . . 8 78 3.1. Structure of the DS Field . . . . . . . . . . . . . . . . 8 79 3.2. Constraints from the DSCP . . . . . . . . . . . . . . . . 8 80 3.2.1. General Scarcity of DSCPs . . . . . . . . . . . . . . 8 81 3.2.2. Handling of the DSCP in Tunneling Rules 9 82 3.2.3. Restoration of Original DSCPs at the Egress Node . . . 9 83 3.3. Constraints from the ECN Field . . . . . . . . . . . . . . 10 84 3.3.1. Structure and Use of the ECN Field . . . . . . . . . . 10 85 3.3.2. Redefinition of the ECN Field . . . . . . . . . . . . 10 86 3.3.3. Handling of the ECN Field in Tunneling Rules . . . . . 11 87 3.3.4. Restoration of the Original ECN Field at the 88 PCN-Egress-Node . . . . . . . . . . . . . . . . . . . 13 90 4. Comparison of Encoding Options . . . . . . . . . . . . . . . . 13 91 4.1. Baseline Encoding . . . . . . . . . . . . . . . . . . . . 14 92 4.2. Encoding with 1 DSCP Providing 3 States . . . . . . . . . 14 93 4.3. Encoding with 2 DSCPs Providing 3 or More States . . . . . 15 94 4.4. Encoding for Packet Specific Dual Marking (PSDM) . . . . . 15 95 4.5. Standardized Encodings . . . . . . . . . . . . . . . . . . 15 96 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 6. Security Implications . . . . . . . . . . . . . . . . . . . . 16 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 101 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 102 9.2. Informative References . . . . . . . . . . . . . . . . . 16 104 1. Introduction 106 The objective of Pre-Congestion Notification (PCN) [RFC5559] is to 107 protect the quality of service (QoS) of inelastic flows within a 108 Diffserv domain, in a simple, scalable, and robust fashion. Two 109 mechanisms are used: admission control, to decide whether to admit or 110 block a new flow request, and flow termination to terminate some 111 existing flows during serious pre-congestion. To achieve this, the 112 overall rate of PCN-traffic is metered on every link in the domain, 113 and PCN-packets are appropriately marked when certain configured 114 rates are exceeded. These configured rates are below the rate of the 115 link. Thus boundary nodes are notified of a potential overload before 116 any real congestion occurs (hence "pre-congestion notification"). 118 [RFC5670] provides for two metering and marking functions that are 119 configured with reference rates. Threshold-marking marks all PCN 120 packets once their traffic rate on a link exceeds the configured 121 reference rate (PCN-threshold-rate). Excess-traffic-marking marks 122 only those PCN packets that exceed the configured reference rate 123 (PCN-excess-rate). 125 Egress nodes monitor the PCN-marks of received PCN-packets and 126 provide information about the PCN-marks to decision points which take 127 decisions about flow admission and termination on this basis 128 [I-D.ietf-pcn-cl-edge-behaviour], [I-D.ietf-pcn-sm-edge-behaviour]. 130 This PCN information has to be encoded into the IP header. This PCN 131 information has to be encoded into the IP header. This requires at 132 least three different codepoints: one for PCN traffic that has not 133 been marked, one for traffic that has been marked by the threshold 134 meter and one for traffic that has been marked by the excess-traffic- 135 meter. 136 Since unused codepoints are not available for that purpose in the IP 137 header (version 4 and 6), already used codepoints must be re-used 138 which imposes additional constraints on design and applicability of 139 PCN-based admission control (AC) and flow termination (FT). This 140 document summarizes these issues as a record of the PCN WG 141 discussions and for the benefit of the wider IETF community. 143 In Section 2, we briefly point out PCN encoding requirement imposed 144 by metering and marking algorithms, and by special packet drop 145 strategies. The Differentiated Services Codepoint (6 bits) and the 146 ECN field (2 bits) have been selected to be re-used for encoding of 147 PCN marks (PCN encoding). In Section 3, we briefly explain the 148 constraints imposed by this decision. In Section 4, we review 149 different PCN encodings supported by the PCN working group that allow 150 different implementations of PCN-based admission control and flow 151 termination which have different pros and cons. 153 2. General PCN Encoding Requirements 155 The choice of metering and marking algorithms and the way they are 156 applied to PCN-based AC and FT impose certain requirements on PCN 157 encoding. 159 2.1. Metering and Marking Algorithms 161 Two different metering and marking algorithms are defined in 162 [RFC5670]: excess-traffic-marking and threshold-marking. They are 163 both configured with reference rates which are termed PCN-excess-rate 164 and PCN-threshold-rate, respectively. When traffic for PCN flows 165 enter a PCN domain, the PCN ingress node sets a codepoint in the IP 166 header indicating that the packet is subject to PCN metering and 167 marking and that it is not-marked (NM). The two metering and marking 168 algorithms possibly re-mark PCN packets as PCN and excess-traffic- 169 marked (ETM) or threshold-marked (ThM). 171 Excess-traffic-marking leaves a rate of PCN traffic equal to the PCN- 172 excess-rate to be not-ETM marked if possible. To that end, the 173 algorithm needs to know whether a PCN packet has already been ETM 174 marked or not. Threshold-marking re-marks all not-marked PCN traffic 175 to ThM when the rate of PCN traffic exceeds the PCN-threshold-rate. 176 Therefore, it does not need knowledge of the prior marking state of 177 the packet for metering, but it needs it for packet re-marking. 179 2.2. Approaches for PCN-Based Admission Control and Flow Termination 181 We briefly review three different approaches to implement PCN-based 182 AC and FT and derive their requirements for PCN encoding. 184 2.2.1. Dual Marking (DM) 186 The intuitive approach for PCN-based AC and FT requires that 187 threshold and excess-traffic-marking are simultaneously activated on 188 all links of a PCN domain and their reference rate is configured with 189 the PCN-admissible-rate (AR) and the PCN-supportable-rate (SR), 190 respectively. Threshold-marking meters all PCN traffic, but re-marks 191 only not-marked traffic (NM) to ThM. Excess-traffic-marking meters 192 only non-ETM traffic and re-marks either not-marked (NM) or 193 threshold-marked (ThM) PCN traffic to ETM. Thus, both meters and 194 markers need to identify PCN packets and their exact PCN codepoint. 195 We call this marking behavior dual marking (DM) and Figure 1 196 illustrates all possible re-marking actions. 198 NM -----------> ThM 199 \ / 200 \ / 201 \ / 202 > ETM < 204 Figure 1: PCN Codepoint Re-Marking Diagram for Dual Marking (DM) 206 Dual marking is used to support the Controlled-Load PCN (CL-PCN) edge 207 behavior [I-D.ietf-pcn-cl-edge-behaviour]. We briefly summarize the 208 concept. All actions are performed on per ingress-egress-aggregate 209 basis. The egress node measures the rate of NM-, ThM-, and ETM- 210 traffic in regular intervals and sends them as PCN egress reports to 211 the AC and FT decision point. 213 If the proportion of re-marked (ThM- and ETM-) PCN traffic is larger 214 than a defined threshold, called CLE-limit, the decision point blocks 215 new flow requests until new PCN egress reports are received, 216 otherwise it admits them. With CL-PCN, AC is rather robust with 217 regard to the value chosen for the CLE-limit. FT works as follows. If 218 the ETM-traffic rate is positive, the decision point triggers the 219 ingress node to send a newly measured rate of the sent PCN traffic. 220 The decision point calculates the rate of PCN traffic that needs to 221 be terminated by: 223 termination-rate = PCN-ingress-rate - (rate-of-NM-traffic + rate-of- 224 ThM-traffic) 226 and terminates an appropriate set of flows. CL-PCN is accurate 227 enough for most application scenarios and its implementation 228 complexity is acceptable, therefore, it is a preferred implementation 229 option for PCN-based AC and FT. 231 2.2.2. Single Marking (SM) 233 Single-marking uses only excess-traffic-marking whose reference rate 234 is set to the PCN-admissible-rate (AR) on all links of the PCN 235 domain. Figure 2 illustrates all possible re-marking actions. 237 NM --------> ETM 239 Figure 2: PCN Codepoint Re-Marking Diagram for Single Marking (SM) 241 Single marking is used to support the single-marking PCN (SM-PCN) 242 edge behavior [I-D.ietf-pcn-sm-edge-behaviour]. We briefly summarize 243 the concept. AC works essentially in the same way as with CL-PCN but 244 AC is sensitive to the value of the CLE-limit. Also FT 245 works similarly to CL-PCN. The PCN-supportable-rate (SR) is not 246 configured on any link, but is implicitly: 248 SR=u*AR 250 in the PCN domain using a network-wide constant u. The decision 251 point triggers FT only if the rate-of-NM-traffic * u < rate-of-NM- 252 traffic + rate-of-ETM-traffic, requests the PCN-sent-rate from the 253 corresponding PCN-ingress-node, calculates the amount of PCN traffic 254 to be terminated by 256 termination-rate = PCN-sent-rate - rate-of-NM-traffic * u, 258 and terminates an appropriate set of flows. 260 SM-PCN has two major benefits: it requires only two PCN codepoints 261 and only excess-traffic-marking is needed which means that it might 262 be earlier to the market than CL-PCN since some chipsets do not yet 263 support threshold-marking. 265 However, it only works well when ingress-egress-aggregates have a 266 high PCN packet rate which is not always the case. Otherwise, over- 267 admission and over-termination may occur [Menth12] [Menth10q]. 269 2.2.3. Packet Specific Dual Marking (PSDM) 271 Packet-specific dual marking (PSDM) uses threshold-marking and 272 excess-traffic-marking whose reference rates are configured with the 273 PCN-admissible-rate and the PCN-supportable-rate, respectively. 274 There are two different types of not-marked packets: those that are 275 subject to threshold-marking (not-ThM) and those that are subject to 276 excess-traffic-marking (not-ETM). Both not-Thm and not-ETM have the 277 same NM-marking and are distinguished by higher layer information 278 (see below). Threshold-marking meters all PCN traffic and re-marks 279 only not-ThM packets to PCN-marked (PM). In contrast, excess- 280 traffic-marking meters only not-ETM packets and possibly re-marks 281 them to PM, too. Again, both meters and markers need to identify PCN 282 packets and their exact PCN codepoint. Figure 3 illustrates all 283 possible re-marking actions. 285 not-ThM not-ETM 286 \ / 287 \ / 288 \ / 289 > PM < 291 Figure 3: PCN Codepoint Re-Marking Diagram for Packet Specific Dual 292 Marking (PSDM) 294 An edge behavior for PSDM has been presented in [Menth09f]. We call 295 it PSDM-PCN. In contrast to CL-PCN and SM-PCN, AC is realized by re- 296 using marked signaling messages for probing. The assumption is that 297 admission requests are triggered by an external end-to-end signaling 298 protocol, e.g. RSVP (RFC2205). Signaling traffic for a flow is also 299 labeled as PCN traffic and if an initial signaling traverses the PCN 300 domain and is re-marked, then the corresponding flow is blocked. This 301 is a light-weight probing mechanism which does not generate extra 302 traffic and does not introduce probing delay [draft-menth-pcn-marked- 303 signaling-ac]. In PSDM-PCN, PCN-ingress-nodes label initial signaling 304 messages as not-ThM and threshold-marking configured with admissible 305 rates possibly re-marks them to PM. Data packets are labeled with 306 not-ETM and excess-traffic-marking configured with supportable rates 307 possibly re-marks them to PM, too, so that the same algorithms for FT 308 may be used as for CL-PCN and SM-PCN. 310 Disadvantages of this approach are that every end-to-end signaling 311 protocol, e.g. RSVP, needs to be adapted that it denies admission if 312 initial request messages are re-marked to PM. 313 Advantages are that the AC algorithm is more accurate than the one of 314 CL-PCN and SM-PCN [Menth12], that only a single DSCP is needed, 315 and that the new tunneling rules in RFC6040 are not needed for 316 deployment. 318 2.2.4. Preferential Packet Dropping 320 The termination algorithms described in [I-D.ietf-pcn-cl-edge 321 behaviour] and [I-D.ietf-pcn-sm-edge-behaviour] require the 322 preferential dropping of ETM-marked packets to avoid over-termination 323 in the case of packet loss. An analysis explaining this phenomenon 324 can be found in Section 4 of [Menth10q]. Thus, preferential dropping 325 of ETM-marked packets is "RECOMMENDED" in [RFC5670]. As a 326 consequence, droppers must have access to the exact marking 327 information of PCN-packets. 329 3. Encoding Constraints 331 The PCN WG decided to use the DS field (i.e., combination of the DSCP 332 and ECN field) for the encoding of the PCN Marks, see [RFC5696]. 333 This section describes the criteria that are used to compare the 334 resulting encoding options described in section 4. 336 3.1. Structure of the DS Field 338 Figure 4 shows the structure of the DS field. [RFC0793] 339 defined the 8 bit ToS field and [RFC2474] redefined it as DS field. 340 It consists of a 6 bit DS codepoint (DSCP, see [RFC2474]) and the 2 341 bit ECN field (see [RFC3168]). 343 0 1 2 3 4 5 6 7 344 +---+---+---+---+---+---+---+---+ 345 | DSCP | ECN | 346 +---+---+---+---+---+---+---+---+ 348 DSCP: Differentiated Services codepoint [RFC2474] 349 ECN: ECN field [RFC3168] 351 Figure 4: The Structure of the DS Field 353 3.2. Constraints from the DSCP 355 The Differentiated Services codepoint (DSCP) indicates the per-hop 356 behavior (PHB), i.e., the treatment IP packets receive from nodes in 357 a DS domain. Multiple DSCPs may indicate the same PHB. PCN traffic 358 is high-priority traffic and requires a special DSCP that indicate a 359 PHB with preferred treatment. 361 3.2.1. General Scarcity of DSCPs 363 As the number of unused DSCPs is small, PCN encoding should use only 364 a single DSCP if possible, in any case not more than two DSCPs. 365 Therefore, the DSCP should be used to indicate that traffic is 366 subject to PCN metering and marking, but not to differentiate 367 different PCN markings. 369 3.2.2. Handling of the DSCP in Tunneling Rules 371 PCN encoding must be chosen in such a way that PCN traffic can be 372 tunneled within a PCN domain without any impact on PCN metering and 373 re-marking. In the following, the "inner header" refers to the 374 header of the encapsulated packet and the "outer header" refers to 375 the encapsulating header. 377 [RFC2983] provides two tunneling modes for Differentiated Services 378 networks. The uniform model copies the DSCP from the inner header to 379 the outer header upon encapsulation and it copies the DSCP from the 380 outer header to the inner header upon decapsulation. This assures 381 that changes applied to the DSCP field survive encapsulation and 382 decapsulation. In contrast, the pipe model ignores the content of 383 the DSCP field in the outer header upon decapsulation. Therefore, 384 decapsulation erases changes applied to the DSCP along the tunnel. 385 As a consequence, only the uniform model may be used for tunneling 386 PCN traffic within a PCN domain, if PCN encoding uses more than a 387 single DSCP. 389 3.2.3. Restoration of Original DSCPs at the Egress Node 391 If PCN-marking does not alter the original DSCP, the traffic leaves 392 the PCN-domain with its original DSCP. 393 However, if the PCN-marking alters the DSCP, then some additional 394 technique is needed to restore the original DSCP. A few possibilities 395 are discussed: 397 1. Each Diffserv class using PCN uses a different set of DSCPs. 398 Therefore, if there are M DSCPs using PCN and PCN encoding uses N 399 different DSCPs, N*M DSCPs are needed. This solution may work well 400 in IP networks. However, when PCN is applied to MPLS networks or 401 other layers restricted to 8 QoS classes and codepoints, this 402 solution fails due to the extreme shortage of available DSCPs. 404 2. The original DSCP for the packets of a flow is signaled to the 405 egress node. No suitable signaling protocol has been developed and 406 therefore, it is not clear whether this approach could work. 408 3. PCN-traffic is tunneled across the PCN-domain. The pipe tunneling 409 model is applied and so the original DSCP is restored after 410 decapsulation. However, tunneling across a PCN domain adds an 411 additional IP header and reduces the maximum transfer unit (MTU) 412 from the perspective of the user. GRE, MPLS, or Ethernet using 413 Pseudo-Wires are potential solutions that scale well also in 414 backbone networks. 416 The most appropriate option depends on the specific circumstances an 417 operator faces. 419 o) Option 1 is most suitable unless there is a shortage of 420 available DSCPs. 422 o) Option 3 is suitable where the reduction of MTU is not liable 423 to cause issues. 425 3.3. Constraints from the ECN Field 427 This section briefly reviews the structure and use of the ECN field. 428 The ECN field may be redefined, but certain constraints must be met 429 [RFC4774]. The impact on PCN deployment is discussed, as well as the 430 constraints imposed by various tunneling rules on the persistence of 431 PCN marks after decapsulation and its impact on possible re-marking 432 actions. 434 3.3.1. Structure and Use of the ECN Field 436 Some transport protocols, like TCP, can typically use packet drops as 437 an indication of congestion in the Internet. The idea of Explicit 438 Congestion Notification (ECN) [RFC3168] is that routers provide a 439 congestion indication for incipient congestion, where the 440 notification can sometimes be through ECN marking (and re-marking) 441 packets rather than dropping them. Figure 5 summarizes the ECN 442 codepoints defined [RFC3168]. 444 +-----+-----+ 445 | ECN FIELD | 446 +-----+-----+ 447 0 0 Not-ECT 448 0 1 ECT(1) 449 1 0 ECT(0) 450 1 1 CE 452 Figure 5: ECN Codepoints within the ECN field 454 ECT stands for "ECN-capable transport" and indicates that the sender 455 and receivers of a flow understand ECN semantics. Packets of other 456 flows are labeled with not-ECT. To indicate congestion to a 457 receiver, routers may re-mark ECT(1) or ECT(0) labeled packets to CE 458 which stands for "congestion experienced". Two different ECT 459 codepoints were introduced "to protect against accidental or 460 malicious concealment of marked packets from the TCP sender" which 461 may be the case with cheating receivers [RFC3540]. 463 3.3.2. Redefinition of the ECN Field 465 The ECN field may be redefined for other purposes and [RFC4774] gives 466 guidelines for that. Essentially, not-ECT-marked packets must never 467 be re-marked to ECT or CE because not-ECT-capable end systems do not 468 reduce their transmission rate when receiving CE-marked packets. 469 This is a threat to the stability of the Internet. 471 Moreover, CE-marked packets must not be re-marked to not-ECT or ECT, 472 because then ECN-capable end systems cannot reduce their transmission 473 rate. The re-use of the ECN field for PCN encoding has some impact on 474 the deployment of PCN. First, routers within a PCN domain must not 475 apply ECN re-marking when the ECN field has PCN semantics. 476 Second, before a PCN packet leaves the PCN domain, the egress nodes 477 must either (A) reset the ECN field of the packet to the contents it 478 had when entering the PCN domain or (B) reset its ECN field to not- 479 ECT. According to Section 3.3.3, tunneling ECN traffic through a PCN 480 domain may help to implement (A). When (B) applies, CE-marked 481 packets must never become PCN packets within a PCN domain as the 482 egress node resets their ECN field to not-ECT. The ingress node may 483 drop such traffic instead. 485 3.3.3. Handling of the ECN Field in Tunneling Rules 487 When packets are encapsulated, the ECN field of the inner header may 488 or may not be copied to the ECN field of the outer header and upon 489 decapsulation, the ECN field of the outer header may or may not be 490 copied from the ECN field of the outer header to the ECN field of the 491 inner header. Various tunneling rules with different treatment of 492 the ECN field exist. Two different modes are defined in [RFC3168] 493 for IP-in-IP tunnels and a third one in [RFC4301] for IP-in-IPsec 494 tunnels. [RFC6040] updates both these RFCs to rationalize them 495 into one consistent approach. 497 3.3.3.1. Limited Functionality Option 499 The limited-functionality option has been defined in [RFC3168]. Upon 501 encapsulation, the ECN field of the outer header is generally set to 502 not-ECT. Upon decapsulation, the ECN field of the inner header 503 remains unchanged. 505 Since this tunneling mode loses information upon encapsulation and 506 decapsulation, it cannot be used for tunneling PCN traffic within a 507 PCN domain. However, the PCN ingress may use this mode to tunnel 508 traffic with ECN semantics to the PCN egress to preserve the ECN 509 field in the inner header while the ECN field of the outer header is 510 used with PCN semantics within the PCN domain. 512 3.3.3.2. Full Functionality Option 514 The full-functionality option has been defined in [RFC3168]. Upon 515 encapsulation, the ECN field of the inner header is copied to the 516 outer header unless the ECN field of the inner header carries CE. In 517 that case, the ECN field of the outer header is set to ECT(0). This 518 choice has been made for security reasons, to disable the ECN fields 519 of the outer header as a covert channel. Upon decapsulation, the ECN 520 field of the inner header remains unchanged unless the ECN field of 521 the outer header carries CE. In that case, the ECN field of the 522 inner header is also set to CE. 524 This mode imposes the following constraints on PCN metering and 525 marking. First, PCN must re-mark the ECN field only to CE because 526 any other information is not copied to the inner header upon 527 decapsulation and will be lost. Second, CE information in 528 encapsulated packet headers is invisible for routers along a tunnel. 529 Threshold marking does not require information about whether PCN 530 packets have already been marked and would work when CE denotes that 531 packets are marked. In contrast, excess-traffic- marking requires 532 information about already excess-traffic-marked packets and cannot be 533 supported with this tunneling mode. Furthermore, this tunneling mode 534 cannot be used when marked or not-marked packets should be 535 preferentially dropped because the PCN marking information is 536 possibly not visible in the outer header of a packet. 538 3.3.3.3. Tunneling with IPSec 540 Tunneling has been defined in Section 5.1.2.1 of [RFC4301]. Upon 541 encapsulation, the ECN field of the inner header is copied to the ECN 542 field of the outer header. Decapsulation works as for the full- 543 functionality option in Section 3.3.3.2. Tunneling with IPsec also 544 requires that PCN re-marks the ECN field only to CE because any other 545 information is not copied to the inner header upon decapsulation and 546 lost. In contrast to Section 3.3.3.2, with IPsec tunnels, CE marks 547 of tunneled PCN traffic remain visible for routers along the tunnel 548 and to their meters, markers, and droppers. 550 3.3.3.4. ECN Tunneling 552 New tunneling rules for ECN are specified in [RFC6040], which 553 updates [RFC3168] and [RFC4301]. These rules provide a consistent and 554 rational approach to encapsulation and decapsulation. 556 With the normal mode, the ECN field of the inner header is copied to 557 the ECN field of the outer header on encapsulation. 558 In compatibility mode, the ECN field of the outer header is reset to 559 not-ECT. 561 Upon decapsulation, the scheme specified in [RFC6040] and shown in 562 Figure 6 is applied. Thus, re-marking encapsulated not-ECT packets 563 to any other codepoint would not survive decapsulation. Therefore, 564 not-ECT cannot be used for PCN encoding. Furthermore, re-marking 565 encapsulated ECT(0) packets to ECT(1) or CE survives decapsulation, 566 but not vice-versa, and re-marking encapsulated ECT(1) packets to CE 567 also survives decapsulation, but not vice-versa. 568 Certain combinations of inner and outer ECN fields cannot result from 569 any transition in any current or previous ECN tunneling 570 specification. These currently unused (CU) combinations are 571 indicated in Figure 6 by '(!!!)' or '(!)', where '(!!!)' means the 572 combination is CU and always potentially dangerous, while '(!)' means 573 it is CU and possibly dangerous. 575 +---------+------------------------------------------------+ 576 |Arriving | Arriving Outer Header | 577 | Inner +---------+------------+------------+------------+ 578 | Header | Not-ECT | ECT(0) | ECT(1) | CE | 579 +---------+---------+------------+------------+------------+ 580 | Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| (!!!)| 581 | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE | 582 | ECT(1) | ECT(1) | ECT(1) (!) | ECT(1) | CE | 583 | CE | CE | CE | CE(!!!)| CE | 584 +---------+---------+------------+------------+------------+ 586 The ECN field in the outgoing header is set to the codepoint at the 587 intersection of the appropriate arriving inner header (row) and 588 arriving outer header (column), or the packet is dropped where 589 indicated. Currently unused combinations are indicated by '(!!!)' 590 or '(!)'. ([RFC6040]: '(!!!)' means the combination is CU and always 591 potentially dangerous, while '(!)' means it is CU and possibly 592 dangerous.) 594 Figure 6: New IP in IP Decapsulation Behavior (from [RFC6040]) 596 3.3.4. Restoration of the Original ECN Field at the PCN-Egress-Node 598 As ECN is an end-to-end service, it is desirable that the egress node 599 of a PCN domain restores the ECN field a PCN packet had at the 600 ingress node. There are basically two options. PCN traffic may be 601 tunneled between ingress and egress node using limited functionality 602 tunnels (see Section 3.3.3.1). Then, PCN marking is applied only to 603 the outer header, and the original ECN field is restored after 604 decapsulation. However, this reduces the MTU from the perspective of 605 the user. Another option is to use some intelligent encoding that 606 preserves the ECN codepoints. However, a viable solution is not 607 known. 609 4. Comparison of Encoding Options 611 The PCN WG has studied four different PCN encodings, which redefine 612 the ECN field. Figure 7 summarizes these PCN encodings. One or at 613 most two different DSCPs are used to indicate PCN traffic, and only 614 for these DSCPs the semantics of the ECN field are redefined within 615 the PCN domain. 616 When a PCN-ingress-node classifies a packet as a PCN-packet it sets 617 its PCN-codepoint to not-marked (NM). Non-PCN traffic can also to be 618 sent with the PCN-specific DSCP, by setting the Not-PCN codepoint. 619 Special per hop behavior, defined in [RFC5670], applies to PCN- 620 traffic. 622 ----------------------------------------------------------------------- 623 | ECN Bits || 00 | 10 | 01 | 11 || DSCP | 624 |==============++==========+==========+==========+==========++=========| 625 | RFC 3168 || Not-ECT | ECT(0) | ECT(1) | CE || Any | 626 |==============++==========+==========+==========+==========++=========| 627 | Baseline || Not-PCN | NM | EXP | PM || PCN-n | 628 |==============++==========+==========+==========+==========++=========| 629 | 3-In-1 || Not-PCN | NM | ThM | ETM || PCN-n | 630 |==============++==========+==========+==========+==========++=========| 631 | 3-In-2 || Not-PCN | NM | CU | ThM || PCN-n | 632 | ||----------+----------+----------+----------++---------| 633 | || Not-PCN | CU | CU | ETM || PCN-m | 634 |==============++==========+==========+==========+==========++=========| 635 | PSDM || Not-PCN | Not-ETM | Not-ThM | PM || PCN-n | 636 ----------------------------------------------------------------------- 638 Notes: PCN-n, PCN-m under the DSCP column denotes PCN compatible 639 DSCPs which may be chosen by the network operator. Not-PCN means that 640 packets are not PCN-enabled. NM means Not-Marked to signal a not-pre- 641 congested path. CU means Currently Unused. 643 Figure 7: Semantics of the ECN field for various encoding types 645 4.1. Baseline Encoding 647 With baseline encoding [RFC5696], the NM codepoint can be re-marked 648 only to PCN-marked (PM). Excess-traffic-marking uses PM as ETM, 649 threshold-marking uses PM as ThM, and only one of the two marking 650 schemes can be used. 652 The 01-codepoint is reserved for experimental purposes (EXP) and the 653 other defined PCN encoding schemes can be seen as extensions of 654 baseline encoding by appropriate redefinition of EXP. Baseline 655 encoding [RFC5696] works well with IPsec tunnels (see Section 656 3.3.3.3). 658 4.2. Encoding with 1 DSCP Providing 3 States 660 PCN 3-state encoding extension in a single DSCP (3-in-1 encoding, 661 [I-D.ietf-pcn-3-in-1-encoding] extends the baseline encoding and 662 supports the simultaneous use of both excess-traffic-marking and 663 threshold-marking. 3-in-1 encoding well supports the preferred CL-PCN 664 and also SM-PCN. 666 The problem with 3-in-1 encoding is that the 10-codepoint does not 667 survive decapsulation with the tunneling options in Section 3.3.3.1 - 668 3.3.3.3. Therefore, 3-in-1 encoding may be used only for PCN domains 669 implementing the new rules for ECN tunneling [RFC6040], see Section 670 3.3.3.4), or where it is known that there are no tunnels in the PCN 671 domain. Currently it is not clear how fast the new tunneling rules 672 will be deployed, but the applicability of 3-in-1-encoding depends on 673 that. 675 4.3. Encoding with 2 DSCPs Providing 3 or More States 677 PCN encoding using 2 DSCPs to provide 3 or more states (3-in-2 678 encoding, [I-D.ietf-pcn-3-state-encoding] uses two different DSCPs to 679 accommodate the three required codepoints NM, ThM, and ETM. It 680 leaves some codepoints currently unused (CU) and proposes also one 681 way how to reuse them to store some information about the content of 682 the ECN field before the packet entered the PCN domain. 3-in-2 683 encoding works well with IPsec tunnels (see Section 3.3.3.3). This 684 type of encoding can support both CL-PCN and SM-PCN schemes. 686 The disadvantage of 3-in-2 encoding is that it consumes two DSCPs. 687 Moreover, the direct application of this encoding scheme to other 688 technologies like MPLS, where even fewer bits are available for the 689 encoding of DSCPs is more difficult. 691 4.4. Encoding for Packet Specific Dual Marking (PSDM) 693 PCN encoding for packet-specific dual marking (PSDM) is designed to 694 support PSDM-PCN outlined in Section 2.2.3. It is the only proposal 695 that supports PCN-based AC and FT with only a single DSCP 696 [I-D.ietf-pcn-psdm-encoding] in the presence of IPsec tunnels (see 697 Section 3.3.3.3). PSDM encoding also supports SM-PCN. 699 4.5. Standardized encodings 701 The baseline encoding described in section 4.1 was published as a 702 draft Internet Standard [RFC5696]. The intention was to allow for 703 experimental encodings to build upon this baseline. However, 704 following the publication of [RFC6040], the WG decided to change 705 approach and instead standardize only one encoding (the 3-in-1 706 encoding described in 4.2 [I-D.ietf-pcn-3-in-1-encoding]. Rather than 707 defining the 3-in-1 encoding as a standards track extension to the 708 existing baseline encoding [RFC5696], it was agreed that it was best 709 to define a new standards track document that obsoletes [RFC5696]. 711 5. Conclusion 713 This document summarizes the PCN Working Group's exploration of a 714 number of approaches for encoding pre-congestion information into the 715 IP header. It is presented as an informational archive. It provides 716 details of all those approaches along with an explanation of the 717 constraints that have to be met. The Working Group has concluded that 718 the "3-in-1" encoding should be published as a standards-track RFC 719 that obsoletes the encoding specified in [RFC5696]. 720 The reasoning is as follows. During the early life of the working 721 group, we decided on an approach of a standardized "baseline 722 encoding" [RFC5696] plus a series of experimental encodings that 723 would all build on the baseline encoding and each of which would be 724 useful in specific circumstances. However, after the tunneling of 725 ECN was standardized in [RFC6040], the PCN WG decided on a different 726 approach - to recommend just one encoding, the "3-in-1 encoding". 728 Although in theory "3-in-1" could be specified as a standards-track 729 extension to the "baseline" encoding, the WG decided that it would be 730 cleaner to obsolete [RFC5696] and specify "3-in-1" encoding in a new 731 stand-alone RFC. 733 6. Security Implications 735 [RFC5559] provides a general description of the security 736 considerations for PCN. This memo does not introduce additional 737 security considerations. 739 7. IANA Considerations 741 This memo includes no request to IANA. 743 8. Acknowledgements 745 We would like to acknowledge the members of the PCN working group and 746 Gorry Fairhust for the discussions that generated and improved the 747 contents of this memo. 749 9. References 751 9.1. Normative References 753 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 754 RFC 793, September 1981. 756 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 757 "Definition of the Differentiated Services Field (DS 758 Field) in the IPv4 and IPv6 Headers", RFC 2474, 759 December 1998. 761 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 762 of Explicit Congestion Notification (ECN) to IP", 763 RFC 3168, September 2001. 765 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 766 Explicit Congestion Notification (ECN) Field", BCP 124, 767 RFC 4774, November 2006. 769 9.2. Informative References 771 [I-D.ietf-pcn-cl-edge-behaviour] 772 Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. 773 Taylor, "PCN Boundary Node Behaviour for the Controlled 774 Load (CL) Mode of Operation", 775 draft-ietf-pcn-cl-edge-behaviour-12 (work in progress), 776 February 2012. 778 [I-D.ietf-pcn-sm-edge-behaviour] 779 Charny, A., Karagiannis, G., Menth, M., and T. Taylor, 780 "PCN Boundary Node Behaviour for the Single Marking (SM) 781 Mode of Operation", draft-ietf-pcn-sm-edge-behaviour-09 782 (work in progress), February 2012. 784 [I-D.ietf-pcn-3-in-1-encoding] 785 Briscoe, B., Moncaster, T., and M. Menth, "Encoding 3 PCN- 786 States in the IP header using a single DSCP", 787 draft-ietf-pcn-3-in-1-encoding-08 (work in progress), 788 August 2011. 790 [I-D.ietf-pcn-3-state-encoding] 791 Briscoe, B., Moncaster, T., and M. Menth, "A PCN encoding 792 using 2 DSCPs to provide 3 or more states", 793 draft-ietf-pcn-3-state-encoding-01 (work in progress), 794 February 2010. 796 [I-D.ietf-pcn-psdm-encoding] 797 Menth, M., Babiarz, J., Moncaster, T., and B. Briscoe, 798 "PCN Encoding for Packet-Specific Dual Marking (PSDM 799 Encoding)", draft-ietf-pcn-psdm-encoding-01 (work in 800 progress), March 2010. 802 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 803 Notification", RFC 6040, November 2010. 805 [RFC2983] Black, D., "Differentiated Services and Tunnels", 806 RFC 2983, October 2000. 808 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 809 Congestion Notification (ECN) Signaling with Nonces", 810 RFC 3540, June 2003. 812 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 813 Internet Protocol", RFC 4301, December 2005. 815 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 816 Architecture", RFC 5559, June 2009. 818 [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- 819 Nodes", RFC 5670, November 2009. 821 [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline 822 Encoding and Transport of Pre-Congestion Information", 823 RFC 5696, November 2009. 825 [Menth09f] 826 Menth, M., Babiarz, J., and P. Eardley, "Pre-Congestion 827 Notification Using Packet-Specific Dual Marking", IEEE 828 Proceedings of the International Workshop on the Network 829 of the Future (Future-Net) at Dresden Germany, June 2009. 831 [Menth12] 832 Menth, M. and F. Lehrieder, " Performance of PCN-Based 833 Admission Control under Challenging Conditions", accepted 834 for publication IEEE/ACM Transactions on Networking in 835 2012. 837 [Menth10q] 838 Menth, M. and F. Lehrieder, "PCN-Based Measured Rate 839 Termination", Computer Networks Journal, vol. 54, no. 3, 840 Sept. 2010 842 Authors' Addresses 844 Georgios Karagiannis 845 University of Twente 846 P.O. Box 217 847 7500 AE Enschede, 848 The Netherlands 850 Email: g.karagiannis@utwente.nl 852 Kwok Ho Chan 853 Consultant 855 Email: khchan.work@gmail.com 857 Toby Moncaster 858 University of Cambridge Computer Laboratory, 859 William Gates Building, J J Thomson Avenue, 860 Cambridge, CB3 0FD. 862 Email Toby.Moncaster@cl.cam.ac.uk 864 Michael Menth 865 Chair of Communication Networks 866 University of Tuebingen 867 Sand 13 868 72076 Tuebingen 869 Germany 871 Email: menth@informatik.uni-tuebingen.de 873 Philip Eardley 874 BT 875 B54/77, Sirius House Adastral Park Martlesham Heath 876 Ipswich, Suffolk IP5 3RE 877 United Kingdom 879 Email: philip.eardley@bt.com 880 Bob Briscoe 881 BT 882 B54/77, Sirius House Adastral Park Martlesham Heath 883 Ipswich, Suffolk IP5 3RE 884 United Kingdom 886 Email: bob.briscoe@bt.com