idnits 2.17.1 draft-chan-pcn-encoding-comparison-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 32 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2009) is 5518 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '18' on line 1257 == Unused Reference: 'I-D.ietf-tsvwg-mlef-concerns' is defined on line 1379, but no explicit reference was found in the text == Unused Reference: 'RFC1633' is defined on line 1385, but no explicit reference was found in the text == Unused Reference: 'RFC2309' is defined on line 1392, but no explicit reference was found in the text == Unused Reference: 'RFC2597' is defined on line 1408, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 1411, but no explicit reference was found in the text == Unused Reference: 'RFC2998' is defined on line 1415, but no explicit reference was found in the text == Unused Reference: 'RFC3247' is defined on line 1429, but no explicit reference was found in the text == Unused Reference: 'RFC3955' is defined on line 1439, but no explicit reference was found in the text == Unused Reference: 'RFC4594' is defined on line 1445, but no explicit reference was found in the text == Unused Reference: 'DClark' is defined on line 1456, but no explicit reference was found in the text == Unused Reference: 'Reid' is defined on line 1464, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-pcn-architecture-09 == Outdated reference: A later version (-07) exists of draft-ietf-pcn-baseline-encoding-02 == Outdated reference: A later version (-10) exists of draft-ietf-tsvwg-ecn-tunnel-01 == Outdated reference: A later version (-07) exists of draft-ietf-tsvwg-admitted-realtime-dscp-05 -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) Summary: 3 errors (**), 0 flaws (~~), 16 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCN K. Chan 3 Internet-Draft Huawei Technologies 4 Intended status: Informational G. Karagiannis 5 Expires: September 9, 2009 University of Twente 6 T. Moncaster 7 BT Research 8 M. Menth 9 University of Wurzburg 10 P. Eardley 11 B. Briscoe 12 BT Research 13 March 8, 2009 15 Pre-Congestion Notification Encoding Comparison 16 draft-chan-pcn-encoding-comparison-04 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may contain material 22 from IETF Documents or IETF Contributions published or made publicly 23 available before November 10, 2008. The person(s) controlling the 24 copyright in some of this material may not have granted the IETF 25 Trust the right to allow modifications of such material outside the 26 IETF Standards Process. Without obtaining an adequate license from 27 the person(s) controlling the copyright in such materials, this 28 document may not be modified outside the IETF Standards Process, and 29 derivative works of it may not be created outside the IETF Standards 30 Process, except to format it for publication as an RFC or to 31 translate it into languages other than English. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on September 9, 2009. 51 Copyright Notice 53 Copyright (c) 2009 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 in effect on the date of 58 publication of this document (http://trustee.ietf.org/license-info). 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. 62 Abstract 64 A number of mechanisms have been proposed to support differential 65 Qualiy of Service for packets in the Internet. DiffServ is an 66 example of such a mechanism. However, the level of assurance that 67 can be provided with DiffServ without substantial over-provisioning 68 is limited. Pre-Congestion Notification (PCN) uses path congestion 69 information across a PCN region to enable per-flow admission control 70 to provide the required service guarantees for the admitted traffic. 71 While admission control will protect the QoS under normal operating 72 conditions, an additional flow termination mechanism is necessary to 73 cope with extreme events (e.g. route changes due to link or node 74 failure). 76 In order to allow the PCN mechanisms to work it is necessary for IP 77 packets to be able to carry the pre-congestion information to the PCN 78 egress nodes. This document explores different ways in which this 79 information can be encoded into IP packets. This document does not 80 choose the encoding but provide guidance and recommendation based on 81 different criteria. This document also provides a historical trace 82 of the consideration on different encoding alternatives for Pre- 83 Congestion Notification. 85 Table of Contents 87 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 88 2. Encoding Requirements . . . . . . . . . . . . . . . . . . . . 6 89 2.1. Encoding States . . . . . . . . . . . . . . . . . . . . . 6 90 2.2. Encoding and Operating Environment . . . . . . . . . . . . 7 91 2.2.1. PCN Capable (Non PCN Capable) Packet Encoding State . 7 92 2.2.2. Nonce Encoding State . . . . . . . . . . . . . . . . . 9 93 2.2.3. Non-PCN Traffic Entering PCN Domain . . . . . . . . . 9 94 2.2.4. PCN Traffic Leaving PCN Domain . . . . . . . . . . . . 10 95 2.2.5. PCN Encoding for Both Edge to Edge and End to End 96 Deployment . . . . . . . . . . . . . . . . . . . . . . 10 97 2.2.6. PCN Encoding and Alternate ECN Semantics . . . . . . . 11 98 2.2.7. PCN Encoding and Tunnels . . . . . . . . . . . . . . . 11 99 2.3. Encoding Selection Criteria . . . . . . . . . . . . . . . 12 100 3. Encoding Options . . . . . . . . . . . . . . . . . . . . . . . 13 101 3.1. Encoding Using ECN and DSCP Fields . . . . . . . . . . . . 13 102 3.1.1. The Use of '01' and '10' Encoding for PCN . . . . . . 14 103 3.1.2. The Use of '11' Encoding for PCN . . . . . . . . . . . 15 104 3.1.3. The Use of '00' Encoding for PCN . . . . . . . . . . . 15 105 3.1.4. Benefits of Using DSCP and ECN Fields . . . . . . . . 15 106 3.1.5. Drawbacks of Using DSCP and ECN Fields . . . . . . . . 16 107 3.1.6. Comparing DSCP and ECN Fields Encoding Options . . . . 16 108 3.1.7. Concerns on Alternate Semantics for the ECN Field . . 16 109 3.1.8. Encoding Choice Considerations . . . . . . . . . . . . 19 110 3.2. Encoding Using DSCP Field . . . . . . . . . . . . . . . . 19 111 3.2.1. Benefits of Using DSCP Field . . . . . . . . . . . . . 20 112 3.2.2. Drawbacks of Using DSCP Field . . . . . . . . . . . . 21 113 3.2.3. Comparing DSCP Field Encoding Options . . . . . . . . 21 114 4. Encoding Recommendations . . . . . . . . . . . . . . . . . . . 22 115 5. Security Implications . . . . . . . . . . . . . . . . . . . . 22 116 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 117 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 118 Appendix A. Encoding Using ECN Field . . . . . . . . . . . . . . 23 119 Appendix A.1. Benefits of Using ECN Field . . . . . . . . . . . . 24 120 Appendix A.2. Drawbacks of Using ECN Field . . . . . . . . . . . . 25 121 Appendix A.3. Concerns on Alternate Semantics for the ECN Field . 25 122 Appendix A.4. Encoding Choice Considerations . . . . . . . . . . . 28 123 Appendix B. Out-of-Band Channel as Encoding Transport . . . . . 28 124 Appendix B.1. Benefits of Using Out-Of-Band Channel . . . . . . . 29 125 Appendix B.2. Drawbacks of Using Out-Of-Band Channel . . . . . . . 29 126 Appendix C. Current PCN Detection, Marking and Transport 127 Mechanisms . . . . . . . . . . . . . . . . . . . . . 29 128 Appendix C.1. Detection, Marking and Transport Mechanisms in 129 CL-PHB . . . . . . . . . . . . . . . . . . . . . . . 29 130 Appendix C.2. Detection, Marking and Transport Mechanisms in 131 Three State Marking . . . . . . . . . . . . . . . . 29 132 Appendix C.3. Detection, Marking and Transport Mechanisms in 133 Single Marking . . . . . . . . . . . . . . . . . . . 30 134 Appendix C.4. Detection, Marking and Transport Mechanisms in 135 Load Control Marking . . . . . . . . . . . . . . . . 30 136 8. Informative References . . . . . . . . . . . . . . . . . . . . 30 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 139 1. Introduction 141 This document examines the ways to encode pre-congestion notification 142 (PCN) [I-D.ietf-pcn-architecture] information in IP packets for 143 transporting the information from the PCN ingress nodes, through the 144 PCN interior nodes, to the PCN egress nodes. Using the examination 145 results to assist the selection of PCN encoding in IP packets. 147 This document first discuss the PCN information that is required to 148 be transported. Then investigate the different fields in the IP 149 header for transporting the required PCN information. Followed with 150 the encoding choices, discussions, and recommendations, when specific 151 field(s) of the IP header is/are used to transport the PCN 152 information. 154 For transporting using data packet (IP) header, the encoding methods 155 investigated are: 157 1. Encoding using the combination of the ECN and DSCP bits of a data 158 packet header 160 2. Encoding using only the DSCP bits of a data packet header 162 We have also considered: 164 1. Encoding using only the ECN bits of a data packet header 166 2. Encoding and transport using a different channel than data 167 packets 169 But these have been considered out of scope for the current PCN 170 Charter and hence moved to the Appendix sections. Keeping them for 171 this version of the document to not loose our understanding of them 172 and for completeness of the survey. 174 The rest of this document is organized as follows: 176 o Section 2 describes the encoding requirements indicated by 177 currently known detection and marking mechanisms that can be used 178 within the PCN-domain. 180 o Section 3 describes the encoding options, organized based on the 181 IP header field(s) used for the encoding. 183 o Section 4 provides a summary on the encoding options 184 recommendation. 186 Additional criterion has been placed on the encoding choices due to 187 the more stringent requirements of tunneling. These additional 188 criterion and their effects on the encoding choices are explored in 189 section 2.2.7 PCN Encoding and Tunnels. There are also progress on 190 possible encoding choice indicated in 191 [I-D.ietf-pcn-baseline-encoding]. 193 2. Encoding Requirements 195 The internal PCN encoding requirements are based on the functionality 196 of PCN [I-D.ietf-pcn-architecture], and possibly how the PCN Marking 197 Algorithms achieve the functionality. There may be external 198 requirements depending on the environment in which PCN operates, for 199 example co-existence with ECN as indicated by RFC 4774 [RFC4774]. 200 These are discussed secondary to the internal PCN encoding 201 requirements because we have limited the PCN operational environment 202 in the PCN WG's first phase charter. But we also need to take into 203 consideration of the encoding standard should not need to be modified 204 for PCN to work in both current charter's environment and when 205 current charter's environment is expanded, for example, to multi- 206 domain and end-to-end. 208 2.1. Encoding States 210 Currently, there are a number of proposals for Pre-Congestion 211 Detection Algorithms. The authors of the different PCN Algorithm 212 documents have agreed to use the notion of Encoding States to 213 represent the information each algorithm wants to export, and hence 214 to be carried from the interior nodes to the edge nodes for flow 215 admission control and flow termination decisions. These Encoding 216 States form the fundamental functional requirements for the encoding 217 choices. 219 Please notice the number of "Encoding State" can be different from 220 the number of encoding bit patterns. For example more than two 221 "Encoding States" may be carried by two encoding bit pattern when the 222 multiple "Encoding States" can be modulated/ multiplexed over some 223 time domains. 225 For simplicity purpose, we indicate the main required encoding states 226 for PCN capable packets: 228 o Un-Marked (UM), for indication of No Pre-Congestion Indication. 230 o Admission Marked (AM), for indication of Flow Admission 231 Information. 233 o Termination Marked (TM), for indication of Flow Termination 234 Information. 236 o Affected Marked (AfM), for indication of ECMP Information. 238 A total of four main required encoding states for PCN capable 239 packets. 241 There are also encoding states that may be required, depending on the 242 environment assumptions made, these encoding states are described in 243 the following sub sections together with their environmental 244 considerations. 246 2.2. Encoding and Operating Environment 248 Currently the PCN Working Group Charter indicates the operating 249 environment being a single domain. If possible, we want a consistent 250 encoding used for current and future operating environment, may they 251 be a single PCN domain, multiple PCN domains, and PCN encoded packet 252 reaching the IP end-point. 254 In this section, we first discuss the operating environment's affect 255 on the encoding states. We then investigate the effect of the 256 operating environment on the encoding options. 258 2.2.1. PCN Capable (Non PCN Capable) Packet Encoding State 260 PCN Capable packet encoding, for separation from Non PCN Capable 261 packet. This encoding allows the PCN nodes to provide the PCN 262 treatments to only the PCN Capable packets. Allowing separation 263 between PCN Capable and Non PCN Capable packets. 265 The Working Group assumes the PCN traffic will be identified by the 266 DSCP codepoint it carries. But the precise meaning of this is not 267 entirely clear. There is a question whether: 269 1. a DSCP is meant to only represent a scheduling behaviour and 270 (pre-)congestion marking behaviour is an optional addition that 271 needs to be turned on or off within each existing DSCP (as for 272 RFC 3168 [RFC3168] ECN), or 274 2. we redefine the meaning of the DSCP field to represent a 275 combination of scheduling and marking behaviour. 277 If the first approach is used, for certain PHBs (e.g. EF [RFC3246]) 278 PCN marking would need the congestion marking behaviour turned on by 279 the setting of another field (e.g. the ECN field). Then there would 280 be a need to further distinguish PCN from Not-PCN packets, both using 281 the same DSCP. Requiring a PCN Capable/Non PCN Capable Encoding 282 State represented by a bit pattern using bits outside of the DSCP 283 field. Notice for this approach, we indicate Non PCN Capable bit 284 pattern because the use of the other PCN encoding bit patterns can 285 indicate PCN Capable. 287 In the second approach, for each scheduling behaviour needing to be 288 combined with PCN marking, a new paired DSCP would need to be 289 defined. Then both DSCPs would map to the same scheduling behaviour 290 but one will and one will not receive PCN treatment. For this 291 approach, the DSCP provides the indication of PCN Capable packets. 293 Hence the decision of taking approach one or approach two will 294 indicate if Non PCN Capable Packet Encoding State will be necessary. 296 When the Non PCN Capable Packet Encoding State is needed, we use the 297 encoding of Not-PCN Capable (Not-PCN) to represent this state. The 298 use of the other required PCN Encoding States will indicate this is a 299 PCN Capable Packet. 301 In this document when we discuss the encoding options of using both 302 the DSCP field and the ECN field to represent the PCN encoding 303 states, we assume the use of the second approach above. This allows 304 the separation between PCN Capable and Non PCN Capable packets be 305 totally taken care of by the use of the DiffServ field, leaving the 306 ECN field totally available for the other required PCN encoding 307 states' usage. 309 We believe the use of the second approach is a good choice because we 310 do not envision we will use PCN for many different scheduling 311 behaviours, hence we will not be creating many of these DSCP pairs. 312 And the use of the second approach allow PCN to use the natural 313 ability of DiffServ for PCN packets be handled separately, with the 314 PCN domain viewed as a separate forwarding domain within routers that 315 can handle multiple forwarding behaviors. This use of DiffServ also 316 ease the adoptation of multi-domain and end-to-end PCN in the future, 317 using inter-domain DiffServ agreements. 319 Superficially, the proposed new DSCP for capacity-admitted traffic 320 [I-D.ietf-tsvwg-admitted-realtime-dscp] seems like it could turn on 321 PCN marking with EF scheduling (approach 2). In this document an 322 early version of PCN is given as an example of schemes that might 323 need to use the new voice-admit codepoint. But the proposed new DSCP 324 for capacity-admitted traffic [I-D.ietf-tsvwg-admitted-realtime-dscp] 325 is really intended to distinguish EF traffic that is admission 326 controlled per flow at the edge of a Diffserv domain from EF traffic 327 merely policed in bulk. The new codepoint is not really intended to 328 switch on a new marking behaviour like PCN. 330 2.2.2. Nonce Encoding State 332 The ECN nonce RFC 3540 [RFC3540] for end-to-end ECN is used to 333 protect the sender from cheating by the receiver and/or by other down 334 stream nodes. PCN may or may not need a mechanism like the ECN 335 nonce. However single bit nonce schemes such as the ECN nonce 336 require in-order, reliable data delivery to function correctly. As 337 PCN operates at the IP layer, in-order delivery cannot be guaranteed. 338 If PCN needs a nonce functionality, it may need to think beyond the 339 current ECN nonce mechanism. And this is beyond the scope of this 340 document. 342 Currently, the PCN work we are doing assumes the trust relationship 343 between all the functional entities are already established. If this 344 assumption is not true, the trust relationships will need to be 345 addressed, but may or may not involve the needing of additional 346 encoding states or the use of the ECN nonce mechanism. 348 2.2.3. Non-PCN Traffic Entering PCN Domain 350 One of the operating environmental concerns is the accidental 351 handling of Non PCN packets by PCN nodes. The Non PCN packets may 352 be: 354 o Non ECN capable packets. 356 o ECN capable packets. 358 With concerns on the impacts of such non PCN packets on: 360 o the processing of PCN packets. 362 o the result of PCN processing on the non PCN packets. 364 We first look at the impacts of PCN processing on the non PCN packet 365 with original ECN bits: 367 o '00': This indicates the original packet is non ECN capable. The 368 best action is to drop this packet when congestion is experienced. 369 The changing of '00' to any other bit patterns will turn such 370 packet into an ECN capable packet for any down stream nodes. 372 o '01': This indicates the original packet is ECN capable. For ECN, 373 the only valid change is to change this packet to '11' when the 374 offered load needs to be reduced. Changing this packet to any 375 other bit pattern may affect down stream ECN nodes. 377 o '10': This indicates the original packet is ECN capable. This 378 packet have the same concerns as the '01' packets. 380 o '11': This indicates the original packet is ECN capable. This 381 encoding is used to indicate congestion and there is trust for the 382 sender to reduce the sending rate when the '11' encoding is 383 received by ECN end points. 385 With the assumption of using DSCP to separate PCN capable and non PCN 386 capable packets, we have to realize the non PCN packets that are 387 receiving PCN processing somehow are using the PCN DSCP. It may be 388 beneficial to assume the responsibility of what packets are allowed 389 to use the PCN DSCP inside the PCN domain rests with the PCN ingress 390 node. Making such assumption will also allow the connecting of 391 multiple PCN domains and eventually the goal of end to end PCN. With 392 the PCN encoding choice and PCN processing being friendly to non PCN 393 packets inside the PCN domain a second line of defense, after the use 394 of the correct PCN DSCP. 396 We defer the investigation of the impact of non PCN packets on PCN 397 processing to the sections that describe the encoding choices. 399 2.2.4. PCN Traffic Leaving PCN Domain 401 There may be two kinds of packets leaving the PCN domain 402 unintentionally, valid PCN packets and non PCN packets that received 403 PCN processing. Non PCN packets that did not receive PCN treatment 404 are considered never entered the PCN domain. 406 The first line of defense is still the use of the PCN DSCP, only 407 packets using the PCN DSCP will receive PCN treatment. Hence any PCN 408 packets leaving the PCN domain will have the PCN DSCP. Since the PCN 409 DSCP is unique, the only danger is for down stream domains to remark 410 the PCN DSCP to the best effort DSCP and the PCN packets being treat 411 as ECN packets. 413 2.2.5. PCN Encoding for Both Edge to Edge and End to End Deployment 415 It is the goal of the PCN Working Group to define a standard for PCN 416 encoding to allow the encoding be used first in the edge to edge and 417 then in the multi-domain and end to end deployment scenarios without 418 the need to change the standard. This section explores this 419 environmental consideration by indicating the requirement this 420 consideration will place on the PCN encoding selection. 422 2.2.6. PCN Encoding and Alternate ECN Semantics 424 Need to discuss the effects of ECN packets leaked into the PCN domain 425 and processed by PCN interior node. Need to discuss the effects of 426 PCN packets leaked into the PCN domain and processed by PCN interior 427 node. Need to discuss the effects of ECN packets leaked out of the 428 PCN domain into the ECN domain and processed by ECN router and ECN 429 end-points. Need to discuss the effects of PCN packets leaked out of 430 the PCN domain into the ECN domain and processed by ECN router and 431 ECN end-points. 433 RFC 4774 [RFC4774] have also required one to give consideration to 434 what harm might be caused by the leaking of PCN traffic into a non- 435 PCN domain. The following looks at each ECN codepoint and shows what 436 harm, if any, would be caused were that codepoint to leak from the 437 PCN domain: 439 o '00': The leak should be safe in all circumstances. RFC 3168 440 compliant routers will believe such packets to be not-ECN capable 441 and as such will drop them if the router is congested. This 442 codepoint may be suitable for different use by PCN. 444 o '01' and '10': RFC 3168 compliant routers will believe these 445 packets are from an ECN capable flow. If the routers are 446 congested they will mark these packets '11' (CE) instead of 447 dropping them. If the endpoints are not ECN capable then this is 448 not good for congestion control. The use of '01' and '10' by PCN 449 can be a potential issue. To be completely safe, it would be best 450 to avoid giving any PCN semantics to these codepoints. 452 o '11': If the packet was already part of an ECN capable flow then 453 receivers will believe this was an indication of congestion on the 454 path. They will thus inform their source of this and the source 455 will perform a congestion response. This codepoint may be 456 suitable for different use by PCN, the degree of suitability may 457 depend on the exact PCN encoding and the metering and marking 458 algorithm using the encoding. 460 More detailed consideration of these points are provided in the 461 sections describing the encoding options. 463 2.2.7. PCN Encoding and Tunnels 465 Additional criterion of handling ECN packets traversing the PCN 466 domain brings up the notion of tunneling in the PCN domain. There 467 has been much work in considering the use of PCN with tunnels, as 468 indicated by [I-D.ietf-tsvwg-ecn-tunnel]. 470 The additional restriction placed on the ECN field by tunneling rules 471 can be summarized as follows: 473 1. RFC 3168 [RFC3168] indicates the ECN bits of the outer IP header 474 may be set to Not-ECT at tunnel ingress. And at tunnel egress, 475 the ECN bits of the inner IP header are unchanged by the tunnel 476 mechanism. This will apply packet dropping and not packet 477 marking when congestion is encountered during tunnel. 479 2. RFC 3168 [RFC3168] also indicates only the Not-ECT and ECT code 480 point of the ECN bits may be copied from the inner IP header to 481 the outer IP header at tunnel ingress and only the CE code point 482 may be copied back to the inner IP header at tunnel egress. This 483 limits the use of only the CE code point during tunnel. 485 3. RFC 4301 [RFC4301] allows the complete ECN field be copied from 486 the inner IP header to the outer header at ingress but only allow 487 the CE code point be copied from outer IP header to the inner IP 488 header at egress. Less restrictive than RFC 3168 [RFC3168] but 489 still limits the use of the ECN field by PCN functionalities. 491 These additional restrictions will be applied to the encoding choices 492 in an up-coming version of this document. 494 2.3. Encoding Selection Criteria 496 Two possible locations within the IP header have been identified as 497 suitable for encoding PCN. These are the 2 bit ECN field whose 498 default meaning is defined in RFC 3168 [RFC3168] and the 6 bit DSCP 499 field defined in RFC 2474 [RFC2474] and RFC 2475 [RFC2475]. It is 500 already accepted that PCN traffic will be distinguished according to 501 which DSCP codepoint it carries. The implications of this decision 502 were discussed in section 2.2.1 above. The current assumption is 503 that PCN will need to be specified as the marking behaviour through 504 definition of a new PCN DSCP. 506 There are a number of other potential issues that might affect the 507 exact choice of encoding to be used. The key ones are: 509 1. The support of the required encoding states to satisfy the 510 functional requirement of PCN. These required encoding states 511 may need two, or three, or four encoding code points to 512 represent. 514 2. Compliance with RFC 4774 [RFC4774] if the ECN field is to be re- 515 used for PCN encoding. 517 3. Compliance with the requirements for specifying DSCPs and DSCP 518 per-hop-behaviour groups [RFC2474]. 520 Each of these are examined in further details in encoding option 521 sections describing their usage. 523 With the above discussion, in additon to the criteria indicated so 524 far, we should give higher preference to encoding options that: 526 o Minimize problems if there are packet leakage by the PCN domain. 528 o Is safest for wider deployment of PCN, when the current chartered 529 environment restriction is relaxed. 531 3. Encoding Options 533 There are couple of methods to carry the encoding states. The method 534 used affects the encoding options. Hence when we describe the 535 different encoding options in this section, we group them based on 536 how the encoding states are carried. 538 The encoding transport methods considered are: 540 o using the combination of the ECN and DSCP bits of a data packet 541 header 543 o using only the ECN bits of a data packet header 545 o using only the DSCP bits of a data packet header 547 We discuss the encoding options for each of the encoding transport 548 methods separately in their own subsections. For shorter reading, we 549 have moved the encoding choices the working group have agreed to not 550 consider (Using only ECN field, Out-of-Band Channel) sections to the 551 Appendix. 553 3.1. Encoding Using ECN and DSCP Fields 555 The use of both DSCP and ECN fields is following the second approach 556 indicated in section 2.2.1. This approach allows a clean traffic 557 treatment separation of PCN Capable traffic and Non PCN Capable 558 traffic. This natural use of the DSCP field, to provide treatment 559 differentiation of packets using different DSCP encoding, is one way 560 of providing the "PCN Capable Packet" encoding state. The using of 561 this approach allows us to focus on encoding the four required PCN 562 Encoding States, as indicated in section 2.1, using the two ECN bits. 564 ----------------------------------------------------------------------- 565 | ECN Bits || 00 | 01 | 10 | 11 || DSCP | 566 |==============++==========+==========+==========+==========++==========| 567 | RFC 3168 || Not-ECT | ECT(1) | ECT(0) | CE || NA | 568 |==============++==========+==========+==========+==========++==========| 569 | Option 1 || AM | UM | UM | TM || PCN-1 | 570 |--------------++----------+----------+----------+----------++----------| 571 | Option 2 || AfM | UM | UM | AM/TM || PCN-1 | 572 |--------------++----------+----------+----------+----------++----------| 573 | Option 3 || UM | NA | NA | AM/TM || PCN-1 | 574 |--------------++----------+----------+----------+----------++----------| 575 | Option 4 || UM | NA | NA | AM || PCN-1 | 576 | || | | | TM || PCN-2 | 577 |--------------++----------+----------+----------+----------++----------| 578 | Option 5 || AM | TM | UM | NA || PCN-1 | 579 ----------------------------------------------------------------------- 581 Notes: NA means Not Applicable. PCN-1, PCN-2 under the DSCP column 582 denotes specific DSCPs used to indicate PCN capable packets. AM/TM 583 means the two encoding states are sharing the same encoding bit 584 pattern. UM means Un-Marked to represent Not Pre-Congested. 586 Figure 1: Encoding of PCN Information Using DSCP and ECN Fields 588 In Figure 1, we listed the fundamental options when both DSCP and ECN 589 fields are used. There are couple of variations of the theme 590 provided by these options. One way of comparing these options is by 591 examining the pros and cons of the different ways the four code 592 points provided by the two ECN bits are used. We group these 593 discussions in the following way: 595 1. The '01' and '10' code points. 597 2. The '11' code point. 599 3. The '00' code point. 601 We discuss each of them in the following sub-sections. 603 3.1.1. The Use of '01' and '10' Encoding for PCN 605 There can be different degrees of usage of the '01' and '10' code 606 points by PCN: 608 1. PCN Does NOT use the '01' and '10' code points. This will be the 609 safest choice. But this choice will leave us with only two 610 usable code points, unless we want to deploy more than one PCN 611 DSCPs. Even when the PCN domain does not use these code points, 612 the PCN domain still have to handle the receiving of '01' and 613 '10' packets at ingress. The notion of safe comes in two 614 flavors, first if there is any packets in the PCN domain having 615 the '01' or '10' encoding, it is immediately known that these are 616 packets in error, either they are leaked into the PCN domain in 617 error or are set to '01' or '10' in error inside the PCN domain. 618 In both cases, action can be taken. The second flavor of safe is 619 if a legitimate PCN packet leaks out of the PCN domain, it will 620 not have the '01' or '10' encoding and should not cause an ECN 621 router to mistaken the PCN packets to be ECN packets. 623 2. PCN uses '01' and '10' code points in an ECN friendly manner. 624 One ECN friendly manner is to have both '01' and '10' to mean 625 "PCN Capable Packet". The determination of ECN friendliness 626 depends on the use of code points beside '01' and '10'. 628 3.1.2. The Use of '11' Encoding for PCN 630 3.1.3. The Use of '00' Encoding for PCN 632 For example, the "01" and "10" encoding can be interpreted as PCN(A) 633 and PCN(T) instead of just PCN. Using the PCN(A) and PCN(T) 634 variation provides the additional information of the ratio of packets 635 AM marked to packets Not AM marked, and the ratio of packets TM 636 marked to packets Not TM marked. Having these ratios being 637 independent from one another. Another variation on the theme is the 638 use of an extra DSCP value to represent the TM encoding state for 639 Option 2. Doing so will eliminate the need to modulate both AM and 640 TM using the single "11" encoding. 642 Notice the Affected Mark encoding state is not directly carried by 643 the ECN bits in Option 1. A variation of Option 1 is to represent 644 the Affected Mark encoding state using '01'. But this may result in 645 interference by RFC 3168 ECN routers when there is mis-configuration, 646 please see section 3.1.4 on discussion of RFC 4774 Concern 2 for more 647 details. 649 3.1.4. Benefits of Using DSCP and ECN Fields 651 A major feature of using both DSCP and ECN fields is the ability to 652 use the inherent nature of DiffServ for traffic class separation to 653 allow PCN treatment be applied to PCN traffic, without concerns of 654 applying PCN treatment to none PCN traffic and vise versa. This 655 feature frees this approach for PCN encoding from some of the 656 concerns raised by RFC 4774 [RFC4774]. This feature will also keep 657 none PCN Capable traffic out of the PCN treatment mechanisms, 658 allowing the PCN treatment mechanisms focus on their respective PCN 659 tasks. 661 This approach also leaves the ECN field available totally for PCN 662 encoding states purposes. Removing the need to carry the Not-PCN 663 Encoding in the ECN field. 665 3.1.5. Drawbacks of Using DSCP and ECN Fields 667 The use of both DSCP and ECN fields will require the setting aside of 668 one (or possibly two) DSCP for use by PCN. This may add complexity 669 to the PCN encoding standardization effort. 671 3.1.6. Comparing DSCP and ECN Fields Encoding Options 673 Here we discuss the differences between the different encoding 674 options when both DSCP and ECN fields are used. There are many 675 encoding options, we have provided the ones we think are favorable in 676 Figure 1. 678 When DSCP is used to differentiate between PCN capable and Not-PCN 679 capable traffic, the encoding of "Not-PCN" in the ECN field is not 680 required. This is the motivation for Option 1 in Figure 1, where the 681 encoding "00" for "Not-ECT" is being used for "AM" (Admission 682 Marking) encoding state. The encodings "01" and "10" for "ECT(1)" 683 and "ECT(0)" supports the required encoding states for "Not Pre- 684 Congested Marking" (PCN), and reserving them for any "Nonce Marking" 685 if necessary. With the possible additional encoding of "PCN(A)" and 686 "PCN(T)" in place of "ECT(1)" and "ECT(0)" for indicating percentage 687 of Admission Marked traffic and percentage of Termination Marked 688 traffic when the algorithm benefits from such additional information. 690 Option 2 in Figure 1 uses the "00" encoding for "AfM". With '01' and 691 '10' encoding the same as for Option 1, requiring the use of "11" 692 encoding for both "AM" (Admission Mark) and "TM" (Termination Mark) 693 states or requiring the allocation of a DSCP for encoding the "TM" 694 state. 696 3.1.7. Concerns on Alternate Semantics for the ECN Field 698 Section 2 of RFC 4774 [RFC4774] raised couple of concerns for usage 699 of alternate semantics for the ECN field. We try to address each of 700 the concerns in this section. 702 1. Section 3.1 of RFC 4774 [RFC4774] discusses Concern 1: "How 703 routers know which ECN semantics to use with which packets." 704 This use of DSCP and ECN for encoding PCN states address this by 705 following the recommendation of RFC 4774 [RFC4774] on using a 706 diffserv codepoint to identify the packets using the alternate 707 ECN semantics. This diffserv codepoint may possibly be a new 708 diffserv codepoint to minimize the possible confusion between 709 using the old per hop behavior of the codepoint and the using of 710 the alternate ECN semantics per hop behavior of the codepoint. 712 2. Section 4 of RFC 4774 [RFC4774] discusses Concern 2: "How does 713 the possible presence of old routers affect the performance of 714 the alternate ECN connections." With the notion of old routers 715 meaning routers that performs RFC 3168 ECN processing instead of 716 PCN processing. The easy answer is the environment using the 717 alternate ECN semantics is envisioned to be within a single 718 administrative domain. With the ability to ensure that all 719 routers along the path understand and agree to the use of the 720 alternate ECN semantics for the traffic identified by the use of 721 a diffserv codepoint. This uses option 2 indicated in section 722 4.2 of RFC 4774 [RFC4774]. But incase there is mis- 723 configuration, the choice of encoding may make a difference: 725 * With encoding Option 1, the old routers will interprete: 727 + '00' encoding as Not-ECT, and will drop AM marked packets. 728 The PCN edge nodes should not admit traffic that it does 729 not receive, hence the PCN admission functionality should 730 be OK. 732 + '01' encoding as ECT(1), which indicates ECN capable and 733 can be remarked to '11' to indicate congestion experienced. 734 The RFC 3168 ECN CE encoding have the same functionality as 735 the PCN TM encoding, to reduce the offered traffic load. 736 Hence the PCN termination functionality should be OK. 738 + '10' encoding as ECT(0). The discussion for '01' above 739 applies equally to this encoding. 741 + '11' encoding as CE. The old router should use this 742 encoding to reduce the offered traffic load and should not 743 remark this to any other ECN encoding, the same 744 functionality the PCN TM encoding requires, hence should be 745 OK for PCN. 747 The above discussion for Option 1 applies equally for PCN 748 traffic leaked out of the PCN domain and interpreted by RFC 749 3168 ECN nodes. 751 * With encoding Option 2, the old routers will interprete: 753 + '00' encoding as Not-ECT, and will drop AfM marked packets. 754 This may possibly affect the efficiency of the Affected 755 Marking functionality. 757 + '01' encoding as ECT(1), which indicates ECN capable and 758 can be remarked to '11' to indicate congestion experienced. 759 The RFC 3168 ECN CE encoding have the same functionality as 760 the PCN TM encoding, to reduce the offered traffic load. 761 Depending on the PCN algorithm on how AM and TM share the 762 same '11' encoding, this may or may not affect the 763 functionality of PCN. 765 + '10' encoding as ECT(0). The discussion for '01' above 766 applies equally to this encoding. 768 + '11' encoding as CE. The old router should use this 769 encoding to reduce the offered traffic load and should not 770 remark this to any other ECN encoding. Depending on the 771 PCN algorithm on how AM and TM share the same '11' 772 encoding, this may or may not affect the functionality of 773 PCN. 775 The above discussion for Option 2 applies equally for PCN 776 traffic leaked out of the PCN domain and interpreted by RFC 777 3168 ECN nodes. 779 3. Concern 3: "How does the possible presence of old routers affect 780 the coexistence of the alternate ECN traffic with competing 781 traffic on the path." Within the PCN domain, the PCN (alternate 782 ECN) traffic is separated from the other traffic using diffserv. 783 If by mis-configuration, an old routers that does not understand 784 PCN handles PCN traffic, the PCN traffic will get the per hop 785 behavior as the other traffic, hence not receiving the benefits 786 of PCN at the old router, but will not affect the coexistence of 787 the PCN and the other traffic. If the old router uses RFC 3168 788 ECN congestion treatment, then the discussion for Concern 2 above 789 applies. 791 4. Concern 4: "How well does the alternate ECN traffic perform." 792 The performance of the different proposed PCN (alternate ECN) 793 metering and marking algorithms are currently under study with 794 their simulation and study results described by their respective 795 documents. 797 The environment using the alternate ECN semantics is envisioned to be 798 within a single administrative domain. With the ability to ensure 799 that all routers along the path understand and agree to the use of 800 the alternate ECN semantics for the traffic identified by the use of 801 a diffserv codepoint. This uses option 2 indicated in section 4.2 of 802 RFC 4774 [RFC4774]. 804 3.1.8. Encoding Choice Considerations 806 o If three encoding states need to be separately represented, Option 807 1 is recommended. 809 o If two encoding states need to be separately represented, for 810 example the marking algorithm allows the AM and TM encoding states 811 be represented using the same bit pattern, Options 2 and 3 are 812 recommended. 814 o If RFC 4774 [RFC4774] concerns need to be addressed by PCN 815 encoding, then Option 1 is recommended, please see section 3.1.4 816 for the detail discussion. Options 2 and 3 may be able to address 817 the RFC 4774 [RFC4774] concerns, but a heavier burden is placed on 818 the metering and marking algorithms to differentiate between TM 819 and AM meaning of the '11' encoding when a RFC 3168 ECN router 820 sets the '11' encoding. 822 o If the metering and marking algorithm requires the use of Affected 823 Marking encoding state, Option 2 is recommended. Alternatively 824 one of the bit patterns of '01' or '10' may be used for the AfM 825 purpose. But using '01' or '10' bit patterns for AfM may increase 826 the interference between RFC 3168 ECN and PCN encodings, please 827 see section 3.1.4 for the detail discussion. 829 o If Option 1 is used and the functionality of Affected Marking 830 encoding state is required, the metering and marking algorithms 831 will need to provide this functionality without the use of the 832 Affected Marking encoding state. 834 3.2. Encoding Using DSCP Field 836 In this type of encoding and transport method the congestion and 837 precongestion information is encoded into the 6 DSCP bits that are 838 transported in the IP header of the data packets. Four possible 839 alternatives can be distinguished, as can be seen in Figure 2, with 840 details provided by draft-westberg-pcn-load-control-02.txt 841 [I-D.westberg-pcn-load-control]. Option 7 needs 2 additional DSCP 842 values, Options 8 and 9 need three additional DSCP values and Option 843 10 needs four additional DSCP values. Note that all additional and 844 experimental DSCP values are representing and are associated with the 845 same PHB. The 1st, 2nd, 3rd, and 4th DSCP values are representing 846 DSCP values that are assigned by IANA as DSCP experimental values, 847 see RFC 2211 [RFC2211]. 849 ----------------------------------------------------------------------- 850 | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add DSCP 3 |Add DSCP 4 | 851 |===========++==========+===========+===========+===========+===========| 852 | Option 6 || Not-PCN | UM | AM/TM | NA | NA | 853 |-----------++----------+-----------+-----------+-----------+-----------| 854 | Option 7 || Not-PCN | UM | AM/TM | AfM | NA | 855 |-----------++----------+-----------+-----------+-----------+-----------| 856 | Option 8 || Not-PCN | UM | AM | TM | NA | 857 |-----------++----------+-----------+-----------+-----------+-----------| 858 | Option 9 || Not-PCN | UM | AM | TM | AfM | 859 ----------------------------------------------------------------------- 861 Notes: Not-PCN means the packet is not PCN capable. UM for Un-Marked 862 meaning Not Pre-Congested 864 Figure 2: Encoding of PCN Information Using DSCP Field 866 3.2.1. Benefits of Using DSCP Field 868 The main benefits of using the DSCP field for PCN encoding are: 870 o it is not affecting the end-to-end ECN semantics and therefore the 871 issues and concerns raised in RFC 4774 [RFC4774] are not 872 applicable for this encoding scheme. 874 o all 4 DSCP encoding options depicted in Figure 2 can support the 875 PCN capable not congested/UnMarked (UM) indication, the admission 876 control (AM) and flow termination (TM) encoding states. 878 o the experimental DSCPs are lightly standardized and therefore, the 879 rules on how to apply and use them are limited. This provides a 880 high flexibility to network operators to apply and use them in 881 different settings. 883 o simple packet classification, since a router needs only to read 884 the DSCP field, instead of reading both DSCP and ECN fields. 886 o Option 8 and 10 support the Affected Marking (AfM) encoding, which 887 according to [I-D.westberg-pcn-load-control], it has benefits if 888 the PCN-domain operates ECMP routing and is not using DSCP for 889 route selection. 891 o by using an additional DSCP to encode the not congested PCN state, 892 all PCN-ingress-nodes can be configured to encode this state into 893 all packets that are entering the PCN domain and are PCN aware. 894 This will solve any PCN-egress-node misconfiguration problems, 895 which can allow a AM/TM or SM encoded packet to outgo a PCN- 896 domain. 898 3.2.2. Drawbacks of Using DSCP Field 900 The main drawbacks of using the DSCP field for PCN encoding are the 901 following: 903 this type of encoding needs to use per PHB, in addition to the 904 original DSCP and depending on the encoding option used, one, two, 905 three, or four DSCP values, respectively. These additional DSCP 906 values can be taken from the DSCP values that are not defined by 907 standards action, see RFC 2211 [RFC2211]. Note that all the 908 additional DSCP values are representing and are associated with 909 one PHB. The value of this DSCP/PHB can either follow a standards 910 action or use a value that is applied for experimental or local 911 use. It is important to note that the number of the DSCP values 912 used for local or experimental use is restricted and therefore the 913 number of different PHBs supported in the PCN domain will also be 914 restricted. 916 applying the DSCP field as PCN encoding transport within an PCN 917 aware MPLS domain, see RFC 5129 [RFC5129], can be problematic due 918 to the scarce packet header real-estate. 920 when the PCN-domain is operating ECMP that uses DSCP to select the 921 routes, a risk of mis-ordering of packets within a flow might 922 occur. The impact of this drawback depends on the following: 924 1. the level of deployment of ECMP algorithms that use DSCP for 925 route selection; 927 2. mis-ordering of packets within a flow when there is 928 termination marking may be acceptable; 930 3. the possibility of configuring the ECMP algorithms that use 931 DSCP for route selection in the PCN-domain that the used PCN 932 aware DSCPs are belonging to the same PHB and therefore, all 933 these DSCP values should be converted to one preconfigured 934 DSCP value before applying it in the ECMP routing algorithm. 935 Note that all the additional experimental DSCPs that are used 936 within PCN are belonging to the same PHB. 938 3.2.3. Comparing DSCP Field Encoding Options 940 Option 6 can support the basic encoding states, i.e,.not PCN, not 941 congested (UM), and the AM/TM encoding states. Option 7 can support 942 the basic encoding states supported by Option 6, but in addition it 943 can support the AfM state. Option 8 can support the following basic 944 encoding states: not PCN, not congested (UM), AM and TM states. 945 Option 9 can support the states supported by Option 8, but in 946 addition it can support the AfM state. Furthermore, in options 6 and 947 7 the encoding sequence associated with Admission Control and Flow 948 Termination is independent of each other. In options 8 and 9 a 949 packet cannot be AM encoded if it has been earlier TM encoded. 951 4. Encoding Recommendations 953 5. Security Implications 955 Packets from normal precedence and higher precedence sessions 956 [ITU-MLPP] aren't distinguishable by PCN Interior Nodes. This 957 prevents an attacker specifically targeting, in the data plane, 958 higher precedence packets (perhaps for DoS or for eavesdropping). 959 However, PCN End Nodes can access this information to help decide 960 whether to admit or terminate a flow. The separation of network 961 information provided by the Interior Nodes and the precedence 962 information at the PCN End Nodes allows simpler, easier and better 963 focused security enforcement. 965 PCN End Nodes police packets to ensure a flow sticks within its 966 agreed limit. This is similar to the existing IntServ behaviour. 967 Between them the PCN End Nodes must fully encircle the PCN-Region, 968 otherwise packets could enter the PCN-Region without being subject to 969 admission control, which would potentially destroy the QoS of 970 existing flows. 972 It is assumed that all the Interior Nodes and PCN End Nodes run PCN 973 and trust each other (ie the PCN-enabled Internet Region is a 974 controlled environment). For instance a non-PCN router wouldn't be 975 able to alert that it's suffering pre-congestion, which potentially 976 would lead to too many calls being admitted (or too few being 977 terminated). Worse, a rogue router could perform attacks such as 978 marking all packets so that no flows were admitted. 980 So security requirements are focussed at specific parts of the PCN- 981 Region: 983 The PCN End Nodes become the trust points. The degree of trust 984 required depends on the kinds of decisions it has to make and the 985 kinds of information it needs to make them. For example when the 986 PCN End Node needs to know the contents of the sessions for making 987 the decisions, when the contents are highly classified, the 988 security requirements for the PCN End Nodes involved will also 989 need to be high. 991 PCN-marking by the Interior Nodes along the packet forwarding path 992 needs to be trusted, because the PCN End Nodes rely on this 993 information. 995 6. IANA Considerations 997 To be completed. 999 7. Acknowledgements 1001 To be completed. 1003 Appendix A. Encoding Using ECN Field 1005 This section takes the approach 1 option indicated in section 2.1.1. 1006 Which the DSCP field only indicates the packet forwarding behavior, 1007 for which both PCN Capable and Non PCN Capable traffic use/share the 1008 same DSCP. This approach requires the use of the Not PCN Capable 1009 Encoding State to be encoding using the ECN bits. Hence this section 1010 describes the encoding options that uses only the ECN field (without 1011 the DSCP field) available in the IP header of the data packets to 1012 encode the PCN states. 1014 The use of the same DSCP for both PCN Capable and Non PCN Capable 1015 also opens the question of having PCN and RFC 3168 ECN traffic using 1016 the same DSCP. Which increases the importance of satisfying the 1017 concerns indicated in RFC 4774. 1019 ----------------------------------------------------------------------- 1020 | ECN Bits || 00 | 01 | 10 | 11 || DSCP | 1021 |==============++==========+==========+==========+==========++==========| 1022 | RFC 3168 || Not-ECT | ECT(1) | ECT(0) | CE || NA | 1023 |==============++==========+==========+==========+==========++==========| 1024 | Option 10 || Not-PCN | AM | PCN | TM || NA | 1025 |--------------++----------+----------+----------+----------++----------| 1026 | Option 11 || Not-PCN | PCN | PCN | AM/TM || NA | 1027 |--------------++----------+----------+----------+----------++----------| 1028 | Option 12 || Not-PCN | AfM | PCN | AM/TM || NA | 1029 ----------------------------------------------------------------------- 1031 Figure 3: Encoding of PCN Information Using ECN Field 1033 In Figure 2, we listed the fundamental options when only the ECN 1034 field is used. Like in Figure 1, there are variations of the theme 1035 provided by these options. For example, when both "01" and "10" 1036 encoding are used for NPM in Option 4, they can be interpreted as 1037 PCN(A) and PCN(T) instead of just PCN. Using the PCN(A) and PCN(T) 1038 variation provides the additional information of the ratio of packets 1039 AM marked to packets Not AM marked, and the ratio of packets TM 1040 marked to packets Not TM marked. Having these ratios being 1041 independent from one another. 1043 For Option 10, the use of '01' for AM and '10' for PCN can be swapped 1044 and provide the same functionality. For Option 12, the use of '01' 1045 for AfM and '10' for PCN can also be swapped without change of 1046 functionality. 1048 Appendix A.1. Benefits of Using ECN Field 1050 The using of only the ECN field for encoding PCN encoding states 1051 allow more efficient use of the DSCP field, not requiring the 1052 allocation of PCN specific DSCP values. 1054 This approach also opens the question of possibly having both PCN and 1055 ECN traffic using the same DSCP. 1057 When the same treatment can be provided to both ECN and PCN traffic 1058 to achieve each of ECN and PCN purpose, then not having DiffServ as 1059 separation between ECN and PCN traffic may be a benefit. Under such 1060 circumstances, having the same encoding between ECN and PCN may be 1061 desireable. But this can only be true if the requirement set forth 1062 in RFC 4774 [RFC4774] for alternate ECN semantics can be satisfied. 1064 If the same treatment can be applied to both ECN and PCN traffic, 1065 then: 1067 o The first issue of RFC 4774 [RFC4774]: "How routers know which ECN 1068 semantics to use with which packets." may be solved because there 1069 are no difference in the treatments of ECN and PCN packets, hence 1070 they can use the same semanics. 1072 o The second and third issues of RFC 4774 [RFC4774]: "How does the 1073 possible presence of old routers affect the performance of the 1074 alternate ECN connections." and "How does the possible presence of 1075 old routers affect the coexistence of the alternate ECN traffic 1076 with competing traffic on the path." are also solved because there 1077 are no difference in the treatment of ECN and PCN packets. 1079 o The forth issue of RFC 4774 [RFC4774]: "How well does the 1080 alternate ECN traffic perform." are dependent on the algorithm 1081 used, and should be provided by the respective algorithm document, 1082 and not in the scope of this document. 1084 Appendix A.2. Drawbacks of Using ECN Field 1086 Notice this group of encoding options does not use DiffServ code 1087 points for PCN encoding. With this group of encoding options, the 1088 required states of "PCN Capable Transport"/"None PCN Capable 1089 Transport" must be encoded using the ECN field. Leaving less 1090 encoding real estate to carry the remaining required PCN encoding 1091 states. Another drawback is without the protection/separation 1092 capability provided by DiffServ, it is typically harder to satisfy 1093 the requirement set forth in RFC 4774 [RFC4774] for alternate ECN 1094 semantics. 1096 Appendix A.3. Concerns on Alternate Semantics for the ECN Field 1098 Section 2 of RFC 4774 [RFC4774] raised couple of concerns for usage 1099 of alternate semantics for the ECN field. We try to address each of 1100 the concerns in this section. 1102 1. Section 3.1 of RFC 4774 [RFC4774] discusses Concern 1: "How 1103 routers know which ECN semantics to use with which packets." 1104 When this group of PCN encodings are used without the use of 1105 DSCP, routers can not distinguished PCN encoded packets from RFC 1106 3168 ECN encoded packets. Hence there needs to be some kind of 1107 differentiation between PCN and RFC 3168 ECN packets, may be 1108 using PCN for real-time traffic types (with specific DSCP) and 1109 ECN for elastic traffic (with specific DSCP). And only 1110 distinguishing PCN Capable and Non-PCN Capable packets in real- 1111 time traffic. Only distinguishing ECT and Not-ECT packets in 1112 elastic traffic. But not having PCN and ECN traffic together. 1114 2. Section 4 of RFC 4774 [RFC4774] discusses Concern 2: "How does 1115 the possible presence of old routers affect the performance of 1116 the alternate ECN connections." With the notion of old routers 1117 meaning routers that performs RFC 3168 ECN processing instead of 1118 PCN processing, or drop packets instead of encoding the 1119 congestion information. The easy answer is the environment using 1120 the alternate ECN semantics is envisioned to be within a single 1121 administrative domain. With the ability to ensure that all 1122 routers along the path understand and agree to the use of the 1123 alternate ECN semantics for the traffic identified to be PCN 1124 Capable. This uses option 2 indicated in section 4.2 of RFC 4774 1125 [RFC4774]. But incase there is mis-configuration, the choice of 1126 encoding may make a difference: 1128 * With encoding Option 10, the old routers will interprete: 1130 + '00' encoding as Not-ECT, and will drop Not-PCN marked 1131 packets when congestion is detected. With '00' the 1132 encoding for Not-PCN, requiring the same functionality as 1133 Not-ECT, the presence of old routers will not affect the 1134 performance of PCN functionality. 1136 + '01' encoding as ECT(1), which indicates ECN capable and 1137 can be remarked to '11' to indicate congestion experienced. 1138 For Option 3, the old router can possibly remark AM to TM. 1139 This puts a burden on the metering and marking algorithms 1140 to treat TM encoded packets to indicate stop admission. 1141 This may or may not be acceptable, depending on the 1142 algorithm. 1144 + '10' encoding as ECT(0), which indicates ECN capable and 1145 can be remarked to '11' to indicate congestion experienced. 1146 The RFC 3168 ECN CE encoding have the same functionality as 1147 the PCN TM encoding, to reduce the offered traffic load. 1148 Hence the PCN termination functionality should be OK. 1150 + '11' encoding as CE. The old router should use this 1151 encoding to reduce the offered traffic load and should not 1152 remark this to any other ECN encoding, the same 1153 functionality the PCN TM encoding requires, hence should be 1154 OK for PCN. 1156 The above discussion for Option 10 applies equally for PCN 1157 traffic leaked out of the PCN domain and interpreted by RFC 1158 3168 ECN nodes. 1160 * With encoding Option 11, the old routers will interprete: 1162 + '00' encoding as Not-ECT, and will drop Not-PCN marked 1163 packets when congestion is detected. With '00' the 1164 encoding for Not-PCN, requiring the same functionality as 1165 Not-ECT, the presence of old routers will not affect the 1166 performance of PCN functionality. 1168 + '01' encoding as ECT(1), which indicates ECN capable and 1169 can be remarked to '11' to indicate congestion experienced. 1170 The RFC 3168 ECN CE encoding have the same functionality as 1171 the PCN TM encoding, to reduce the offered traffic load. 1172 Depending on the PCN algorithm on how AM and TM share the 1173 same '11' encoding, this may or may not affect the 1174 functionality of PCN. 1176 + '10' encoding as ECT(0). The discussion for '01' above 1177 applies equally to this encoding. 1179 + '11' encoding as CE. The old router should use this 1180 encoding to reduce the offered traffic load and should not 1181 remark this to any other ECN encoding. Depending on the 1182 PCN algorithm on how AM and TM share the same '11' 1183 encoding, this may or may not affect the functionality of 1184 PCN. 1186 The above discussion for Option 11 applies equally for PCN 1187 traffic leaked out of the PCN domain and interpreted by RFC 1188 3168 ECN nodes. 1190 * With encoding Option 12, the old routers will interprete: 1192 + '00' encoding as Not-ECT, and will drop Not-PCN marked 1193 packets when congestion is detected. With '00' the 1194 encoding for Not-PCN, requiring the same functionality as 1195 Not-ECT, the presence of old routers will not affect the 1196 performance of PCN functionality. 1198 + '01' encoding as ECT(1), which indicates ECN capable and 1199 can be remarked to '11' to indicate congestion experienced. 1200 For Option 5, the old router can possibly remark AfM to TM. 1201 This may or may not be acceptable, depending on the 1202 algorithm's Affected Marking functionality. 1204 + '10' encoding as ECT(1), which indicates ECN capable and 1205 can be remarked to '11' to indicate congestion experienced. 1206 The RFC 3168 ECN CE encoding have the same functionality as 1207 the PCN TM encoding, to reduce the offered traffic load. 1208 Depending on the PCN algorithm on how AM and TM share the 1209 same '11' encoding, this may or may not affect the 1210 functionality of PCN. 1212 + '11' encoding as CE. The old router should use this 1213 encoding to reduce the offered traffic load and should not 1214 remark this to any other ECN encoding. Depending on the 1215 PCN algorithm on how AM and TM share the same '11' 1216 encoding, this may or may not affect the functionality of 1217 PCN. 1219 The above discussion for Option 12 applies equally for PCN 1220 traffic leaked out of the PCN domain and interpreted by RFC 1221 3168 ECN nodes. 1223 3. Concern 3: "How does the possible presence of old routers affect 1224 the coexistence of the alternate ECN traffic with competing 1225 traffic on the path." If RFC 3168 ECN and PCN traffic are to be 1226 treated within a single DiffServ PHB, because with these encoding 1227 there is no way to differentiate between the ECN packets from the 1228 PCN traffic, the metering and marking algorithm used must be 1229 totally friendly between ECN and PCN traffic, else they will 1230 affect each other in possibly non-acceptable ways. These 1231 encoding will work OK with traffic besides ECN because of the use 1232 of 'Not-PCN' encoding. 1234 4. Concern 4: "How well does the alternate ECN traffic perform." 1235 The performance of the different proposed PCN (alternate ECN) 1236 metering and marking algorithms are currently under study with 1237 their simulation and study results described by their respective 1238 documents. 1240 Appendix A.4. Encoding Choice Considerations 1242 o If three encoding states need to be separately represented, Option 1243 10 is recommended. 1245 o If the marking algorithm allows the AM and TM encoding states be 1246 represented using the same bit pattern, Option 11 is recommended. 1248 o If the marking algorithm requires the use of Affected Marking 1249 encoding state, Option 12 is recommended. For Option 12, 1250 alternative NPM bit patterns ('01' or '10') may be used for the 1251 AfM purpose. 1253 Appendix B. Out-of-Band Channel as Encoding Transport 1255 In this type of encoding and transport method the congestion and 1256 precongestion information can be encoded using the IPFIX protocol RFC 1257 3955 [18], that is normally used to carry flow-based IP traffic 1258 measurements from an observation point to a collecting point. Note 1259 that this encoding scheme is denoted in this document as "IPFIX 1260 channel". An observation point is a location in a network where IP 1261 packets can be observed and measured. A collecting point can be a 1262 process or a node that receives flow records from one or more 1263 observation points. In the PCN case, each PCN-interior-node will be 1264 an IPFIX observation point and the PCN-egress-node will be the IPFIX 1265 collecting point. 1267 The PCN-interior-node will support the metering process and the flow 1268 records. Note that in this case each flow record can be associated 1269 with the record of the congestion and pre-congestion metering 1270 information associated with each PHB. The PCN-egress-node will then 1271 support the IPFIX collecting process, which will receive flow records 1272 from one or more congested and pre-congested PCN-interior-nodes. 1273 Using this encoding method the encoding modes/states can be 1274 aggregated and transported to the egress node by using the flow 1275 records at regular intervals or at the moment that a congestion and 1276 pre-congestion situation occurs. The used transport channel in this 1277 case is not the data path but a signaling protocol. 1279 Appendix B.1. Benefits of Using Out-Of-Band Channel 1281 This encoding scheme does not use the data path for encoding and 1282 transport, but it is able to transport the congestion and pre- 1283 congestion information associated with the encoding states by using a 1284 separate signaling channel. Another benefit of using this encoding 1285 scheme is that it is not affecting the end-to-end ECN semantics and 1286 therefore the issues and concerns raised in RFC 4774 are not 1287 applicable for this encoding scheme. 1289 Appendix B.2. Drawbacks of Using Out-Of-Band Channel 1291 The "IPFIX channel" encoding mode needs a separate signaling channel 1292 for the transport of the congestion and precongestion information 1293 from the PCN-interior-nodes towards the PCN-egress-node. The 1294 requirement of using an additional channel increases the complexity 1295 and influences negatively the performance of the PCN-interior-nodes 1296 since each PCN-interior-node needs to support in addition to the data 1297 path a separate channel. 1299 Appendix C. Current PCN Detection, Marking and Transport Mechanisms 1301 This appendix indicates the different available PCN based mechanisms 1302 that can be used for congestion and pre-congestion detection and 1303 marking used at interior nodes. The requirements and characteristics 1304 of such algorithms may influence the encoding and transport of the 1305 PCN encoding states. 1307 Appendix C.1. Detection, Marking and Transport Mechanisms in CL-PHB 1309 Please see draft-briscoe-tsvwg-cl-phb-03.txt 1310 [I-D.briscoe-tsvwg-cl-phb] for details on the Controlled-Load PHB 1311 Algorithm. 1313 Appendix C.2. Detection, Marking and Transport Mechanisms in Three 1314 State Marking 1316 Please see draft-babiarz-pcn-3sm-01.txt [I-D.babiarz-pcn-3sm] for 1317 details on the Three State Marking Algorithm. 1319 Appendix C.3. Detection, Marking and Transport Mechanisms in Single 1320 Marking 1322 Please see draft-charny-pcn-single-marking-03.txt 1323 [I-D.charny-pcn-single-marking] for details on the Single Marking 1324 Algorithm. 1326 Appendix C.4. Detection, Marking and Transport Mechanisms in Load 1327 Control Marking 1329 Please see draft-westberg-pcn-load-control-02.txt 1330 [I-D.westberg-pcn-load-control] for details on the Load Control 1331 Algorithm. 1333 8. Informative References 1335 [I-D.ietf-pcn-architecture] 1336 Eardley, P., "Pre-Congestion Notification (PCN) 1337 Architecture", draft-ietf-pcn-architecture-09 (work in 1338 progress), January 2009. 1340 [I-D.ietf-pcn-baseline-encoding] 1341 Moncaster, T., Briscoe, B., and M. Menth, "Baseline 1342 Encoding and Transport of Pre-Congestion Information", 1343 draft-ietf-pcn-baseline-encoding-02 (work in progress), 1344 February 2009. 1346 [I-D.ietf-tsvwg-ecn-tunnel] 1347 Briscoe, B., "Layered Encapsulation of Congestion 1348 Notification", draft-ietf-tsvwg-ecn-tunnel-01 (work in 1349 progress), October 2008. 1351 [I-D.babiarz-pcn-3sm] 1352 Babiarz, J., Liu, X., Chan, K., and M. Menth, "Three State 1353 PCN Marking", draft-babiarz-pcn-3sm-01 (work in progress), 1354 November 2007. 1356 [I-D.charny-pcn-single-marking] 1357 Charny, A., Zhang, X., Faucheur, F., and V. Liatsos, "Pre- 1358 Congestion Notification Using Single Marking for Admission 1359 and Termination", draft-charny-pcn-single-marking-03 1360 (work in progress), November 2007. 1362 [I-D.westberg-pcn-load-control] 1363 Westberg, L., Bhargava, A., Bader, A., Karagiannis, G., 1364 and H. Mekkes, "LC-PCN: The Load Control PCN Solution", 1365 draft-westberg-pcn-load-control-05 (work in progress), 1366 November 2008. 1368 [I-D.briscoe-tsvwg-cl-phb] 1369 Briscoe, B., "Pre-Congestion Notification marking", 1370 draft-briscoe-tsvwg-cl-phb-03 (work in progress), 1371 October 2006. 1373 [I-D.ietf-tsvwg-admitted-realtime-dscp] 1374 Baker, F., Polk, J., and M. Dolly, "DSCP for Capacity- 1375 Admitted Traffic", 1376 draft-ietf-tsvwg-admitted-realtime-dscp-05 (work in 1377 progress), November 2008. 1379 [I-D.ietf-tsvwg-mlef-concerns] 1380 Baker, F. and J. Polk, "MLEF Without Capacity Admission 1381 Does Not Satisfy MLPP Requirements", 1382 draft-ietf-tsvwg-mlef-concerns-00 (work in progress), 1383 February 2005. 1385 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 1386 Services in the Internet Architecture: an Overview", 1387 RFC 1633, June 1994. 1389 [RFC2211] Wroclawski, J., "Specification of the Controlled-Load 1390 Network Element Service", RFC 2211, September 1997. 1392 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 1393 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 1394 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 1395 S., Wroclawski, J., and L. Zhang, "Recommendations on 1396 Queue Management and Congestion Avoidance in the 1397 Internet", RFC 2309, April 1998. 1399 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1400 "Definition of the Differentiated Services Field (DS 1401 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1402 December 1998. 1404 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1405 and W. Weiss, "An Architecture for Differentiated 1406 Services", RFC 2475, December 1998. 1408 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 1409 "Assured Forwarding PHB Group", RFC 2597, June 1999. 1411 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 1412 McManus, "Requirements for Traffic Engineering Over MPLS", 1413 RFC 2702, September 1999. 1415 [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., 1416 Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. 1417 Felstaine, "A Framework for Integrated Services Operation 1418 over Diffserv Networks", RFC 2998, November 2000. 1420 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1421 of Explicit Congestion Notification (ECN) to IP", 1422 RFC 3168, September 2001. 1424 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 1425 J., Courtney, W., Davari, S., Firoiu, V., and D. 1426 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 1427 Behavior)", RFC 3246, March 2002. 1429 [RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., 1430 Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. 1431 Ramakrishnan, "Supplemental Information for the New 1432 Definition of the EF PHB (Expedited Forwarding Per-Hop 1433 Behavior)", RFC 3247, March 2002. 1435 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 1436 Congestion Notification (ECN) Signaling with Nonces", 1437 RFC 3540, June 2003. 1439 [RFC3955] Leinen, S., "Evaluation of Candidate Protocols for IP Flow 1440 Information Export (IPFIX)", RFC 3955, October 2004. 1442 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1443 Internet Protocol", RFC 4301, December 2005. 1445 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1446 Guidelines for DiffServ Service Classes", RFC 4594, 1447 August 2006. 1449 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 1450 Explicit Congestion Notification (ECN) Field", BCP 124, 1451 RFC 4774, November 2006. 1453 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 1454 Marking in MPLS", RFC 5129, January 2008. 1456 [DClark] "Supporting Real-Time Applications in an Integrated 1457 Services Packet Network: Architecture and Mechanisms", 1458 Proceedings of SIGCOMM '92 at Baltimore MD, August 1992. 1460 [ITU-MLPP] 1461 "Multilevel Precedence and Pre-emption Service (MLPP)", 1462 ITU-T Recommendation I.255.3, 1990. 1464 [Reid] "Economics and Scalability of QoS Solutions", BT 1465 Technology Journal Vol 23 No 2, April 2005. 1467 Authors' Addresses 1469 Kwok Ho Chan 1470 Huawei Technologies 1471 125 Nagog Park 1472 Acton, MA 01720 1473 USA 1475 Email: khchan@huawei.com 1477 Georgios Karagiannis 1478 University of Twente 1479 P.O. Box 217 1480 7500 AE Enschede, 1481 The Netherlands 1483 Email: g.karagiannis@ewi.utwente.nl 1485 Toby Moncaster 1486 BT Research 1487 B54/70, Sirius House Adastral Park Martlesham Heath 1488 Ipswich, Suffolk IP5 3RE 1489 United Kingdom 1491 Email: toby.moncaster@bt.com 1493 Michael Menth 1494 University of Wurzburg 1495 Institute of Computer Science 1496 Room B206 1497 Am Hubland, Wuerzburg D-97074 1498 Germany 1500 Email: menth@informatik.uni-wuerzburg.de 1501 Philip Eardley 1502 BT Research 1503 B54/77, Sirius House Adastral Park Martlesham Heath 1504 Ipswich, Suffolk IP5 3RE 1505 United Kingdom 1507 Email: philip.eardley@bt.com 1509 Bob Briscoe 1510 BT Research 1511 B54/77, Sirius House Adastral Park Martlesham Heath 1512 Ipswich, Suffolk IP5 3RE 1513 United Kingdom 1515 Email: bob.briscoe@bt.com