idnits 2.17.1 draft-ietf-pcn-architecture-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2410. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 755: '...fServ Codepoints SHOULD be chosen that...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2008) is 5763 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-ietf-pwe3-congestion-frmwk-01 == Outdated reference: A later version (-05) exists of draft-westberg-pcn-load-control-03 == Outdated reference: A later version (-03) exists of draft-briscoe-re-pcn-border-cheat-01 == Outdated reference: A later version (-01) exists of draft-moncaster-pcn-3-state-encoding-00 == Outdated reference: A later version (-01) exists of draft-tsou-pcn-racf-applic-00 == Outdated reference: A later version (-02) exists of draft-sarker-pcn-ecn-pcn-usecases-01 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 7 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 July 14, 2008 5 Intended status: Informational 6 Expires: January 15, 2009 8 Pre-Congestion Notification Architecture 9 draft-ietf-pcn-architecture-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 15, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 The purpose of this document is to describe a general architecture 43 for flow admission and termination based on pre-congestion 44 information in order to protect the quality of service of established 45 inelastic flows within a single DiffServ domain. 47 Status 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 4. Deployment scenarios . . . . . . . . . . . . . . . . . . . . . 8 55 5. Assumptions and constraints on scope . . . . . . . . . . . . . 10 56 5.1. Assumption 1: Trust and support of PCN - controlled 57 environment . . . . . . . . . . . . . . . . . . . . . . . 11 58 5.2. Assumption 2: Real-time applications . . . . . . . . . . . 11 59 5.3. Assumption 3: Many flows and additional load . . . . . . . 12 60 5.4. Assumption 4: Emergency use out of scope . . . . . . . . . 12 61 6. High-level functional architecture . . . . . . . . . . . . . . 12 62 6.1. Flow admission . . . . . . . . . . . . . . . . . . . . . . 14 63 6.2. Flow termination . . . . . . . . . . . . . . . . . . . . . 15 64 6.3. Flow admission and flow termination when there are 65 only two PCN encoding states . . . . . . . . . . . . . . . 16 66 6.4. Information transport . . . . . . . . . . . . . . . . . . 16 67 6.5. PCN-traffic . . . . . . . . . . . . . . . . . . . . . . . 17 68 6.6. Backwards compatibility . . . . . . . . . . . . . . . . . 17 69 7. Detailed Functional architecture . . . . . . . . . . . . . . . 18 70 7.1. PCN-interior-node functions . . . . . . . . . . . . . . . 19 71 7.2. PCN-ingress-node functions . . . . . . . . . . . . . . . . 19 72 7.3. PCN-egress-node functions . . . . . . . . . . . . . . . . 20 73 7.4. Other admission control functions . . . . . . . . . . . . 20 74 7.5. Other flow termination functions . . . . . . . . . . . . . 21 75 7.6. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 22 76 7.7. Tunnelling . . . . . . . . . . . . . . . . . . . . . . . . 23 77 7.8. Fault handling . . . . . . . . . . . . . . . . . . . . . . 24 78 8. Design goals and challenges . . . . . . . . . . . . . . . . . 24 79 9. Operations and Management . . . . . . . . . . . . . . . . . . 27 80 9.1. Configuration OAM . . . . . . . . . . . . . . . . . . . . 27 81 9.1.1. System options . . . . . . . . . . . . . . . . . . . . 28 82 9.1.2. Parameters . . . . . . . . . . . . . . . . . . . . . . 29 83 9.2. Performance & Provisioning OAM . . . . . . . . . . . . . . 31 84 9.3. Accounting OAM . . . . . . . . . . . . . . . . . . . . . . 32 85 9.4. Fault OAM . . . . . . . . . . . . . . . . . . . . . . . . 32 86 9.5. Security OAM . . . . . . . . . . . . . . . . . . . . . . . 33 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 88 11. Security considerations . . . . . . . . . . . . . . . . . . . 34 89 12. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 35 90 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 91 14. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 36 92 15. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 93 15.1. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 36 94 15.2. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 37 95 15.3. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 38 96 15.4. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 39 97 16. Appendix A: Possible work items beyond the scope of the 98 current PCN WG Charter . . . . . . . . . . . . . . . . . . . . 40 99 17. Appendix B: Probing . . . . . . . . . . . . . . . . . . . . . 42 100 17.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 42 101 17.2. Probing functions . . . . . . . . . . . . . . . . . . . . 43 102 17.3. Discussion of rationale for probing, its downsides and 103 open issues . . . . . . . . . . . . . . . . . . . . . . . 43 104 18. Informative References . . . . . . . . . . . . . . . . . . . . 46 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51 106 Intellectual Property and Copyright Statements . . . . . . . . . . 52 108 1. Introduction 110 The purpose of this document is to describe a general architecture 111 for flow admission and termination based on (pre-) congestion 112 information in order to protect the quality of service of flows 113 within a DiffServ domain [RFC2475]. This document defines an 114 architecture for implementing two mechanisms to protect the quality 115 of service of established inelastic flows within a single DiffServ 116 domain, where all boundary and interior nodes are PCN-enabled and 117 trust each other for correct PCN operation. Flow admission control 118 determines whether a new flow should be admitted, in order to protect 119 the QoS of existing PCN-flows in normal circumstances. However, in 120 abnormal circumstances, for instance a disaster affecting multiple 121 nodes and causing traffic re-routes, then the QoS on existing PCN- 122 flows may degrade even though care was exercised when admitting those 123 flows. Therefore we also propose a mechanism for flow termination, 124 which removes enough traffic in order to protect the QoS of the 125 remaining PCN-flows. 127 As a fundamental building block to enable these two mechanisms, PCN- 128 interior-nodes generate, encode and transport pre-congestion 129 information towards the PCN-egress-nodes. Two rates, a PCN- 130 threshold-rate and a PCN-excess-rate, are associated with each link 131 of the PCN-domain. Each rate is used by a marking behaviour that 132 determines how and when PCN-packets are marked, and how the markings 133 are encoded in packet headers. Overall the aim is to enable PCN- 134 nodes to give an "early warning" of potential congestion before there 135 is any significant build-up of PCN-packets in the queue. 137 PCN-boundary-nodes convert measurements of these PCN-markings into 138 decisions about flow admission and termination. The admission 139 control mechanism limits the PCN-traffic on each link to *roughly* 140 its PCN-threshold-rate and the flow termination mechanism limits the 141 PCN-traffic on each link to *roughly* its PCN-excess-rate. 143 This document describes the PCN architecture and outlines some 144 benefits, deployment scenarios, assumptions and terminology for PCN. 145 The behaviour of PCN-interior-nodes is standardised in three 146 documents, which are summarised in this 147 document.[I-D.eardley-pcn-marking-behaviour] standardises the two 148 marking behaviours of PCN-nodes: threshold marking and excess traffic 149 marking. Threshold marking marks all PCN-packets if the PCN traffic 150 rate is greater than a first configured rate, "PCN-threshold-rate". 151 Excess traffic marking marks a proportion of PCN-packets, such that 152 the amount marked equals the traffic rate in excess of a second 153 configured rate, "PCN-excess-rate". PCN encoding uses a combination 154 of the DSCP field and ECN field in the IP header to indicate that a 155 packet is a PCN-packet and whether it is PCN-marked. 157 [I-D.moncaster-pcn-baseline-encoding] standardises two PCN encoding 158 states (PCN-marked and not PCN-marked) whilst 159 [I-D.moncaster-pcn-3-state-encoding] standardises an extended scheme 160 with three encoding states (threshold-marked, excess-traffic-marked, 161 not PCN-marked) but requires an extra DiffServ codepoint. PCN 162 therefore defines semantics for the ECN field different from the 163 default semantics of [RFC3168]; PCN's encoding has been chosen to 164 meet the guidelines of BCP124, [RFC4774]. The behaviour of PCN- 165 boundary-nodes is described in Informational documents. Several 166 possibilities are outlined in this document; detailed descriptions 167 and comparisons are in [I-D.charny-pcn-comparison] and [Menth08]. 169 2. Terminology 171 o PCN-domain: a PCN-capable domain; a contiguous set of PCN-enabled 172 nodes that perform DiffServ scheduling; the complete set of PCN- 173 nodes whose PCN-marking can in principle influence decisions about 174 flow admission and termination for the PCN-domain, including the 175 PCN-egress-nodes which measure these PCN-marks. 177 o PCN-boundary-node: a PCN-node that connects one PCN-domain to a 178 node either in another PCN-domain or in a non PCN-domain. 180 o PCN-interior-node: a node in a PCN-domain that is not a PCN- 181 boundary-node. 183 o PCN-node: a PCN-boundary-node or a PCN-interior-node 185 o PCN-egress-node: a PCN-boundary-node in its role in handling 186 traffic as it leaves a PCN-domain. 188 o PCN-ingress-node: a PCN-boundary-node in its role in handling 189 traffic as it enters a PCN-domain. 191 o PCN-traffic, PCN-packets, PCN-BA: a PCN-domain carries traffic of 192 different DiffServ behaviour aggregates (BAs) [RFC2475]. The 193 PCN-BA uses the PCN mechanisms to carry PCN-traffic and the 194 corresponding packets are PCN-packets. The same network will 195 carry traffic of other DiffServ BAs. The PCN-BA is distinguished 196 by a combination of the DiffServ codepoint (DSCP) and ECN fields; 197 note that a packet that shares the same DSCP as PCN-traffic but 198 its ECN field is 00 (Not ECT) is not part of the PCN-BA. 200 o PCN-flow: the unit of PCN-traffic that the PCN-boundary-node 201 admits (or terminates); the unit could be a single microflow (as 202 defined in [RFC2475]) or some identifiable collection of 203 microflows. 205 o Ingress-egress-aggregate: The collection of PCN-packets from all 206 PCN-flows that travel in one direction between a specific pair of 207 PCN-boundary-nodes. 209 o PCN-threshold-rate: a reference rate configured for each link in 210 the PCN-domain, which is lower than the PCN-excess-rate. It is 211 used by a marking behaviour that determines whether a packet 212 should be PCN-marked with a first encoding, "threshold-marked". 213 It's roughly the rate up to which PCN admission control should 214 accept new flows. 216 o PCN-excess-rate: a reference rate configured for each link in the 217 PCN-domain, which is higher than the PCN-threshold-rate. It is 218 used by a marking behaviour that determines whether a packet 219 should be PCN-marked with a second encoding, "excess-traffic- 220 marked". It's roughly that rate down to which flow termination 221 should, if necessary, terminate already admitted flows. 223 o Threshold-marking: a PCN-marking behaviour with the objective that 224 all PCN-traffic is marked if the PCN-traffic exceeds the PCN- 225 threshold-rate. 227 o Excess-traffic-marking: a PCN-marking behaviour with the objective 228 that the amount of PCN-traffic that is PCN-marked is equal to the 229 amount that exceeds the PCN-excess-rate. 231 o Pre-congestion: a condition of a link within a PCN-domain in which 232 the PCN-node performs PCN-marking, in order to provide an "early 233 warning" of potential congestion before there is any significant 234 build-up of PCN-packets in the real queue. (Hence, by analogy 235 with ECN we call our mechanism Pre-Congestion Notification.) 237 o PCN-marking: the process of setting the header in a PCN-packet 238 based on defined rules, in reaction to pre-congestion; either 239 threshold-marking or excess-traffic-marking. 241 o PCN-feedback-information: information signalled by a PCN-egress- 242 node to a PCN-ingress-node or central control node, which is 243 needed for the flow admission and flow termination mechanisms. 245 3. Benefits 247 We believe that the key benefits of the PCN mechanisms described in 248 this document are that they are simple, scalable, and robust because: 250 o Per flow state is only required at the PCN-ingress-nodes 251 ("stateless core"). This is required for policing purposes (to 252 prevent non-admitted PCN traffic from entering the PCN-domain) and 253 so on. It is not generally required that other network entities 254 are aware of individual flows (although they may be in particular 255 deployment scenarios). 257 o Admission control is resilient: PCN's QoS is decoupled from the 258 routing system; hence in general admitted flows can survive 259 capacity, routing or topology changes without additional 260 signalling, and they don't have to be told (or learn) about such 261 changes. The PCN-threshold-rate on each PCN-node can be chosen 262 small enough that admitted traffic can still be carried after a 263 rerouting in most failure cases [Menth]. This is an important 264 feature as QoS violations in core networks due to link failures 265 are more likely than QoS violations due to increased traffic 266 volume [Iyer]. 268 o The PCN-marking behaviours only operate on the overall PCN-traffic 269 on the link, not per flow. 271 o The information of these measurements is signalled to the PCN- 272 egress-nodes by the PCN-marks in the packet headers, ie "in-band". 273 No additional signalling protocol is required for transporting the 274 PCN-marks. Therefore no secure binding is required between data 275 packets and separate congestion messages. 277 o The PCN-egress-nodes make separate measurements, operating on the 278 aggregate PCN-traffic from each PCN-ingress-node, ie not per flow. 279 Similarly, signalling by the PCN-egress-node of PCN-feedback- 280 information (which is used for flow admission and termination 281 decisions) is at the granularity of the ingress-egress-aggregate. 282 An alternative approach is that the PCN-egress-nodes monitor the 283 PCN-traffic and signal PCN-feedback-information (which is used for 284 flow admission and termination decisions) at the granularity of 285 one (or a few) PCN-marks. 287 o The admitted PCN-load is controlled dynamically. Therefore it 288 adapts as the traffic matrix changes, and also if the network 289 topology changes (eg after a link failure). Hence an operator can 290 be less conservative when deploying network capacity, and less 291 accurate in their prediction of the PCN-traffic matrix. 293 o The termination mechanism complements admission control. It 294 allows the network to recover from sudden unexpected surges of 295 PCN-traffic on some links, thus restoring QoS to the remaining 296 flows. Such scenarios are expected to be rare but not impossible. 297 They can be caused by large network failures that redirect lots of 298 admitted PCN-traffic to other links, or by malfunction of the 299 measurement-based admission control in the presence of admitted 300 flows that send for a while with an atypically low rate and then 301 increase their rates in a correlated way. 303 o Flow termination can also enable an operator to be less 304 conservative when deploying network capacity. It is an 305 alternative to running links at low utilisation in order to 306 protect against link or node failures. This is especially the 307 case with SRLGs (shared risk link groups, which are links that 308 share a resource, such as a fibre, whose failure affects all those 309 links [RFC4216]. A requirement to fully protect traffic against a 310 single SRLG failure requires low utilisation (~10%) of the link 311 bandwidth on some links before failure [PCN-email-SRLG]. 313 o The PCN-excess-rate may be set below the maximum rate that PCN- 314 traffic can be transmitted on a link, in order to trigger 315 termination of some PCN-flows before loss (or excessive delay) of 316 PCN-packets occurs, or to keep the maximum PCN-load on a link 317 below a level configured by the operator. 319 o Provisioning of the network is decoupled from the process of 320 adding new customers. By contrast, with the DiffServ architecture 321 [RFC2475] operators rely on subscription-time Service Level 322 Agreements that statically define the parameters of the traffic 323 that will be accepted from a customer, and so the operator has to 324 run the provisioning process each time a new customer is added to 325 check that the Service Level Agreement can be fulfilled. A PCN- 326 domain doesn't need such traffic conditioning. 328 4. Deployment scenarios 330 Operators of networks will want to use the PCN mechanisms in various 331 arrangements, for instance depending on how they are performing 332 admission control outside the PCN-domain (users after all are 333 concerned about QoS end-to-end), what their particular goals and 334 assumptions are, how many PCN encoding states are available, and so 335 on. 337 From the perspective of the outside world, a PCN-domain essentially 338 looks like a DiffServ domain. PCN-traffic is either transported 339 across it transparently or policed at the PCN-ingress-node (ie 340 dropped or carried at a lower QoS). A couple of differences are 341 that: PCN-traffic has better QoS guarantees than normal DiffServ 342 traffic (because PCN's mechanisms better protect the QoS of admitted 343 flows); and in rare circumstances (failures), on the one hand some 344 PCN-flows may get terminated, but on the other hand other flows will 345 get their QoS restored. Non PCN-traffic is treated transparently, ie 346 the PCN-domain is a normal DiffServ domain. 348 An operator may choose to deploy either admission control or flow 349 termination or both. Although designed to work together, they are 350 independent mechanisms, and the use of one does not require or 351 prevent the use of the other. 353 For example, an operator could use just PCN's admission control, 354 solving heavy congestion (caused by re-routing) by 'just waiting' - 355 as sessions end, PCN-traffic naturally reduces, and meanwhile the 356 admission control mechanism will prevent admission of new flows that 357 use the affected links. So the PCN-domain will naturally return to 358 normal operation, but with reduced capacity. The drawback of this 359 approach would be that until PCN-traffic naturally departs to relieve 360 the congestion, all PCN-flows as well as lower priority services will 361 be adversely affected. 363 Another example is that an operator could just rely for admission 364 control on statically provisioned capacity per PCN-ingress-node 365 (regardless of the PCN-egress-node of a flow), as is typical in the 366 hose model of the DiffServ architecture [RFC2475]. Such traffic 367 conditioning agreements can lead to focused overload: many flows 368 happen to focus on a particular link and then all flows through the 369 congested link fail catastrophically. PCN's flow termination 370 mechanism could then be used to counteract such a problem. 372 The possibility of deploying just one of PCN's flow admission and 373 termination mechanisms is certainly an option when only two PCN 374 encoding states are available (PCN-marked and not PCN-marked), as in 375 [I-D.moncaster-pcn-baseline-encoding]. Another option in this 376 circumstance is to trigger both admission control and flow 377 termination from the single type of PCN-marking; the main downside is 378 that admission control is less accurate. 380 Within the PCN-domain there is some flexibility about where the 381 decision making functionality is located. For admission control, the 382 most natural place is the PCN-ingress-node. For flow termination, 383 whether the PCN-ingress-node or PCN-egress-node is more natural 384 depends on the mechanism used to convert packet markings into a flow 385 termination decision. These possibilities are outlined more later 386 and also discussed elsewhere, such as in [Menth08]. Another 387 possibility is that the decision making functionality is at some 388 central control node. This is briefly discussed in Appendix A and 389 described in [I-D.tsou-pcn-racf-applic]. 391 The flow admission and termination decisions need to be enforced 392 through per-flow policing by the PCN-ingress-nodes. If there are 393 several PCN-domains on the end-to-end path then each needs to police 394 at its PCN-ingress-nodes. One exception is if the operator runs both 395 the access network (not a PCN-domain) and the core network (a PCN- 396 domain); per flow policing could be devolved to the access network 397 and not done at the PCN-ingress-node. Note: to aid readability, the 398 rest of this draft assumes that policing is done by the PCN-ingress- 399 nodes. 401 PCN admission control has to fit with the overall approach to 402 admission control. For instance [I-D.briscoe-tsvwg-cl-architecture] 403 describes the case where RSVP signalling runs end-to-end. The PCN- 404 domain is a single RSVP hop, ie only the PCN-boundary-nodes process 405 RSVP messages, with RSVP messages processed on each hop outside the 406 PCN-domain, as in IntServ over DiffServ [RFC2998]. It would also be 407 possible for the RSVP signalling to be originated and/or terminated 408 by proxies, with application-layer signalling between the end user 409 and the proxy (eg SIP signalling with a home hub). A similar example 410 would use NSIS signalling is used instead of RSVP. 412 It is possible that a user wants its inelastic traffic to use the PCN 413 mechanisms but also react to ECN marking outside the PCN-domain 414 [I-D.sarker-pcn-ecn-pcn-usecases]. Two ways to do this are to tunnel 415 all PCN-packets across the PCN-domain, so that the ECN marks is 416 carried transparently across the PCN-domain, or to use the three 417 state PCN encoding [I-D.moncaster-pcn-3-state-encoding]. This is 418 discussed further in Section Section 7. 420 Some possible deployment models that are outside the current PCN WG 421 Charter are outlined in Appendix A. 423 5. Assumptions and constraints on scope 425 The scope of PCN is, at least initially (see Appendix A), restricted 426 by the following assumptions: 428 1. these components are deployed in a single DiffServ domain, within 429 which all PCN-nodes are PCN-enabled and trust each other for 430 truthful PCN-marking and transport 432 2. all flows handled by these mechanisms are inelastic and 433 constrained to a known peak rate through policing or shaping 435 3. the number of PCN-flows across any potential bottleneck link is 436 sufficiently large that stateless, statistical mechanisms can be 437 effective. To put it another way, the aggregate bit rate of PCN- 438 traffic across any potential bottleneck link needs to be 439 sufficiently large relative to the maximum additional bit rate 440 added by one flow. This is the basic assumption of measurement- 441 based admission control. 443 4. PCN-flows may have different precedence, but the applicability of 444 the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) 445 is out of scope. 447 5.1. Assumption 1: Trust and support of PCN - controlled environment 449 We assume that the PCN-domain is a controlled environment, ie all the 450 nodes in a PCN-domain run PCN and trust each other. There are 451 several reasons for proposing this assumption: 453 o The PCN-domain has to be encircled by a ring of PCN-boundary- 454 nodes, otherwise traffic could enter a PCN BA without being 455 subject to admission control, which would potentially degrade the 456 QoS of existing PCN-flows. 458 o Similarly, a PCN-boundary-node has to trust that all the PCN-nodes 459 mark PCN-traffic consistently. A node not doing PCN-marking 460 wouldn't be able to alert when it suffered pre-congestion, which 461 potentially would lead to too many PCN-flows being admitted (or 462 too few being terminated). Worse, a rogue node could perform 463 various attacks, as discussed in the Security Considerations 464 section. 466 One way of assuring the above two points is that the entire PCN- 467 domain is run by a single operator. Another possibility is that 468 there are several operators but they trust each other to a sufficient 469 level, in their handling of PCN-traffic. 471 Note: All PCN-nodes need to be trustworthy. However if it's known 472 that an interface cannot become pre-congested then it's not strictly 473 necessary for it to be capable of PCN-marking. But this must be 474 known even in unusual circumstances, eg after the failure of some 475 links. 477 5.2. Assumption 2: Real-time applications 479 We assume that any variation of source bit rate is independent of the 480 level of pre-congestion. We assume that PCN-packets come from real 481 time applications generating inelastic traffic, ie it sends packets 482 at the rate the codec produces them, regardless of the availability 483 of capacity [RFC4594]. For example, voice and video requiring low 484 delay, jitter and packet loss, the Controlled Load Service, 485 [RFC2211], and the Telephony service class, [RFC4594]. This 486 assumption is to help focus the effort where it looks like PCN would 487 be most useful, ie the sorts of applications where per flow QoS is a 488 known requirement. In other words we focus on PCN providing a 489 benefit to inelastic traffic (PCN may or may not provide a benefit to 490 other types of traffic). For instance, the impact of this assumption 491 would be to guide simulations work. 493 As a consequence, it is assumed that PCN-marking is being applied to 494 traffic scheduled with the expedited forwarding per-hop behaviour, 495 [RFC3246], or traffic with similar characteristics. 497 5.3. Assumption 3: Many flows and additional load 499 We assume that there are many PCN-flows on any bottleneck link in the 500 PCN-domain (or, to put it another way, the aggregate bit rate of PCN- 501 traffic across any potential bottleneck link is sufficiently large 502 relative to the maximum additional bit rate added by one PCN-flow). 503 Measurement-based admission control assumes that the present is a 504 reasonable prediction of the future: the network conditions are 505 measured at the time of a new flow request, however the actual 506 network performance must be OK during the call some time later. One 507 issue is that if there are only a few variable rate flows, then the 508 aggregate traffic level may vary a lot, perhaps enough to cause some 509 packets to get dropped. If there are many flows then the aggregate 510 traffic level should be statistically smoothed. How many flows is 511 enough depends on a number of things such as the variation in each 512 flow's rate, the total rate of PCN-traffic, and the size of the 513 "safety margin" between the traffic level at which we start 514 admission-marking and at which packets are dropped or significantly 515 delayed. 517 We do not make explicit assumptions on how many PCN-flows are in each 518 ingress-egress-aggregate. Performance evaluation work may clarify 519 whether it is necessary to make any additional assumption on 520 aggregation at the ingress-egress-aggregate level. 522 5.4. Assumption 4: Emergency use out of scope 524 PCN-flows may have different precedence, but the applicability of the 525 PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc) is out 526 of scope for consideration by the PCN WG. 528 6. High-level functional architecture 530 The high-level approach is to split functionality between: 532 o PCN-interior-nodes 'inside' the PCN-domain, which monitor their 533 own state of pre-congestion and mark PCN-packets if appropriate. 534 They are not flow-aware, nor aware of ingress-egress-aggregates. 535 The functionality is also done by PCN-ingress-nodes for their 536 outgoing interfaces (ie those 'inside' the PCN-domain). 538 o PCN-boundary-nodes at the edge of the PCN-domain, which control 539 admission of new PCN-flows and termination of existing PCN-flows, 540 based on information from PCN-interior-nodes. This information is 541 in the form of the PCN-marked data packets (which are intercepted 542 by the PCN-egress-nodes) and not signalling messages. Generally 543 PCN-ingress-nodes are flow-aware. 545 The aim of this split is to keep the bulk of the network simple, 546 scalable and robust, whilst confining policy, application-level and 547 security interactions to the edge of the PCN-domain. For example the 548 lack of flow awareness means that the PCN-interior-nodes don't care 549 about the flow information associated with the PCN-packets that they 550 carry, nor do the PCN-boundary-nodes care about which PCN-interior- 551 nodes its flows traverse. The objective is to standardise PCN- 552 marking behaviour, but potentially produce more than one 553 (informational) RFC describing how PCN-boundary-nodes react to PCN- 554 marks. 556 In order to generate information about the current state of the PCN- 557 domain, each PCN-node PCN-marks packets if it is "pre-congested". 558 Exactly when a PCN-node decides if it is "pre-congested" (the 559 algorithm) and exactly how packets are "PCN-marked" (the encoding) 560 are defined in separate standards-track documents, but at a high 561 level it is as follows: 563 o the algorithms: a PCN-node meters the amount of PCN-traffic on 564 each one of its outgoing (or incoming) links. The measurement is 565 made as an aggregate of all PCN-packets, and not per flow. There 566 are two algorithms, one for threshold-marking and one for excess- 567 traffic-marking. 569 o the encoding(s): a PCN-node PCN-marks a PCN-packet by setting the 570 ECN field to 11 and potentially altering the DSCP. 572 The PCN-boundary-nodes monitor the PCN-marked packets in order to 573 extract information about the current state of the PCN-domain. Based 574 on this monitoring, a decision is made about whether to admit a 575 prospective new flow or whether to terminate existing flow(s). 577 PCN-marking needs to be configured on all links in the PCN-domain to 578 ensure that the PCN mechanisms protect all links. The actual 579 functionality can be configured on the outgoing or incoming 580 interfaces of PCN-nodes - or one algorithm could be configured on the 581 outgoing interface and the other on the incoming interface. The 582 important thing is that a consistent choice is made across the PCN- 583 domain to ensure that the PCN mechanisms protect all links. See 584 [I-D.eardley-pcn-marking-behaviour] for further discussion. 586 The objective of the threshold-marking algorithm is to threshold-mark 587 all PCN-packets whenever the rate of PCN-packets is greater than some 588 configured rate, the PCN-threshold-rate. The objective of the 589 excess-traffic-marking algorithm is to excess-traffic-mark PCN- 590 packets at a rate equal to the difference between the bit rate of 591 PCN-packets and some configured rate, the PCN-excess-rate. Note that 592 this description reflects the overall intent of the algorithm rather 593 than its instantaneous behaviour, since the rate measured at a 594 particular moment depends on the detailed algorithm, its 595 implementation and the traffic's variance as well as its rate (eg 596 marking may well continue after a recent overload even after the 597 instantaneous rate has dropped). The algorithms are specified in 598 [I-D.eardley-pcn-marking-behaviour]. 600 In a PCN-domain the operator may have two or three encoding states 601 available. In both cases the ECN field is set to 11 to indicate PCN- 602 marking. In the former case, one DSCP is used. In the latter case a 603 second DSCP is used, which allows distinct threshold-marks and 604 excess-traffic-marks. The encoding is specified in 605 [I-D.moncaster-pcn-baseline-encoding] and 606 [I-D.moncaster-pcn-3-state-encoding]. 608 All the various admission and termination approaches are detailed and 609 compared in [I-D.charny-pcn-comparison] and [Menth08]. The 610 discussion below is just a brief summary. It initially assumes there 611 are three encoding states available. 613 6.1. Flow admission 615 The objective of PCN's flow admission control mechanism is to limit 616 the PCN-traffic on each link in the PCN-domain to *roughly* its PCN- 617 threshold-rate, by admitting or blocking prospective new flows, in 618 order to protect the QoS of existing PCN-flows. The PCN-threshold- 619 rate is a parameter that can be configured by the operator and will 620 be set lower than the traffic rate at which the link becomes 621 congested and the node drops packets. 623 Exactly how the admission control decision is made will be defined 624 separately in informational documents. At a high level two 625 approaches are proposed: 627 o the PCN-egress-node measures (possibly as a moving average) the 628 fraction of the PCN-traffic that is threshold-marked. The 629 fraction is measured for a specific ingress-egress-aggregate. If 630 the fraction is below a threshold value then the new flow is 631 admitted, and if the fraction is above the threshold value then it 632 is blocked. In [I-D.eardley-pcn-architecture] the fraction is 633 measured as an EWMA (exponentially weighted moving average) and 634 termed the "congestion level estimate". 636 o the PCN-egress-node monitors PCN-traffic and if it receives one 637 (or several) threshold-marked packets, then the new flow is 638 blocked, otherwise it is admitted. One possibility is to react to 639 the marking state of an initial flow set-up packet (eg RSVP PATH). 640 Another is that after one (or several) threshold-marks then all 641 flows are blocked until after a specific period of no congestion. 643 Note that the admission control decision is made for a particular 644 pair of PCN-boundary-nodes. So it is quite possible for a new flow 645 to be admitted between one pair of PCN-boundary-nodes, whilst at the 646 same time another admission request is blocked between a different 647 pair of PCN-boundary-nodes. 649 6.2. Flow termination 651 The objective of PCN's flow termination mechanism is to limit the 652 PCN-traffic on each link to *roughly* its PCN-excess-rate, by 653 terminating some existing PCN-flows, in order to protect the QoS of 654 the remaining PCN-flows. The PCN-excess-rate is a parameter that can 655 be configured by the operator and may be set lower than the traffic 656 rate at which the link becomes congested and the node drops packets. 658 Exactly how the flow termination decision is made will be defined 659 separately in informational documents. At a high level several 660 approaches are proposed: 662 o In one approach the PCN-egress-node measures the rate of PCN- 663 traffic that is not excess-traffic-marked, which is the amount of 664 PCN-traffic that can actually be supported. Also the PCN-ingress- 665 node measures the rate of PCN-traffic that is destined for this 666 specific PCN-egress-node, and hence it can calculate the excess 667 amount that should be terminated. 669 o Another approach instead measures the rate of excess-traffic- 670 marked traffic and terminates this amount of traffic. This 671 terminates more traffic than the previous bullet if some nodes are 672 dropping PCN-traffic. 674 o Another approach monitors PCN-packets and terminates any PCN-flow 675 with an excess-traffic-marked packet. Compared with the 676 approaches above, PCN-marking needs to be done at a reduced rate 677 (every "s" bytes of excess traffic) otherwise far too much traffic 678 would be terminated. 680 Since flow termination is designed for "abnormal" circumstances, it 681 is quite likely that some PCN-nodes are congested and hence packets 682 are being dropped and/or significantly queued. The flow termination 683 mechanism must bear this in mind. 685 Note also that the termination control decision is made for a 686 particular pair of PCN-boundary-nodes. So it is quite possible for 687 PCN-flows to be terminated between one pair of PCN-boundary-nodes, 688 whilst at the same time none are terminated between a different pair 689 of PCN-boundary-nodes. 691 6.3. Flow admission and flow termination when there are only two PCN 692 encoding states 694 If a PCN-domain has only two encoding states available (PCN-marked 695 and not PCN-marked), ie it's using the baseline encoding 696 [I-D.moncaster-pcn-baseline-encoding], then an operator has three 697 options: 699 o admission control only: PCN-marking means threshold-marking, ie 700 only the threshold-marking algorithm writes PCN-marks. Only PCN 701 admission control is available. 703 o flow termination only: PCN-marking means excess-traffic-marking, 704 ie only the excess-traffic-marking algorithm writes PCN-marks. 705 Only PCN termination control is available. 707 o both admission control and flow termination: only the excess- 708 traffic-marking algorithm writes PCN-marks, however the configured 709 rate (PCN-excess-rate) is set at the rate the admission control 710 mechanism needs to limit PCN-traffic to. 711 [I-D.charny-pcn-single-marking] describes how both admission 712 control and flow termination can be triggered in this case and 713 also gives some of the pros and cons of this approach. The main 714 downside is that admission control is less accurate. 716 6.4. Information transport 718 The transport of pre-congestion information from a PCN-node to a PCN- 719 egress-node is through PCN-markings in data packet headers, ie "in- 720 band": no signalling protocol messaging is needed. Signalling is 721 needed to transport PCN-feedback-information between the PCN- 722 boundary-nodes, for example to convey the fraction of PCN-marked 723 traffic from a PCN-egress-node to the relevant PCN-ingress-node. 724 Exactly what information needs to be transported will be described in 725 the future PCN WG document(s) about the boundary mechanisms. The 726 signalling could be done by an extension of RSVP or NSIS, for 727 instance; protocol work will be done by the relevant WG, but for 728 example [I-D.lefaucheur-rsvp-ecn] describes the extensions needed for 729 RSVP. 731 6.5. PCN-traffic 733 The following are some high-level points about how PCN works: 735 o There needs to be a way for a PCN-node to distinguish PCN-traffic 736 from other traffic. This is through a combination of the DSCP 737 field and/or ECN field. 739 o The PCN mechanisms may be applied to more than one behaviour 740 aggregate which are distinguished by DSCP. However the current 741 PCN encodings, [I-D.moncaster-pcn-baseline-encoding] and 742 [I-D.moncaster-pcn-3-state-encoding], only allow one PCN-BA. 744 o There may be traffic that is more important than PCN, perhaps a 745 particular application or an operator's control messages. A PCN- 746 node may dedicate capacity to such traffic or priority schedule it 747 over PCN. In the latter case its traffic needs to contribute to 748 the PCN meters (ie be metered by the threshold-marking and excess- 749 traffic-marking algorithms). 751 o There may be other traffic that uses the same DSCP as PCN-traffic 752 but with the ECN field is 00 (Not ECT), and so not subject to PCN- 753 marking, nor PCN's admission control and flow termination 754 mechanisms.. To quote [I-D.moncaster-pcn-baseline-encoding]: "To 755 conserve DSCPs, DiffServ Codepoints SHOULD be chosen that are 756 already defined for use with admission controlled traffic, such as 757 the Voice-Admit codepoint defined in [voice-admit]." Since 758 scheduling behaviour is coupled with the DSCP only, therefore the 759 same scheduling and buffer management rules are applied to non- 760 PCN-traffic and PCN-traffic using the same PCN-enabled DSCP. 761 There may be no "non-PCN-traffic", but if there is it needs to 762 contribute to the PCN meters. 764 o There will be traffic less important than PCN. For instance best 765 effort or assured forwarding traffic. It will be scheduled at 766 lower priority than PCN, and use a separate queue or queues. 767 However, a PCN-node should dedicate some capacity to lower 768 priority traffic so that it isn't starved. Such traffic doesn't 769 contribute to the PCN meters. 771 6.6. Backwards compatibility 773 PCN specifies semantics for the ECN field that differ from the 774 default semantics of [RFC3168]. BCP124 [RFC4774] gives guidelines 775 for specifying alternative semantics for the ECN field. These are 776 discussed in the baseline encoding 777 [I-D.moncaster-pcn-baseline-encoding] and extended encoding 778 [I-D.moncaster-pcn-3-state-encoding] documents. In summary, PCN 779 meets these guidelines by: 781 o using a DSCP (or two DSCPs in the extended encoding) to allow PCN- 782 nodes to distinguish PCN-traffic that uses the alternative ECN 783 semantics; 785 o defining these semantics for use within a controlled region, the 786 PCN-domain; 788 o taking appropriate action if ECN capable, non-PCN traffic arrives 789 at a PCN-ingress-node with the DSCP used by PCN. 791 The 'appropriate action' can differ in the case of baseline encoding 792 and extended encoding. In the former, ECN-capable traffic that uses 793 the same DSCP as PCN is blocked from entering the PCN-domain 794 directly. Blocking means it is dropped or downgraded to a lower 795 priority behaviour aggregate, or alternatively such traffic may be 796 tunnelled through the PCN-domain. The reason that blocking is needed 797 is that the PCN-egress-node clears the ECN field to 00. The extended 798 encoding adds support for end-to-end ECN, since the value of the ECN 799 field is preserved across the PCN-domain. However, PCN-packets that 800 get PCN-marked emerge from the PCN-domain with the ECN field set to 801 11 (CE). It may make sense to expose such marks to a rate adaptive 802 endpoint. However, it could violate [RFC4774] if the endpoint 803 doesn't understand ECN, and therefore the PCN-domain first needs to 804 ensure that the end-to-end transport is ECN capable (probably through 805 signalling). 807 7. Detailed Functional architecture 809 This section is intended to provide a systematic summary of the new 810 functional architecture in the PCN-domain. First it describes 811 functions needed at the three specific types of PCN-node; these are 812 data plane functions and are in addition to their normal router 813 functions. Then it describes further functionality needed for both 814 flow admission control and flow termination; these are signalling and 815 decision-making functions, and there are various possibilities for 816 where the functions are physically located. The section is split 817 into: 819 1. functions needed at PCN-interior-nodes 821 2. functions needed at PCN-ingress-nodes 823 3. functions needed at PCN-egress-nodes 824 4. other functions needed for flow admission control 826 5. other functions needed for flow termination control 828 Note: Probing is covered in Appendix B. 830 The section then discusses some other detailed topics: 832 1. addressing 834 2. tunnelling 836 3. fault handling 838 7.1. PCN-interior-node functions 840 Each link of the PCN-domain is configured with the following 841 functionality: 843 o Packet classify - decide whether an incoming packet is a PCN- 844 packet or not. 846 o Packet condition - if the level if traffic is sufficiently high to 847 overload the PCN_BA, ie cause real congestion, then drop or 848 downgrade PCN-packets. 850 o Meter - measure the 'amount of PCN-traffic'. The measurement is 851 made as an aggregate of all PCN-packets, and not per flow. 853 o Mark - algorithms determine whether to PCN-mark PCN-packets and 854 what packet encoding is used. 856 The functions are specified in [I-D.eardley-pcn-marking-behaviour] 857 and the encodings in [I-D.moncaster-pcn-baseline-encoding] and 858 [I-D.moncaster-pcn-3-state-encoding]. 860 7.2. PCN-ingress-node functions 862 Each ingress link of the PCN-domain is configured with the following 863 functionality: 865 o Packet classify - decide whether an incoming packet is part of a 866 previously admitted flow, by using a filter spec (eg DSCP, source 867 and destination addresses and port numbers). 869 o Police - police, by dropping or downgrading, any packets received 870 with a DSCP demanding PCN transport that do not belong to an 871 admitted flow. Similarly, police packets that are part of a 872 previously admitted flow, to check that the flow keeps to the 873 agreed rate or flowspec (eg RFC1633 [RFC1633] for a microflow and 874 its NSIS equivalent). 876 o Packet colour - set the DSCP and ECN fields appropriately, see 877 [I-D.moncaster-pcn-baseline-encoding] or 878 [I-D.moncaster-pcn-3-state-encoding] as appropriate for the PCN- 879 domain. 881 o Meter - some approaches to flow termination require the PCN- 882 ingress-node to measure the (aggregate) rate of PCN-traffic 883 towards a particular PCN-egress-node. 885 The first two are policing functions, needed to make sure that PCN- 886 packets admitted into the PCN-domain belong to a flow that's been 887 admitted and to ensure that the flow keeps to the flowspec agreed (eg 888 doesn't go at a faster rate and is inelastic traffic). Installing 889 the filter spec will typically be done by the signalling protocol, as 890 will re-installing the filter, for example after a re-route that 891 changes the PCN-ingress-node (see [I-D.briscoe-tsvwg-cl-architecture] 892 for an example using RSVP). Packet colouring allows the rest of the 893 PCN-domain to recognise PCN-packets. 895 7.3. PCN-egress-node functions 897 Each egress link of the PCN-domain is configured with the following 898 functionality: 900 o Packet classify - determine which PCN-ingress-node a PCN-packet 901 has come from. 903 o Meter - "measure PCN-traffic" or "monitor PCN-marks". 905 o Packet colour - for PCN-packets, set the DSCP and ECN fields to 906 the appropriate values for use outside the PCN-domain. 908 The metering functionality of course depends on whether it is 909 targeted at admission control or flow termination. Alternative 910 proposals involve the PCN-egress-node "measuring" as an aggregate (ie 911 not per flow) all PCN-packets from a particular PCN-ingress-node, or 912 "monitoring" the PCN-traffic and reacting to one (or several) PCN- 913 marked packets. 915 7.4. Other admission control functions 917 As well as the functions covered above, other specific admission 918 control functions can be performed at a PCN-boundary-node (PCN- 919 ingress-node or PCN-egress-node) or at a centralised node, but not at 920 normal PCN-interior-nodes. The functions are: 922 o Make decision about admission - based on the output of the PCN- 923 egress-node's PCN meter function. In the case where it "measures 924 PCN-traffic", the measured traffic on the ingress-egress-aggregate 925 is compared with some reference level. In the case where it 926 "monitors PCN-marks", then the decision is based on whether one 927 (or several) packets is (are) PCN-marked or not. In either case, 928 the admission decision also takes account of policy and 929 application layer requirements. 931 o Communicate decision about admission - signal the decision to the 932 node making the admission control request (which may be outside 933 the PCN-domain), and to the policer (PCN-ingress-node function) 934 for enforcement of the decision. 936 There are various possibilities for how the functionality can be 937 distributed (we assume the operator would configure which is used): 939 o The decision is made at the PCN-egress-node and the decision 940 (admit or block) is signalled to the PCN-ingress-node. This seems 941 most natural. 943 o The decision is made at the PCN-ingress-node, which requires that 944 the PCN-egress-node signals PCN-feedback-information to the PCN- 945 ingress-node. For example, it could signal the current fraction 946 of PCN-traffic that is PCN-marked. 948 o The decision is made at a centralised node (see Appendix A). 950 7.5. Other flow termination functions 952 Specific termination control functions can be performed at a PCN- 953 boundary-node (PCN-ingress-node or PCN-egress-node) or at a 954 centralised node, but not at normal PCN-interior-nodes. There are 955 various possibilities for how the functionality can be distributed, 956 similar to those discussed above in the Admission control section; 957 the flow termination decision could be made at the PCN-ingress-node, 958 the PCN-egress-node or at some centralised node. The functions are: 960 o PCN-meter at PCN-egress-node - similarly to flow admission, there 961 are two types of proposals: to "measure PCN-traffic" on the 962 ingress-egress-aggregate, and to "monitor PCN-marks" and react to 963 one (or several) PCN-marks. 965 o (if required) PCN-meter at PCN-ingress-node - make "measurements 966 of PCN-traffic" being sent towards a particular PCN-egress-node; 967 again, this is done for the ingress-egress-aggregate and not per 968 flow. 970 o (if required) Communicate PCN-feedback-information to the node 971 that makes the flow termination decision. For example, as in 972 [I-D.briscoe-tsvwg-cl-architecture], communicate the PCN-egress- 973 node's measurements to the PCN-ingress-node. 975 o Make decision about flow termination - use the information from 976 the PCN-meter(s) to decide which PCN-flow or PCN-flows to 977 terminate. The decision takes account of policy and application 978 layer requirements. 980 o Communicate decision about flow termination - signal the decision 981 to the node that is able to terminate the flow (which may be 982 outside the PCN-domain), and to the policer (PCN-ingress-node 983 function) for enforcement of the decision. 985 7.6. Addressing 987 PCN-nodes may need to know the address of other PCN-nodes. Note: in 988 all cases PCN-interior-nodes don't need to know the address of any 989 other PCN-nodes (except as normal their next hop neighbours, for 990 routing purposes). 992 The PCN-egress-node needs to know the address of the PCN-ingress-node 993 associated with a flow, at a minimum so that the PCN-ingress-node can 994 be informed to enforce the admission decision (and any flow 995 termination decision) through policing. There are various 996 possibilities for how the PCN-egress-node can do this, ie associate 997 the received packet to the correct ingress-egress-aggregate. It is 998 not the intention of this document to mandate a particular mechanism. 1000 o The addressing information can be gathered from signalling. For 1001 example, regular processing of an RSVP Path message, as the PCN- 1002 ingress-node is the previous RSVP hop (PHOP) 1003 ([I-D.lefaucheur-rsvp-ecn]). Or the PCN-ingress-node could signal 1004 its address to the PCN-egress-node. 1006 o Always tunnel PCN-traffic across the PCN-domain. Then the PCN- 1007 ingress-node's address is simply the source address of the outer 1008 packet header. The PCN-ingress-node needs to learn the address of 1009 the PCN-egress-node, either by manual configuration or by one of 1010 the automated tunnel endpoint discovery mechanisms (such as 1011 signalling or probing over the data route, interrogating routing 1012 or using a centralised broker). 1014 7.7. Tunnelling 1016 Tunnels may originate and/or terminate within a PCN-domain. It is 1017 important that the PCN-marking of any packet can potentially 1018 influence PCN's flow admission control and termination - it shouldn't 1019 matter whether the packet happens to be tunnelled at the PCN-node 1020 that PCN-marks the packet, or indeed whether it's decapsulated or 1021 encapsulated by a subsequent PCN-node. This suggests that the 1022 "uniform conceptual model" described in [RFC2983] should be re- 1023 applied in the PCN context. In line with this and the approach of 1024 [RFC4303] and [I-D.briscoe-tsvwg-ecn-tunnel], the following rule is 1025 applied if encapsulation is done within the PCN-domain: 1027 o any PCN-marking is copied into the outer header 1029 Similarly, in line with the "uniform conceptual model" of [RFC2983] 1030 and the "full-functionality option" of [RFC3168], the following rule 1031 is applied if decapsulation is done within the PCN-domain: 1033 o if the outer header's marking state is more severe then it is 1034 copied onto the inner header 1036 o Note: the order of increasing severity is: not PCN-marked; 1037 threshold-marking; excess-traffic-marking. 1039 An operator may wish to tunnel PCN-traffic from PCN-ingress-nodes to 1040 PCN-egress-nodes. The PCN-marks shouldn't be visible outside the 1041 PCN-domain, which can be achieved by the PCN-egress-node doing the 1042 packet colouring function (Section 7.3) after all the other (PCN and 1043 tunnelling) functions. The potential reasons for doing such 1044 tunnelling are: the PCN-egress-node then automatically knows the 1045 address of the relevant PCN-ingress-node for a flow; even if ECMP is 1046 running, all PCN-packets on a particular ingress-egress-aggregate 1047 follow the same path. But it also has drawbacks, for example the 1048 additional overhead in terms of bandwidth and processing, and the 1049 cost of setting up a mesh of tunnels between PCN-boundary-nodes 1050 (there is an N^2 scaling issue). 1052 Potential issues arise for a "partially PCN-capable tunnel", ie where 1053 only one tunnel endpoint is in the PCN domain: 1055 1. The tunnel starts outside a PCN-domain and finishes inside it. 1056 If the packet arrives at the tunnel ingress with the same 1057 encoding as used within the PCN-domain to indicate PCN-marking, 1058 then this could lead the PCN-egress-node to falsely measure pre- 1059 congestion. 1061 2. The tunnel starts inside a PCN-domain and finishes outside it. 1062 If the packet arrives at the tunnel ingress already PCN-marked, 1063 then it will still have the same encoding when it's decapsulated 1064 which could potentially confuse nodes beyond the tunnel egress. 1066 In line with the solution for partially capable DiffServ tunnels in 1067 [RFC2983], the following rules are applied: 1069 o For case (1), the tunnel egress node clears any PCN-marking on the 1070 inner header. This rule is applied before the 'copy on 1071 decapsulation' rule above. 1073 o For case (2), the tunnel ingress node clears any PCN-marking on 1074 the inner header. This rule is applied after the 'copy on 1075 encapsulation' rule above. 1077 Note that the above implies that one has to know, or figure out, the 1078 characteristics of the other end of the tunnel as part of setting it 1079 up. 1081 Tunnelling constraints were a major factor in the choice of encoding, 1082 as explained in [I-D.moncaster-pcn-baseline-encoding] and 1083 [I-D.moncaster-pcn-3-state-encoding]. A lengthy discussion of all 1084 the issues associated with layered encapsulation of congestion 1085 notification (for ECN as well as PCN) is in 1086 [I-D.briscoe-tsvwg-ecn-tunnel]. 1088 7.8. Fault handling 1090 If a PCN-interior-node fails (or one of its links), then lower layer 1091 protection mechanisms or the regular IP routing protocol will 1092 eventually re-route round it. If the new route can carry all the 1093 admitted traffic, flows will gracefully continue. If instead this 1094 causes early warning of pre-congestion on the new route, then 1095 admission control based on pre-congestion notification will ensure 1096 new flows will not be admitted until enough existing flows have 1097 departed. Re-routing may result in heavy (pre-)congestion, when the 1098 flow termination mechanism will kick in. 1100 If a PCN-boundary-node fails then we would like the regular QoS 1101 signalling protocol to take care of things. As an example 1102 [I-D.briscoe-tsvwg-cl-architecture] considers what happens if RSVP is 1103 the QoS signalling protocol. 1105 8. Design goals and challenges 1107 Prior work on PCN and similar mechanisms has thrown up a number of 1108 considerations about PCN's design goals (things PCN should be good 1109 at) and some issues that have been hard to solve in a fully 1110 satisfactory manner. Taken as a whole it represents a list of trade- 1111 offs (it's unlikely that they can all be 100% achieved) and perhaps 1112 as evaluation criteria to help an operator (or the IETF) decide 1113 between options. 1115 The following are key design goals for PCN (based on 1116 [I-D.chan-pcn-problem-statement]): 1118 o The PCN-enabled packet forwarding network should be simple, 1119 scalable and robust 1121 o Compatibility with other traffic (ie a proposed solution should 1122 work well when non-PCN traffic is also present in the network) 1124 o Support of different types of real-time traffic (eg should work 1125 well with CBR and VBR voice and video sources treated together) 1127 o Reaction time of the mechanisms should be commensurate with the 1128 desired application-level requirements (eg a termination mechanism 1129 needs to terminate flows before significant QoS issues are 1130 experienced by real-time traffic, and before most users hang up). 1132 o Compatibility with different precedence levels of real-time 1133 applications (eg preferential treatment of higher precedence calls 1134 over lower precedence calls, [ITU-MLPP]). 1136 The following are open issues. They are mainly taken from 1137 [I-D.briscoe-tsvwg-cl-architecture] which also describes some 1138 possible solutions. Note that some may be considered unimportant in 1139 general or in specific deployment scenarios or by some operators. 1141 NOTE: Potential solutions are out of scope for this document. 1143 o ECMP (Equal Cost Multi-Path) Routing: The level of pre-congestion 1144 is measured on a specific ingress-egress-aggregate. However, if 1145 the PCN-domain runs ECMP, then traffic on this ingress-egress- 1146 aggregate may follow several different paths - some of the paths 1147 could be pre-congested whilst others are not. There are three 1148 potential problems: 1150 1. over-admission: a new flow is admitted (because the pre- 1151 congestion level measured by the PCN-egress-node is 1152 sufficiently diluted by unmarked packets from non-congested 1153 paths that a new flow is admitted), but its packets travel 1154 through a pre-congested PCN-node 1156 2. under-admission: a new flow is blocked (because the pre- 1157 congestion level measured by the PCN-egress-node is 1158 sufficiently increased by PCN-marked packets from pre- 1159 congested paths that a new flow is blocked), but its packets 1160 travel along an uncongested path 1162 3. ineffective termination: flows are terminated, however their 1163 path doesn't travel through the (pre-)congested router(s). 1164 Since flow termination is a 'last resort' that protects the 1165 network should over-admission occur, this problem is probably 1166 more important to solve than the other two. 1168 o ECMP and signalling: It is possible that, in a PCN-domain running 1169 ECMP, the signalling packets (eg RSVP, NSIS) follow a different 1170 path than the data packets, which could matter if the signalling 1171 packets are used as probes. Whether this is an issue depends on 1172 which fields the ECMP algorithm uses; if the ECMP algorithm is 1173 restricted to the source and destination IP addresses, then it 1174 won't be. ECMP and signalling interactions are a specific 1175 instance of a general issue for non-traditional routing combined 1176 with resource management along a path [Hancock]. 1178 o Tunnelling: There are scenarios where tunnelling makes it hard to 1179 determine the path in the PCN-domain. The problem, its impact and 1180 the potential solutions are similar to those for ECMP. 1182 o Scenarios with only one tunnel endpoint in the PCN domain may make 1183 it harder for the PCN-egress-node to gather from the signalling 1184 messages (eg RSVP, NSIS) the identity of the PCN-ingress-node. 1186 o Bi-Directional Sessions: Many applications have bi-directional 1187 sessions - hence there are two flows that should be admitted (or 1188 terminated) as a pair - for instance a bi-directional voice call 1189 only makes sense if flows in both directions are admitted. 1190 However, PCN's mechanisms concern admission and termination of a 1191 single flow, and coordination of the decision for both flows is a 1192 matter for the signalling protocol and out of scope of PCN. One 1193 possible example would use SIP pre-conditions; there are others. 1195 o Global Coordination: PCN makes its admission decision based on 1196 PCN-markings on a particular ingress-egress-aggregate. Decisions 1197 about flows through a different ingress-egress-aggregate are made 1198 independently. However, one can imagine network topologies and 1199 traffic matrices where, from a global perspective, it would be 1200 better to make a coordinated decision across all the ingress- 1201 egress-aggregates for the whole PCN-domain. For example, to block 1202 (or even terminate) flows on one ingress-egress-aggregate so that 1203 more important flows through a different ingress-egress-aggregate 1204 could be admitted. The problem may well be second order. 1206 o Aggregate Traffic Characteristics: Even when the number of flows 1207 is stable, the traffic level through the PCN-domain will vary 1208 because the sources vary their traffic rates. PCN works best when 1209 there's not too much variability in the total traffic level at a 1210 PCN-node's interface (ie in the aggregate traffic from all 1211 sources). Too much variation means that a node may (at one 1212 moment) not be doing any PCN-marking and then (at another moment) 1213 drop packets because it's overloaded. This makes it hard to tune 1214 the admission control scheme to stop admitting new flows at the 1215 right time. Therefore the problem is more likely with fewer, 1216 burstier flows. 1218 o Flash crowds and Speed of Reaction: PCN is a measurement-based 1219 mechanism and so there is an inherent delay between packet marking 1220 by PCN-interior-nodes and any admission control reaction at PCN- 1221 boundary-nodes. For example, potentially if a big burst of 1222 admission requests occurs in a very short space of time (eg 1223 prompted by a televote), they could all get admitted before enough 1224 PCN-marks are seen to block new flows. In other words, any 1225 additional load offered within the reaction time of the mechanism 1226 mustn't move the PCN-domain directly from no congestion to 1227 overload. This 'vulnerability period' may impact at the 1228 signalling level, for instance QoS requests should be rate limited 1229 to bound the number of requests able to arrive within the 1230 vulnerability period. 1232 o Silent at start: after a successful admission request the source 1233 may wait some time before sending data (eg waiting for the called 1234 party to answer). Then the risk is that, in some circumstances, 1235 PCN's measurements underestimate what the pre-congestion level 1236 will be when the source does start sending data. 1238 9. Operations and Management 1240 This Section considers operations and management issues, under the 1241 FCAPS headings: OAM of Faults, Configuration, Accounting, Performance 1242 and Security. Provisioning is discussed with performance. 1244 9.1. Configuration OAM 1246 This architecture document predates the detailed standards actions of 1247 the PCN WG. Here we assume that only inter-operable PCN-marking 1248 behaviours will be standardised, otherwise we would have to consider 1249 how to avoid interactions between non inter-operable marking 1250 behaviours. However, more diversity in PCN-boundary-node behaviours 1251 is expected, in order to interface with diverse industry 1252 architectures. It may be possible to have different PCN-boundary- 1253 node behaviours for different ingress-egress-aggregates within the 1254 same PCN-domain. 1256 PCN functionality is configured on either the egress or the ingress 1257 interfaces of PCN-nodes. A consistent choice must be made across the 1258 PCN-domain to ensure that the PCN mechanisms protect all links. 1260 PCN configuration control variables fall into the following 1261 categories: 1263 o system options (enabling or disabling behaviours) 1265 o parameters (setting levels, addresses etc) 1267 One possibility is that all configurable variables sit within an SNMP 1268 management framework [RFC3411], being structured within a defined 1269 management information base (MIB) on each node, and being remotely 1270 readable and settable via a suitably secure management protocol 1271 (SNMPv3). 1273 Some configuration options and parameters have to be set once to 1274 'globally' control the whole PCN-domain. Where possible, these are 1275 identified below. This may affect operational complexity and the 1276 chances of interoperability problems between kit from different 1277 vendors. 1279 It may be possible for an operator to configure some PCN-interior- 1280 nodes so they don't run the PCN mechanisms, if it knows that these 1281 links will never become (pre-)congested. 1283 9.1.1. System options 1285 On PCN-interior-nodes there will be very few system options: 1287 o Whether two PCN-markings (threshold-marked and excess-traffic- 1288 marked) are enabled or only one. Typically all nodes throughout a 1289 PCN-domain will be configured the same in this respect. However, 1290 exceptions could be made. For example, if most PCN-nodes used 1291 both markings, but some legacy hardware was incapable of running 1292 two algorithms, an operator might be willing to configure these 1293 legacy nodes solely for excess-traffic-marking to enable flow 1294 termination as a back-stop. It would be sensible to place such 1295 nodes where they could be provisioned with a greater leeway over 1296 expected traffic levels. 1298 o what marking algorithm to use, if an equipment vendor provides a 1299 choice. 1301 PCN-boundary-nodes (ingress and egress) will have more system 1302 options: 1304 o Which of admission and flow termination are enabled. If any PCN- 1305 interior-node is configured to generate a marking, all PCN- 1306 boundary-nodes must be able to handle that marking. Therefore all 1307 PCN-boundary-nodes must be configured the same in this respect. 1309 o Where flow admission and termination decisions are made: at the 1310 PCN-ingress-node, PCN-egress-node or at a centralised node (see 1311 Section 7). Theoretically, this configuration choice could be 1312 negotiated for each pair of PCN-boundary-nodes, but we cannot 1313 imagine why such complexity would be required, except perhaps in 1314 future inter-domain scenarios. 1316 PCN-egress-nodes will have further system options: 1318 o How the mapping should be established between each packet and its 1319 aggregate, eg by MPLS label, by IP packet filterspec; and how to 1320 take account of ECMP. 1322 o If an equipment vendor provides a choice, there may be options to 1323 select which smoothing algorithm to use for measurements. 1325 9.1.2. Parameters 1327 Like any DiffServ domain, every node within a PCN-domain will need to 1328 be configured with the DSCP(s) used to identify PCN-packets. On each 1329 interior link the main configuration parameters are the PCN- 1330 threshold-rate and PCN-excess-rate. A larger PCN-threshold-rate 1331 enables more PCN-traffic to be admitted on a link, hence improving 1332 capacity utilisation. A PCN-excess-rate set further above the PCN- 1333 threshold-rate allows greater increases in traffic (whether due to 1334 natural fluctuations or some unexpected event) before any flows are 1335 terminated, ie minimises the chances of unnecessarily triggering the 1336 termination mechanism. For instance an operator may want to design 1337 their network so that it can cope with a failure of any single PCN- 1338 node without terminating any flows. 1340 Setting these rates on first deployment of PCN will be very similar 1341 to the traditional process for sizing an admission controlled 1342 network, depending on: the operator's requirements for minimising 1343 flow blocking (grade of service), the expected PCN traffic load on 1344 each link and its statistical characteristics (the traffic matrix), 1345 contingency for re-routing the PCN traffic matrix in the event of 1346 single or multiple failures and the expected load from other classes 1347 relative to link capacities [Menth]. But once a domain is up and 1348 running, a PCN design goal is to be able to determine growth in these 1349 configured rates much more simply, by monitoring PCN-marking rates 1350 from actual rather than expected traffic (see Section 9.2 on 1351 Performance & Provisioning). 1353 Operators may also wish to configure a rate greater than the PCN- 1354 excess-rate that is the absolute maximum rate that a link allows for 1355 PCN-traffic. This may simply be the physical link rate, but some 1356 operators may wish to configure a logical limit to prevent starvation 1357 of other traffic classes during any brief period after PCN-traffic 1358 exceeds the PCN-excess-rate but before flow termination brings it 1359 back below this rate. 1361 Specific marking algorithms will also depend on further configuration 1362 parameters. For instance, threshold-marking will require a threshold 1363 queue depth and excess-traffic-marking may require a scaling 1364 parameter. It will be preferable for each marking algorithm to have 1365 rules to set defaults for these parameters relative to the reference 1366 marking rate, but then allow operators to change them, for instance 1367 if average traffic characteristics change over time. The PCN-egress- 1368 node may allow configuration of the following: 1370 o how it smooths metering of PCN-markings (eg EWMA parameters) 1372 Whichever node makes admission and flow termination decisions will 1373 contain algorithms for converting PCN-marking levels into admission 1374 or flow termination decisions. These will also require configurable 1375 parameters, for instance: 1377 o any admission control algorithm will at least require a marking 1378 threshold setting above which it denies admission to new flows; 1380 o flow termination algorithms will probably require a parameter to 1381 delay termination of any flows until it is more certain that an 1382 anomalous event is not transient; 1384 o a parameter to control the trade-off between how quickly excess 1385 flows are terminated and over-termination. 1387 One particular proposal, [I-D.charny-pcn-single-marking] would 1388 require a global parameter to be defined on all PCN-nodes, but only 1389 needs one PCN marking rate to be configured on each link. The global 1390 parameter is a scaling factor between admission and termination, for 1391 example the amount by which the PCN-excess-rate is implicitly assumed 1392 to be above the PCN-threshold-rate. [I-D.charny-pcn-single-marking] 1393 discusses in full the impact of this particular proposal on the 1394 operation of PCN. 1396 9.2. Performance & Provisioning OAM 1398 Monitoring of performance factors measurable from *outside* the PCN 1399 domain will be no different with PCN than with any other packet-based 1400 flow admission control system, both at the flow level (blocking 1401 probability etc) and the packet level (jitter [RFC3393], [Y.1541], 1402 loss rate [RFC4656], mean opinion score [P.800], etc). The 1403 difference is that PCN is intentionally designed to indicate 1404 *internally* which exact resource(s) are the cause of performance 1405 problems and by how much. 1407 Even better, PCN indicates which resources will probably cause 1408 problems if they are not upgraded soon. This can be achieved by the 1409 management system monitoring the total amount (in bytes) of PCN- 1410 marking generated by each queue over a period. Given possible long 1411 provisioning lead times, pre-congestion volume is the best metric to 1412 reveal whether sufficient persistent demand has mounted up to warrant 1413 an upgrade. Because, even before utilisation becomes problematic, 1414 the statistical variability of traffic will cause occasional bursts 1415 of pre-congestion. This 'early warning system' decouples the process 1416 of adding customers from the provisioning process. This should cut 1417 the time to add a customer when compared against admission control 1418 provided over native DiffServ [RFC2998], because it saves having to 1419 re-run the capacity planning process before adding each customer. 1421 Alternatively, before triggering an upgrade, the long term pre- 1422 congestion volume on each link can be used to balance traffic load 1423 across the PCN-domain by adjusting the link weights of the routing 1424 system. When an upgrade to a link's configured PCN-rates is 1425 required, it may also be necessary to upgrade the physical capacity 1426 available to other classes. But usually there will be sufficient 1427 physical capacity for the upgrade to go ahead as a simple 1428 configuration change. Alternatively, [Songhurst] has proposed an 1429 adaptive rather than preconfigured system, where the configured PCN- 1430 threshold-rate is replaced with a high and low water mark and the 1431 marking algorithm automatically optimises how physical capacity is 1432 shared using the relative loads from PCN and other traffic classes. 1434 All the above processes require just three extra counters associated 1435 with each PCN queue: threshold-markings, excess-traffic-markings and 1436 drop. Every time a PCN packet is marked or dropped its size in bytes 1437 should be added to the appropriate counter. Then the management 1438 system can read the counters at any time and subtract a previous 1439 reading to establish the incremental volume of each type of 1440 (pre-)congestion. Readings should be taken frequently, so that 1441 anomalous events (eg re-routes) can be separated from regular 1442 fluctuating demand if required. 1444 9.3. Accounting OAM 1446 Accounting is only done at trust boundaries so it is out of scope of 1447 the initial Charter of the PCN WG which is confined to intra-domain 1448 issues. Use of PCN internal to a domain makes no difference to the 1449 flow signalling events crossing trust boundaries outside the PCN- 1450 domain, which are typically used for accounting. 1452 9.4. Fault OAM 1454 Fault OAM is about preventing faults, telling the management system 1455 (or manual operator) that the system has recovered (or not) from a 1456 failure, and about maintaining information to aid fault diagnosis. 1458 Admission blocking and particularly flow termination mechanisms 1459 should rarely be needed in practice. It would be unfortunate if they 1460 didn't work after an option had been accidentally disabled. 1461 Therefore it will be necessary to regularly test that the live system 1462 works as intended (devising a meaningful test is left as an exercise 1463 for the operator). 1465 Section 7 describes how the PCN architecture has been designed to 1466 ensure admitted flows continue gracefully after recovering 1467 automatically from link or node failures. The need to record and 1468 monitor re-routing events affecting signalling is unchanged by the 1469 addition of PCN to a DiffServ domain. Similarly, re-routing events 1470 within the PCN-domain will be recorded and monitored just as they 1471 would be without PCN. 1473 PCN-marking does make it possible to record 'near-misses'. For 1474 instance, at the PCN-egress-node a 'reporting threshold' could be set 1475 to monitor how often - and for how long - the system comes close to 1476 triggering flow blocking without actually doing so. Similarly, 1477 bursts of flow termination marking could be recorded even if they are 1478 not sufficiently sustained to trigger flow termination. Such 1479 statistics could be correlated with per-queue counts of marking 1480 volume (Section 9.2) to upgrade resources in danger of causing 1481 service degradation, or to trigger manual tracing of intermittent 1482 incipient errors that would otherwise have gone unnoticed. 1484 Finally, of course, many faults are caused by failings in the 1485 management process ('human error'): a wrongly configured address in a 1486 node, a wrong address given in a signalling protocol, a wrongly 1487 configured parameter in a queueing algorithm, a node set into a 1488 different mode from other nodes, and so on. Generally, a clean 1489 design with few configurable options ensures this class of faults can 1490 be traced more easily and prevented more often. Sound management 1491 practice at run-time also helps. For instance: a management system 1492 should be used that constrains configuration changes within system 1493 rules (eg preventing an option setting inconsistent with other 1494 nodes); configuration options should also be recorded in an offline 1495 database; and regular automatic consistency checks between live 1496 systems and the database. PCN adds nothing specific to this class of 1497 problems. By the time standards are in place, we expect that the PCN 1498 WG will have ruthlessly removed gratuitous configuration choices. 1499 However, at the time of writing, the WG is yet to choose between 1500 multiple competing proposals, so the range of possible options in 1501 Section 9.1 does seem rather wide compared to the original near-zero 1502 configuration intent of the architecture. 1504 9.5. Security OAM 1506 Security OAM is about using secure operational practices as well as 1507 being able to track security breaches or near-misses at run-time. 1508 PCN adds few specifics to the general good practice required in this 1509 field [RFC4778], other than those below. The correct functions of 1510 the system should be monitored (Section 9.2) in multiple independent 1511 ways and correlated to detect possible security breaches. Persistent 1512 (pre-)congestion marking should raise an alarm (both on the node 1513 doing the marking and on the PCN-egress-node metering it). 1514 Similarly, persistently poor external QoS metrics such as jitter or 1515 MOS should raise an alarm. The following are examples of symptoms 1516 that may be the result of innocent faults, rather than attacks, but 1517 until diagnosed they should be logged and trigger a security alarm: 1519 o Anomalous patterns of non-conforming incoming signals and packets 1520 rejected at the PCN-ingress-nodes (eg packets already marked PCN- 1521 capable, or traffic persistently starving token bucket policers). 1523 o PCN-capable packets arriving at a PCN-egress-node with no 1524 associated state for mapping them to a valid ingress-egress- 1525 aggregate. 1527 o A PCN-ingress-node receiving feedback signals about the pre- 1528 congestion level on a non-existent aggregate, or that are 1529 inconsistent with other signals (eg unexpected sequence numbers, 1530 inconsistent addressing, conflicting reports of the pre-congestion 1531 level, etc). 1533 o Pre-congestion marking arriving at an PCN-egress-node with 1534 (pre-)congestion markings focused on particular flows, rather than 1535 randomly distributed throughout the aggregate. 1537 10. IANA Considerations 1539 This memo includes no request to IANA. 1541 11. Security considerations 1543 Security considerations essentially come from the Trust Assumption 1544 (Section 5.1), ie that all PCN-nodes are PCN-enabled and trust each 1545 other for truthful PCN-marking and transport. PCN splits 1546 functionality between PCN-interior-nodes and PCN-boundary-nodes, and 1547 the security considerations are somewhat different for each, mainly 1548 because PCN-boundary-nodes are flow-aware and PCN-interior-nodes are 1549 not. 1551 o Because the PCN-boundary-nodes are flow-aware, they are trusted to 1552 use that awareness correctly. The degree of trust required 1553 depends on the kinds of decisions they have to make and the kinds 1554 of information they need to make them. For example when the PCN- 1555 boundary-node needs to know the contents of the sessions for 1556 making the admission and termination decisions, or when the 1557 contents are highly classified, then the security requirements for 1558 the PCN-boundary-nodes involved will also need to be high. 1560 o the PCN-ingress-nodes police packets to ensure a PCN-flow sticks 1561 within its agreed limit, and to ensure that only PCN-flows which 1562 have been admitted contribute PCN-traffic into the PCN-domain. 1563 The policer must drop (or perhaps downgrade to a different DSCP) 1564 any PCN-packets received that are outside this remit. This is 1565 similar to the existing IntServ behaviour. Between them the PCN- 1566 boundary-nodes must encircle the PCN-domain, otherwise PCN-packets 1567 could enter the PCN-domain without being subject to admission 1568 control, which would potentially destroy the QoS of existing 1569 flows. 1571 o PCN-interior-nodes aren't flow-aware. This prevents some security 1572 attacks where an attacker targets specific flows in the data plane 1573 - for instance for DoS or eavesdropping. 1575 o PCN-marking by the PCN-interior-nodes along the packet forwarding 1576 path needs to be trusted, because the PCN-boundary-nodes rely on 1577 this information. For instance a rogue PCN-interior-node could 1578 PCN-mark all packets so that no flows were admitted. Another 1579 possibility is that it doesn't PCN-mark any packets, even when 1580 it's pre-congested. More subtly, the rogue PCN-interior-node 1581 could perform these attacks selectively on particular flows, or it 1582 could PCN-mark the correct fraction overall, but carefully choose 1583 which flows it marked. 1585 o the PCN-boundary-nodes should be able to deal with DoS attacks and 1586 state exhaustion attacks based on fast changes in per flow 1587 signalling. 1589 o the signalling between the PCN-boundary-nodes (and possibly a 1590 central control node) must be protected from attacks. For example 1591 the recipient needs to validate that the message is indeed from 1592 the node that claims to have sent it. Possible measures include 1593 digest authentication and protection against replay and man-in- 1594 the-middle attacks. For the specific protocol RSVP, hop-by-hop 1595 authentication is in [RFC2747], and 1596 [I-D.behringer-tsvwg-rsvp-security-groupkeying] may also be 1597 useful; for a generic signalling protocol the PCN WG document on 1598 "Requirements for signalling" will describe the requirements in 1599 more detail. 1601 Operational security advice is given in Section 9.5. 1603 12. Conclusions 1605 The document describes a general architecture for flow admission and 1606 termination based on pre-congestion information in order to protect 1607 the quality of service of established inelastic flows within a single 1608 DiffServ domain. The main topic is the functional architecture. It 1609 also mentions other topics like the assumptions and open issues. 1611 13. Acknowledgements 1613 This document is a revised version of [I-D.eardley-pcn-architecture]. 1614 Its authors were: P. Eardley, J. Babiarz, K. Chan, A. Charny, R. 1615 Geib, G. Karagiannis, M. Menth, T. Tsou. They are therefore 1616 contributors to this document. 1618 Thanks to those who've made comments on 1619 [I-D.eardley-pcn-architecture] and on earlier versions of this draft: 1620 Lachlan Andrew, Joe Babiarz, Fred Baker, David Black, Steven Blake, 1621 Bob Briscoe, Jason Canon, Ken Carlberg, Anna Charny, Joachim 1622 Charzinski, Andras Csaszar, Lars Eggert, Ruediger Geib, Wei Gengyu, 1623 Robert Hancock, Ingemar Johansson, Georgios Karagiannis, Michael 1624 Menth, Toby Moncaster, Ben Strulo, Tom Taylor, Hannes Tschofenig, 1625 Tina Tsou, Lars Westberg, Magnus Westerlund, Delei Yu. Thanks to Bob 1626 Briscoe who extensively revised the Operations and Management 1627 section. 1629 This document is the result of discussions in the PCN WG and 1630 forerunner activity in the TSVWG. A number of previous drafts were 1631 presented to TSVWG: [I-D.chan-pcn-problem-statement], 1632 [I-D.briscoe-tsvwg-cl-architecture], [I-D.briscoe-tsvwg-cl-phb], 1633 [I-D.charny-pcn-single-marking], [I-D.babiarz-pcn-sip-cap], 1634 [I-D.lefaucheur-rsvp-ecn], [I-D.westberg-pcn-load-control]. The 1635 authors of them were: B, Briscoe, P. Eardley, D. Songhurst, F. Le 1636 Faucheur, A. Charny, J. Babiarz, K. Chan, S. Dudley, G. Karagiannis, 1637 A. Bader, L. Westberg, J. Zhang, V. Liatsos, X-G. Liu, A. Bhargava. 1639 14. Comments Solicited 1641 Comments and questions are encouraged and very welcome. They can be 1642 addressed to the IETF PCN working group mailing list . 1644 15. Changes 1646 15.1. Changes from -03 to -04 1648 o Minor changes throughout to reflect the consenus call about PCN- 1649 marking (as reflected in [I-D.eardley-pcn-marking-behaviour]). 1651 o Minor changes throughout to reflect the current decisions about 1652 encoding (as reflected in [I-D.moncaster-pcn-baseline-encoding]and 1653 [I-D.moncaster-pcn-3-state-encoding]). 1655 o Introduction: re-structured to create new sections on Benefits, 1656 Deployment scenarios and Assumptions. 1658 o Introduction: Added pointers to other PCN documents. 1660 o Terminology: changed PCN-lower-rate to PCN-threshold-rate and PCN- 1661 upper-rate to PCN-excess-rate; excess-rate-marking to excess- 1662 traffic-marking. 1664 o Benefits: added bullet about SRLGs. 1666 o Deployment scenarios: new section combining material from various 1667 places within the document. 1669 o S6 (high level functional architecture): re-structured and edited 1670 to improve clarity, and reflect the latest PCN-marking and 1671 encoding drafts. 1673 o S6.4: added claim that the most natural place to make an admission 1674 decision is a PCN-egress-node. 1676 o S6.5: updated the bullet about non-PCN-traffic that uses the same 1677 DSCP as PCN-traffic. 1679 o S6.6: added a section about backwards compatibility with respect 1680 to [RFC4774]. 1682 o Appendix A: added bullet about end-to-end PCN. 1684 o Probing: moved to Appendix B. 1686 o Other minor clarifications, typos etc. 1688 15.2. Changes from -02 to -03 1690 o Abstract: Clarified by removing the term 'aggregated'. Follow-up 1691 clarifications later in draft: S1: expanded PCN-egress-nodes 1692 bullet to mention case where the PCN-feedback-information is about 1693 one (or a few) PCN-marks, rather than aggregated information; S3 1694 clarified PCN-meter; S5 minor changes; conclusion. 1696 o S1: added a paragraph about how the PCN-domain looks to the 1697 outside world (essentially it looks like a DiffServ domain). 1699 o S2: tweaked the PCN-traffic terminology bullet: changed PCN 1700 traffic classes to PCN behaviour aggregates, to be more in line 1701 with traditional DiffServ jargon (-> follow-up changes later in 1702 draft); included a definition of PCN-flows (and corrected a couple 1703 of 'PCN microflows' to 'PCN-flows' later in draft) 1705 o S3.5: added possibility of downgrading to best effort, where PCN- 1706 packets arrive at PCN-ingress-node already ECN marked (CE or ECN 1707 nonce) 1709 o S4: added note about whether talk about PCN operating on an 1710 interface or on a link. In S8.1 (OAM) mentioned that PCN 1711 functionality needs to be configured consistently on either the 1712 ingress or the egress interface of PCN-nodes in a PCN-domain. 1714 o S5.2: clarified that signalling protocol installs flow filter spec 1715 at PCN-ingress-node (& updates after possible re-route) 1717 o S5.6: addressing: clarified 1719 o S5.7: added tunnelling issue of N^2 scaling if you set up a mesh 1720 of tunnels between PCN-boundary-nodes 1722 o S7.3: Clarified the "third viewpoint" of probing (always probe). 1724 o S8.1: clarified that SNMP is only an example; added note that an 1725 operator may be able to not run PCN on some PCN-interior-nodes, if 1726 it knows that these links will never become (pre-)congested; added 1727 note that it may be possible to have different PCN-boundary-node 1728 behaviours for different ingress-egress-aggregates within the same 1729 PCN-domain. 1731 o Appendix: Created an Appendix about "Possible work items beyond 1732 the scope of the current PCN WG Charter". Material moved from 1733 near start of S3 and elsewhere throughout draft. Moved text about 1734 centralised decision node to Appendix. 1736 o Other minor clarifications. 1738 15.3. Changes from -01 to -02 1740 o S1: Benefits: provisioning bullet extended to stress that PCN does 1741 not use RFC2475-style traffic conditioning. 1743 o S1: Deployment models: mentioned, as variant of PCN-domain 1744 extending to end nodes, that may extend to LAN edge switch. 1746 o S3.1: Trust Assumption: added note about not needing PCN-marking 1747 capability if known that an interface cannot become pre-congested. 1749 o S4: now divided into sub-sections 1751 o S4.1: Admission control: added second proposed method for how to 1752 decide to block new flows (PCN-egress-node receives one (or 1753 several) PCN-marked packets). 1755 o S5: Probing sub-section removed. Material now in new S7. 1757 o S5.6: Addressing: clarified how PCN-ingress-node can discover 1758 address of PCN-egress-node 1760 o S5.6: Addressing: centralised node case, added that PCN-ingress- 1761 node may need to know address of PCN-egress-node 1763 o S5.8: Tunnelling: added case of "partially PCN-capable tunnel" and 1764 degraded bullet on this in S6 (Open Issues) 1766 o S7: Probing: new section. Much more comprehensive than old S5.5. 1768 o S8: Operations and Management: substantially revised. 1770 o other minor changes not affecting semantics 1772 15.4. Changes from -00 to -01 1774 In addition to clarifications and nit squashing, the main changes 1775 are: 1777 o S1: Benefits: added one about provisioning (and contrast with 1778 DiffServ SLAs) 1780 o S1: Benefits: clarified that the objective is also to stop PCN- 1781 packets being significantly delayed (previously only mentioned not 1782 dropping packets) 1784 o S1: Deployment models: added one where policing is done at ingress 1785 of access network and not at ingress of PCN-domain (assume trust 1786 between networks) 1788 o S1: Deployment models: corrected MPLS-TE to MPLS 1790 o S2: Terminology: adjusted definition of PCN-domain 1792 o S3.5: Other assumptions: corrected, so that two assumptions (PCN- 1793 nodes not performing ECN and PCN-ingress-node discarding arriving 1794 CE packet) only apply if the PCN WG decides to encode PCN-marking 1795 in the ECN-field. 1797 o S4 & S5: changed PCN-marking algorithm to marking behaviour 1799 o S4: clarified that PCN-interior-node functionality applies for 1800 each outgoing interface, and added clarification: "The 1801 functionality is also done by PCN-ingress-nodes for their outgoing 1802 interfaces (ie those 'inside' the PCN-domain)." 1804 o S4 (near end): altered to say that a PCN-node "should" dedicate 1805 some capacity to lower priority traffic so that it isn't starved 1806 (was "may") 1808 o S5: clarified to say that PCN functionality is done on an 1809 'interface' (rather than on a 'link') 1811 o S5.2: deleted erroneous mention of service level agreement 1813 o S5.5: Probing: re-written, especially to distinguish probing to 1814 test the ingress-egress-aggregate from probing to test a 1815 particular ECMP path. 1817 o S5.7: Addressing: added mention of probing; added that in the case 1818 where traffic is always tunnelled across the PCN-domain, add a 1819 note that he PCN-ingress-node needs to know the address of the 1820 PCN-egress-node. 1822 o S5.8: Tunnelling: re-written, especially to provide a clearer 1823 description of copying on tunnel entry/exit, by adding explanation 1824 (keeping tunnel encaps/decaps and PCN-marking orthogonal), 1825 deleting one bullet ("if the inner header's marking state is more 1826 sever then it is preserved" - shouldn't happen), and better 1827 referencing of other IETF documents. 1829 o S6: Open issues: stressed that "NOTE: Potential solutions are out 1830 of scope for this document" and edited a couple of sentences that 1831 were close to solution space. 1833 o S6: Open issues: added one about scenarios with only one tunnel 1834 endpoint in the PCN domain . 1836 o S6: Open issues: ECMP: added under-admission as another potential 1837 risk 1839 o S6: Open issues: added one about "Silent at start" 1841 o S10: Conclusions: a small conclusions section added 1843 16. Appendix A: Possible work items beyond the scope of the current PCN 1844 WG Charter 1846 This section mentions some topics that are outside the PCN WG's 1847 current Charter, but which have been mentioned as areas of interest. 1848 They might be work items for: the PCN WG after a future re- 1849 chartering; some other IETF WG; another standards body; an operator- 1850 specific usage that's not standardised. 1852 NOTE: it should be crystal clear that this section discusses 1853 possibilities only. 1855 The first set of possibilities relate to the restrictions on scope 1856 imposed by the PCN WG Charter (see Section 3): 1858 o a single PCN-domain encompasses several autonomous systems that 1859 don't trust each other (perhaps by using a mechanism like re-ECN, 1860 [I-D.briscoe-re-pcn-border-cheat]. 1862 o not all the nodes run PCN. For example, the PCN-domain is a 1863 multi-site enterprise network. The sites are connected by a VPN 1864 tunnel; although PCN doesn't operate inside the tunnel, the PCN 1865 mechanisms still work properly because the of the good QoS on the 1866 virtual link (the tunnel). Another example is that PCN is 1867 deployed on the general Internet (ie widely but not universally 1868 deployed). 1870 o applying the PCN mechanisms to other types of traffic, ie beyond 1871 inelastic traffic. For instance, applying the PCN mechanisms to 1872 traffic scheduled with the Assured Forwarding per-hop behaviour. 1873 One example could be flow-rate adaptation by elastic applications, 1874 that adapts according to the pre-congestion information. 1876 o the aggregation assumption doesn't hold, because the link capacity 1877 is too low. Measurement-based admission control is then risky. 1879 o the applicability of PCN mechanisms for emergency use (911, GETS, 1880 WPS, MLPP, etc.) 1882 Other possibilities include: 1884 o The PCN-domain extends to the end users. The scenario is 1885 described in [I-D.babiarz-pcn-sip-cap]. The end users need to be 1886 trusted to do their own policing. This scenario is in the scope 1887 of the PCN WG charter if there is sufficient traffic for the 1888 aggregation assumption to hold. A variant is that the PCN-domain 1889 extends out as far as the LAN edge switch. 1891 o indicating pre-congestion through signalling messages rather than 1892 in-band (in the form of PCN-marked packets) 1894 o the decision-making functionality is at a centralised node rather 1895 than at the PCN-boundary-nodes. This requires that the PCN- 1896 egress-node signals PCN-feedback-information to the centralised 1897 node, and that the centralised node signals to the PCN-ingress- 1898 node about the decision about admission (or termination). It may 1899 also need the centralised node and the PCN-boundary-nodes to know 1900 each other's addresses. It would be possible for the centralised 1901 node to be one of the PCN-boundary-nodes, when clearly the 1902 signalling would sometimes be replaced by a message internal to 1903 the node. 1905 o Signalling extensions for specific protocols (eg RSVP, NSIS). For 1906 example: the details of how the signalling protocol installs the 1907 flowspec at the PCN-ingress-node for an admitted PCN-flow; and how 1908 the signalling protocol carries the PCN-feedback-information. 1909 Perhaps also for other functions such as: coping with failure of a 1910 PCN-boundary-node ([I-D.briscoe-tsvwg-cl-architecture] considers 1911 what happens if RSVP is the QoS signalling protocol); establishing 1912 a tunnel across the PCN-domain if it is necessary to carry ECN 1913 marks transparently. Note: There is a PCN WG Milestone on 1914 "Requirements for signalling", which is potential input for the 1915 appropriate WGs. 1917 o Policing by the PCN-ingress-node may not be needed if the PCN- 1918 domain can trust that the upstream network has already policed the 1919 traffic on its behalf. 1921 o PCN for Pseudowire: PCN may be used as a congestion avoidance 1922 mechanism for edge to edge pseudowire emulations 1923 [I-D.ietf-pwe3-congestion-frmwk]. 1925 o PCN for MPLS: [RFC3270] defines how to support the DiffServ 1926 architecture in MPLS networks. [RFC5129] describes how to add PCN 1927 for admission control of microflows into a set of MPLS aggregates 1928 (Multi-protocol label switching). PCN-marking is done in MPLS's 1929 EXP field (which [I-D.andersson-mpls-expbits-def] proposes to re- 1930 name to the Class of Service (CoS) bits). 1932 o PCN for Ethernet: Similarly, it may be possible to extend PCN into 1933 Ethernet networks, where PCN-marking is done in the Ethernet 1934 header. NOTE: Specific consideration of this extension is outside 1935 the IETF's remit. 1937 . 1939 17. Appendix B: Probing 1941 17.1. Introduction 1943 Probing is an optional mechanism to assist admission control. 1945 PCN's admission control, as described so far, is essentially a 1946 reactive mechanism where the PCN-egress-node monitors the pre- 1947 congestion level for traffic from each PCN-ingress-node; if the level 1948 rises then it blocks new flows on that ingress-egress-aggregate. 1949 However, it's possible that an ingress-egress-aggregate carries no 1950 traffic, and so the PCN-egress-node can't make an admission decision 1951 using the usual method described earlier. 1953 One approach is to be "optimistic" and simply admit the new flow. 1954 However it's possible to envisage a scenario where the traffic levels 1955 on other ingress-egress-aggregates are already so high that they're 1956 blocking new PCN-flows, and admitting a new flow onto this 'empty' 1957 ingress-egress-aggregate adds extra traffic onto the link that's 1958 already pre-congested - which may 'tip the balance' so that PCN's 1959 flow termination mechanism is activated or some packets are dropped. 1960 This risk could be lessened by configuring on each link sufficient 1961 'safety margin' above the PCN-threshold-rate. 1963 An alternative approach is to make PCN a more proactive mechanism. 1964 The PCN-ingress-node explicitly determines, before admitting the 1965 prospective new flow, whether the ingress-egress-aggregate can 1966 support it. This can be seen as a "pessimistic" approach, in 1967 contrast to the "optimism" of the approach above. It involves 1968 probing: a PCN-ingress-node generates and sends probe packets in 1969 order to test the pre-congestion level that the flow would 1970 experience. 1972 One possibility is that a probe packet is just a dummy data packet, 1973 generated by the PCN-ingress-node and addressed to the PCN-egress- 1974 node. Another possibility is that a probe packet is a signalling 1975 packet that is anyway travelling from the PCN-ingress-node to the 1976 PCN-egress-node (eg an RSVP PATH message travelling from source to 1977 destination). 1979 17.2. Probing functions 1981 The probing functions are: 1983 o Make decision that probing is needed. As described above, this is 1984 when the ingress-egress-aggregate (or the ECMP path - Section 8) 1985 carries no PCN-traffic. An alternative is always to probe, ie 1986 probe before admitting every PCN-flow. 1988 o (if required) Communicate the request that probing is needed - the 1989 PCN-egress-node signals to the PCN-ingress-node that probing is 1990 needed 1992 o (if required) Generate probe traffic - the PCN-ingress-node 1993 generates the probe traffic. The appropriate number (or rate) of 1994 probe packets will depend on the PCN-marking algorithm; for 1995 example an excess-traffic-marking algorithm generates fewer PCN- 1996 marks than a threshold-marking algorithm, and so will need more 1997 probe packets. 1999 o Forward probe packets - as far as PCN-interior-nodes are 2000 concerned, probe packets are handled the same as (ordinary data) 2001 PCN-packets, in terms of routing, scheduling and PCN-marking. 2003 o Consume probe packets - the PCN-egress-node consumes probe packets 2004 to ensure that they don't travel beyond the PCN-domain. 2006 17.3. Discussion of rationale for probing, its downsides and open 2007 issues 2009 It is an unresolved question whether probing is really needed, but 2010 three viewpoints have been put forward as to why it is useful. The 2011 first is perhaps the most obvious: there is no PCN-traffic on the 2012 ingress-egress-aggregate. The second assumes that multipath routing 2013 ECMP is running in the PCN-domain. The third viewpoint is that 2014 admission control is always done by probing. We now consider each in 2015 turn. 2017 The first viewpoint assumes the following: 2019 o There is no PCN-traffic on the ingress-egress-aggregate (so a 2020 normal admission decision cannot be made). 2022 o Simply admitting the new flow has a significant risk of leading to 2023 overload: packets dropped or flows terminated. 2025 On the former bullet, [PCN-email-traffic-empty-aggregates] suggests 2026 that, during the future busy hour of a national network with about 2027 100 PCN-boundary-nodes, there are likely to be significant numbers of 2028 aggregates with very few flows under nearly all circumstances. 2030 The latter bullet could occur if a new flow starts on many of the 2031 empty ingress-egress-aggregates and causes overload on a link in the 2032 PCN-domain. To be a problem this would probably have to happen in a 2033 short time period (flash crowd) because, after the reaction time of 2034 the system, other (non-empty) ingress-egress-aggregates that pass 2035 through the link will measure pre-congestion and so block new flows, 2036 and also flows naturally end anyway. 2038 The downsides of probing for this viewpoint are: 2040 o Probing adds delay to the admission control process. 2042 o Sufficient probing traffic has to be generated to test the pre- 2043 congestion level of the ingress-egress-aggregate. But the probing 2044 traffic itself may cause pre-congestion, causing other PCN-flows 2045 to be blocked or even terminated - and in the flash crowd scenario 2046 there will be probing on many ingress-egress-aggregates. 2048 The open issues associated with this viewpoint include: 2050 o What rate and pattern of probe packets does the PCN-ingress-node 2051 need to generate, so that there's enough traffic to make the 2052 admission decision? 2054 o What difficulty does the delay (whilst probing is done) cause 2055 applications, eg packets might be dropped? 2057 o Are there other ways of dealing with the flash crowd scenario? 2058 For instance limit the rate at which new flows are admitted; or 2059 perhaps for a PCN-egress-node to block new flows on its empty 2060 ingress-egress-aggregates when its non-empty ones are pre- 2061 congested. 2063 The second viewpoint applies in the case where there is multipath 2064 routing (ECMP) in the PCN-domain. Note that ECMP is often used on 2065 core networks. There are two possibilities: 2067 (1) If admission control is based on measurements of the ingress- 2068 egress-aggregate, then the viewpoint that probing is useful assumes: 2070 o there's a significant chance that the traffic is unevenly balanced 2071 across the ECMP paths, and hence there's a significant risk of 2072 admitting a flow that should be blocked (because it follows an 2073 ECMP path that is pre-congested) or blocking a flow that should be 2074 admitted. 2076 o Note: [PCN-email-ECMP] suggests unbalanced traffic is quite 2077 possible, even with quite a large number of flows on a PCN-link 2078 (eg 1000) when Assumption 3 (aggregation) is likely to be 2079 satisfied. 2081 (2) If admission control is based on measurements of pre-congestion 2082 on specific ECMP paths, then the viewpoint that probing is useful 2083 assumes: 2085 o There is no PCN-traffic on the ECMP path on which to base an 2086 admission decision. 2088 o Simply admitting the new flow has a significant risk of leading to 2089 overload. 2091 o The PCN-egress-node can match a packet to an ECMP path. 2093 o Note: This is similar to the first viewpoint and so similarly 2094 could occur in a flash crowd if a new flow starts more-or-less 2095 simultaneously on many of the empty ECMP paths. Because there are 2096 several (sometimes many) ECMP paths between each pair of PCN- 2097 boundary-nodes, it's presumably more likely that an ECMP path is 2098 'empty' than an ingress-egress-aggregate. To constrain the number 2099 of ECMP paths, a few tunnels could be set-up between each pair of 2100 PCN-boundary-nodes. Tunnelling also solves the third bullet 2101 (which is otherwise hard because an ECMP routing decision is made 2102 independently on each node). 2104 The downsides of probing for this viewpoint are: 2106 o Probing adds delay to the admission control process. 2108 o Sufficient probing traffic has to be generated to test the pre- 2109 congestion level of the ECMP path. But there's the risk that the 2110 probing traffic itself may cause pre-congestion, causing other 2111 PCN-flows to be blocked or even terminated. 2113 o The PCN-egress-node needs to consume the probe packets to ensure 2114 they don't travel beyond the PCN-domain (eg they might confuse the 2115 destination end node). Hence somehow the PCN-egress-node has to 2116 be able to disambiguate a probe packet from a data packet, via the 2117 characteristic setting of particular bit(s) in the packet's header 2118 or body - but these bit(s) mustn't be used by any PCN-interior- 2119 node's ECMP algorithm. In the general case this isn't possible, 2120 but it should be OK for a typical ECMP algorithm which examines: 2121 the source and destination IP addresses and port numbers, the 2122 protocol ID and the DSCP. 2124 The third viewpoint assumes the following: 2126 o Every admission control decision involves probing, using the 2127 signalling set-up message as the probe packet (eg RSVP PATH). 2129 o The PCN-marking behaviour is such that every packet is PCN-marked 2130 if the flow should be blocked, hence only a single probing packet 2131 is needed. 2133 This viewpoint [I-D.draft-babiarz-pcn-3sm] has in particular been 2134 suggested for the scenario where the PCN-domain reaches out towards 2135 the end terminals (note that it's assumed the trust and aggregation 2136 assumptions still hold), although it has also been suggested for 2137 other scenarios. 2139 18. Informative References 2141 [I-D.briscoe-tsvwg-cl-architecture] 2142 Briscoe, B., "An edge-to-edge Deployment Model for Pre- 2143 Congestion Notification: Admission Control over a 2144 DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04 2145 (work in progress), October 2006. 2147 [I-D.briscoe-tsvwg-cl-phb] 2148 Briscoe, B., "Pre-Congestion Notification marking", 2149 draft-briscoe-tsvwg-cl-phb-03 (work in progress), 2150 October 2006. 2152 [I-D.babiarz-pcn-sip-cap] 2153 Babiarz, J., "SIP Controlled Admission and Preemption", 2154 draft-babiarz-pcn-sip-cap-00 (work in progress), 2155 October 2006. 2157 [I-D.lefaucheur-rsvp-ecn] 2158 Faucheur, F., "RSVP Extensions for Admission Control over 2159 Diffserv using Pre-congestion Notification (PCN)", 2160 draft-lefaucheur-rsvp-ecn-01 (work in progress), 2161 June 2006. 2163 [I-D.chan-pcn-problem-statement] 2164 Chan, K., "Pre-Congestion Notification Problem Statement", 2165 draft-chan-pcn-problem-statement-01 (work in progress), 2166 October 2006. 2168 [I-D.ietf-pwe3-congestion-frmwk] 2169 "Pseudowire Congestion Control Framework", May 2008, . 2173 [I-D.briscoe-tsvwg-ecn-tunnel] 2174 "Layered Encapsulation of Congestion Notification", 2175 July 2008, . 2178 [I-D.charny-pcn-single-marking] 2179 "Pre-Congestion Notification Using Single Marking for 2180 Admission and Termination", November 2007, . 2184 [I-D.eardley-pcn-architecture] 2185 "Pre-Congestion Notification Architecture", June 2007, . 2189 [I-D.westberg-pcn-load-control] 2190 "LC-PCN: The Load Control PCN Solution", February 2008, . 2194 [I-D.behringer-tsvwg-rsvp-security-groupkeying] 2195 "Applicability of Keying Methods for RSVP Security", 2196 November 2007, . 2199 [I-D.briscoe-re-pcn-border-cheat] 2200 "Emulating Border Flow Policing using Re-ECN on Bulk 2201 Data", February 2008, . 2204 [I-D.draft-babiarz-pcn-3sm] 2205 "Three State PCN Marking", November 2007, . 2208 [RFC5129] "Explicit Congestion Marking in MPLS", RFC 5129, 2209 January 2008. 2211 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2212 RFC 4303, December 2005. 2214 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 2215 and W. Weiss, "An Architecture for Differentiated 2216 Services", RFC 2475, December 1998. 2218 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 2219 J., Courtney, W., Davari, S., Firoiu, V., and D. 2220 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 2221 Behavior)", RFC 3246, March 2002. 2223 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 2224 Guidelines for DiffServ Service Classes", RFC 4594, 2225 August 2006. 2227 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2228 of Explicit Congestion Notification (ECN) to IP", 2229 RFC 3168, September 2001. 2231 [RFC2211] Wroclawski, J., "Specification of the Controlled-Load 2232 Network Element Service", RFC 2211, September 1997. 2234 [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., 2235 Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. 2236 Felstaine, "A Framework for Integrated Services Operation 2237 over Diffserv Networks", RFC 2998, November 2000. 2239 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 2240 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 2241 Protocol Label Switching (MPLS) Support of Differentiated 2242 Services", RFC 3270, May 2002. 2244 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 2245 Services in the Internet Architecture: an Overview", 2246 RFC 1633, June 1994. 2248 [RFC2983] Black, D., "Differentiated Services and Tunnels", 2249 RFC 2983, October 2000. 2251 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 2252 Authentication", RFC 2747, January 2000. 2254 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 2255 Architecture for Describing Simple Network Management 2256 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 2257 December 2002. 2259 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 2260 Metric for IP Performance Metrics (IPPM)", RFC 3393, 2261 November 2002. 2263 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 2264 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 2265 November 2005. 2267 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 2268 Zekauskas, "A One-way Active Measurement Protocol 2269 (OWAMP)", RFC 4656, September 2006. 2271 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 2272 Explicit Congestion Notification (ECN) Field", BCP 124, 2273 RFC 4774, November 2006. 2275 [RFC4778] Kaeo, M., "Operational Security Current Practices in 2276 Internet Service Provider Environments", RFC 4778, 2277 January 2007. 2279 [ITU-MLPP] 2280 "Multilevel Precedence and Pre-emption Service (MLPP)", 2281 ITU-T Recommendation I.255.3, 1990. 2283 [Iyer] "An approach to alleviate link overload as observed on an 2284 IP backbone", IEEE INFOCOM , 2003, 2285 . 2287 [Y.1541] "Network Performance Objectives for IP-based Services", 2288 ITU-T Recommendation Y.1541, February 2006. 2290 [P.800] "Methods for subjective determination of transmission 2291 quality", ITU-T Recommendation P.800, August 1996. 2293 [Songhurst] 2294 "Guaranteed QoS Synthesis for Admission Control with 2295 Shared Capacity", BT Technical Report TR-CXR9-2006-001, 2296 Feburary 2006, . 2299 [Menth] "PCN-Based Resilient Network Admission Control: The Impact 2300 of a Single Bit"", Technical Report , 2007, . 2304 [PCN-email-ECMP] 2305 "Email to PCN WG mailing list", November 2007, . 2308 [PCN-email-traffic-empty-aggregates] 2309 "Email to PCN WG mailing list", October 2007, . 2312 [PCN-email-SRLG] 2313 "Email to PCN WG mailing list", March 2008, . 2316 [I-D.eardley-pcn-marking-behaviour] 2317 "Marking behaviour of PCN-nodes", June 2008, . 2321 [I-D.moncaster-pcn-baseline-encoding] 2322 "Baseline Encoding and Transport of Pre-Congestion 2323 Information", July 2008, . 2327 [I-D.moncaster-pcn-3-state-encoding] 2328 "A three state extended PCN encoding scheme", June 2008, < 2329 http://www.ietf.org/internet-drafts/ 2330 draft-moncaster-pcn-3-state-encoding-00.txt>. 2332 [I-D.charny-pcn-comparison] 2333 "Pre-Congestion Notification Using Single Marking for 2334 Admission and Termination", November 2007, . 2338 [I-D.tsou-pcn-racf-applic] 2339 "Applicability Statement for the Use of Pre-Congestion 2340 Notification in a Resource-Controlled Network", 2341 February 2008, . 2344 [I-D.sarker-pcn-ecn-pcn-usecases] 2345 "Usecases and Benefits of end to end ECN support in PCN 2346 Domains", May 2008, . 2349 [I-D.andersson-mpls-expbits-def] 2350 "MPLS EXP-bits definition", March 2008, . 2354 [Menth08] "PCN-Based Admission Control and Flow Termination", 2008, 2355 . 2358 [Hancock] "Slide 14 of 'NSIS: An Outline Framework for QoS 2359 Signalling'", May 2002, . 2362 Author's Address 2364 Philip Eardley 2365 BT 2366 B54/77, Sirius House Adastral Park Martlesham Heath 2367 Ipswich, Suffolk IP5 3RE 2368 United Kingdom 2370 Email: philip.eardley@bt.com 2372 Full Copyright Statement 2374 Copyright (C) The IETF Trust (2008). 2376 This document is subject to the rights, licenses and restrictions 2377 contained in BCP 78, and except as set forth therein, the authors 2378 retain all their rights. 2380 This document and the information contained herein are provided on an 2381 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2382 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2383 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2384 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2385 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2386 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2388 Intellectual Property 2390 The IETF takes no position regarding the validity or scope of any 2391 Intellectual Property Rights or other rights that might be claimed to 2392 pertain to the implementation or use of the technology described in 2393 this document or the extent to which any license under such rights 2394 might or might not be available; nor does it represent that it has 2395 made any independent effort to identify any such rights. Information 2396 on the procedures with respect to rights in RFC documents can be 2397 found in BCP 78 and BCP 79. 2399 Copies of IPR disclosures made to the IETF Secretariat and any 2400 assurances of licenses to be made available, or the result of an 2401 attempt made to obtain a general license or permission for the use of 2402 such proprietary rights by implementers or users of this 2403 specification can be obtained from the IETF on-line IPR repository at 2404 http://www.ietf.org/ipr. 2406 The IETF invites any interested party to bring to its attention any 2407 copyrights, patents or patent applications, or other proprietary 2408 rights that may cover technology that may be required to implement 2409 this standard. Please address the information to the IETF at 2410 ietf-ipr@ietf.org. 2412 Acknowledgment 2414 Funding for the RFC Editor function is provided by the IETF 2415 Administrative Support Activity (IASA).