idnits 2.17.1 draft-ietf-pcn-psdm-encoding-02.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 1 instance 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 12, 2012) is 4422 days in the past. Is this intentional? Checking references for intended status: Historic ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5696 (Obsoleted by RFC 6660) == Outdated reference: A later version (-11) exists of draft-ietf-pcn-3-in-1-encoding-09 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Congestion and Pre Congestion M. Menth 3 Internet-Draft University of Tuebingen 4 Intended status: Historic J. Babiarz 5 Expires: September 13, 2012 3inova Networks Inc 6 T. Moncaster 7 University of Cambridge 8 B. Briscoe 9 BT 10 March 12, 2012 12 PCN Encoding for Packet-Specific Dual Marking (PSDM Encoding) 13 draft-ietf-pcn-psdm-encoding-02 15 Abstract 17 Pre-congestion notification (PCN) is a link-specific and load- 18 dependent packet re-marking mechanism and provides in Differentiated 19 Services networks feedback to egress nodes about load conditions 20 within the domain. It is used to support admission control and flow 21 termination decision in a simple way. This document proposes how PCN 22 marks can be encoded into the IP header for packet-specific dual 23 marking (PSDM). PSDM encoding provides three different codepoints: 24 not-ETM, not-ThM, and PM. Excess-traffic-marking may re-mark not- 25 ETM-packets to PM and threshold-marking may re-mark not-ThM-packets 26 to PM. 28 Status 30 Since its original publication, the baseline encoding (RFC5696) on 31 which this document depends has become obsolete. The PCN working 32 GRoup has chosen to publish this as a historical document to preserve 33 the details of the encoding and to allow it to be cited in other 34 documents. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on September 13, 2012. 53 Copyright Notice 55 Copyright (c) 2012 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Encoding for Packet-Specific Dual Marking . . . . . . . . . . 6 74 3.1. Proposed Encoding and Expected Node Behavior . . . . . . . 6 75 3.1.1. PCN Codepoints . . . . . . . . . . . . . . . . . . . . 6 76 3.1.2. Codepoint Handling by PCN Ingress Nodes . . . . . . . 6 77 3.1.3. Codepoint Handling by PCN Interfaces . . . . . . . . . 7 78 3.1.4. Codepoint Handling by PCN Egress Nodes . . . . . . . . 7 79 3.2. Reasons for the Proposed Encoding . . . . . . . . . . . . 7 80 3.2.1. Scarcity of DSCPs . . . . . . . . . . . . . . . . . . 7 81 3.2.2. Problems with Tunneling . . . . . . . . . . . . . . . 7 82 3.2.3. Problems with the ECN Field . . . . . . . . . . . . . 8 83 3.3. Handling of ECN Traffic . . . . . . . . . . . . . . . . . 9 84 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 86 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 7. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 9 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 93 1. Introduction 95 The objective of Pre-Congestion Notification (PCN) [RFC5559] is to 96 protect the quality of service (QoS) of inelastic flows within a 97 Diffserv domain, in a simple, scalable, and robust fashion. Two 98 mechanisms are used: admission control (AC), to decide whether to 99 admit or block a new flow request, and (in abnormal circumstances) 100 flow termination (FT) to decide whether to terminate some of the 101 existing flows. To achieve this, the overall rate of PCN-traffic is 102 metered on every link in the domain, and PCN-packets are 103 appropriately marked when certain configured rates are exceeded. 104 These configured rates are below the rate of the link thus providing 105 notification to boundary nodes about overloads before any congestion 106 occurs (hence "pre-congestion notification"). 108 The level of marking allows boundary nodes to make decisions about 109 whether to admit or terminate. This is achieved by marking packets 110 on interior nodes according to some metering function implemented at 111 each node. Excess-traffic-marking marks PCN packets that exceed a 112 certain reference rate on a link while threshold marking marks all 113 PCN packets on a link when the PCN traffic rate exceeds a lower 114 reference rate [RFC5670]. These marks are monitored by the egress 115 nodes of the PCN domain. 117 This document proposes how PCN marks can be encoded into the IP 118 header when packet-specific dual marking (PSDM) is used to re-mark 119 packets [Menth09f]. That means, both excess-traffic-marking and 120 threshold-marking are activated on the links within a PCN domain, but 121 packets are subject to re-marking by only one of them. The encoding 122 of unmarked PCN packets indicates whether they are subject to either 123 excess-traffic-marking (not-ETM) or threshold-marking (not-ThM) and 124 they may be re-marked to PCN-marked (PM). 126 PSDM encoding can be applied in networks implementing 128 o only AC based on threshold-marking (reference rate = PCN- 129 admissible-rate), 131 o only FT based on excess-traffic-marking (reference rate = PCN- 132 supportable-rate), 134 o both AC and FT based on excess-traffic-marking (reference rate = 135 PCN-admissible-rate) 137 o Probe-based AC based on threshold-marking (reference rate = PCN- 138 admissible-rate) and FT based on excess-traffic-marking (reference 139 rate = PCN-supportable-rate)[Menth09f]. 141 The motivation for PSDM encoding is that probe packets are subject 142 only to threshold-marking and that data packets are subject only to 143 excess-traffic-marking. Nevertheless, routers should not need to 144 differentiate explicitly between probe and data packets since packets 145 are a priori marked with an appropriate codepoint (not-ETM, not-ThM) 146 indicating the marking mechanism applying to them. 148 Following the publication of new rules relating to the tunnelling of 149 ECN marks [RFC6040], the PCN workign group decided to obsolete 150 [RFC5696] in favour of the 3-in-1 encoding 151 [I-D.ietf-pcn-3-in-1-encoding]. A side-effect of this decision was 152 to make the PSDM encoding obsolete. However the PCN working group 153 feels it is useful to have a formal historical record of this 154 encoding. This ensures details of the encoding are not lost and also 155 allows it to be cited in other documents. 157 1.1. Requirements notation 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 2. Terminology 165 Most of the terminology used in this document is defined in 166 [RFC5559]. The following additional terms are defined in this 167 document: 169 o PCN-capable flow - a flow subject to PCN-based admission control 170 and/or flow termination 172 o PCN-enabled DSCP - DSCP indicating within a PCN domain that 173 packets possibly belong to a PCN-capable flow 175 o PCN-capable ECN codepoint (PCN codepoint) - DSCP set to a PCN- 176 enabled DSCP and ECN field set to a codepoint indicating that a 177 packet belongs to a PCN-capable flow (not-ThM, not-ETM, or PM, 178 explained below) 180 o PCN packet - a packet belonging to a PCN capable flow within a PCN 181 domain, must have a PCN-enabled DSCP and a PCN-capable ECN 182 codepoint 184 o not-PCN capable (not-PCN) - new ECN codepoint for packets of non- 185 PCN-capable flows when a PCN-enabled DSCP is set 187 o not-excess-traffic-marked (not-ETM) - new ECN codepoint for 188 unmarked PCN packets that are subject to excess-traffic-marking 190 o not-threshold-marked (not-ThM) - new ECN codepoint for unmarked 191 PCN packets that are subject to threshold-marking 193 o PCN-marked (PM) - new ECN codepoint for re-marked PCN packets 194 regardless whether they were subject to excess-traffic-marking or 195 threshold-marking. 197 3. Encoding for Packet-Specific Dual Marking 199 In this section the encoding for packet-specific dual marking (PSDM) 200 is presented and the reasons for the proposed design are outlined. 202 3.1. Proposed Encoding and Expected Node Behavior 204 The encoding reuses a PCN-enabled DSCP to indicate packets of PCN- 205 capable flows within a PCN domain. 207 3.1.1. PCN Codepoints 209 The ECN field of packets with a PCN-enabled DSCP is interpreted 210 within a PCN domain as PCN codepoint while it is interpreted as ECN 211 codepoint outside PCN domains. Four new PCN codepoints are defined 212 in Figure 1. PSDM encoding can be seen as an extension of baseline 213 encoding [RFC5696] 215 +--------+----------------------------------------------------+ 216 | | Codepoint in ECN field of IP header | 217 | DSCP | (RFC3168 codepoint name) | 218 | +--------------+-------------+-------------+---------+ 219 | | 00 (Not-ECT) | 10 (ECT(0)) | 01 (ECT(1)) | 11 (CE) | 220 +--------+--------------+-------------+-------------+---------+ 221 | DSCP n | not-PCN | not-ETM | not-ThM | PM | 222 +--------+--------------+-------------+-------------+---------+ 224 Figure 1: PSDM encoding. 226 3.1.2. Codepoint Handling by PCN Ingress Nodes 228 When packets belonging to PCN flows arrive at the ingress router of 229 the PCN domain, the ingress router first drops all CE-marked packets. 230 Then, it sets the DSCP of the remaining PCN packets to an PCN-enabled 231 DSCP and re-marks the ECN field of all PCN packets that are subject 232 to threshold-marking to not-ThM (e.g. probe packets), and all PCN 233 packets that are subject to excess-traffic-marking to not-ETM (e.g. 235 data packets). If packets with a PCN-enabled DSCP arrive that belong 236 to non-PCN flows, the PCN ingress node re-marks their ECN field to 237 not-PCN or re-marks their DSCP to a different one while preserving 238 the contents of the ECN field. 240 3.1.3. Codepoint Handling by PCN Interfaces 242 If the meter for excess-traffic-marking of a PCN node indicates that 243 a PCN packet should be re-marked, its ECN field is set to PCN-marked 244 (PM) only if it was not-ETM before. If the meter for threshold- 245 marking of a PCN node indicates that a PCN packet should be re- 246 marked, its ECN field is set to PCN-marked (PM) only if it was not- 247 ThM before. 249 3.1.4. Codepoint Handling by PCN Egress Nodes 251 If the egress node of a PCN domain receives a PM-packet, it infers 252 somehow whether the packet was not-ETM or not-ThM by the PCN ingress 253 node to interpret the marking. This can be done as probe packets 254 must be distinguishable from PCN data packets anyway. The egress 255 node resets the ECN field of all packets with PCN-enabled DSCPs to 256 not-ECT. This breaks the ECN capability for all flows with PCN- 257 enabled DSCPs, regardless whether they are PCN-capable or not. 258 Appropriate tunnelling across a PCN domain can preserve the ECN 259 marking of packets with PCN-enabled DSCPs and the ECN-capability of 260 their flows (see Section 3.3). When the DSCPs in the headers of 261 packets belonging to flows with PCN-enabled DSCPs have been changed 262 to another DSCP, the egress node should reverse that change. 264 3.2. Reasons for the Proposed Encoding 266 3.2.1. Scarcity of DSCPs 268 DSCPs are a scarce resource in the IP header so that at most one 269 should be used for PCN encoding. 271 3.2.2. Problems with Tunneling 273 The encoding scheme must cope with tunnelling within PCN domains. 274 However, various tunnelling schemes limit the persistence of ECN 275 marks in the top-most IP header to a different degree. Two IP-in-IP 276 tunnelling modes are defined in [RFC3168] and a third one in 277 [RFC4301] for IP-in-IPsec tunnels. 279 The limited-functionality option in [RFC3168] requires that the ECN 280 codepoint in the outer header is set to not-ECT so that ECN is 281 disabled for all tunnel routers, i.e., they drop packets instead of 282 mark them in case of congestion. The tunnel egress just decapsulates 283 the packet and leaves the ECN codepoints of the inner packet header 284 unchanged. 286 o This mode protects the inner IP header from being PCN-marked upon 287 decapsulation. It can be used to tunnel ECN marks across PCN 288 domains such that PCN marking is applied to the outer header 289 without affecting the inner header. 291 o This mode is not useful to tunnel PCN traffic with PCN-enabled 292 DSCP and PCN-capable PCN-codepoints within PCN domain because the 293 ECN marking information from the outer ECN fields is lost upon 294 decapsulation. 296 The full-functionality option in [RFC3168] requires that the ECN 297 codepoint in the outer header is copied from the inner header unless 298 the inner header codepoint is CE. In this case, the outer header 299 codepoint is set to ECT(0). This choice has been made to disable the 300 ECN fields of the outer header as a covert channel. Upon 301 decapsulation, the ECN codepoint of the inner header remains 302 unchanged unless the outer header ECN codepoint is CE. In this case, 303 the inner header codepoint is also set to CE. This preserves outer 304 header information if it is CE. However, the fact that CE marks of 305 the inner header are not visible in the outer header may be a problem 306 for excess-traffic-marking as it takes already marked traffic into 307 account and for some required packet drop policies. 309 Tunnelling with IPsec copies the inner header ECN field to the outer 310 header ECN field RFC4301, Sect. 5.1.2.1 [RFC4301] upon encapsulation. 311 Upon decapsulation, CE-marks of the outer header are copied into the 312 inner header, the other marks are ignored. With this tunnelling 313 mode, CE marks of the inner header become visible to all meters, 314 markers, and droppers for tunnelled traffic. In addition, limited 315 information from the outer header is propagated into the inner 316 header. Therefore, only IPsec tunnels should be used inside PCN 317 domains when ECN bits are reused for PCN encoding. Another 318 consequence is that CE is the only codepoint to which packets can be 319 re-marked along a tunnel within a PCN domain so that the changed 320 codepoint survives decapsulation. 322 3.2.3. Problems with the ECN Field 324 The guidelines in [RFC4774] describe how the ECN bits can be reused 325 while being compatible with [RFC3168]. A CE mark of a packet must 326 never be changed to another ECN codepoint. Furthermore, a not-ECT 327 mark of a packet must never be changed to one of the ECN-capable 328 codepoints ECT(0), ECT(1), or CE. Care must be taken that this rule 329 is enforced when PCN packets leave the PCN domain. As a consequence, 330 all CE-marked PCN packets must be dropped before entering a PCN 331 domain and the ECN field of all PCN packets must be reset to not-ECT 332 when leaving a PCN domain. 334 3.3. Handling of ECN Traffic 336 ECN is intended to control elastic traffic as TCP reacts to ECN 337 marks. Inelastic real-time traffic is mostly not transmitted over 338 TCP such that this application of ECN is not appropriate. However, 339 there have been proposals made that would re-use the PCN signals for 340 rate adaptation. Therefore, two different options might be useful. 342 o preserve ECN marks from outside a PCN domain, i.e. CE-marked 343 packets should not be dropped. To handle this case, ECN packets 344 should be tunnelled through a PCN domain such that the ECN marking 345 is hidden from the PCN control and PCN marking is applied only to 346 the outer header. 348 o add PCN markings to the ECN field if applications wish to receive 349 the PCN markings for whatever purpose. In that case IPsec tunnels 350 should be used for tunnelling. This, however, must be done only 351 if end systems are ECN capable and signal that they wish to 352 receive this additional PCN marking information. If this is 353 useful, the required signalling needs to be defined. 355 Both options are an independent of the way how PCN marks are encoded. 356 Therefore, they are not in the scope of this document. 358 4. IANA Considerations 360 This document makes no request to IANA. 362 5. Security Considerations 364 {ToDo} 366 6. Conclusions 368 This document describes an encoding scheme with the following 369 benefits: {ToDo} 371 7. Comments Solicited 373 Comments and questions are encouraged and very welcome. They can be 374 addressed to the IETF PCN working group mailing list , 375 and/or to the authors. 377 8. References 379 8.1. Normative References 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, March 1997. 384 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 385 of Explicit Congestion Notification (ECN) to IP", 386 RFC 3168, September 2001. 388 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 389 Internet Protocol", RFC 4301, December 2005. 391 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 392 Explicit Congestion Notification (ECN) Field", BCP 124, 393 RFC 4774, November 2006. 395 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 396 Architecture", RFC 5559, June 2009. 398 [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- 399 Nodes", RFC 5670, November 2009. 401 [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline 402 Encoding and Transport of Pre-Congestion Information", 403 RFC 5696, November 2009. 405 8.2. Informative References 407 [I-D.ietf-pcn-3-in-1-encoding] 408 Briscoe, B., Moncaster, T., and M. Menth, "Encoding 3 PCN- 409 States in the IP header using a single DSCP", 410 draft-ietf-pcn-3-in-1-encoding-09 (work in progress), 411 March 2012. 413 [Menth09f] 414 Menth, M., Babiarz, J., and P. Eardley, "Pre-Congestion 415 Notification Using Packet-Specific Dual Marking", 416 Proceedings of the International Workshop on the Network 417 of the Future (Future-Net), IEEE, Dresden, Germany, 418 June 2009. 420 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 421 Notification", RFC 6040, November 2010. 423 Authors' Addresses 425 Michael Menth 426 University of Tuebingen 427 Department of Computer Science 428 Sand 13 429 Tuebingen D-72076 430 Germany 432 Phone: +49 07071 29 70505 433 Email: menth@informatik.uni-tuebingen.de 434 URI: http://www.kn.inf.uni-tuebingen.de 436 Jozef Babiarz 437 3inova Networks Inc 438 CRC Innovation Centre 439 Bldg 94 Room 216D 440 3701 Carling Avenue 441 Ottawa K2H 8S2 442 Canada 444 Phone: +1-613-298-0438 445 Email: j.babiarz@3inovanetworks.com 447 Toby Moncaster 448 University of Cambridge 449 Computer Laboratory 450 JJ Thomson Avenue 451 Cambridge CB3 0FD 452 UK 454 Phone: +44 1223 763654 455 Email: toby@moncaster.com 457 Bob Briscoe 458 BT 459 B54/77, Adastral Park 460 Martlesham Heath 461 Ipswich IP5 3RE 462 UK 464 Phone: +44 1473 645196 465 Email: bob.briscoe@bt.com 466 URI: http://www.bobbriscoe.net