idnits 2.17.1 draft-ietf-pcn-architecture-10.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.i 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to 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 16, 2009) is 5518 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Congestion and Pre-Congestion Philip. Eardley (Editor) 3 Notification Working Group BT 4 Internet-Draft March 16, 2009 5 Intended status: Informational 6 Expires: September 17, 2009 8 Pre-Congestion Notification (PCN) Architecture 9 draft-ietf-pcn-architecture-10 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 6, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document describes a general architecture for flow admission and 58 termination based on pre-congestion information in order to protect 59 the quality of service of established inelastic flows within a single 60 DiffServ domain. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1.1. Applicability of PCN . . . . . . . . . . . . . . . . . . 5 66 1.2. Example use case for PCN . . . . . . . . . . . . . . . . 6 67 1.3. Documents about PCN . . . . . . . . . . . . . . . . . . . 9 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 3. High-level functional architecture . . . . . . . . . . . . . . 12 70 3.1. Flow admission . . . . . . . . . . . . . . . . . . . . . 14 71 3.2. Flow termination . . . . . . . . . . . . . . . . . . . . 15 72 3.3. Flow admission and/or flow termination when there are 73 only two PCN encoding states . . . . . . . . . . . . . . 16 74 3.4. Information transport . . . . . . . . . . . . . . . . . . 17 75 3.5. PCN-traffic . . . . . . . . . . . . . . . . . . . . . . . 17 76 3.6. Backwards compatibility . . . . . . . . . . . . . . . . . 18 77 4. Detailed Functional architecture . . . . . . . . . . . . . . . 18 78 4.1. PCN-interior-node functions . . . . . . . . . . . . . . . 19 79 4.2. PCN-ingress-node functions . . . . . . . . . . . . . . . 20 80 4.3. PCN-egress-node functions . . . . . . . . . . . . . . . . 20 81 4.4. Admission control functions . . . . . . . . . . . . . . . 21 82 4.5. Flow termination functions . . . . . . . . . . . . . . . 22 83 4.6. Addressing . . . . . . . . . . . . . . . . . . . . . . . 22 84 4.7. Tunnelling . . . . . . . . . . . . . . . . . . . . . . . 23 85 4.8. Fault handling . . . . . . . . . . . . . . . . . . . . . 25 86 5. Operations and Management . . . . . . . . . . . . . . . . . . 25 87 5.1. Configuration Operations and Management . . . . . . . . . 25 88 5.1.1. System options . . . . . . . . . . . . . . . . . . . . 26 89 5.1.2. Parameters . . . . . . . . . . . . . . . . . . . . . . 27 90 5.2. Performance & Provisioning Operations and Management . . 28 91 5.3. Accounting Operations and Management . . . . . . . . . . 30 92 5.4. Fault Operations and Management . . . . . . . . . . . . . 30 93 5.5. Security Operations and Management . . . . . . . . . . . 31 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 95 7. Security considerations . . . . . . . . . . . . . . . . . . . 32 96 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 33 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 98 10. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 33 99 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 100 11.1. Changes from -098 to -10 . . . . . . . . . . . . . . . . 34 101 11.2. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 34 102 11.3. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 34 103 11.4. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 35 104 11.5. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 35 105 11.6. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 36 106 11.7. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 37 107 11.8. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 37 108 11.9. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 38 109 11.10. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 39 111 12. Appendix A: Applicability of PCN . . . . . . . . . . . . . . . 41 112 12.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . . 41 113 12.2. Deployment scenarios . . . . . . . . . . . . . . . . . . 42 114 12.3. Assumptions and constraints on scope . . . . . . . . . . 44 115 12.3.1. Assumption 1: Trust and support of PCN - 116 controlled environment . . . . . . . . . . . . . . . . 45 117 12.3.2. Assumption 2: Real-time applications . . . . . . . . . 45 118 12.3.3. Assumption 3: Many flows and additional load . . . . . 46 119 12.3.4. Assumption 4: Emergency use out of scope . . . . . . . 46 120 12.4. Challenges . . . . . . . . . . . . . . . . . . . . . . . 46 121 13. Appendix B: Possible future work items . . . . . . . . . . . . 49 122 13.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . . 49 123 13.2. Probing . . . . . . . . . . . . . . . . . . . . . . . . . 52 124 13.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 52 125 13.2.2. Probing functions . . . . . . . . . . . . . . . . . . 53 126 13.2.3. Discussion of rationale for probing, its downsides 127 and open issues . . . . . . . . . . . . . . . . . . . 54 128 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 129 14.1. Normative References . . . . . . . . . . . . . . . . . . 56 130 14.2. Informative References . . . . . . . . . . . . . . . . . 56 131 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 61 133 1. Introduction 135 1.1. Applicability of PCN 137 The objective of the Pre-Congestion Notification (PCN) mechanisms is 138 to protect the quality of service (QoS) of flows within a DiffServ 139 domain [RFC2475], in a simple, scalable and robust fashion. Two 140 mechanisms are defined to protect the QoS of established inelastic 141 flows within a single DiffServ domain, where all boundary and 142 interior nodes are PCN-enabled and are trusted for correct PCN 143 operation. Flow admission control determines whether a new flow 144 should be admitted, in order to protect the QoS of existing PCN-flows 145 in normal circumstances. However, in abnormal circumstances, for 146 instance a disaster affecting multiple nodes and causing traffic re- 147 routes, then the QoS on existing PCN-flows may degrade even though 148 care was exercised when admitting those flows. The flow termination 149 mechanism removes enough traffic in order to protect the QoS of the 150 remaining PCN-flows. 152 Compared with alternative QoS mechanisms, PCN has certain advantages 153 and disadvantages that will make it appropriate in particular 154 scenarios. For example, compared with hop-by-hop IntServ [RFC1633], 155 PCN only requires per flow state at the PCN-ingress-nodes. Compared 156 with the DiffServ architecture [RFC2475], an operator needs to be 157 less accurate and/or conservative in its prediction of the traffic 158 matrix. The DiffServ architecture's traffic conditioning agreements 159 are static and coarse; they are defined at subscription time, and 160 they are used to limit the total traffic at each ingress of the 161 domain regardless of the egress for the traffic. On the other hand, 162 PCN firstly uses admission control based on measurements of the 163 current conditions between the specific pair of PCN-boundary-nodes, 164 and secondly, in case of a disaster, PCN protects the QoS of most 165 flows by terminating a few selected ones. 167 PCN's admission control is a measurement-based mechanism. Hence it 168 assumes that the present is a reasonable prediction of the future: 169 the network conditions are measured at the time of a new flow 170 request, but the actual network performance must be acceptable during 171 the call some time later. Hence PCN is unsuitable in several 172 circumstances: 174 o If the source adapts its bit rate dependent on the level of pre- 175 congestion, because then the aggregate traffic might become 176 unstable. The assumption in this document is that PCN-packets 177 come from real time applications generating inelastic traffic, 178 such as the Controlled Load Service, [RFC2211]. 180 o If a potential bottleneck link has capacity for only a few flows, 181 because then a new flow can move a link directly from no pre- 182 congestion to being so overloaded that it has to drop packets. 183 The assumption in this document is that this isn't a problem. 185 o If there is the danger of a "flash crowd" in which many admission 186 requests arrive within the reaction time of PCN's admission 187 mechanism, because then they all might get admitted and so 188 overload the network. The assumption in this document is that, if 189 it is necessary, then flash crowds are limited in some fashion 190 beyond the scope of this document, for instance by rate limiting 191 QoS requests. 193 The applicability of PCN is discussed further in Appendix A. 195 1.2. Example use case for PCN 197 This section outlines an end-to-end QoS scenario that uses the PCN 198 mechanisms within one domain. The parts outside the PCN-domain are 199 out of scope for PCN, but are included to help clarify how PCN could 200 be used. Note that the section is only an example - in particular 201 there are other possibilities (see later) for how the PCN-boundary- 202 nodes perform admission control and flow termination. 204 As a fundamental building block, each link of the PCN-domain operates 205 two PCN-marking behaviours [PCN08-2] (Figure 1): 207 o Threshold marking, which marks all PCN-packets if the PCN traffic 208 rate is greater than a first configured rate, the PCN-threshold- 209 rate. The admission control mechanism limits the PCN-traffic on 210 each link to *roughly* its PCN-threshold-rate. 212 o Excess traffic marking, which marks a proportion of PCN-packets, 213 such that the amount marked equals the traffic rate in excess of a 214 second configured rate, the PCN-excess-rate. The flow termination 215 mechanism limits the PCN-traffic on each link to *roughly* its 216 PCN-excess-rate. 218 Overall the aim is to give an "early warning" of potential congestion 219 before there is any significant build-up of PCN-packets in the queue 220 on the link; we term this "pre-congestion notification" by analogy 221 with ECN (Explicit Congestion Notification, [RFC3168]). Note that 222 the link only meters the bulk PCN-traffic (and not per flow). 224 ==Marking behaviour== ==PCN mechanisms== 225 ^ 226 Rate of ^ 227 PCN-traffic on | 228 bottleneck link | (as below and also) 229 | (as below) Drop some PCN-pkts 230 | 231 scheduler rate -|------------------------------------------------ 232 (for PCN-traffic) | 233 | Some pkts Terminate some 234 | excess-traffic-marked admitted flows 235 | & & 236 | Rest of pkts Block new flows 237 | threshold-marked 238 | 239 PCN-excess-rate -|------------------------------------------------ 240 (=PCN-supportable-rate)| 241 | All pkts Block new flows 242 | threshold-marked 243 | 244 PCN-threshold-rate -|------------------------------------------------ 245 (=PCN-admissible-rate)| 246 | No pkts Admit new flows 247 | PCN-marked 248 | 250 Figure 1: Example of how the PCN admission control and flow 251 termination mechanisms operate as the rate of PCN-traffic increases. 253 The two forms of PCN-marking are indicated by setting of the ECN and 254 DSCP (Differentiated Services Codepoint [RFC2474]) fields to known 255 values, which are configured for the domain. Thus the PCN-egress- 256 nodes can monitor the PCN-markings in order to measure the severity 257 of pre-congestion. In addition, the PCN-ingress-nodes need to set 258 the ECN and DSCP fields to that configured for an unmarked PCN- 259 packet, and the PCN-egress-nodes need to revert to values appropriate 260 outside the PCN-domain. 262 For admission control, we assume end-to-end RSVP signalling (Resource 263 Reservation Protocol) [RFC2205]) in this example. The PCN-domain is 264 a single RSVP hop. The PCN-domain operates DiffServ, and we assume 265 that PCN-traffic is scheduled with the expedited forwarding (EF) per- 266 hop behaviour, [RFC3246]. Hence the overall solution is in line with 267 the "IntServ over DiffServ" framework defined in [RFC2998], as shown 268 in Figure 2. 270 ___ ___ _______________________________________ ____ ___ 271 | | | | | PCN- PCN- PCN- | | | | | 272 | | | | |ingress interior egress| | | | | 273 | | | | | -node -nodes -node | | | | | 274 | | | | |-------+ +-------+ +-------+ +------| | | | | 275 | | | | | PCN- | | PCN- | | PCN- | | | | | | | 276 | |..| |..|marking|..|marking|..|marking|..| Meter|..| |..| | 277 | | | | |-------+ +-------+ +-------+ +------| | | | | 278 | | | | | \ / | | | | | 279 | | | | | \ / | | | | | 280 | | | | | \ PCN-feedback-information / | | | | | 281 | | | | | \ (for admission control) / | | | | | 282 | | | | | --<-----<----<----<-----<-- | | | | | 283 | | | | | PCN-feedback-information | | | | | 284 | | | | | (for flow termination) | | | | | 285 |___| |___| |_______________________________________| |____| |___| 287 Sx Access PCN-domain Access Rx 288 End Network Network End 289 Host Host 290 <---- signalling across PCN-domain---> 291 (for admission control & flow termination) 293 <-------------------end-to-end QoS signalling protocol---------------> 295 Figure 2: Example of possible overall QoS architecture 297 A source wanting to start a new QoS flow sends an RSVP PATH message. 298 Normal hop-by-hop IntServ [RFC1633] is used outside the PCN-domain 299 (we assume successfully). The PATH message travels across the PCN- 300 domain; the PCN-egress-node reads the PHOP object to discover the 301 specific PCN-ingress-node for this flow. The RESV message travels 302 back from the receiver, and triggers the PCN-egress-node to check 303 what fraction of the PCN-traffic, from the relevant PCN-ingress-node, 304 is currently being threshold-marked. It adds an object with this 305 information onto the RESV message, and hence the PCN-ingress-node 306 learns about the level of pre-congestion on the path. If this level 307 is below some threshold, then the PCN-ingress-node admits the new 308 flow into the PCN-domain. The RSVP message triggers the PCN-ingress- 309 node to install two normal IntServ items: five-tuple information, so 310 that it can subsequently identify data packets that are part of a 311 previously admitted PCN-flow; and a traffic profile, so that it can 312 police the flow to within its contract. Similarly, the RSVP message 313 triggers the PCN-egress-node to install five-tuple and PHOP 314 information, so that it can identify packets as part of a flow from a 315 specific PCN-ingress-node. 317 The flow termination mechanism may happen when some abnormal 318 circumstances causes a link to become so pre-congested that it 319 excess-traffic-marks (and perhaps also drops) PCN-packets. In this 320 example, when a PCN-egress-node observes such a packet it then, with 321 some probability, terminates this PCN-flow; the probability is 322 configured low enough to avoid over-termination and high enough to 323 ensure rapid termination of enough flows. It also informs the 324 relevant PCN-ingress-node, so it can block any further traffic on the 325 terminated flow. 327 1.3. Documents about PCN 329 The purpose of this document is to describe a general architecture 330 for flow admission and termination based on (pre-) congestion 331 information in order to protect the quality of service of flows 332 within a DiffServ domain. This document describes the PCN 333 architecture at a high level (Section 3) and in more detail (Section 334 4). It also defines some terminology, and considerations about 335 operations and management, and security. Appendix A considers the 336 applicability of PCN in more detail, covering its benefits, 337 deployment scenarios, assumptions and potential challenges. Appendix 338 B covers some potential future work items. 340 Aspects of PCN are also documented elsewhere: 342 o Marking behaviour: threshold marking and excess traffic marking 343 are standardised in [PCN08-2]. 345 o Encoding: the "baseline" encoding is described in [PCN08-1], which 346 standardises two PCN encoding states (PCN-marked and not PCN- 347 marked), whilst (experimental) extensions to the baseline encoding 348 can provide three encoding states (threshold-marked, excess- 349 traffic-marked, not PCN-marked, or perhaps further encoding states 350 as suggested in [Westberg08]). Section 3.6 considers backwards 351 compatability of PCN encoding with ECN. 353 o PCN-boundary-node behaviour: how the PCN-boundary-nodes convert 354 the PCN-markings into decisions about flow admission and flow 355 termination. The concept is that the standardised marking 356 behaviours allow several possible PCN-boundary-node behaviours, 357 which are described in Informational documents. A number of 358 possibilities are outlined in this document; detailed descriptions 359 and comparisons are in [Charny07-1] and [Menth08-3]. 361 o Signalling between PCN-boundary-nodes: Signalling is needed to 362 transport PCN-feedback-information between the PCN-boundary-nodes 363 (in the example above, this is the fraction of traffic, between 364 the pair of PCN-boundary-nodes, that is PCN-marked). The exact 365 details vary for different PCN-boundary-node behaviours, and so 366 should be described in those documents. It may require an 367 extension to the signalling protocol - standardisation is out of 368 scope of the PCN WG. 370 o The interface by which the PCN-boundary-nodes learn identification 371 information about the admitted flows: the exact requirements vary 372 for different PCN-boundary-node behaviours and for different 373 signalling protocols, and so should be described in those 374 documents. They will be similar to those described in the example 375 above - a PCN-ingress-node needs to be able to identify that a 376 packet is part of a previously admitted flow (typically from its 377 five-tuple) and each PCN-boundary-node needs to be able to 378 identify the other PCN-boundary-node for the flow. 380 2. Terminology 382 o PCN-domain: a PCN-capable domain; a contiguous set of PCN-enabled 383 nodes that perform DiffServ scheduling [RFC2474]; the complete set 384 of PCN-nodes whose PCN-marking can in principle influence 385 decisions about flow admission and termination for the PCN-domain, 386 including the PCN-egress-nodes, which measure these PCN-marks. 388 o PCN-boundary-node: a PCN-node that connects one PCN-domain to a 389 node either in another PCN-domain or in a non PCN-domain. 391 o PCN-interior-node: a node in a PCN-domain that is not a PCN- 392 boundary-node. 394 o PCN-node: a PCN-boundary-node or a PCN-interior-node 396 o PCN-egress-node: a PCN-boundary-node in its role in handling 397 traffic as it leaves a PCN-domain. 399 o PCN-ingress-node: a PCN-boundary-node in its role in handling 400 traffic as it enters a PCN-domain. 402 o PCN-traffic, PCN-packets, PCN-BA: a PCN-domain carries traffic of 403 different DiffServ behaviour aggregates (BAs) [RFC2474]. The 404 PCN-BA uses the PCN mechanisms to carry PCN-traffic and the 405 corresponding packets are PCN-packets. The same network will 406 carry traffic of other DiffServ BAs. The PCN-BA is distinguished 407 by a combination of the DiffServ codepoint (DSCP) and ECN fields. 409 o PCN-flow: the unit of PCN-traffic that the PCN-boundary-node 410 admits (or terminates); the unit could be a single microflow (as 411 defined in [RFC2474]) or some identifiable collection of 412 microflows. 414 o Ingress-egress-aggregate: The collection of PCN-packets from all 415 PCN-flows that travel in one direction between a specific pair of 416 PCN-boundary-nodes. 418 o PCN-threshold-rate: a reference rate configured for each link in 419 the PCN-domain, which is lower than the PCN-excess-rate. It is 420 used by a marking behaviour that determines whether a packet 421 should be PCN-marked with a first encoding, "threshold-marked". 423 o PCN-excess-rate: a reference rate configured for each link in the 424 PCN-domain, which is higher than the PCN-threshold-rate. It is 425 used by a marking behaviour that determines whether a packet 426 should be PCN-marked with a second encoding, "excess-traffic- 427 marked". 429 o Threshold-marking: a PCN-marking behaviour with the objective that 430 all PCN-traffic is marked if the PCN-traffic exceeds the PCN- 431 threshold-rate. 433 o Excess-traffic-marking: a PCN-marking behaviour with the objective 434 that the amount of PCN-traffic that is PCN-marked is equal to the 435 amount that exceeds the PCN-excess-rate. 437 o Pre-congestion: a condition of a link within a PCN-domain such 438 that the PCN-node performs PCN-marking, in order to provide an 439 "early warning" of potential congestion before there is any 440 significant build-up of PCN-packets in the real queue. (Hence, by 441 analogy with ECN we call our mechanism Pre-Congestion 442 Notification.) 444 o PCN-marking: the process of setting the header in a PCN-packet 445 based on defined rules, in reaction to pre-congestion; either 446 threshold-marking or excess-traffic-marking. 448 o PCN-colouring: the process of setting the header in a PCN-packet 449 by a PCN-boundary-node; performed by a PCN-ingress-node so that 450 PCN-nodes can easily identify PCN-packets; performed by a PCN- 451 egress-node so that the header is appropriate for nodes beyond the 452 PCN-domain. 454 o PCN-feedback-information: information signalled by a PCN-egress- 455 node to a PCN-ingress-node (or a central control node), which is 456 needed for the flow admission and flow termination mechanisms. 458 o PCN-admissible-rate: the rate of PCN-traffic on a link up to which 459 PCN admission control should accept new PCN-flows. 461 o PCN-supportable-rate: the rate of PCN-traffic on a link down to 462 which PCN flow termination should, if necessary, terminate already 463 admitted PCN-flows. 465 3. High-level functional architecture 467 The high-level approach is to split functionality between: 469 o PCN-interior-nodes 'inside' the PCN-domain, which monitor their 470 own state of pre-congestion and mark PCN-packets as appropriate. 471 They are not flow-aware, nor aware of ingress-egress-aggregates. 472 The functionality is also done by PCN-ingress-nodes for their 473 outgoing interfaces (ie those 'inside' the PCN-domain). 475 o PCN-boundary-nodes at the edge of the PCN-domain, which control 476 admission of new PCN-flows and termination of existing PCN-flows, 477 based on information from PCN-interior-nodes. This information is 478 in the form of the PCN-marked data packets (which are intercepted 479 by the PCN-egress-nodes) and not signalling messages. Generally 480 PCN-ingress-nodes are flow-aware. 482 The aim of this split is to keep the bulk of the network simple, 483 scalable and robust, whilst confining policy, application-level and 484 security interactions to the edge of the PCN-domain. For example the 485 lack of flow awareness means that the PCN-interior-nodes don't care 486 about the flow information associated with PCN-packets, nor do the 487 PCN-boundary-nodes care about which PCN-interior-nodes its ingress- 488 egress-aggregates traverse. 490 In order to generate information about the current state of the PCN- 491 domain, each PCN-node PCN-marks packets if it is "pre-congested". 492 Exactly when a PCN-node decides if it is "pre-congested" (the 493 algorithm) and exactly how packets are "PCN-marked" (the encoding) 494 will be defined in separate standards-track documents, but at a high 495 level it is as follows: 497 o the algorithms: a PCN-node meters the amount of PCN-traffic on 498 each one of its outgoing (or incoming) links. The measurement is 499 made as an aggregate of all PCN-packets, and not per flow. There 500 are two algorithms, one for threshold-marking and one for excess- 501 traffic-marking. 503 o the encoding(s): a PCN-node PCN-marks a PCN-packet by modifying a 504 combination of the DSCP and ECN fields. In the "baseline" 505 encoding [PCN08-1], the ECN field is set to 11 and the DSCP is not 506 altered. Extension encodings may be defined that, at most, use a 507 second DSCP (eg as in [Moncaster08]) and/or set the ECN field to 508 values other than 11 (eg as in [Menth08-2]). 510 In a PCN-domain the operator may have two or three encoding states 511 available. The baseline encoding provides two encoding states (not 512 PCN-marked, PCN-marked), whilst extended encodings can provide three 513 encoding states (not PCN-marked, threshold-marked, excess-traffic- 514 marked). 516 An operator may choose to deploy either admission control or flow 517 termination or both. Although designed to work together, they are 518 independent mechanisms, and the use of one does not require or 519 prevent the use of the other. Three encoding states naturally allows 520 both flow admission and flow termination. If there are only two 521 encoding states, then there are several options - see Section 3.3. 523 The PCN-boundary-nodes monitor the PCN-marked packets in order to 524 extract information about the current state of the PCN-domain. Based 525 on this monitoring, a distributed decision is made about whether to 526 admit a prospective new flow or whether to terminate existing 527 flow(s). Sections 4.4 and 4.5 mention various possibilities for how 528 the functionality could be distributed. 530 PCN-marking needs to be configured on all (potentially pre-congested) 531 links in the PCN-domain to ensure that the PCN mechanisms protect all 532 links. The actual functionality can be configured on the outgoing or 533 incoming interfaces of PCN-nodes - or one algorithm could be 534 configured on the outgoing interface and the other on the incoming 535 interface. The important point is that a consistent choice is made 536 across the PCN-domain to ensure that the PCN mechanisms protect all 537 links. See [PCN08-2] for further discussion. 539 The objective of the threshold-marking algorithm is to threshold-mark 540 all PCN-packets whenever the rate of PCN-packets is greater than some 541 configured rate, the PCN-threshold-rate. The objective of the 542 excess-traffic-marking algorithm is to excess-traffic-mark PCN- 543 packets at a rate equal to the difference between the bit rate of 544 PCN-packets and some configured rate, the PCN-excess-rate. Note that 545 this description reflects the overall intent of the algorithm rather 546 than its instantaneous behaviour, since the rate measured at a 547 particular moment depends on the detailed algorithm, its 548 implementation, and the traffic's variance as well as its rate (eg 549 marking may well continue after a recent overload even after the 550 instantaneous rate has dropped). The algorithms are specified in 551 [PCN08-2]. 553 Admission and termination approaches are detailed and compared in 554 [Charny07-1] and [Menth08-3]. The discussion below is just a brief 555 summary. Sections 3.1 and 3.2 assume there are three encoding states 556 available, whilst Section 3.3 assumes there are two encoding states 557 available. 559 From the perspective of the outside world, a PCN-domain essentially 560 looks like a DiffServ domain. PCN-traffic is either transported 561 across it transparently or policed at the PCN-ingress-node (ie 562 dropped or carried at a lower QoS). One difference is that PCN- 563 traffic has better QoS guarantees than normal DiffServ traffic, 564 because the PCN mechanisms better protect the QoS of admitted flows. 565 Another difference may occur in the rare circumstance when there is a 566 failure: on the one hand some PCN-flows may get terminated, but on 567 the other hand other flows will get their QoS restored. Non PCN- 568 traffic is treated transparently, ie the PCN-domain is a normal 569 DiffServ domain. 571 3.1. Flow admission 573 The objective of PCN's flow admission control mechanism is to limit 574 the PCN-traffic on each link in the PCN-domain to *roughly* its PCN- 575 admissible-rate, by admitting or blocking prospective new flows, in 576 order to protect the QoS of existing PCN-flows. With three encoding 577 states available, the PCN-threshold-rate is configured by the 578 operator as equal to the PCN-admissible-rate on each link. It is set 579 lower than the traffic rate at which the link becomes congested and 580 the node drops packets. 582 Exactly how the admission control decision is made will be defined 583 separately in informational documents. This document describes two 584 approaches (others might be possible): 586 o the PCN-egress-node measures (possibly as a moving average) the 587 fraction of the PCN-traffic that is threshold-marked. The 588 fraction is measured for a specific ingress-egress-aggregate. If 589 the fraction is below a threshold value then the new flow is 590 admitted, and if the fraction is above the threshold value then it 591 is blocked. The fraction could be measured as an EWMA 592 (exponentially weighted moving average), which has sometimes been 593 called the "congestion level estimate". 595 o the PCN-egress-node monitors PCN-traffic and if it receives one 596 (or several) threshold-marked packets, then the new flow is 597 blocked, otherwise it is admitted. One possibility may be to 598 react to the marking state of an initial flow set-up packet (eg 599 RSVP PATH). Another is that after one (or several) threshold- 600 marks then all flows are blocked until after a specific period of 601 no congestion. 603 Note that the admission control decision is made for a particular 604 pair of PCN-boundary-nodes. So it is quite possible for a new flow 605 to be admitted between one pair of PCN-boundary-nodes, whilst at the 606 same time another admission request is blocked between a different 607 pair of PCN-boundary-nodes. 609 3.2. Flow termination 611 The objective of PCN's flow termination mechanism is to limit the 612 PCN-traffic on each link to *roughly* its PCN-supportable-rate, by 613 terminating some existing PCN-flows, in order to protect the QoS of 614 the remaining PCN-flows. With three encoding states available, the 615 PCN-excess-rate is configured by the operator as equal to the PCN- 616 supportable-rate on each link. It may be set lower than the traffic 617 rate at which the link becomes congested and the node drops packets. 619 Exactly how the flow termination decision is made will be defined 620 separately in informational documents. This document describes 621 several approaches (others might be possible): 623 o In one approach the PCN-egress-node measures the rate of PCN- 624 traffic that is not excess-traffic-marked, which is the amount of 625 PCN-traffic that can actually be supported, and communicates this 626 to the PCN-ingress-node. Also the PCN-ingress-node measures the 627 rate of PCN-traffic that is destined for this specific PCN-egress- 628 node. The difference represents the excess amount that should be 629 terminated. 631 o Another approach instead measures the rate of excess-traffic- 632 marked traffic and terminates this amount of traffic. This 633 terminates less traffic than the previous bullet if some nodes are 634 dropping PCN-traffic. 636 o Another approach monitors PCN-packets and terminates some of the 637 PCN-flows that have an excess-traffic-marked packet. (If all such 638 flows were terminated, far too much traffic would be terminated, 639 so a random selection needs to be made from those with an excess- 640 traffic-marked packet, [Menth08-1].) 642 Since flow termination is designed for "abnormal" circumstances, it 643 is quite likely that some PCN-nodes are congested and hence packets 644 are being dropped and/or significantly queued. The flow termination 645 mechanism must accommodate this. 647 Note also that the termination control decision is made for a 648 particular pair of PCN-boundary-nodes. So it is quite possible for 649 PCN-flows to be terminated between one pair of PCN-boundary-nodes, 650 whilst at the same time none are terminated between a different pair 651 of PCN-boundary-nodes. 653 3.3. Flow admission and/or flow termination when there are only two PCN 654 encoding states 656 If a PCN-domain has only two encoding states available (PCN-marked 657 and not PCN-marked), ie it is using the baseline encoding [PCN08-1], 658 then an operator has three options (others might be possible): 660 o admission control only: PCN-marking means threshold-marking, ie 661 only the threshold-marking algorithm writes PCN-marks. Only PCN 662 admission control is available. 664 o flow termination only: PCN-marking means excess-traffic-marking, 665 ie only the excess-traffic-marking algorithm writes PCN-marks. 666 Only PCN termination control is available. 668 o both admission control and flow termination: only the excess- 669 traffic-marking algorithm writes PCN-marks, however the configured 670 rate (PCN-excess-rate) is set equal to the PCN-admissible-rate, as 671 shown in Figure 3. [Charny07-2] describes how both admission 672 control and flow termination can be triggered in this case and 673 also gives some of the pros and cons of this approach. The main 674 downside is that admission control is less accurate. 676 ==Marking behaviour== ==PCN mechanisms== 677 ^ 678 Rate of ^ 679 PCN-traffic on | 680 bottleneck link | Terminate some 681 | admitted flows 682 | & 683 | Block new flows 684 | 685 | Some pkts 686 U*PCN-excess-rate -| excess-traffic-marked ----------------- 687 (=PCN-supportable-rate)| 688 | Block new flows 689 | 690 | 691 PCN-excess-rate -|------------------------------------------------ 692 (=PCN-admissible-rate)| 693 | No pkts Admit new flows 694 | PCN-marked 695 | 697 Figure 3: Schematic of how the PCN admission control and flow 698 termination mechanisms operate as the rate of PCN-traffic increases, 699 for a PCN-domain with two encoding states and using the approach of 700 [Charny07-2]. Note: U is a global parameter for all links in the 701 PCN-domain. 703 3.4. Information transport 705 The transport of pre-congestion information from a PCN-node to a PCN- 706 egress-node is through PCN-markings in data packet headers, ie "in- 707 band": no signalling protocol messaging is needed. Signalling is 708 needed to transport PCN-feedback-information, for example to convey 709 the fraction of PCN-marked traffic from a PCN-egress-node to the 710 relevant PCN-ingress-node. Exactly what information needs to be 711 transported will be described in future documents about possible 712 boundary mechanisms. The signalling could be done by an extension of 713 RSVP or NSIS, for instance; [Lefaucheur06] describes the extensions 714 needed for RSVP. 716 3.5. PCN-traffic 718 The following are some high-level points about how PCN works: 720 o There needs to be a way for a PCN-node to distinguish PCN-traffic 721 from other traffic. This is through a combination of the DSCP 722 field and/or ECN field. 724 o It is not advised to have non PCN-traffic that competes for the 725 same capacity as PCN-traffic but, if there is such traffic, there 726 needs to be a mechanism to limit it. "Capacity" means the 727 forwarding bandwidth on a link; "competes" means that non PCN- 728 packets will delay PCN-packets in the queue for the link. Hence 729 more non PCN-traffic results in poorer QoS for PCN. Further, the 730 unpredictable amount of non PCN-traffic makes the PCN mechanisms 731 less accurate and so reduces PCN's ability to protect the QoS of 732 admitted PCN-flows 734 o Two examples of such non PCN-traffic (ie that competes for the 735 same capacity as PCN-traffic) are: 737 1. traffic that is priority scheduled over PCN (perhaps a particular 738 application or an operator's control messages). 740 2. traffic that is scheduled at the same priority as PCN (for 741 example if the Voice-Admit codepoint is used for PCN-traffic 742 [PCN08-1] and there is non-PCN voice-admit traffic in the PCN- 743 domain). 745 o If there is such non PCN-traffic (ie that competes for the same 746 capacity as PCN-traffic), then PCN's mechanisms should take 747 account of it, in order to improve the accuracy of the decision 748 about whether to admit (or terminate) a PCN-flow. For example, 749 one mechanism is that such non PCN-traffic contributes to the PCN 750 meters (ie is metered by the threshold-marking and excess-traffic- 751 marking algorithms). 753 o There will be non PCN-traffic that doesn't compete for the same 754 capacity as PCN-traffic, because it is forwarded at lower 755 priority. Hence it shouldn't contribute to the PCN meters. 756 Examples are best effort and assured forwarding traffic. However, 757 a PCN-node should dedicate some capacity to lower priority traffic 758 so that it isn't starved. 760 o The document assumes that the PCN mechanisms are applied to a 761 single behaviour aggregate in the PCN-domain. However, it would 762 also be possible to apply them independently to more than one 763 behaviour aggregate, which are distinguished by DSCP. 765 3.6. Backwards compatibility 767 PCN specifies semantics for the ECN field that differ from the 768 default semantics of [RFC3168]. A particular PCN encoding scheme 769 needs to describe how it meets the guidelines of BCP 124 [RFC4774] 770 for specifying alternative semantics for the ECN field. In summary 771 the approach is to: 773 o use a DSCP to allow PCN-nodes to distinguish PCN-traffic that uses 774 the alternative ECN semantics; 776 o define these semantics for use within a controlled region, the 777 PCN-domain; 779 o take appropriate action if ECN capable, non-PCN traffic arrives at 780 a PCN-ingress-node with the DSCP used by PCN. 782 For the baseline encoding [PCN08-1], the 'appropriate action' is to 783 block ECN-capable traffic that uses the same DSCP as PCN from 784 entering the PCN-domain directly. Blocking means it is dropped or 785 downgraded to a lower priority behaviour aggregate, or alternatively 786 such traffic may be tunnelled through the PCN-domain. The reason 787 that 'appropriate action' is needed is that the PCN-egress-node 788 clears the ECN field to 00. 790 Extended encoding schemes may take different 'appropriate action'. 792 4. Detailed Functional architecture 794 This section is intended to provide a systematic summary of the new 795 functional architecture in the PCN-domain. First it describes 796 functions needed at the three specific types of PCN-node; these are 797 data plane functions and are in addition to their normal router 798 functions. Then it describes further functionality needed for both 799 flow admission control and flow termination; these are signalling and 800 decision-making functions, and there are various possibilities for 801 where the functions are physically located. The section is split 802 into: 804 1. functions needed at PCN-interior-nodes 806 2. functions needed at PCN-ingress-nodes 808 3. functions needed at PCN-egress-nodes 810 4. other functions needed for flow admission control 812 5. other functions needed for flow termination control 814 Note: Probing is covered in the Appendix. 816 The section then discusses some other detailed topics: 818 1. addressing 820 2. tunnelling 822 3. fault handling 824 4.1. PCN-interior-node functions 826 Each link of the PCN-domain is configured with the following 827 functionality: 829 o Behaviour aggregate classification - determine whether an incoming 830 packet is a PCN-packet or not. 832 o Meter - measure the 'amount of PCN-traffic'. The measurement is 833 made as an aggregate of all PCN-packets, and not per flow. 835 o PCN-mark - algorithms determine whether to PCN-mark PCN-packets 836 and what packet encoding is used. 838 The functions are defined in [PCN08-2] and the baseline encoding in 839 [PCN08-1] (extended encodings are to be defined in other documents). 841 4.2. PCN-ingress-node functions 843 Each ingress link of the PCN-domain is configured with the following 844 functionality: 846 o Packet classification - determine whether an incoming packet is 847 part of a previously admitted flow, by using a filter spec (eg 848 DSCP, source and destination addresses, port numbers, and 849 protocol). 851 o Traffic conditioning - police, by dropping, any packets received 852 with a DSCP indicating PCN transport that do not belong to an 853 admitted flow. (A prospective PCN-flow that is rejected could be 854 blocked or admitted into a lower priority behaviour aggregate.) 855 Similarly, police packets that are part of a previously admitted 856 flow, to check that the flow keeps to the agreed rate or flowspec 857 (eg [RFC1633] for a microflow and its NSIS equivalent). 859 o PCN-colour - set the DSCP and ECN fields appropriately for the 860 PCN-domain, for example as in [PCN08-1]. 862 o Meter - some approaches to flow termination require the PCN- 863 ingress-node to measure the (aggregate) rate of PCN-traffic 864 towards a particular PCN-egress-node. 866 The first two are policing functions, needed to make sure that PCN- 867 packets admitted into the PCN-domain belong to a flow that has been 868 admitted and to ensure that the flow keeps to the flowspec agreed (eg 869 doesn't exceed an agreed maximum rate and is inelastic traffic). 870 Installing the filter spec will typically be done by the signalling 871 protocol, as will re-installing the filter, for example after a re- 872 route that changes the PCN-ingress-node (see [Briscoe06] for an 873 example using RSVP). PCN-colouring allows the rest of the PCN-domain 874 to recognise PCN-packets. 876 4.3. PCN-egress-node functions 878 Each egress link of the PCN-domain is configured with the following 879 functionality: 881 o Packet classify - determine which PCN-ingress-node a PCN-packet 882 has come from. 884 o Meter - "measure PCN-traffic" or "monitor PCN-marks". 886 o PCN-colour - for PCN-packets, set the DSCP and ECN fields to the 887 appropriate values for use outside the PCN-domain. 889 The metering functionality of course depends on whether it is 890 targeted at admission control or flow termination. Alternatives 891 involve the PCN-egress-node "measuring" as an aggregate (ie not per 892 flow) all PCN-packets from a particular PCN-ingress-node, or 893 "monitoring" the PCN-traffic and reacting to one (or several) PCN- 894 marked packets. For PCN-colouring, [PCN08-1] specifies that the PCN- 895 egress-node re-sets the ECN field to 00; other encodings may define 896 different behaviour. 898 4.4. Admission control functions 900 As well as the functions covered above, other specific admission 901 control functions need to be performed (others might be possible): 903 o Make decision about admission - based on the output of the PCN- 904 egress-node's PCN meter function. In the case where it "measures 905 PCN-traffic", the measured traffic on the ingress-egress-aggregate 906 is compared with some reference level. In the case where it 907 "monitors PCN-marks", then the decision is based on whether one 908 (or several) packets is (are) PCN-marked or not (eg the RSVP PATH 909 message). In either case, the admission decision also takes 910 account of policy and application layer requirements [RFC2753]. 912 o Communicate decision about admission - signal the decision to the 913 node making the admission control request (which may be outside 914 the PCN-domain), and to the policer (PCN-ingress-node function) 915 for enforcement of the decision. 917 There are various possibilities for how the functionality could be 918 distributed (we assume the operator would configure which is used): 920 o The decision is made at the PCN-egress-node and the decision 921 (admit or block) is signalled to the PCN-ingress-node. 923 o The decision is recommended by the PCN-egress-node (admit or 924 block) but the decision is definitively made by the PCN-ingress- 925 node. The rationale is that the PCN-egress-node naturally has the 926 necessary information about PCN-marking on the ingress-egress- 927 aggregate, but the PCN-ingress-node is the policy enforcement 928 point [RFC2753], which polices incoming traffic to ensure it is 929 part of an admitted PCN-flow. 931 o The decision is made at the PCN-ingress-node, which requires that 932 the PCN-egress-node signals PCN-feedback-information to the PCN- 933 ingress-node. For example, it could signal the current fraction 934 of PCN-traffic that is PCN-marked. 936 o The decision is made at a centralised node (see Appendix B). 938 Note: Admission control functionality is not performed by normal PCN- 939 interior-nodes. 941 4.5. Flow termination functions 943 As well as the functions covered above, other specific termination 944 control functions need to be performed (others might be possible): 946 o PCN-meter at PCN-egress-node - similarly to flow admission, there 947 are two types of possibilities: to "measure PCN-traffic" on the 948 ingress-egress-aggregate, and to "monitor PCN-marks" and react to 949 one (or several) PCN-marks. 951 o (if required) PCN-meter at PCN-ingress-node - make "measurements 952 of PCN-traffic" being sent towards a particular PCN-egress-node; 953 again, this is done for the ingress-egress-aggregate and not per 954 flow. 956 o (if required) Communicate PCN-feedback-information to the node 957 that makes the flow termination decision. For example, as in 958 [Briscoe06], communicate the PCN-egress-node's measurements to the 959 PCN-ingress-node. 961 o Make decision about flow termination - use the information from 962 the PCN-meter(s) to decide which PCN-flow or PCN-flows to 963 terminate. The decision takes account of policy and application 964 layer requirements [RFC2753]. 966 o Communicate decision about flow termination - signal the decision 967 to the node that is able to terminate the flow (which may be 968 outside the PCN-domain), and to the policer (PCN-ingress-node 969 function) for enforcement of the decision. 971 There are various possibilities for how the functionality could be 972 distributed, similar to those discussed above in the Admission 973 control section. 975 4.6. Addressing 977 PCN-nodes may need to know the address of other PCN-nodes. Note: in 978 all cases PCN-interior-nodes don't need to know the address of any 979 other PCN-nodes (except as normal their next hop neighbours, for 980 routing purposes). 982 The PCN-egress-node needs to know the address of the PCN-ingress-node 983 associated with a flow, at a minimum so that the PCN-ingress-node can 984 be informed to enforce the admission decision (and any flow 985 termination decision) through policing. There are various 986 possibilities for how the PCN-egress-node can do this, ie associate 987 the received packet to the correct ingress-egress-aggregate. It is 988 not the intention of this document to mandate a particular mechanism. 990 o The addressing information can be gathered from signalling. For 991 example, regular processing of an RSVP PATH message, as the PCN- 992 ingress-node is the previous RSVP hop (PHOP) ([Lefaucheur06]). Or 993 the PCN-ingress-node could signal its address to the PCN-egress- 994 node. 996 o Always tunnel PCN-traffic across the PCN-domain. Then the PCN- 997 ingress-node's address is simply the source address of the outer 998 packet header. The PCN-ingress-node needs to learn the address of 999 the PCN-egress-node, either by manual configuration or by one of 1000 the automated tunnel endpoint discovery mechanisms (such as 1001 signalling or probing over the data route, interrogating routing 1002 or using a centralised broker). 1004 4.7. Tunnelling 1006 Tunnels may originate and/or terminate within a PCN-domain (eg IP 1007 over IP, IP over MPLS). It is important that the PCN-marking of any 1008 packet can potentially influence PCN's flow admission control and 1009 termination - it shouldn't matter whether the packet happens to be 1010 tunnelled at the PCN-node that PCN-marks the packet, or indeed 1011 whether it's decapsulated or encapsulated by a subsequent PCN-node. 1012 This suggests that the "uniform conceptual model" described in 1013 [RFC2983] should be re-applied in the PCN context. In line with this 1014 and the approach of [RFC4303] and [Briscoe08-2], the following rule 1015 is applied if encapsulation is done within the PCN-domain: 1017 o any PCN-marking is copied into the outer header 1019 Note: A tunnel will not provide this behaviour if it complies with 1020 [RFC3168] tunnelling in either mode, but it will if it complies with 1021 [RFC4301] IPSec tunnelling. 1023 Similarly, in line with the "uniform conceptual model" of [RFC2983], 1024 the "full-functionality option" of [RFC3168], and [RFC4301], the 1025 following rule is applied if decapsulation is done within the PCN- 1026 domain: 1028 o if the outer header's marking state is more severe then it is 1029 copied onto the inner header. 1031 Note: the order of increasing severity is: not PCN-marked; threshold- 1032 marking; excess-traffic-marking. 1034 An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to 1035 PCN-egress-nodes. The PCN-marks shouldn't be visible outside the 1036 PCN-domain, which can be achieved by the PCN-egress-node doing the 1037 PCN-colouring function (Section 4.3) after all the other (PCN and 1038 tunnelling) functions. The potential reasons for doing such 1039 tunnelling are: the PCN-egress-node then automatically knows the 1040 address of the relevant PCN-ingress-node for a flow; even if ECMP is 1041 running, all PCN-packets on a particular ingress-egress-aggregate 1042 follow the same path. (ECMP: Equal Cost Multi-Path, Section 12.4.) 1043 But it also has drawbacks, for example the additional overhead in 1044 terms of bandwidth and processing, and the cost of setting up a mesh 1045 of tunnels between PCN-boundary-nodes (there is an N^2 scaling 1046 issue). 1048 Potential issues arise for a "partially PCN-capable tunnel", ie where 1049 only one tunnel endpoint is in the PCN domain: 1051 1. The tunnel originates outside a PCN-domain and ends inside it. 1052 If the packet arrives at the tunnel ingress with the same 1053 encoding as used within the PCN-domain to indicate PCN-marking, 1054 then this could lead the PCN-egress-node to falsely measure pre- 1055 congestion. 1057 2. The tunnel originates inside a PCN-domain and ends outside it. 1058 If the packet arrives at the tunnel ingress already PCN-marked, 1059 then it will still have the same encoding when it's decapsulated 1060 which could potentially confuse nodes beyond the tunnel egress. 1062 In line with the solution for partially capable DiffServ tunnels in 1063 [RFC2983], the following rules are applied: 1065 o For case (1), the tunnel egress node clears any PCN-marking on the 1066 inner header. This rule is applied before the 'copy on 1067 decapsulation' rule above. 1069 o For case (2), the tunnel ingress node clears any PCN-marking on 1070 the inner header. This rule is applied after the 'copy on 1071 encapsulation' rule above. 1073 Note that the above implies that one has to know, or determine, the 1074 characteristics of the other end of the tunnel as part of 1075 establishing it. 1077 Tunnelling constraints were a major factor in the choice of the 1078 baseline encoding. As explained in [PCN08-1], with current 1079 tunnelling endpoints only the 11 codepoint of the ECN field survives 1080 decapsulation, and hence the baseline encoding only uses the 11 1081 codepoint to indicate PCN-marking. Extended encoding schemes need to 1082 explain their interactions with (or assumptions about) tunnelling. A 1083 lengthy discussion of all the issues associated with layered 1084 encapsulation of congestion notification (for ECN as well as PCN) is 1085 in [Briscoe08-2]. 1087 4.8. Fault handling 1089 If a PCN-interior-node (or one of its links) fails, then lower layer 1090 protection mechanisms or the regular IP routing protocol will 1091 eventually re-route around it. If the new route can carry all the 1092 admitted traffic, flows will gracefully continue. If instead this 1093 causes early warning of pre-congestion on the new route, then 1094 admission control based on pre-congestion notification will ensure 1095 new flows will not be admitted until enough existing flows have 1096 departed. Re-routing may result in heavy (pre-)congestion, when the 1097 flow termination mechanism will kick in. 1099 If a PCN-boundary-node fails then we would like the regular QoS 1100 signalling protocol to be responsible for taking appropriate action. 1101 As an example [Briscoe08-2] considers what happens if RSVP is the QoS 1102 signalling protocol. 1104 5. Operations and Management 1106 This Section considers operations and management issues, under the 1107 FCAPS headings: the Operations and Management of Faults, 1108 Configuration, Accounting, Performance and Security. Provisioning is 1109 discussed with performance. 1111 5.1. Configuration Operations and Management 1113 Threshold-marking and excess-traffic-marking are standardised in 1114 [PCN08-2]. However, more diversity in PCN-boundary-node behaviours 1115 is expected, in order to interface with diverse industry 1116 architectures. It may be possible to have different PCN-boundary- 1117 node behaviours for different ingress-egress-aggregates within the 1118 same PCN-domain. 1120 A PCN marking behaviour (threshold-marking, excess-traffic-marking) 1121 is enabled on either the egress or the ingress interfaces of PCN- 1122 nodes. A consistent choice must be made across the PCN-domain to 1123 ensure that the PCN mechanisms protect all links. 1125 PCN configuration control variables fall into the following 1126 categories: 1128 o system options (enabling or disabling behaviours) 1130 o parameters (setting levels, addresses etc) 1132 One possibility is that all configurable variables sit within an SNMP 1133 management framework [RFC3411], being structured within a defined 1134 management information base (MIB) on each node, and being remotely 1135 readable and settable via a suitably secure management protocol 1136 (SNMPv3). 1138 Some configuration options and parameters have to be set once to 1139 'globally' control the whole PCN-domain. Where possible, these are 1140 identified below. This may affect operational complexity and the 1141 chances of interoperability problems between equipment from different 1142 vendors. 1144 It may be possible for an operator to configure some PCN-interior- 1145 nodes so that they don't run the PCN mechanisms, if it knows that 1146 these links will never become (pre-)congested. 1148 5.1.1. System options 1150 On PCN-interior-nodes there will be very few system options: 1152 o Whether two PCN-markings (threshold-marked and excess-traffic- 1153 marked) are enabled or only one. Typically all nodes throughout a 1154 PCN-domain will be configured the same in this respect. However, 1155 exceptions could be made. For example, if most PCN-nodes used 1156 both markings, but some legacy hardware was incapable of running 1157 two algorithms, an operator might be willing to configure these 1158 legacy nodes solely for excess-traffic-marking to enable flow 1159 termination as a back-stop. It would be sensible to place such 1160 nodes where they could be provisioned with a greater leeway over 1161 expected traffic levels. 1163 o In the case where only one PCN-marking is enabled, all nodes must 1164 be configured to generate PCN-marks from the same meter (ie either 1165 the threshold meter or the excess traffic meter). 1167 PCN-boundary-nodes (ingress and egress) will have more system 1168 options: 1170 o Which of admission and flow termination are enabled. If any PCN- 1171 interior-node is configured to generate a marking, all PCN- 1172 boundary-nodes must be able to interpret that marking (which 1173 includes understanding, in a PCN-domain that uses only one type of 1174 PCN-marking, whether they are generated by PCN-interior-nodes' 1175 threshold meters or the excess traffic meters). Therefore all 1176 PCN-boundary-nodes must be configured the same in this respect. 1178 o Where flow admission and termination decisions are made: at PCN- 1179 ingress-nodes or at PCN-egress-nodes (or at a centralised node, 1180 see Appendix B). Theoretically, this configuration choice could 1181 be negotiated for each pair of PCN-boundary-nodes, but we cannot 1182 imagine why such complexity would be required, except perhaps in 1183 future inter-domain scenarios. 1185 o How PCN-markings are translated into admission control and flow 1186 termination decisions (see Section 3.1 and Section 3.2). 1188 PCN-egress-nodes will have further system options: 1190 o How the mapping should be established between each packet and its 1191 aggregate, eg by MPLS label, by IP packet filter spec; and how to 1192 take account of ECMP. 1194 o If an equipment vendor provides a choice, there may be options to 1195 select which smoothing algorithm to use for measurements. 1197 5.1.2. Parameters 1199 Like any DiffServ domain, every node within a PCN-domain will need to 1200 be configured with the DSCP(s) used to identify PCN-packets. On each 1201 interior link the main configuration parameters are the PCN- 1202 threshold-rate and PCN-excess-rate. A larger PCN-threshold-rate 1203 enables more PCN-traffic to be admitted on a link, hence improving 1204 capacity utilisation. A PCN-excess-rate set further above the PCN- 1205 threshold-rate allows greater increases in traffic (whether due to 1206 natural fluctuations or some unexpected event) before any flows are 1207 terminated, ie minimises the chances of unnecessarily triggering the 1208 termination mechanism. For instance, an operator may want to design 1209 their network so that it can cope with a failure of any single PCN- 1210 node without terminating any flows. 1212 Setting these rates on first deployment of PCN will be very similar 1213 to the traditional process for sizing an admission controlled 1214 network, depending on: the operator's requirements for minimising 1215 flow blocking (grade of service), the expected PCN traffic load on 1216 each link and its statistical characteristics (the traffic matrix), 1217 contingency for re-routing the PCN traffic matrix in the event of 1218 single or multiple failures, and the expected load from other classes 1219 relative to link capacities [Menth07]. But once a domain is in 1220 operation, a PCN design goal is to be able to determine growth in 1221 these configured rates much more simply, by monitoring PCN-marking 1222 rates from actual rather than expected traffic (see Section 5.2 on 1223 Performance & Provisioning). 1225 Operators may also wish to configure a rate greater than the PCN- 1226 excess-rate that is the absolute maximum rate that a link allows for 1227 PCN-traffic. This may simply be the physical link rate, but some 1228 operators may wish to configure a logical limit to prevent starvation 1229 of other traffic classes during any brief period after PCN-traffic 1230 exceeds the PCN-excess-rate but before flow termination brings it 1231 back below this rate. 1233 Threshold-marking requires a threshold token bucket depth to be 1234 configured, excess-traffic-marking needs a value for the MTU (maximum 1235 size of a PCN-packet on the link) and both require setting a maximum 1236 size of their token buckets. It will be preferable for there to be 1237 rules to set defaults for these parameters, but then allow operators 1238 to change them, for instance if average traffic characteristics 1239 change over time. 1241 The PCN-egress-node may allow configuration of the following: 1243 o how it smooths metering of PCN-markings (eg EWMA parameters) 1245 Whichever node makes admission and flow termination decisions will 1246 contain algorithms for converting PCN-marking levels into admission 1247 or flow termination decisions. These will also require configurable 1248 parameters, for instance: 1250 o an admission control algorithm that is based on the fraction of 1251 marked packets will at least require a marking threshold setting 1252 above which it denies admission to new flows; 1254 o flow termination algorithms will probably require a parameter to 1255 delay termination of any flows until it is more certain that an 1256 anomalous event is not transient; 1258 o a parameter to control the trade-off between how quickly excess 1259 flows are terminated, and over-termination. 1261 One particular approach, [Charny07-2] would require a global 1262 parameter to be defined on all PCN-nodes, but only needs one PCN 1263 marking rate to be configured on each link. The global parameter is 1264 a scaling factor between admission and termination (the PCN-traffic 1265 rate on a link up to which flows are admitted vs the rate above which 1266 flows are terminated). [Charny07-2] discusses in full the impact of 1267 this particular approach on the operation of PCN. 1269 5.2. Performance & Provisioning Operations and Management 1271 Monitoring of performance factors measurable from *outside* the PCN 1272 domain will be no different with PCN than with any other packet-based 1273 flow admission control system, both at the flow level (blocking 1274 probability, etc) and the packet level (jitter [RFC3393], [Y.1541], 1275 loss rate [RFC4656], mean opinion score [P.800], etc). The 1276 difference is that PCN is intentionally designed to indicate 1277 *internally* which exact resource(s) are the cause of performance 1278 problems and by how much. 1280 Even better, PCN indicates which resources will probably cause 1281 problems if they are not upgraded soon. This can be achieved by the 1282 management system monitoring the total amount (in bytes) of PCN- 1283 marking generated by each queue over a period. Given possible long 1284 provisioning lead times, pre-congestion volume is the best metric to 1285 reveal whether sufficient persistent demand has occurred to warrant 1286 an upgrade. Because, even before utilisation becomes problematic, 1287 the statistical variability of traffic will cause occasional bursts 1288 of pre-congestion. This 'early warning system' decouples the process 1289 of adding customers from the provisioning process. This should cut 1290 the time to add a customer when compared against admission control 1291 provided over native DiffServ [RFC2998], because it saves having to 1292 verify the capacity planning process before adding each customer. 1294 Alternatively, before triggering an upgrade, the long term pre- 1295 congestion volume on each link can be used to balance traffic load 1296 across the PCN-domain by adjusting the link weights of the routing 1297 system. When an upgrade to a link's configured PCN-rates is 1298 required, it may also be necessary to upgrade the physical capacity 1299 available to other classes. But usually there will be sufficient 1300 physical capacity for the upgrade to go ahead as a simple 1301 configuration change. Alternatively, [Songhurst06] describes an 1302 adaptive rather than preconfigured system, where the configured PCN- 1303 threshold-rate is replaced with a high and low water mark and the 1304 marking algorithm automatically optimises how physical capacity is 1305 shared using the relative loads from PCN and other traffic classes. 1307 All the above processes require just three extra counters associated 1308 with each PCN queue: threshold-markings, excess-traffic-markings and 1309 drop. Every time a PCN packet is marked or dropped its size in bytes 1310 should be added to the appropriate counter. Then the management 1311 system can read the counters at any time and subtract a previous 1312 reading to establish the incremental volume of each type of 1313 (pre-)congestion. Readings should be taken frequently, so that 1314 anomalous events (eg re-routes) can be distinguished from regular 1315 fluctuating demand if required. 1317 5.3. Accounting Operations and Management 1319 Accounting is only done at trust boundaries so it is out of scope of 1320 this document, which is confined to intra-domain issues. Use of PCN 1321 internal to a domain makes no difference to the flow signalling 1322 events crossing trust boundaries outside the PCN-domain, which are 1323 typically used for accounting. 1325 5.4. Fault Operations and Management 1327 Fault Operations and Management is about preventing faults, telling 1328 the management system (or manual operator) that the system has 1329 recovered (or not) from a failure, and about maintaining information 1330 to aid fault diagnosis. 1332 Admission blocking and particularly flow termination mechanisms 1333 should rarely be needed in practice. It would be unfortunate if they 1334 didn't work after an option had been accidentally disabled. 1335 Therefore it will be necessary to regularly test that the live system 1336 works as intended (devising a meaningful test is left as an exercise 1337 for the operator). 1339 Section 4 describes how the PCN architecture has been designed to 1340 ensure admitted flows continue gracefully after recovering 1341 automatically from link or node failures. The need to record and 1342 monitor re-routing events affecting signalling is unchanged by the 1343 addition of PCN to a DiffServ domain. Similarly, re-routing events 1344 within the PCN-domain will be recorded and monitored just as they 1345 would be without PCN. 1347 PCN-marking does make it possible to record 'near-misses'. For 1348 instance, at the PCN-egress-node a 'reporting threshold' could be set 1349 to monitor how often - and for how long - the system comes close to 1350 triggering flow blocking without actually doing so. Similarly, 1351 bursts of flow termination marking could be recorded even if they are 1352 not sufficiently sustained to trigger flow termination. Such 1353 statistics could be correlated with per-queue counts of marking 1354 volume (Section 5.2) to upgrade resources in danger of causing 1355 service degradation, or to trigger manual tracing of intermittent 1356 incipient errors that would otherwise have gone unnoticed. 1358 Finally, of course, many faults are caused by failings in the 1359 management process ('human error'): a wrongly configured address in a 1360 node, a wrong address given in a signalling protocol, a wrongly 1361 configured parameter in a queueing algorithm, a node set into a 1362 different mode from other nodes, and so on. Generally, a clean 1363 design with few configurable options ensures this class of faults can 1364 be traced more easily and prevented more often. Sound management 1365 practice at run-time also helps. For instance: a management system 1366 should be used that constrains configuration changes within system 1367 rules (eg preventing an option setting inconsistent with other 1368 nodes); configuration options should also be recorded in an offline 1369 database; and regular automatic consistency checks between live 1370 systems and the database should be performed. PCN adds nothing 1371 specific to this class of problems. 1373 5.5. Security Operations and Management 1375 Security Operations and Management is about using secure operational 1376 practices as well as being able to track security breaches or near- 1377 misses at run-time. PCN adds few specifics to the general good 1378 practice required in this field [RFC4778], other than those below. 1379 The correct functions of the system should be monitored (Section 5.2) 1380 in multiple independent ways and correlated to detect possible 1381 security breaches. Persistent (pre-)congestion marking should raise 1382 an alarm (both on the node doing the marking and on the PCN-egress- 1383 node metering it). Similarly, persistently poor external QoS metrics 1384 (such as jitter or mean opinion score) should raise an alarm. The 1385 following are examples of symptoms that may be the result of innocent 1386 faults, rather than attacks, but until diagnosed they should be 1387 logged and trigger a security alarm: 1389 o Anomalous patterns of non-conforming incoming signals and packets 1390 rejected at the PCN-ingress-nodes (eg packets already marked PCN- 1391 capable, or traffic persistently starving token bucket policers). 1393 o PCN-capable packets arriving at a PCN-egress-node with no 1394 associated state for mapping them to a valid ingress-egress- 1395 aggregate. 1397 o A PCN-ingress-node receiving feedback signals about the pre- 1398 congestion level on a non-existent aggregate, or that are 1399 inconsistent with other signals (eg unexpected sequence numbers, 1400 inconsistent addressing, conflicting reports of the pre-congestion 1401 level, etc). 1403 o Pre-congestion marking arriving at a PCN-egress-node with 1404 (pre-)congestion markings focused on particular flows, rather than 1405 randomly distributed throughout the aggregate. 1407 6. IANA Considerations 1409 This memo includes no request to IANA. 1411 7. Security considerations 1413 Security considerations essentially come from the Trust Assumption 1414 (Section 12.3.1), ie that all PCN-nodes are PCN-enabled and are 1415 trusted for truthful PCN-marking and transport. PCN splits 1416 functionality between PCN-interior-nodes and PCN-boundary-nodes, and 1417 the security considerations are somewhat different for each, mainly 1418 because PCN-boundary-nodes are flow-aware and PCN-interior-nodes are 1419 not. 1421 o Because the PCN-boundary-nodes are flow-aware, they are trusted to 1422 use that awareness correctly. The degree of trust required 1423 depends on the kinds of decisions they have to make and the kinds 1424 of information they need to make them. There is nothing specific 1425 to PCN. 1427 o The PCN-ingress-nodes police packets to ensure a PCN-flow sticks 1428 within its agreed limit, and to ensure that only PCN-flows that 1429 have been admitted contribute PCN-traffic into the PCN-domain. 1430 The policer must drop (or perhaps downgrade to a different DSCP) 1431 any PCN-packets received that are outside this remit. This is 1432 similar to the existing IntServ behaviour. Between them the PCN- 1433 boundary-nodes must encircle the PCN-domain, otherwise PCN-packets 1434 could enter the PCN-domain without being subject to admission 1435 control, which would potentially destroy the QoS of existing 1436 flows. 1438 o PCN-interior-nodes are not flow-aware. This prevents some 1439 security attacks where an attacker targets specific flows in the 1440 data plane - for instance for DoS or eavesdropping. 1442 o The PCN-boundary-nodes rely on correct PCN-marking by the PCN- 1443 interior-nodes. For instance a rogue PCN-interior-node could PCN- 1444 mark all packets so that no flows were admitted. Another 1445 possibility is that it doesn't PCN-mark any packets, even when it 1446 is pre-congested. More subtly, the rogue PCN-interior-node could 1447 perform these attacks selectively on particular flows, or it could 1448 PCN-mark the correct fraction overall, but carefully choose which 1449 flows it marked. 1451 o The PCN-boundary-nodes should be able to deal with DoS attacks and 1452 state exhaustion attacks based on fast changes in per flow 1453 signalling. 1455 o The signalling between the PCN-boundary-nodes must be protected 1456 from attacks. For example the recipient needs to validate that 1457 the message is indeed from the node that claims to have sent it. 1458 Possible measures include digest authentication and protection 1459 against replay and man-in-the-middle attacks. For the specific 1460 protocol RSVP, hop-by-hop authentication is in [RFC2747], and 1461 [Behringer07] may also be useful. 1463 Operational security advice is given in Section 5.5. 1465 8. Conclusions 1467 The document describes a general architecture for flow admission and 1468 termination based on pre-congestion information in order to protect 1469 the quality of service of established inelastic flows within a single 1470 DiffServ domain. The main topic is the functional architecture. It 1471 also mentions other topics like the assumptions and open issues. 1473 9. Acknowledgements 1475 This document is a revised version of an earlier individual draft 1476 authored by: P. Eardley, J. Babiarz, K. Chan, A. Charny, R. Geib, G. 1477 Karagiannis, M. Menth, T. Tsou. They are therefore contributors to 1478 this document. 1480 Thanks to those who have made comments on this document: Lachlan 1481 Andrew, Joe Babiarz, Fred Baker, David Black, Steven Blake, Ron 1482 Bonica, Scott Bradner, Bob Briscoe, Ross Callon, Jason Canon, Ken 1483 Carlberg, Anna Charny, Joachim Charzinski, Andras Csaszar, Francis 1484 Dupont, Lars Eggert, Pasi Eronen, Ruediger Geib, Wei Gengyu, Robert 1485 Hancock, Fortune Huang, Christian Hublet, Cullen Jennings, Ingemar 1486 Johansson, Georgios Karagiannis, Hein Mekkes, Michael Menth, Toby 1487 Moncaster, Dan Romascanu, Daisuke Satoh, Ben Strulo, Tom Taylor, 1488 Hannes Tschofenig, Tina Tsou, David Ward, Lars Westberg, Magnus 1489 Westerlund, Delei Yu. Thanks to Bob Briscoe who extensively revised 1490 the Operations and Management section. 1492 This document is the result of discussions in the PCN WG and 1493 forerunner activity in the TSVWG. A number of previous drafts were 1494 presented to TSVWG; their authors were: B, Briscoe, P. Eardley, D. 1495 Songhurst, F. Le Faucheur, A. Charny, J. Babiarz, K. Chan, S. Dudley, 1496 G. Karagiannis, A. Bader, L. Westberg, J. Zhang, V. Liatsos, X-G. 1497 Liu, A. Bhargava. 1499 10. Comments Solicited 1501 Comments and questions are encouraged and very welcome. They can be 1502 addressed to the IETF PCN working group mailing list . 1504 11. Changes 1506 11.1. Changes from -098 to -10 1508 Changes to deal with IESG comments: 1510 o New introduction to provide gentler introduction for the PCN 1511 novice: quick summary of PCN's applicability; quick example of how 1512 it all hangs together in one end-to-end qos scenario; quick 1513 summary of PCN "documentation" 1515 o OAM changed to Operations and Management 1517 o Processed some of the minor suggestions in the Gen-ART Review by 1518 Francis Dupont 1520 o Two wording tweaks in Sections 3.2 & 3.4 (as agreed on mailing 1521 list) 1523 o Updated boilerplate. this draft may include material pre- Nov 10 1524 2008 blah. 1526 11.2. Changes from -08 to -09 1528 Small changes to deal with WG Chair comments: 1530 o tweak language in various places to make it more RFC-like and less 1531 that of a scholarly work, for instance from "we propose" to "this 1532 document describes" 1534 o tweak language in various places to make it a stand alone 1535 architecture document rather than a discussion of the PCN WG. Now 1536 only mentions WG at start of Annex. 1538 o References: IDs are no longer referenced to by the draft name 1540 o References: removed some of less important references to IDs 1542 11.3. Changes from -07 to -08 1544 Small changes from second WG last call: 1546 o Section 2: added definition for PCN-admissible-rate and PCN- 1547 supportable-rate. Small changes to use these terms as follows: 1548 Section 3, bullets 2 & 9; S6.1 para 1; S6.2 para1; S6.3 bullet 3; 1549 added to Figs 1 & 2. 1551 o added the phrase "(others might be possible") before the list of 1552 approaches in Section 6.3, 7.4 & 7.5. 1554 o added references to RFC2753 (A framework for policy-based 1555 admission control) in S7.4 & S7.5. 1557 o throughout, updated references now that marking behaviour & 1558 baseline encoding are WG drafts. 1560 o a few typos corrected 1562 11.4. Changes from -06 to -07 1564 References re-formatted to pass ID nits. No other changes. 1566 11.5. Changes from -05 to -06 1568 Minor clarifications throughout, the least insignificant are as 1569 follows: 1571 o Section 1: added to the list of encoding states in an 'extended' 1572 scheme: "or perhaps further encoding states as suggested in 1573 draft-westberg-pcn-load-control" 1575 o Section 2: added definition for PCN-colouring (to clarify that the 1576 term is used consistently differently from 'PCN-marking') 1578 o Section 6.1 and 6.2: added "(others might be possible)" before the 1579 list of high level approaches for making flow admission 1580 (termination) decisions. 1582 o Section 6.2: corrected a significant typo in 2nd bullet (more -> 1583 less) 1585 o Section 6.3: corrected a couple of significant typos in Figure 2 1587 o Section 6.5 (PCN-traffic) re-written for clarity. Non PCN-traffic 1588 contributing to PCN meters is now given as an example (there may 1589 be cases where don't need to meter it). 1591 o Section 7.7: added to the text about encapsulation being done 1592 within the PCN-domain: "Note: A tunnel will not provide this 1593 behaviour if it complies with [RFC3168] tunnelling in either mode, 1594 but it will if it complies with [RFC4301] IPSec tunnelling." 1596 o Section 7.7: added mention of [RFC4301] to the text about 1597 decapsulation being done within the PCN-domain. 1599 o Section 8: deleted the text about design goals, since this is 1600 already covered adequately earlier eg in S3. 1602 o Section 11: replaced the last sentence of bullet 1 by "There is 1603 nothing specific to PCN." 1605 o Appendix: added to open issues: possibility of automatically and 1606 periodically probing. 1608 o References: Split out Normative references (RFC2474 & RFC3246). 1610 11.6. Changes from -04 to -05 1612 Minor nits removed as follows: 1614 o Further minor changes to reflect that baseline encoding is 1615 consensus, standards track document, whilst there can be 1616 (experimental track) encoding extensions 1618 o Traffic conditioning updated to reflect discussions in Dublin, 1619 mainly that PCN-interior-nodes don't police PCN-traffic (so 1620 deleted bullet in S7.1) and that it is not advised to have non 1621 PCN-traffic that shares the same capacity (on a link) as PCN- 1622 traffic (so added bullet in S6.5) 1624 o Probing moved into Appendix A and deleted the 'third viewpoint' 1625 (admission control based on the marking of a single packet like an 1626 RSVP PATH message) - since this isn't really probing, and in any 1627 case is already mentioned in S6.1. 1629 o Minor changes to S9 Operations and management - mainly to reflect 1630 that consensus on marking behaviour has simplified things so eg 1631 there are fewer parameters to configure. 1633 o A few terminology-related errors expunged, and two pictures added 1634 to help. 1636 o Re-phrased the claim about the natural decision point in S7.4 1638 o Clarified that extended encoding schemes need to explain their 1639 interactions with (or assumptions about) tunnelling (S7.7) and how 1640 they meet the guidelines of BCP124 (S6.6) 1642 o Corrected the third bullet in S6.2 (to reflect consensus about 1643 PCN-marking) 1645 11.7. Changes from -03 to -04 1647 o Minor changes throughout to reflect the consensus call about PCN- 1648 marking (as reflected in [PCN08-2]). 1650 o Minor changes throughout to reflect the current decisions about 1651 encoding (as reflected in [PCN08-1] and [Moncaster08]). 1653 o Introduction: re-structured to create new sections on Benefits, 1654 Deployment scenarios and Assumptions. 1656 o Introduction: Added pointers to other PCN documents. 1658 o Terminology: changed PCN-lower-rate to PCN-threshold-rate and PCN- 1659 upper-rate to PCN-excess-rate; excess-rate-marking to excess- 1660 traffic-marking. 1662 o Benefits: added bullet about SRLGs. 1664 o Deployment scenarios: new section combining material from various 1665 places within the document. 1667 o S6 (high level functional architecture): re-structured and edited 1668 to improve clarity, and reflect the latest PCN-marking and 1669 encoding drafts. 1671 o S6.4: added claim that the most natural place to make an admission 1672 decision is a PCN-egress-node. 1674 o S6.5: updated the bullet about non-PCN-traffic that uses the same 1675 DSCP as PCN-traffic. 1677 o S6.6: added a section about backwards compatibility with respect 1678 to [RFC4774]. 1680 o Appendix A: added bullet about end-to-end PCN. 1682 o Probing: moved to Appendix B. 1684 o Other minor clarifications, typos etc. 1686 11.8. Changes from -02 to -03 1688 o Abstract: Clarified by removing the term 'aggregated'. Follow-up 1689 clarifications later in draft: S1: expanded PCN-egress-nodes 1690 bullet to mention case where the PCN-feedback-information is about 1691 one (or a few) PCN-marks, rather than aggregated information; S3 1692 clarified PCN-meter; S5 minor changes; conclusion. 1694 o S1: added a paragraph about how the PCN-domain looks to the 1695 outside world (essentially it looks like a DiffServ domain). 1697 o S2: tweaked the PCN-traffic terminology bullet: changed PCN 1698 traffic classes to PCN behaviour aggregates, to be more in line 1699 with traditional DiffServ jargon (-> follow-up changes later in 1700 draft); included a definition of PCN-flows (and corrected a couple 1701 of 'PCN microflows' to 'PCN-flows' later in draft) 1703 o S3.5: added possibility of downgrading to best effort, where PCN- 1704 packets arrive at PCN-ingress-node already ECN marked (CE or ECN 1705 nonce) 1707 o S4: added note about whether talk about PCN operating on an 1708 interface or on a link. In S8.1 (OAM) mentioned that PCN 1709 functionality needs to be configured consistently on either the 1710 ingress or the egress interface of PCN-nodes in a PCN-domain. 1712 o S5.2: clarified that signalling protocol installs flow filter spec 1713 at PCN-ingress-node (& updates after possible re-route) 1715 o S5.6: addressing: clarified 1717 o S5.7: added tunnelling issue of N^2 scaling if you set up a mesh 1718 of tunnels between PCN-boundary-nodes 1720 o S7.3: Clarified the "third viewpoint" of probing (always probe). 1722 o S8.1: clarified that SNMP is only an example; added note that an 1723 operator may be able to not run PCN on some PCN-interior-nodes, if 1724 it knows that these links will never become (pre-)congested; added 1725 note that it may be possible to have different PCN-boundary-node 1726 behaviours for different ingress-egress-aggregates within the same 1727 PCN-domain. 1729 o Appendix: Created an Appendix about "Possible work items beyond 1730 the scope of the current PCN WG Charter". Material moved from 1731 near start of S3 and elsewhere throughout draft. Moved text about 1732 centralised decision node to Appendix. 1734 o Other minor clarifications. 1736 11.9. Changes from -01 to -02 1738 o S1: Benefits: provisioning bullet extended to stress that PCN does 1739 not use RFC2475-style traffic conditioning. 1741 o S1: Deployment models: mentioned, as variant of PCN-domain 1742 extending to end nodes, that may extend to LAN edge switch. 1744 o S3.1: Trust Assumption: added note about not needing PCN-marking 1745 capability if known that an interface cannot become pre-congested. 1747 o S4: now divided into sub-sections 1749 o S4.1: Admission control: added second proposed method for how to 1750 decide to block new flows (PCN-egress-node receives one (or 1751 several) PCN-marked packets). 1753 o S5: Probing sub-section removed. Material now in new S7. 1755 o S5.6: Addressing: clarified how PCN-ingress-node can discover 1756 address of PCN-egress-node 1758 o S5.6: Addressing: centralised node case, added that PCN-ingress- 1759 node may need to know address of PCN-egress-node 1761 o S5.8: Tunnelling: added case of "partially PCN-capable tunnel" and 1762 degraded bullet on this in S6 (Open Issues) 1764 o S7: Probing: new section. Much more comprehensive than old S5.5. 1766 o S8: Operations and Management: substantially revised. 1768 o other minor changes not affecting semantics 1770 11.10. Changes from -00 to -01 1772 In addition to clarifications and nit squashing, the main changes 1773 are: 1775 o S1: Benefits: added one about provisioning (and contrast with 1776 DiffServ SLAs) 1778 o S1: Benefits: clarified that the objective is also to stop PCN- 1779 packets being significantly delayed (previously only mentioned not 1780 dropping packets) 1782 o S1: Deployment models: added one where policing is done at ingress 1783 of access network and not at ingress of PCN-domain (assume trust 1784 between networks) 1786 o S1: Deployment models: corrected MPLS-TE to MPLS 1787 o S2: Terminology: adjusted definition of PCN-domain 1789 o S3.5: Other assumptions: corrected, so that two assumptions (PCN- 1790 nodes not performing ECN and PCN-ingress-node discarding arriving 1791 CE packet) only apply if the PCN WG decides to encode PCN-marking 1792 in the ECN-field. 1794 o S4 & S5: changed PCN-marking algorithm to marking behaviour 1796 o S4: clarified that PCN-interior-node functionality applies for 1797 each outgoing interface, and added clarification: "The 1798 functionality is also done by PCN-ingress-nodes for their outgoing 1799 interfaces (ie those 'inside' the PCN-domain)." 1801 o S4 (near end): altered to say that a PCN-node "should" dedicate 1802 some capacity to lower priority traffic so that it isn't starved 1803 (was "may") 1805 o S5: clarified to say that PCN functionality is done on an 1806 'interface' (rather than on a 'link') 1808 o S5.2: deleted erroneous mention of service level agreement 1810 o S5.5: Probing: re-written, especially to distinguish probing to 1811 test the ingress-egress-aggregate from probing to test a 1812 particular ECMP path. 1814 o S5.7: Addressing: added mention of probing; added that in the case 1815 where traffic is always tunnelled across the PCN-domain, add a 1816 note that he PCN-ingress-node needs to know the address of the 1817 PCN-egress-node. 1819 o S5.8: Tunnelling: re-written, especially to provide a clearer 1820 description of copying on tunnel entry/exit, by adding explanation 1821 (keeping tunnel encaps/decaps and PCN-marking orthogonal), 1822 deleting one bullet ("if the inner header's marking state is more 1823 sever then it is preserved" - shouldn't happen), and better 1824 referencing of other IETF documents. 1826 o S6: Open issues: stressed that "NOTE: Potential solutions are out 1827 of scope for this document" and edited a couple of sentences that 1828 were close to solution space. 1830 o S6: Open issues: added one about scenarios with only one tunnel 1831 endpoint in the PCN domain . 1833 o S6: Open issues: ECMP: added under-admission as another potential 1834 risk 1836 o S6: Open issues: added one about "Silent at start" 1838 o S10: Conclusions: a small conclusions section added 1840 12. Appendix A: Applicability of PCN 1842 12.1. Benefits 1844 We believe that the key benefits of the PCN mechanisms described in 1845 this document are that they are simple, scalable, and robust because: 1847 o Per flow state is only required at the PCN-ingress-nodes 1848 ("stateless core"). This is required for policing purposes (to 1849 prevent non-admitted PCN traffic from entering the PCN-domain) and 1850 so on. It is not generally required that other network entities 1851 are aware of individual flows (although they may be in particular 1852 deployment scenarios). 1854 o Admission control is resilient: with PCN QoS is decoupled from the 1855 routing system. Hence in general admitted flows can survive 1856 capacity, routing or topology changes without additional 1857 signalling. The PCN-admissible-rate on each link can be chosen 1858 small enough that admitted traffic can still be carried after a 1859 rerouting in most failure cases [Menth07]. This is an important 1860 feature as QoS violations in core networks due to link failures 1861 are more likely than QoS violations due to increased traffic 1862 volume [Iyer03]. 1864 o The PCN-marking behaviours only operate on the overall PCN-traffic 1865 on the link, not per flow. 1867 o The information of these measurements is signalled to the PCN- 1868 egress-nodes by the PCN-marks in the packet headers, ie [Style] 1869 "in-band". No additional signalling protocol is required for 1870 transporting the PCN-marks. Therefore no secure binding is 1871 required between data packets and separate congestion messages. 1873 o The PCN-egress-nodes make separate measurements, operating on the 1874 aggregate PCN-traffic from each PCN-ingress-node, ie not per flow. 1875 Similarly, signalling by the PCN-egress-node of PCN-feedback- 1876 information (which is used for flow admission and termination 1877 decisions) is at the granularity of the ingress-egress-aggregate. 1878 An alternative approach is that the PCN-egress-nodes monitor the 1879 PCN-traffic and signal PCN-feedback-information (which is used for 1880 flow admission and termination decisions) at the granularity of 1881 one (or a few) PCN-marks. 1883 o The admitted PCN-load is controlled dynamically. Therefore it 1884 adapts as the traffic matrix changes, and also if the network 1885 topology changes (eg after a link failure). Hence an operator can 1886 be less conservative when deploying network capacity, and less 1887 accurate in their prediction of the PCN-traffic matrix. 1889 o The termination mechanism complements admission control. It 1890 allows the network to recover from sudden unexpected surges of 1891 PCN-traffic on some links, thus restoring QoS to the remaining 1892 flows. Such scenarios are expected to be rare but not impossible. 1893 They can be caused by large network failures that redirect lots of 1894 admitted PCN-traffic to other links, or by malfunction of the 1895 measurement-based admission control in the presence of admitted 1896 flows that send for a while with an atypically low rate and then 1897 increase their rates in a correlated way. 1899 o Flow termination can also enable an operator to be less 1900 conservative when deploying network capacity. It is an 1901 alternative to running links at low utilisation in order to 1902 protect against link or node failures. This is especially the 1903 case with SRLGs (shared risk link groups, which are links that 1904 share a resource, such as a fibre, whose failure affects all those 1905 links [RFC4216]). Fully protecting traffic against a single SRLG 1906 failure requires low utilisation (~10%) of the link bandwidth on 1907 some links before failure [Charny08]. 1909 o The PCN-supportable-rate may be set below the maximum rate that 1910 PCN-traffic can be transmitted on a link, in order to trigger 1911 termination of some PCN-flows before loss (or excessive delay) of 1912 PCN-packets occurs, or to keep the maximum PCN-load on a link 1913 below a level configured by the operator. 1915 o Provisioning of the network is decoupled from the process of 1916 adding new customers. By contrast, with the DiffServ architecture 1917 [RFC2475] operators rely on subscription-time Service Level 1918 Agreements, which statically define the parameters of the traffic 1919 that will be accepted from a customer, and so the operator has to 1920 verify provision is sufficient each time a new customer is added 1921 to check that the Service Level Agreement can be fulfilled. A 1922 PCN-domain doesn't need such traffic conditioning. 1924 12.2. Deployment scenarios 1926 Operators of networks will want to use the PCN mechanisms in various 1927 arrangements, for instance depending on how they are performing 1928 admission control outside the PCN-domain (users after all are 1929 concerned about QoS end-to-end), what their particular goals and 1930 assumptions are, how many PCN encoding states are available, and so 1931 on. 1933 A PCN-domain may have three encoding states (or pedantically, an 1934 operator may choose to use up three encoding states for PCN): not 1935 PCN-marked, threshold-marked, excess-traffic-marked. Then both PCN 1936 admission control and flow termination can be supported. As 1937 illustrated in Figure 1, admission control accepts new flows until 1938 the PCN-traffic rate on the bottleneck link rises above the PCN- 1939 threshold-rate, whilst if necessary the flow termination mechanism 1940 terminates flows down to the PCN-excess-rate on the bottleneck link. 1942 On the other hand, a PCN-domain may have two encoding states (as in 1943 [PCN08-1]) (or pedantically, an operator may choose to use up two 1944 encoding states for PCN): not PCN-marked, PCN-marked. Then there are 1945 three possibilities, as discussed in the following paragraphs (see 1946 also Section 3.3). 1948 First, an operator could just use PCN's admission control, solving 1949 heavy congestion (caused by re-routing) by 'just waiting' - as 1950 sessions end, PCN-traffic naturally reduces, and meanwhile the 1951 admission control mechanism will prevent admission of new flows that 1952 use the affected links. So the PCN-domain will naturally return to 1953 normal operation, but with reduced capacity. The drawback of this 1954 approach would be that, until sufficient sessions have ended to 1955 relieve the congestion, all PCN-flows as well as lower priority 1956 services will be adversely affected. 1958 Second, an operator could just rely for admission control on 1959 statically provisioned capacity per PCN-ingress-node (regardless of 1960 the PCN-egress-node of a flow), as is typical in the hose model of 1961 the DiffServ architecture [RFC2475]. Such traffic conditioning 1962 agreements can lead to focused overload: many flows happen to focus 1963 on a particular link and then all flows through the congested link 1964 fail catastrophically. PCN's flow termination mechanism could then 1965 be used to counteract such a problem. 1967 Third, both admission control and flow termination can be triggered 1968 from the single type of PCN-marking; the main downside is that 1969 admission control is less accurate [Charny07-2]. This possibility is 1970 illustrated in Figure 3. 1972 Within the PCN-domain there is some flexibility about how the 1973 decision making functionality is distributed. These possibilities 1974 are outlined in Section 4.4 and also discussed elsewhere, such as in 1975 [Menth08-3]. 1977 The flow admission and termination decisions need to be enforced 1978 through per flow policing by the PCN-ingress-nodes. If there are 1979 several PCN-domains on the end-to-end path, then each needs to police 1980 at its PCN-ingress-nodes. One exception is if the operator runs both 1981 the access network (not a PCN-domain) and the core network (a PCN- 1982 domain); per flow policing could be devolved to the access network 1983 and not done at the PCN-ingress-node. Note: to aid readability, the 1984 rest of this draft assumes that policing is done by the PCN-ingress- 1985 nodes. 1987 PCN admission control has to fit with the overall approach to 1988 admission control. For instance [Briscoe06] describes the case where 1989 RSVP signalling runs end-to-end. The PCN-domain is a single RSVP 1990 hop, ie only the PCN-boundary-nodes process RSVP messages, with RSVP 1991 messages processed on each hop outside the PCN-domain, as in IntServ 1992 over DiffServ [RFC2998]. It would also be possible for the RSVP 1993 signalling to be originated and/or terminated by proxies, with 1994 application-layer signalling between the end user and the proxy (eg 1995 SIP signalling with a home hub). A similar example would use NSIS 1996 signalling instead of RSVP. (NSIS: Next Steps in Signalling, 1997 [RFC3726].) 1999 It is possible that a user wants its inelastic traffic to use the PCN 2000 mechanisms but also react to ECN marking outside the PCN-domain 2001 [Sarker08]. Two possible ways to do this are to tunnel all PCN- 2002 packets across the PCN-domain, so that the ECN marks are carried 2003 transparently across the PCN-domain, or to use an encoding like 2004 [Moncaster08]. Tunnelling is discussed further in Section 4.7. 2006 Some further possible deployment models are outlined in the Appendix. 2008 12.3. Assumptions and constraints on scope 2010 The scope is restricted by the following assumptions: 2012 1. these components are deployed in a single DiffServ domain, within 2013 which all PCN-nodes are PCN-enabled and are trusted for truthful 2014 PCN-marking and transport 2016 2. all flows handled by these mechanisms are inelastic and 2017 constrained to a known peak rate through policing or shaping 2019 3. the number of PCN-flows across any potential bottleneck link is 2020 sufficiently large that stateless, statistical mechanisms can be 2021 effective. To put it another way, the aggregate bit rate of PCN- 2022 traffic across any potential bottleneck link needs to be 2023 sufficiently large relative to the maximum additional bit rate 2024 added by one flow. This is the basic assumption of measurement- 2025 based admission control. 2027 4. PCN-flows may have different precedence, but the applicability of 2028 the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) 2029 is out of scope. 2031 12.3.1. Assumption 1: Trust and support of PCN - controlled environment 2033 We assume that the PCN-domain is a controlled environment, ie all the 2034 nodes in a PCN-domain run PCN and are trusted. There are several 2035 reasons this assumption: 2037 o The PCN-domain has to be encircled by a ring of PCN-boundary- 2038 nodes, otherwise traffic could enter a PCN-BA without being 2039 subject to admission control, which would potentially degrade the 2040 QoS of existing PCN-flows. 2042 o Similarly, a PCN-boundary-node has to trust that all the PCN-nodes 2043 mark PCN-traffic consistently. A node not performing PCN-marking 2044 wouldn't be able to alert when it suffered pre-congestion, which 2045 potentially would lead to too many PCN-flows being admitted (or 2046 too few being terminated). Worse, a rogue node could perform 2047 various attacks, as discussed in the Security Considerations 2048 section. 2050 One way of assuring the above two points is that the entire PCN- 2051 domain is run by a single operator. Another possibility is that 2052 there are several operators that trust each other in their handling 2053 of PCN-traffic. 2055 Note: All PCN-nodes need to be trustworthy. However if it is known 2056 that an interface cannot become pre-congested then it is not strictly 2057 necessary for it to be capable of PCN-marking. But this must be 2058 known even in unusual circumstances, eg after the failure of some 2059 links. 2061 12.3.2. Assumption 2: Real-time applications 2063 We assume that any variation of source bit rate is independent of the 2064 level of pre-congestion. We assume that PCN-packets come from real 2065 time applications generating inelastic traffic, ie sending packets at 2066 the rate the codec produces them, regardless of the availability of 2067 capacity [RFC4594]. For example, voice and video requiring low 2068 delay, jitter and packet loss, the Controlled Load Service, 2069 [RFC2211], and the Telephony service class, [RFC4594]. This 2070 assumption is to help focus the effort where it looks like PCN would 2071 be most useful, ie the sorts of applications where per flow QoS is a 2072 known requirement. In other words we focus on PCN providing a 2073 benefit to inelastic traffic (PCN may or may not provide a benefit to 2074 other types of traffic). 2076 As a consequence, it is assumed that PCN-marking is being applied to 2077 traffic scheduled with the expedited forwarding per-hop behaviour, 2078 [RFC3246], or a per-hop behaviour with similar characteristics. 2080 12.3.3. Assumption 3: Many flows and additional load 2082 We assume that there are many PCN-flows on any bottleneck link in the 2083 PCN-domain (or, to put it another way, the aggregate bit rate of PCN- 2084 traffic across any potential bottleneck link is sufficiently large 2085 relative to the maximum additional bit rate added by one PCN-flow). 2086 Measurement-based admission control assumes that the present is a 2087 reasonable prediction of the future: the network conditions are 2088 measured at the time of a new flow request, however the actual 2089 network performance must be acceptable during the call some time 2090 later. One issue is that if there are only a few variable rate 2091 flows, then the aggregate traffic level may vary a lot, perhaps 2092 enough to cause some packets to get dropped. If there are many flows 2093 then the aggregate traffic level should be statistically smoothed. 2094 How many flows is enough depends on a number of factors such as the 2095 variation in each flow's rate, the total rate of PCN-traffic, and the 2096 size of the "safety margin" between the traffic level at which we 2097 start admission-marking and at which packets are dropped or 2098 significantly delayed. 2100 We do not make explicit assumptions on how many PCN-flows are in each 2101 ingress-egress-aggregate. Performance evaluation work may clarify 2102 whether it is necessary to make any additional assumption on 2103 aggregation at the ingress-egress-aggregate level. 2105 12.3.4. Assumption 4: Emergency use out of scope 2107 PCN-flows may have different precedence, but the applicability of the 2108 PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc) is out 2109 of scope of this document. 2111 12.4. Challenges 2113 Prior work on PCN and similar mechanisms has thrown up a number of 2114 considerations about PCN's design goals (things PCN should be good 2115 at) and some issues that have been hard to solve in a fully 2116 satisfactory manner. Taken as a whole it represents a list of trade- 2117 offs (it is unlikely that they can all be 100% achieved) and perhaps 2118 as evaluation criteria to help an operator (or the IETF) decide 2119 between options. 2121 The following are open issues. They are mainly taken from 2122 [Briscoe06], which also describes some possible solutions. Note that 2123 some may be considered unimportant in general or in specific 2124 deployment scenarios or by some operators. 2126 NOTE: Potential solutions are out of scope for this document. 2128 o ECMP (Equal Cost Multi-Path) Routing: The level of pre-congestion 2129 is measured on a specific ingress-egress-aggregate. However, if 2130 the PCN-domain runs ECMP, then traffic on this ingress-egress- 2131 aggregate may follow several different paths - some of the paths 2132 could be pre-congested whilst others are not. There are three 2133 potential problems: 2135 1. over-admission: a new flow is admitted (because the pre- 2136 congestion level measured by the PCN-egress-node is 2137 sufficiently diluted by unmarked packets from non-congested 2138 paths that a new flow is admitted), but its packets travel 2139 through a pre-congested PCN-node. 2141 2. under-admission: a new flow is blocked (because the pre- 2142 congestion level measured by the PCN-egress-node is 2143 sufficiently increased by PCN-marked packets from pre- 2144 congested paths that a new flow is blocked), but its packets 2145 travel along an uncongested path. 2147 3. ineffective termination: a flow is terminated, but its path 2148 doesn't travel through the (pre-)congested router(s). Since 2149 flow termination is a 'last resort', which protects the 2150 network should over-admission occur, this problem is probably 2151 more important to solve than the other two. 2153 o ECMP and signalling: It is possible that, in a PCN-domain running 2154 ECMP, the signalling packets (eg RSVP, NSIS) follow a different 2155 path than the data packets, which could matter if the signalling 2156 packets are used as probes. Whether this is an issue depends on 2157 which fields the ECMP algorithm uses; if the ECMP algorithm is 2158 restricted to the source and destination IP addresses, then it 2159 will not be an issue. ECMP and signalling interactions are a 2160 specific instance of a general issue for non-traditional routing 2161 combined with resource management along a path [Hancock02]. 2163 o Tunnelling: There are scenarios where tunnelling makes it 2164 difficult to determine the path in the PCN-domain. The problem, 2165 its impact, and the potential solutions are similar to those for 2166 ECMP. 2168 o Scenarios with only one tunnel endpoint in the PCN domain may make 2169 it harder for the PCN-egress-node to gather from the signalling 2170 messages (eg RSVP, NSIS) the identity of the PCN-ingress-node. 2172 o Bi-Directional Sessions: Many applications have bi-directional 2173 sessions - hence there are two microflows that should be admitted 2174 (or terminated) as a pair - for instance a bi-directional voice 2175 call only makes sense if microflows in both directions are 2176 admitted. However, the PCN mechanisms concern admission and 2177 termination of a single flow, and coordination of the decision for 2178 both flows is a matter for the signalling protocol and out of 2179 scope of PCN. One possible example would use SIP pre-conditions. 2180 However, there are others. 2182 o Global Coordination: PCN makes its admission decision based on 2183 PCN-markings on a particular ingress-egress-aggregate. Decisions 2184 about flows through a different ingress-egress-aggregate are made 2185 independently. However, one can imagine network topologies and 2186 traffic matrices where, from a global perspective, it would be 2187 better to make a coordinated decision across all the ingress- 2188 egress-aggregates for the whole PCN-domain. For example, to block 2189 (or even terminate) flows on one ingress-egress-aggregate so that 2190 more important flows through a different ingress-egress-aggregate 2191 could be admitted. The problem may well be relatively 2192 insignificant. 2194 o Aggregate Traffic Characteristics: Even when the number of flows 2195 is stable, the traffic level through the PCN-domain will vary 2196 because the sources vary their traffic rates. PCN works best when 2197 there is not too much variability in the total traffic level at a 2198 PCN-node's interface (ie in the aggregate traffic from all 2199 sources). Too much variation means that a node may (at one 2200 moment) not be doing any PCN-marking and then (at another moment) 2201 drop packets because it is overloaded. This makes it hard to tune 2202 the admission control scheme to stop admitting new flows at the 2203 right time. Therefore the problem is more likely with fewer, 2204 burstier flows. 2206 o Flash crowds and Speed of Reaction: PCN is a measurement-based 2207 mechanism and so there is an inherent delay between packet marking 2208 by PCN-interior-nodes and any admission control reaction at PCN- 2209 boundary-nodes. For example, potentially if a big burst of 2210 admission requests occurs in a very short space of time (eg 2211 prompted by a televote), they could all get admitted before enough 2212 PCN-marks are seen to block new flows. In other words, any 2213 additional load offered within the reaction time of the mechanism 2214 must not move the PCN-domain directly from a no congestion state 2215 to overload. This 'vulnerability period' may have an impact at 2216 the signalling level, for instance QoS requests should be rate 2217 limited to bound the number of requests able to arrive within the 2218 vulnerability period. 2220 o Silent at start: after a successful admission request the source 2221 may wait some time before sending data (eg waiting for the called 2222 party to answer). Then the risk is that, in some circumstances, 2223 PCN's measurements underestimate what the pre-congestion level 2224 will be when the source does start sending data. 2226 13. Appendix B: Possible future work items 2228 13.1. Benefits 2230 We believe that the key benefits of the PCN mechanisms described in 2231 this document are that they are simple, scalable, and robust because: 2233 o Per flow state is only required at the PCN-ingress-nodes 2234 ("stateless core"). This is required for policing purposes (to 2235 prevent non-admitted PCN traffic from entering the PCN-domain) and 2236 so on. It is not generally required that other network entities 2237 are aware of individual flows (although they may be in particular 2238 deployment scenarios). 2240 o Admission control is resilient: with PCN QoS is decoupled from the 2241 routing system. Hence in general admitted flows can survive 2242 capacity, routing or topology changes without additional 2243 signalling. The PCN-admissible-rate on each link can be chosen 2244 small enough that admitted traffic can still be carried after a 2245 rerouting in most failure cases [Menth07]. This is an important 2246 feature as QoS violations in core networks due to link failures 2247 are more likely than QoS violations due to increased traffic 2248 volume [Iyer03]. 2250 o The PCN-marking behaviours only operate on the overall PCN-traffic 2251 on the link, not per flow. 2253 o The information of these measurements is signalled to the PCN- 2254 egress-nodes by the PCN-marks in the packet headers, ie [Style] 2255 "in-band". No additional signalling protocol is required for 2256 transporting the PCN-marks. Therefore no secure binding is 2257 required between data packets and separate congestion messages. 2259 o The PCN-egress-nodes make separate measurements, operating on the 2260 aggregate PCN-traffic from each PCN-ingress-node, ie not per flow. 2261 Similarly, signalling by the PCN-egress-node of PCN-feedback- 2262 information (which is used for flow admission and termination 2263 decisions) is at the granularity of the ingress-egress-aggregate. 2264 An alternative approach is that the PCN-egress-nodes monitor the 2265 PCN-traffic and signal PCN-feedback-information (which is used for 2266 flow admission and termination decisions) at the granularity of 2267 one (or a few) PCN-marks. 2269 o The admitted PCN-load is controlled dynamically. Therefore it 2270 adapts as the traffic matrix changes, and also if the network 2271 topology changes (eg after a link failure). Hence an operator can 2272 be less conservative when deploying network capacity, and less 2273 accurate in their prediction of the PCN-traffic matrix. 2275 o The termination mechanism complements admission control. It 2276 allows the network to recover from sudden unexpected surges of 2277 PCN-traffic on some links, thus restoring QoS to the remaining 2278 flows. Such scenarios are expected to be rare but not impossible. 2279 They can be caused by large network failures that redirect lots of 2280 admitted PCN-traffic to other links, or by malfunction of the 2281 measurement-based admission control in the presence of admitted 2282 flows that send for a while with an atypically low rate and then 2283 increase their rates in a correlated way. 2285 o Flow termination can also enable an operator to be less 2286 conservative when deploying network capacity. It is an 2287 alternative to running links at low utilisation in order to 2288 protect against link or node failures. This is especially the 2289 case with SRLGs (shared risk link groups, which are links that 2290 share a resource, such as a fibre, whose failure affects all those 2291 links [RFC4216]). Fully protecting traffic against a single SRLG 2292 failure requires low utilisation (~10%) of the link bandwidth on 2293 some links before failure [Charny08]. 2295 o The PCN-supportable-rate may be set below the maximum rate that 2296 PCN-traffic can be transmitted on a link, in order to trigger 2297 termination of some PCN-flows before loss (or excessive delay) of 2298 PCN-packets occurs, or to keep the maximum PCN-load on a link 2299 below a level configured by the operator. 2301 o Provisioning of the network is decoupled from the process of 2302 adding new customers. By contrast, with the DiffServ architecture 2303 [RFC2475] operators rely on subscription-time Service Level 2304 Agreements, which statically define the parameters of the traffic 2305 that will be accepted from a customer, and so the operator has to 2306 verify provision is sufficient each time a new customer is added 2307 to check that the Service Level Agreement can be fulfilled. A 2308 PCN-domain doesn't need such traffic conditioning. 2310 This section mentions some topics that are outside the PCN WG's 2311 current charter, but which have been mentioned as areas of interest. 2312 They might be work items for: the PCN WG after a future re- 2313 chartering; some other IETF WG; another standards body; an operator- 2314 specific usage that is not standardised. 2316 NOTE: it should be crystal clear that this section discusses 2317 possibilities only. 2319 The first set of possibilities relate to the restrictions described 2320 in Section 12.3: 2322 o a single PCN-domain encompasses several autonomous systems that do 2323 not trust each other, perhaps by using a mechanism like re-PCN, 2324 [Briscoe08-1]. 2326 o not all the nodes run PCN. For example, the PCN-domain is a 2327 multi-site enterprise network. The sites are connected by a VPN 2328 tunnel; although PCN doesn't operate inside the tunnel, the PCN 2329 mechanisms still work properly because of the good QoS on the 2330 virtual link (the tunnel). Another example is that PCN is 2331 deployed on the general Internet (ie widely but not universally 2332 deployed). 2334 o applying the PCN mechanisms to other types of traffic, ie beyond 2335 inelastic traffic. For instance, applying the PCN mechanisms to 2336 traffic scheduled with the Assured Forwarding per-hop behaviour. 2337 One example could be flow-rate adaptation by elastic applications 2338 that adapt according to the pre-congestion information. 2340 o the aggregation assumption doesn't hold, because the link capacity 2341 is too low. Measurement-based admission control is less accurate, 2342 with a greater risk of over-admission for instance. 2344 o the applicability of PCN mechanisms for emergency use (911, GETS, 2345 WPS, MLPP, etc.) 2347 Other possibilities include: 2349 o Probing. This is discussed in Section 13.1 below. 2351 o The PCN-domain extends to the end users. The scenario is 2352 described in [Babiarz06]. The end users need to be trusted to do 2353 their own policing. If there is sufficient traffic, then the 2354 aggregation assumption may hold. A variant is that the PCN-domain 2355 extends out as far as the LAN edge switch. 2357 o indicating pre-congestion through signalling messages rather than 2358 in-band (in the form of PCN-marked packets) 2360 o the decision-making functionality is at a centralised node rather 2361 than at the PCN-boundary-nodes. This requires that the PCN- 2362 egress-node signals PCN-feedback-information to the centralised 2363 node, and that the centralised node signals to the PCN-ingress- 2364 node the decision about admission (or termination). It may need 2365 the centralised node and the PCN-boundary-nodes to be configured 2366 with each other's addresses. The centralised case is described 2367 further in [Tsou08]. 2369 o Signalling extensions for specific protocols (eg RSVP, NSIS). For 2370 example: the details of how the signalling protocol installs the 2371 flowspec at the PCN-ingress-node for an admitted PCN-flow; and how 2372 the signalling protocol carries the PCN-feedback-information. 2373 Perhaps also for other functions such as: coping with failure of a 2374 PCN-boundary-node ([Briscoe06] considers what happens if RSVP is 2375 the QoS signalling protocol); establishing a tunnel across the 2376 PCN-domain if it is necessary to carry ECN marks transparently. 2378 o Policing by the PCN-ingress-node may not be needed if the PCN- 2379 domain can trust that the upstream network has already policed the 2380 traffic on its behalf. 2382 o PCN for Pseudowire: PCN may be used as a congestion avoidance 2383 mechanism for edge to edge pseudowire emulations [PWE3-08]. 2385 o PCN for MPLS: [RFC3270] defines how to support the DiffServ 2386 architecture in MPLS networks (Multi-protocol label switching). 2387 [RFC5129] describes how to add PCN for admission control of 2388 microflows into a set of MPLS aggregates. PCN-marking is done in 2389 MPLS's EXP field (which [MPLS08] re-names the Class of Service 2390 (CoS) field). 2392 o PCN for Ethernet: Similarly, it may be possible to extend PCN into 2393 Ethernet networks, where PCN-marking is done in the Ethernet 2394 header. NOTE: Specific consideration of this extension is outside 2395 the IETF's remit. 2397 13.2. Probing 2399 13.2.1. Introduction 2401 Probing is a potential mechanism to assist admission control. 2403 PCN's admission control, as described so far, is essentially a 2404 reactive mechanism where the PCN-egress-node monitors the pre- 2405 congestion level for traffic from each PCN-ingress-node; if the level 2406 rises then it blocks new flows on that ingress-egress-aggregate. 2407 However, it's possible that an ingress-egress-aggregate carries no 2408 traffic, and so the PCN-egress-node can't make an admission decision 2409 using the usual method described earlier. 2411 One approach is to be "optimistic" and simply admit the new flow. 2413 However it's possible to envisage a scenario where the traffic levels 2414 on other ingress-egress-aggregates are already so high that they're 2415 blocking new PCN-flows, and admitting a new flow onto this 'empty' 2416 ingress-egress-aggregate adds extra traffic onto a link that is 2417 already pre-congested - which may 'tip the balance' so that PCN's 2418 flow termination mechanism is activated or some packets are dropped. 2419 This risk could be lessened by configuring on each link sufficient 2420 'safety margin' above the PCN-threshold-rate. 2422 An alternative approach is to make PCN a more proactive mechanism. 2423 The PCN-ingress-node explicitly determines, before admitting the 2424 prospective new flow, whether the ingress-egress-aggregate can 2425 support it. This can be seen as a "pessimistic" approach, in 2426 contrast to the "optimism" of the approach above. It involves 2427 probing: a PCN-ingress-node generates and sends probe packets in 2428 order to test the pre-congestion level that the flow would 2429 experience. 2431 One possibility is that a probe packet is just a dummy data packet, 2432 generated by the PCN-ingress-node and addressed to the PCN-egress- 2433 node. 2435 13.2.2. Probing functions 2437 The probing functions are: 2439 o Make decision that probing is needed. As described above, this is 2440 when the ingress-egress-aggregate (or the ECMP path - Section 2441 12.4) carries no PCN-traffic. An alternative is always to probe, 2442 ie probe before admitting every PCN-flow. 2444 o (if required) Communicate the request that probing is needed - the 2445 PCN-egress-node signals to the PCN-ingress-node that probing is 2446 needed 2448 o (if required) Generate probe traffic - the PCN-ingress-node 2449 generates the probe traffic. The appropriate number (or rate) of 2450 probe packets will depend on the PCN-marking algorithm; for 2451 example an excess-traffic-marking algorithm generates fewer PCN- 2452 marks than a threshold-marking algorithm, and so will need more 2453 probe packets. 2455 o Forward probe packets - as far as PCN-interior-nodes are 2456 concerned, probe packets are handled the same as (ordinary data) 2457 PCN-packets, in terms of routing, scheduling and PCN-marking. 2459 o Consume probe packets - the PCN-egress-node consumes probe packets 2460 to ensure that they don't travel beyond the PCN-domain. 2462 13.2.3. Discussion of rationale for probing, its downsides and open 2463 issues 2465 It is an unresolved question whether probing is really needed, but 2466 two viewpoints have been put forward as to why it is useful. The 2467 first is perhaps the most obvious: there is no PCN-traffic on the 2468 ingress-egress-aggregate. The second assumes that multipath routing 2469 ECMP is running in the PCN-domain. We now consider each in turn. 2471 The first viewpoint assumes the following: 2473 o There is no PCN-traffic on the ingress-egress-aggregate (so a 2474 normal admission decision cannot be made). 2476 o Simply admitting the new flow has a significant risk of leading to 2477 overload: packets dropped or flows terminated. 2479 On the former bullet, [Eardley07] suggests that, during the future 2480 busy hour of a national network with about 100 PCN-boundary-nodes, 2481 there are likely to be significant numbers of aggregates with very 2482 few flows under nearly all circumstances. 2484 The latter bullet could occur if new flows start on many of the empty 2485 ingress-egress-aggregates, which together overload a link in the PCN- 2486 domain. To be a problem this would probably have to happen in a 2487 short time period (flash crowd) because, after the reaction time of 2488 the system, other (non-empty) ingress-egress-aggregates that pass 2489 through the link will measure pre-congestion and so block new flows. 2490 Also, flows naturally end anyway. 2492 The downsides of probing for this viewpoint are: 2494 o Probing adds delay to the admission control process. 2496 o Sufficient probing traffic has to be generated to test the pre- 2497 congestion level of the ingress-egress-aggregate. But the probing 2498 traffic itself may cause pre-congestion, causing other PCN-flows 2499 to be blocked or even terminated - and in the flash crowd scenario 2500 there will be probing on many ingress-egress-aggregates. 2502 The second viewpoint applies in the case where there is multipath 2503 routing (ECMP) in the PCN-domain. Note that ECMP is often used on 2504 core networks. There are two possibilities: 2506 (1) If admission control is based on measurements of the ingress- 2507 egress-aggregate, then the viewpoint that probing is useful assumes: 2509 o there's a significant chance that the traffic is unevenly balanced 2510 across the ECMP paths, and hence there's a significant risk of 2511 admitting a flow that should be blocked (because it follows an 2512 ECMP path that is pre-congested) or blocking a flow that should be 2513 admitted. 2515 o Note: [Charny07-3] suggests unbalanced traffic is quite possible, 2516 even with quite a large number of flows on a PCN-link (eg 1000) 2517 when Assumption 3 (aggregation) is likely to be satisfied. 2519 (2) If admission control is based on measurements of pre-congestion 2520 on specific ECMP paths, then the viewpoint that probing is useful 2521 assumes: 2523 o There is no PCN-traffic on the ECMP path on which to base an 2524 admission decision. 2526 o Simply admitting the new flow has a significant risk of leading to 2527 overload. 2529 o The PCN-egress-node can match a packet to an ECMP path. 2531 o Note: This is similar to the first viewpoint and so similarly 2532 could occur in a flash crowd if a new flow starts more-or-less 2533 simultaneously on many of the empty ECMP paths. Because there are 2534 several (sometimes many) ECMP paths between each pair of PCN- 2535 boundary-nodes, it's presumably more likely that an ECMP path is 2536 'empty' than an ingress-egress-aggregate is. To constrain the 2537 number of ECMP paths, a few tunnels could be set-up between each 2538 pair of PCN-boundary-nodes. Tunnelling also solves the issue in 2539 the bullet immediately above (which is otherwise hard because an 2540 ECMP routing decision is made independently on each node). 2542 The downsides of probing for this viewpoint are: 2544 o Probing adds delay to the admission control process. 2546 o Sufficient probing traffic has to be generated to test the pre- 2547 congestion level of the ECMP path. But there's the risk that the 2548 probing traffic itself may cause pre-congestion, causing other 2549 PCN-flows to be blocked or even terminated. 2551 o The PCN-egress-node needs to consume the probe packets to ensure 2552 they don't travel beyond the PCN-domain, since they might confuse 2553 the destination end node. This is non-trivial, since probe 2554 packets are addressed to the destination end node, in order to 2555 test the relevant ECMP path (ie they are not addressed to the PCN- 2556 egress-node, unlike the first viewpoint above). 2558 The open issues associated with this viewpoint include: 2560 o What rate and pattern of probe packets does the PCN-ingress-node 2561 need to generate, so that there's enough traffic to make the 2562 admission decision? 2564 o What difficulty does the delay (whilst probing is done), and 2565 possible packet drops, cause applications? 2567 o Can the delay be alleviated by automatically and periodically 2568 probing on the ingress-egress-aggregate? Or does this add too 2569 much overhead? 2571 o Are there other ways of dealing with the flash crowd scenario? 2572 For instance, by limiting the rate at which new flows are 2573 admitted; or perhaps by a PCN-egress-node blocking new flows on 2574 its empty ingress-egress-aggregates when its non-empty ones are 2575 pre-congested. 2577 o (Second viewpoint only) How does the PCN-egress-node disambiguate 2578 probe packets from data packets (so it can consume the former)? 2579 The PCN-egress-node must match the characteristic setting of 2580 particular bits in the probe packet's header or body - but these 2581 bits must not be used by any PCN-interior-node's ECMP algorithm. 2582 In the general case this isn't possible, but it should be possible 2583 for a typical ECMP algorithm (which examines: the source and 2584 destination IP addresses and port numbers, the protocol ID, and 2585 the DSCP). 2587 14. References 2589 14.1. Normative References 2591 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2592 "Definition of the Differentiated Services Field (DS 2593 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2594 December 1998. 2596 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 2597 J., Courtney, W., Davari, S., Firoiu, V., and D. 2598 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 2599 Behavior)", RFC 3246, March 2002. 2601 14.2. Informative References 2603 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 2604 Services in the Internet Architecture: an Overview", 2605 RFC 1633, June 1994. 2607 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 2608 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2609 Functional Specification", RFC 2205, September 1997. 2611 [RFC2211] Wroclawski, J., "Specification of the Controlled-Load 2612 Network Element Service", RFC 2211, September 1997. 2614 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 2615 and W. Weiss, "An Architecture for Differentiated 2616 Services", RFC 2475, December 1998. 2618 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 2619 Authentication", RFC 2747, January 2000. 2621 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 2622 for Policy-based Admission Control", RFC 2753, 2623 January 2000. 2625 [RFC2983] Black, D., "Differentiated Services and Tunnels", 2626 RFC 2983, October 2000. 2628 [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., 2629 Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. 2630 Felstaine, "A Framework for Integrated Services Operation 2631 over Diffserv Networks", RFC 2998, November 2000. 2633 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2634 of Explicit Congestion Notification (ECN) to IP", 2635 RFC 3168, September 2001. 2637 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 2638 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 2639 Protocol Label Switching (MPLS) Support of Differentiated 2640 Services", RFC 3270, May 2002. 2642 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 2643 Metric for IP Performance Metrics (IPPM)", RFC 3393, 2644 November 2002. 2646 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 2647 Architecture for Describing Simple Network Management 2648 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 2649 December 2002. 2651 [RFC3726] Brunner, M., "Requirements for Signaling Protocols", 2652 RFC 3726, April 2004. 2654 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 2655 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 2656 November 2005. 2658 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2659 Internet Protocol", RFC 4301, December 2005. 2661 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2662 RFC 4303, December 2005. 2664 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 2665 Guidelines for DiffServ Service Classes", RFC 4594, 2666 August 2006. 2668 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 2669 Zekauskas, "A One-way Active Measurement Protocol 2670 (OWAMP)", RFC 4656, September 2006. 2672 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 2673 Explicit Congestion Notification (ECN) Field", BCP 124, 2674 RFC 4774, November 2006. 2676 [RFC4778] Kaeo, M., "Operational Security Current Practices in 2677 Internet Service Provider Environments", RFC 4778, 2678 January 2007. 2680 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 2681 Marking in MPLS", RFC 5129, January 2008. 2683 [P.800] "Methods for subjective determination of transmission 2684 quality", ITU-T Recommendation P.800, August 1996. 2686 [Y.1541] "Network Performance Objectives for IP-based Services", 2687 ITU-T Recommendation Y.1541, February 2006. 2689 [MPLS08] "Multi-Protocol Label Switching (MPLS) label stack entry: 2690 "EXP" field renamed to "Traffic Class" field (work in 2691 progress)", Dec 2008. 2693 [PCN08-1] "Baseline Encoding and Transport of Pre-Congestion 2694 Information (work in progress)", Oct 2008. 2696 [PCN08-2] "Marking behaviour of PCN-nodes (work in progress)", 2697 Oct 2008. 2699 [PWE3-08] "Pseudowire Congestion Control Framework (work in 2700 progress)", May 2008. 2702 [Babiarz06] 2703 "SIP Controlled Admission and Preemption (work in 2704 progress)", Oct 2006. 2706 [Behringer07] 2707 "Applicability of Keying Methods for RSVP Security (work 2708 in progress)", Nov 2007. 2710 [Briscoe06] 2711 "An edge-to-edge Deployment Model for Pre-Congestion 2712 Notification: Admission Control over a DiffServ Region 2713 (work in progress)", October 2006. 2715 [Briscoe08-1] 2716 "Emulating Border Flow Policing using Re-PCN on Bulk Data 2717 (work in progress)", Sept 2008. 2719 [Briscoe08-2] 2720 "Layered Encapsulation of Congestion Notification (work in 2721 progress)", July 2008. 2723 [Charny07-1] 2724 "Comparison of Proposed PCN Approaches (work in 2725 progress)", November 2007. 2727 [Charny07-2] 2728 "Pre-Congestion Notification Using Single Marking for 2729 Admission and Termination (work in progress)", 2730 November 2007. 2732 [Charny07-3] 2733 "Email to PCN WG mailing list", November 2007, . 2736 [Charny08] 2737 "Email to PCN WG mailing list", March 2008, . 2740 [Eardley07] 2741 "Email to PCN WG mailing list", October 2007, . 2744 [Hancock02] 2745 "Slide 14 of 'NSIS: An Outline Framework for QoS 2746 Signalling'", May 2002, . 2749 [Iyer03] "An approach to alleviate link overload as observed on an 2750 IP backbone", IEEE INFOCOM , 2003, 2751 . 2753 [Lefaucheur06] 2754 "RSVP Extensions for Admission Control over Diffserv using 2755 Pre-congestion Notification (PCN) (work in progress)", 2756 June 2006. 2758 [Menth07] "PCN-Based Resilient Network Admission Control: The Impact 2759 of a Single Bit"", Technical Report , 2007, . 2763 [Menth08-1] 2764 "Edge-Assisted Marked Flow Termination (work in 2765 progress)", February 2008. 2767 [Menth08-2] 2768 "PCN Encoding for Packet-Specific Dual Marking (PSDM) 2769 (work in progress)", July 2008. 2771 [Menth08-3] 2772 "PCN-Based Admission Control and Flow Termination", 2008, 2773 . 2776 [Moncaster08] 2777 "A three state extended PCN encoding scheme (work in 2778 progress)", June 2008. 2780 [Sarker08] 2781 "Usecases and Benefits of end to end ECN support in PCN 2782 Domains (work in progress)", November 2008. 2784 [Songhurst06] 2785 "Guaranteed QoS Synthesis for Admission Control with 2786 Shared Capacity", BT Technical Report TR-CXR9-2006-001, 2787 Feburary 2006, . 2790 [Style] "Guardian Style", Note: This document uses the 2791 abbreviations 'ie' and 'eg' (not 'i.e.' and 'e.g.'), as in 2792 many style guides, eg, 2007, 2793 . 2795 [Tsou08] "Applicability Statement for the Use of Pre-Congestion 2796 Notification in a Resource-Controlled Network (work in 2797 progress)", November 2008. 2799 [Westberg08] 2800 "LC-PCN: The Load Control PCN Solution (work in 2801 progress)", November 2008. 2803 Author's Address 2805 Philip Eardley 2806 BT 2807 B54/77, Sirius House Adastral Park Martlesham Heath 2808 Ipswich, Suffolk IP5 3RE 2809 United Kingdom 2811 Email: philip.eardley@bt.com