idnits 2.17.1 draft-chan-pcn-problem-statement-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 726. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 737. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 744. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 750. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 22, 2006) is 6394 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '8' is defined on line 626, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 636, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 643, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 661, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 680, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-briscoe-tsvwg-cl-architecture-03 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-rmd-08 -- Obsolete informational reference (is this intentional?): RFC 2309 (ref. '22') (Obsoleted by RFC 7567) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCN K. Chan 3 Internet-Draft Nortel Networks 4 Intended status: Informational A. Charny 5 Expires: April 25, 2007 Cisco Systems 6 P. Eardley 7 BT Research 8 October 22, 2006 10 Pre-Congestion Notification Problem Statement 11 draft-chan-pcn-problem-statement-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 25, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 DiffServ mechanisms have been developed to support Quality of Service 45 (QoS). However, the level of assurance that can be provided with 46 DiffServ without substantial over-provisioning is limited. Pre- 47 Congestion Notification (PCN) investigates the use of per-flow 48 admission control to provide the required service guarantees for the 49 admitted traffic. While admission control will protect the QoS under 50 normal operating conditions, an additional flow pre-emption mechanism 51 is necessary in the times of heavy congestion (e.g. caused by route 52 changes due to link or node failure). 54 This document provides a problem statement on the addition of flow 55 admission control and flow pre-emption functionality to a DiffServ 56 network, in particular for the support of real time services such as 57 voice and video. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Architecture and Deployment Scenarios . . . . . . . . . . . . 5 65 2.1. Functional Architecture . . . . . . . . . . . . . . . . . 6 66 2.2. Notion of Trust . . . . . . . . . . . . . . . . . . . . . 7 67 2.3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 7 68 3. Standards . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4. Assumptions and Constraints on Problem Scope . . . . . . . . . 9 70 4.1. Assumption 1: Controlled Environment . . . . . . . . . . . 9 71 4.2. Assumption 2: Many Flows and Additional Load . . . . . . . 10 72 4.3. Assumption 3: Real-Time Applications . . . . . . . . . . . 10 73 5. Open Design Issues . . . . . . . . . . . . . . . . . . . . . . 11 74 6. Security Implications . . . . . . . . . . . . . . . . . . . . 12 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 77 9. Informative References . . . . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 79 Intellectual Property and Copyright Statements . . . . . . . . . . 17 81 1. Introduction 83 1.1. Motivation 85 IP networks were initially designed to perform per IP packet 86 forwarding treatment without discrimination. With the increased use 87 of the IP network by applications with different transport functional 88 requirement, the notion of Quality of Service (QoS) was introduced 89 [19]. 91 DiffServ [10] introduced differentiated per packet forwarding 92 treatment to provide QoS: some packets are served at a higher 93 scheduling priority than others. Diffserv Service Classes [18] 94 categorises various DiffServ traffic and recommends how they can be 95 used for packets from applications with different transport 96 requirements. For instance there are Telephony and Real-time 97 Interactive service classes. Applications like these need low loss, 98 low delay and low jitter. A suitable Per Hop Behavior (PHB) is 99 Expedited Forwarding (EF) [16], which works by assuring that packets 100 (usually) encounter very short or empty queues. Each router is 101 allocated a certain amount of bandwidth for the EF PHB, for instance. 102 Excess packets are dropped and delayed, thus leading to poorer QoS 103 for an end user running an application like voice-over-IP. Even if 104 average traffic levels are known, due to traffic variations the level 105 of assurance that can be provided with DiffServ without substantial 106 over-provisioning is limited. 108 To help ensure that the average traffic loads remain within the 109 allocated bandwidth limits, the DiffServ Architecture [10] introduces 110 the idea of policing the amount of traffic in a class as it enters 111 the network. The acceptable traffic level is described by a traffic 112 conditioning agreement (TCA). However, in practice, TCAs police the 113 aggregate traffic in a class at the network ingress, and for 114 scalability reasons typically includes traffic to different 115 destinations. As a result, TCA's do not guarantee that EF aggregate 116 at any given node in the network does not exceed the allocated 117 capacity [21], and so don't ensure that a particular end user's QoS 118 is guaranteed. Also, in practice TCAs are static and so require 119 accurate and/or conservative prediction of the traffic matrix. 121 To cope with the issue of exceeding bandwidth allocation to EF on 122 some links, in practice a policer or shaper is assumed to be 123 installed at the interior nodes as well. However, shaping or 124 policing traffic causes excess packets be dropped and delayed, thus 125 leading to poorer QoS for an end user running an application like 126 voice-over-IP. Even if average traffic levels remain within the 127 allocated bandwidth limits, traffic variations may limit the level of 128 assurance that can be provided with DiffServ without substantial 129 over-provisioning. 131 These factors motivate us to work on per flow admission control for a 132 DiffServ network, and in particular on measurement-based admission 133 control, ie new flow requests are blocked dynamically in response to 134 actual (incipient) congestion on a router within the DiffServ 135 network. 137 However, despite flow admission control, sometimes there can be heavy 138 congestion - for example caused by link or node failure that 139 effectively reduces the network's capacity. The default option is 140 that the QoS of all flows is degraded. However, by pre-empting some 141 flows the QoS of the remaining flows can be protected. The work 142 reported in [7] indicates that in the context where calls have 143 different recongizable precedence levels (e.g. in the context of 144 military/emergency calls [20]), this problem can be partially 145 addressed by dropping lower-precedence calls preferentially while 146 protecting higher precedence calls. However, as it was shown in [6], 147 the need to pre-empt some flows of a given precedence level, while 148 protecting the QoS of the rest of the flows of this precedence level 149 remains. 151 This motivates us to work on per flow pre-emption for a DiffServ 152 network, and in particular on measurement-based pre-emption, ie 153 existing flows are dropped dynamically in response to actual 154 congestion on a router within the DiffServ network. 156 Explicit Congestion Notification (ECN) [15] introduced the idea of a 157 router indicating that it is congested by changing the header of 158 packets ("marking" them). However, ECN in RFC3168 [15] is designed 159 for TCP applications. This motivates us to develop the concept for 160 real-time applications. A router "PCN-marks" packets as an early 161 warning of its incipient congestion ("pre-congestion"). These 162 markings are then used by the admission control and pre-emption 163 mechanisms. 165 The rest of this document discusses our proposed goals, assumptions 166 and some functional architecture directions. 168 1.2. Goals 170 From the functional standpoint, the goal of the proposed PCN approach 171 is twofold: 173 o Flow Admission Control: block admission of new flows as soon as 174 signs of incipient congestion are detected, to prevent congestion 175 / overload. 177 o Flow Pre-emption: If traffic exceeds the desired/allocated 178 capacity (e.g. due to a failure), pre-empt sufficient flows so 179 that the QoS of the remaining flows is protected. 181 The following are proposed as design goals: 183 o The PCN-enabled packet forwarding network should be simple, 184 scalable and robust 186 o Compatibility with other traffic (i.e. a proposed solution should 187 work well when non-PCN traffic is also present in the network) 189 o Support of different types of real-time traffic (eg should work 190 well with CBR and VBR voice and video sources) 192 o Reaction time of the mechanisms should be commensurate with the 193 desired application-level requirements (e.g. a pre-emption 194 mechanism needs to pre-empt flows before significant QoS issues 195 are experienced by all real-time traffic, and before a user hangs 196 up) 198 o Compatibility with different precedence levels of real-time 199 applications (e.g. preferential treatment of higher precedence 200 calls over lower precedence calls, MLPP [20]. 202 2. Architecture and Deployment Scenarios 204 The above goals point to a high-level approach where functionality is 205 split between: 207 o Nodes in the PCN-enabled network, which monitor their own state of 208 (pre) congestion and mark packets if appropriate 210 o Nodes at the edge of the PCN-enabled network, which control 211 admission of new flows and pre-emption of existing flows, based on 212 information from nodes in the network. This information is in the 213 form of the marked packets and not explicit signalling messages. 215 The aim of this split is to keep the bulk of the network simple, 216 scalable and robust, whilst confining policy, application-level and 217 security interactions to the edge of the PCN network. 219 Section 2.1 provides a high-level description of the functional 220 architecture, and Section 2.2 considers some possible deployment 221 scenarios. 223 2.1. Functional Architecture 225 Figure 1 shows a schematic diagram of the high-level functional 226 architecture: 228 +------------------------------------+ 229 | PCN-Region | 230 +------+ +------+ +------+ 231 | | | | | | 232 |PEN A | ----> |PIN A | ----> |PEN B | 233 | | | | | | 234 +------+ +------+ +------+ 235 | | 236 +------------------------------------+ 238 Figure 1: PCN-based Functional Architecture 240 The terms are defined as follows: 242 PCN-Region: 244 A DiffServ region of the Internet running PCN, that is the PCN- 245 based mechanisms are used to decide whether to admit a new flow 246 to the DiffServ region and whether to pre-empt an existing 247 flow. All traffic enters/leaves the PCN-Region through a PCN 248 End Node. Please note that the PCN-Region is also defined by 249 the Diffserv Service Class [18] that is subject to the PCN 250 mechanisms. 252 PCN Interior Node (PIN) (function): 254 The PCN Interior Node is an "on-path" function. It performs 255 traffic metering and PCN-marking: the function that enables a 256 network element to give an early warning of its own incipient 257 congestion ("pre-congestion") on one of its interfaces, ie 258 traffic is above a certain level, by marking, e.g. changing the 259 header of packet(s). 261 PCN End Node (PEN) (function): 263 The PCN End Node is an "on-path" function. The PCN End Node is 264 where the PCN Region ends. It indicates the significance of 265 the PCN packet marking which terminates at this functional 266 node. This functional description does not imply which 267 physical device will implement this function (e.g., edge 268 router, media gateway or end-host). This "on-path" function 269 performs the detection of PCN-marks: the function that monitors 270 PCN-marking to obtain on-path congestion information as 271 signaled through PCN-marking by PCN-enabled Interior Nodes. 272 For PCN's purpose, these actions may include but not be limited 273 to: 275 + Make Flow Admission Control and/or Flow Pre-emption 276 decisions. 278 + Signalling the PCN information to others for making the Flow 279 Admission Control and/or Flow Pre-emption decisions. 281 + Perform measurement of marked packets across multiple IP 282 packets of a flow to derive network information for a flow 283 that a single packet can not provide. 285 + Perform measurement of marked packets across multiple IP 286 flows to derive additional network information. 288 2.2. Notion of Trust 290 With the above Functional Architecture, there exists a notion of 291 trust between the different functional elements: 293 o PENs trusting PINs to provide the correct network information. 295 o PINs trusting PENs that admission control and pre-emption will be 296 administered correctly so the PINs will not be over-whelmed with 297 traffic. 299 o Users/Applications trusting the PENs that they will provide 300 dependable informations for taking application actions. 302 o PENs trusting other PENs that when one PEN performs its task of 303 flow admission control, other PENs will also perform their flow 304 admission control actions. So that the "good citizens" does not 305 get penelized. 307 We discuss some notion of trust further in section 4.1 Assumption 1: 308 Controlled Environment and in section 6 Security Implications. 310 2.3. Deployment Scenarios 312 The previous section describes the functional architecture. The 313 association of these functions to physical devices may depend on the 314 deployment scenario. We make some general comments about the 315 physical devices where the functions above will typically reside: 317 o The PCN Interior Node function typically resides in a network 318 element like a router or a switch where packet forwarding is 319 handled. 321 o The PCN End Node function typically resides in a router, but may 322 also be on a host or a proxy. It is typically the closest PCN- 323 enabled device to the user. 325 Operators of networks will want to use the PCN functions (and 326 standards) in various arrangements, for instance depending on how 327 they are performing admission control outside the PCN-region, their 328 goals beyond those in Section 1.2, and assumptions in addition to 329 those in Section 4. 331 Hence we shall work on several deployment scenarios. Initially we 332 have the following possibilities in mind: 334 o IntServ over DiffServ [14], the DiffServ region is PCN-enabled. 335 This is described in CL Architecture [2]. 337 o SIP-controlled Admission and Pre-emption: trusted SIP endpoints 338 (gateway or host) perform application flow admission and flow pre- 339 emption, based on network information provided by PCN marking. 340 This is described in SIP Controlled Admission and Preemption [4]. 342 o Pseudowire: PCN may be used as a congestion avoidance mechanism 343 for end-user deployed pseudowires (collaborate with the PWE3 WG in 344 investigation of this possibility). 346 3. Standards 348 To solve the PCN functionality described above, we will work on 349 developing a standard for each of the following problems: 351 o How should the measurement of pre-congestion be done at the PINs? 352 For determining when an interior node should mark a packet in 353 order to give early warning of its own congestion? Should there 354 be a standardized algorithm? Or just the required behavior should 355 be standardized? 357 o How should such a mark be encoded by the PINs in a packet (in the 358 ECN and/or DSCP fields)? 360 o How should these markings (at packet granularity) be interpreted 361 by the PENs for making flow admission control and flow pre-emption 362 decisions (at flow granularity)? 364 Initial work addressing these questions has been reported to the IETF 365 in CL Architecture [2], RT ECN [1], NSIS RMD [5]. Note that other 366 options are possible. 368 One of the key questions that need to be answered in the context of 369 standardisation is, what level of detail of standardisation is 370 appropriate for the first bullet? For example, should PCN be 371 specified as an algorithm relating the probability of PCN-marking a 372 packet to (some specific description of the) traffic level? Or 373 something more detailed (e.g. implementation specifics) or less 374 detailed (describe the behaviour in more general terms than an 375 algorithm). We want flexibility, but also want to be sure that 376 different standards-compliant implementations will work together. 378 A similar issue arises for the third bullet. Additionally, it might 379 be possible to specify more than one way of reacting to the PCN- 380 markings. On the plus side, different reaction behaviours may be 381 more suited to different deployment scenarios. But this could 382 require coordination of the PCN End Nodes for a particular PCN- 383 region, so they agreed to use the same reaction behaviour. 385 On the second bullet, CL PHB [3] has some options for how to do the 386 encoding, focussed on use of the ECN field, and an initial analysis 387 of their pros and cons. Another possibility is to use the DSCP 388 field, as in NSIS RMD [5], or a combination of the two. The WG will 389 study the trade-offs between different encoding options. 391 4. Assumptions and Constraints on Problem Scope 393 In order to make rapid progress, initially we will restrict the 394 problem space in several ways. NOTE: Subsequent re-chartering may 395 investigate solutions for when some of these restrictions are not in 396 place. The working assumption is that the standards developed in the 397 initial phase should not need to be modified to satisfy the solutions 398 for when these restrictions are removed. 400 4.1. Assumption 1: Controlled Environment 402 We assume that the PCN-enabled Internet Region is a controlled 403 environment, i.e. all the interior and end nodes of the region run 404 PCN and trust each other. 406 There are several reasons for proposing this assumption: 408 o The PCN-Region has to be fully encircled by a ring of PCN End 409 Nodes, otherwise packets could enter the PCN-Region without being 410 subject to admission control, which would potentially destroy the 411 QoS of existing flows. 413 o Similarly, a PCN End Node has to trust that all the interior 414 routers are doing PCN-marking. A non-PCN router won't be able to 415 alert that it's suffering pre-congestion, which potentially would 416 lead to too many calls being admitted (or too few being pre- 417 empted). Worse, a rogue router could perform attacks such as 418 marking all packets so that no flows were admitted. 420 One way of assuring the above two points is that the entire PCN- 421 region is run by a single operator. Another possibility is that 422 there are several operators but they trust each other to a sufficient 423 level. Please note that this restriction applies to packets in the 424 traffic class that is subject to the PCN mechanisms. 426 4.2. Assumption 2: Many Flows and Additional Load 428 We assume that there are many flows on any bottleneck link in the 429 PCN-enabled region. 431 Measurement-based admission control assumes that the past is a 432 reasonable reflection of the future: the network conditions are 433 measured at the time of a new flow request, however the actual 434 network performance must be OK during the call some time later. 436 One issue is that if there are only a few variable rate flows, then 437 the aggregate traffic level may vary a lot, perhaps enough to cause 438 some packets to get dropped. If there are many flows then the 439 aggregate traffic level should be statistically smoothed. How many 440 flows is enough depends on a number of things such as the variation 441 in each flow's rate, the total PCN bandwidth, and the size of the 442 "safety margin" between the traffic level at which we start PCN- 443 marking and at which packets are dropped. 445 4.3. Assumption 3: Real-Time Applications 447 We assume that packets come from real time applications generating 448 inelastic traffic like voice and video requiring low delay, jitter 449 and packet loss, i.e. as defined by the Controlled Load Service [9]. 451 This assumption is to help focus the effort where it looks like PCN 452 would be most useful, ie the sorts of applications where per flow QoS 453 is a known requirement. For instance, the impact of this assumption 454 would be to guide simulations work. NOTE: PCN should be readily 455 extendible to other applications like ones that typically use Assured 456 Forwarding [12]. 458 5. Open Design Issues 460 Whilst working on the general issues of flow admission control and 461 flow pre-emption, we have found several issues that proved hard to 462 solve. They are briefly documented here - further details are in 463 [2]. In general they seem to be characteristics of most measurement- 464 based admission control schemes, but some may not be relevant to 465 particular deployment scenarios. From the perspective of this 466 problem statement, besides just noting the issue the PCN WG could: 468 o Upgrade the issue, so it's added to the "Goals" section earlier, 469 or to the "Assumptions" section as appropriate 471 o Downgrade the issue, either because it isn't that important or 472 because it's better dealt with outside the PCN solution 474 o Wait and see, ie as the PCN solution is developed assess how much 475 extra complexity solving the issue would add 477 The comments below are about admission control, but generally a 478 similar issue arises for flow pre-emption. 480 ECMP (Equal Cost Multi-Path) Routing: 482 In order to decide whether to admit a new flow, the CL 483 Architecture [2] scheme determines what the ingress and egress 484 PENs would be and measures the current level of PCN-marking 485 between them (Congestion-Level-Estimate). If routers in the 486 PCN-region run ECMP, then traffic between a particular pair of 487 PENs may follow several different paths. The problem is that 488 if just one of the paths is congested such that packets are 489 being PCN-marked, then the Congestion-Level-Estimate measured 490 by the egress PEN will be diluted by unmarked packets from 491 other non-congested paths. 493 Bi-Directional Sessions: 495 CL Architecture [2] describes a flow admission control 496 mechanism. However, from the application perspective, for a 497 bi-directional session the two flows should be admitted as a 498 pair - for instance a bi-directional voice call only makes 499 sense if flows in both directions are admitted. 501 Global Coordination: 503 CL Architecture [2] makes its admission decision based on PCN- 504 markings between a particular pair of PENs. Decisions about 505 flows through a different pair of PENs are made independently. 507 However, one can imagine network topologies and traffic 508 matrices where from a global perspective it would be better to 509 make a coordinated decision across all the pairs of PENs for 510 the whole PCN-region. For example, to block (or even pre-empt) 511 flows on one PEN pair so that more important flows through a 512 different pair could be admitted. 514 Aggregate Traffic Characteristics: 516 Even when the number of flows is stable, the traffic level 517 through the PCN-region will vary because the sources vary their 518 traffic rates. The CL Architecture [2] mechanism works best 519 when there's "some" variability in the total traffic level at a 520 router's interface (ie in the aggregate traffic from all 521 sources). Too much variation means that a router may (at one 522 moment) not be doing any PCN-marking and then (at another 523 moment) be overloaded, ie drop packets. This makes it hard to 524 tune the admission control scheme to stop admitting new flows 525 at the right time. However, too little variation can also be a 526 problem. For example, if all the sources are constant bit rate 527 and are synchronised, then the total traffic level at a 528 router's interface could be (almost) at its capacity and all 529 packets could still be serviced instantly. However, admitting 530 one more flow could tip the router over its capacity, so its 531 queue grew indefinitely until it had to drop packets. "Some" 532 traffic variation means that as the traffic level nears the 533 capacity limit, some packets are PCN-marked but there's still 534 enough capacity to cope with the traffic fluctuations. Hence 535 new flows can be blocked and packets are never dropped. 537 Speed of Reaction: 539 The CL Architecture [2] mechanism has a limited speed of 540 reaction: if a big burst of admission requests occurs in a very 541 short space of time (eg prompted by a televote), they could all 542 get admitted before enough PCN-marks are seen to block new 543 flows. In other words, any additional load offered within the 544 reaction time of the mechanism mustn't move the CL-Region 545 directly from no congestion to overload. 547 6. Security Implications 549 Packets from normal precedence and higher precedence sessions [20] 550 aren't distinguishable by PCN Interior Nodes. This prevents an 551 attacker specifically targeting, in the data plane, higher precedence 552 packets (perhaps for DoS or for eavesdropping). However, PCN End 553 Nodes can access this information to help decide whether to admit or 554 pre-empt a flow. The separation of network information provided by 555 the Interior Nodes and the precedence information at the PCN End 556 Nodes allows simpler, easier and better focused security enforcement. 558 PCN End Nodes police packets to ensure a flow sticks within its 559 agreed limit. This is similar to the existing IntServ behaviour. 560 Between them the PCN End Nodes must fully encircle the PCN-Region, 561 otherwise packets could enter the PCN-Region without being subject to 562 admission control, which would potentially destroy the QoS of 563 existing flows. 565 It is assumed that all the Interior Nodes and PCN End Nodes run PCN 566 and trust each other (ie the PCN-enabled Internet Region is a 567 controlled environment). For instance a non-PCN router wouldn't be 568 able to alert that it's suffering pre-congestion, which potentially 569 would lead to too many calls being admitted (or too few being pre- 570 empted). Worse, a rogue router could perform attacks such as marking 571 all packets so that no flows were admitted. 573 So security requirements are focussed at specific parts of the PCN- 574 Region: 576 The PCN End Nodes become the trust points. The degree of trust 577 required depends on the kinds of decisions it has to make and the 578 kinds of information it needs to make them. For example when the 579 PCN End Node needs to know the contents of the sessions for making 580 the decisions, when the contents are highly classified, the 581 security requirements for the PCN End Nodes involved will also 582 need to be high. 584 PCN-marking by the Interior Nodes along the packet forwarding path 585 needs to be trusted, because the PCN End Nodes rely on this 586 information. 588 7. IANA Considerations 590 To be completed. 592 8. Acknowledgements 594 To be completed. 596 9. Informative References 598 [1] Babiarz, J., "Congestion Notification Process for Real-Time 599 Traffic", draft-babiarz-tsvwg-rtecn-05 (work in progress), 600 October 2005. 602 [2] Briscoe, B., "An edge-to-edge Deployment Model for Pre- 603 Congestion Notification: Admission Control over a DiffServ 604 Region", draft-briscoe-tsvwg-cl-architecture-03 (work in 605 progress), June 2006. 607 [3] Briscoe, B., "Pre-Congestion Notification marking", 608 draft-briscoe-tsvwg-cl-phb-03 (work in progress), October 2006. 610 [4] Babiarz, J., "SIP Controlled Admission and Preemption", 611 draft-babiarz-pcn-sip-cap-00 (work in progress), October 2006. 613 [5] Bader, A., "RMD-QOSM - The Resource Management in Diffserv QOS 614 Model", draft-ietf-nsis-rmd-08 (work in progress), 615 October 2006. 617 [6] Baker, F. and J. Polk, "MLEF Without Capacity Admission Does 618 Not Satisfy MLPP Requirements", 619 draft-ietf-tsvwg-mlef-concerns-00 (work in progress), 620 February 2005. 622 [7] Silverman, S., "Multi-Level Expedited Forwarding Per Hop 623 Behavior (MLEF PHB)", draft-silverman-tsvwg-mlefphb-03 (work in 624 progress), October 2005. 626 [8] Braden, B., Clark, D., and S. Shenker, "Integrated Services in 627 the Internet Architecture: an Overview", RFC 1633, June 1994. 629 [9] Wroclawski, J., "Specification of the Controlled-Load Network 630 Element Service", RFC 2211, September 1997. 632 [10] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of 633 the Differentiated Services Field (DS Field) in the IPv4 and 634 IPv6 Headers", RFC 2474, December 1998. 636 [11] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. 637 Weiss, "An Architecture for Differentiated Services", RFC 2475, 638 December 1998. 640 [12] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured 641 Forwarding PHB Group", RFC 2597, June 1999. 643 [13] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 644 McManus, "Requirements for Traffic Engineering Over MPLS", 645 RFC 2702, September 1999. 647 [14] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., 648 Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. 649 Felstaine, "A Framework for Integrated Services Operation over 650 Diffserv Networks", RFC 2998, November 2000. 652 [15] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of 653 Explicit Congestion Notification (ECN) to IP", RFC 3168, 654 September 2001. 656 [16] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., 657 Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An 658 Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, 659 March 2002. 661 [17] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., 662 Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. 663 Ramakrishnan, "Supplemental Information for the New Definition 664 of the EF PHB (Expedited Forwarding Per-Hop Behavior)", 665 RFC 3247, March 2002. 667 [18] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines 668 for DiffServ Service Classes", RFC 4594, August 2006. 670 [19] "Supporting Real-Time Applications in an Integrated Services 671 Packet Network: Architecture and Mechanisms", Proceedings of 672 SIGCOMM '92 at Baltimore MD, August 1992. 674 [20] "Multilevel Precedence and Pre-emption Service (MLPP)", ITU-T 675 Recommendation I.255.3, 1990. 677 [21] "Economics and Scalability of QoS Solutions", BT Technology 678 Journal Vol 23 No 2, April 2005. 680 [22] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., 681 Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, 682 C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, 683 J., and L. Zhang, "Recommendations on Queue Management and 684 Congestion Avoidance in the Internet", RFC 2309, April 1998. 686 Authors' Addresses 688 Kwok Ho Chan 689 Nortel Networks 690 600 Technology Park Drive 691 Billerica, MA 01821 692 USA 694 Email: khchan@nortel.com 696 Anna Charny 697 Cisco Systems 698 14164 Massachusetts Ave 699 Boxborough, MA 01719 700 USA 702 Email: acharny@cisco.com 704 Philip Eardley 705 BT Research 706 B54/77, Sirius House Adastral Park Martlesham Heath 707 Ipswich, Suffolk IP5 3RE 708 United Kingdom 710 Email: philip.eardley@bt.com 712 Full Copyright Statement 714 Copyright (C) The Internet Society (2006). 716 This document is subject to the rights, licenses and restrictions 717 contained in BCP 78, and except as set forth therein, the authors 718 retain all their rights. 720 This document and the information contained herein are provided on an 721 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 722 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 723 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 724 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 725 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 726 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 728 Intellectual Property 730 The IETF takes no position regarding the validity or scope of any 731 Intellectual Property Rights or other rights that might be claimed to 732 pertain to the implementation or use of the technology described in 733 this document or the extent to which any license under such rights 734 might or might not be available; nor does it represent that it has 735 made any independent effort to identify any such rights. Information 736 on the procedures with respect to rights in RFC documents can be 737 found in BCP 78 and BCP 79. 739 Copies of IPR disclosures made to the IETF Secretariat and any 740 assurances of licenses to be made available, or the result of an 741 attempt made to obtain a general license or permission for the use of 742 such proprietary rights by implementers or users of this 743 specification can be obtained from the IETF on-line IPR repository at 744 http://www.ietf.org/ipr. 746 The IETF invites any interested party to bring to its attention any 747 copyrights, patents or patent applications, or other proprietary 748 rights that may cover technology that may be required to implement 749 this standard. Please address the information to the IETF at 750 ietf-ipr@ietf.org. 752 Acknowledgment 754 Funding for the RFC Editor function is provided by the IETF 755 Administrative Support Activity (IASA).