idnits 2.17.1 draft-ietf-pcn-cl-edge-behaviour-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2010) is 5050 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 132, but not defined == Unused Reference: 'I-D.babiarz-pcn-explicit-marking' is defined on line 675, but no explicit reference was found in the text == Unused Reference: 'I-D.zhang-pcn-performance-evaluation' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'Menth08f' is defined on line 709, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5696 (Obsoleted by RFC 6660) -- No information found for draft-SM-edge-behaviour - is the name correct? -- No information found for draft-babiarz-pcn-explicit-marking - is the name correct? -- No information found for draft-satoh-pcn-performance-termination - is the name correct? -- No information found for draft-zhang-pcn-performance-evaluation - is the name correct? Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Charny 3 Internet-Draft Cisco Systems 4 Intended status: Informational F. Huang 5 Expires: December 28, 2010 Huawei Technologies 6 G. Karagiannis 7 U. Twente 8 M. Menth 9 University of Wuerzburg 10 T. Taylor, Ed. 11 Huawei Technologies 12 June 26, 2010 14 PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of 15 Operation 16 draft-ietf-pcn-cl-edge-behaviour-05 18 Abstract 20 Precongestion notification (PCN) is a means for protecting quality of 21 service for inelastic traffic admitted to a Diffserv domain. The 22 overall PCN architecture is described in RFC 5559. This memo is one 23 of a series describing possible boundary node behaviours for a PCN 24 domain. The behaviour described here is that for a form of 25 measurement-based load control using three PCN marking states, not 26 PCN-marked, threshold-marked, and excess-traffic-marked. This 27 behaviour is known informally as the Controlled Load (CL) PCN edge 28 behaviour. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 28, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Assumed Core Network Behaviour for CL . . . . . . . . . . . . 5 66 3. Node Behaviours . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. Behaviour of the PCN-Egress- Node . . . . . . . . . . . . 7 69 3.2.1. Data Collection . . . . . . . . . . . . . . . . . . . 7 70 3.2.2. Reporting the PCN Data . . . . . . . . . . . . . . . . 7 71 3.2.3. Optional Report Suppression . . . . . . . . . . . . . 8 72 3.2.4. Optional Calculation and Reporting of Congestion 73 Level Estimate . . . . . . . . . . . . . . . . . . . . 8 74 3.3. Behaviour at the Decision Point . . . . . . . . . . . . . 9 75 3.3.1. Flow Admission . . . . . . . . . . . . . . . . . . . . 9 76 3.3.2. Flow Termination . . . . . . . . . . . . . . . . . . . 9 77 3.3.3. Decision Point Action For Missing Egress Node 78 Reports . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.4. Behaviour of the Ingress Node . . . . . . . . . . . . . . 11 80 3.5. Summary of Timers . . . . . . . . . . . . . . . . . . . . 11 81 4. Identifying Ingress and Egress Nodes for PCN Traffic . . . . . 12 82 5. Specification of Diffserv Per- Domain Behaviour . . . . . . . 12 83 5.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 12 84 5.2. Technical Specification . . . . . . . . . . . . . . . . . 13 85 5.3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 13 86 5.4. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 13 87 5.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 14 88 5.6. Example Uses . . . . . . . . . . . . . . . . . . . . . . . 14 89 5.7. Environmental Concerns . . . . . . . . . . . . . . . . . . 14 90 5.8. Security Considerations . . . . . . . . . . . . . . . . . 15 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 96 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 99 1. Introduction 101 The objective of Pre-Congestion Notification (PCN) is to protect the 102 quality of service (QoS) of inelastic flows within a Diffserv domain, 103 in a simple, scalable, and robust fashion. Two mechanisms are used: 104 admission control, to decide whether to admit or block a new flow 105 request, and (in abnormal circumstances) flow termination to decide 106 whether to terminate some of the existing flows. To achieve this, 107 the overall rate of PCN-traffic is metered on every link in the 108 domain, and PCN-packets are appropriately marked when certain 109 configured rates are exceeded. These configured rates are below the 110 rate of the link thus providing notification to boundary nodes about 111 overloads before any congestion occurs (hence the "pre" part of pre- 112 congestion notification). The level of marking allows decisions to 113 be made on whether to admit or terminate individual flows. For more 114 details see [RFC5559]. 116 Boundary node behaviours specify a detailed set of algorithms and 117 edge node behaviours used to implement the PCN mechanisms. Since the 118 algorithms depend on specific metering and marking behaviour at the 119 interior nodes, it is also necessary to specify the assumptions made 120 about interior node behaviour. Finally, because PCN uses DSCP values 121 to carry its markings, a specification of boundary node behaviour 122 must include the per domain behaviour (PDB) template specified in 123 [RFC3086], filled out with the appropriate content. The present 124 document accomplishes these tasks for the controlled load (CL) mode 125 of operation. 127 1.1. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC2119 [RFC2119]. 133 In addition to the terms defined in [RFC5559], this document uses the 134 following terms: 136 Decision Point 137 The node that makes the decision about which flows to admit and to 138 terminate. In a given network deployment, this may be the ingress 139 node or a centralized control node. Regardless of the location of 140 the Decision Point, the ingress node is the point where the 141 decisions are enforced. 143 NM-rate 144 rate of not-marked PCN traffic in octets per second. For further 145 details see Section 3.2.1. 147 ThM-rate 148 rate of threshold-marked PCN traffic in octets per second. For 149 further details see Section 3.2.1. 151 ETM-rate 152 rate of excess-traffic-marked PCN traffic in octets per second. 153 For further details see Section 3.2.1. 155 Congestion level estimate (CLE) 156 A value derived from the measurement of PCN packets received at a 157 PCN-egress-node for a given ingress-egress-aggregate, representing 158 the ratio of marked to total PCN traffic (measured in octets) over 159 a short period. For further details see Section 3.2.4. 161 PCN-admission-state 162 The state ("admit" or "block") derived by the Decision Point for a 163 given ingress-egress-aggregate based on PCN packet marking 164 statistics. The Decision Point decides to admit or block new 165 flows offered to the aggregate based on the current value of the 166 PCN- admission-state. For further details see Section 3.3.1. 168 Admission decision threshold 169 A fractional value to which the Decision Point compares the CLE to 170 determine the PCN-admission-state for a given ingress-egress 171 aggregate. If the CLE is below the admission decision threshold 172 the PCN-admission-state is set to "admit". If the CLE is above 173 the admission decision threshold the PCN-admission-state is set to 174 "block". For further details see Section 3.3.1. 176 2. Assumed Core Network Behaviour for CL 178 This section describes the assumed behaviour for nodes of the PCN- 179 domain when acting in their role as PCN-interior-nodes. The CL mode 180 of operation assumes that: 182 o encoding of PCN status within individual packets is based on 183 [RFC5696], extended to provide a third PCN encoding state. 184 Extensions for this purpose will be specified by the IETF. 185 Possible extensions are documented in [ID.PCN3state] or 186 alternatively [ID.PCN3in1]; 188 o the domain satisfies the conditions specified in the applicable 189 encoding extension document; 191 o on each link the reference rate for the threshold meter is 192 configured to be equal to the PCN-admissible-rate for the link; 194 o on each link the reference rate for the excess traffic meter is 195 configured to be equal to the PCN-supportable-rate for the link; 197 o PCN-interior-nodes perform threshold-marking and excess-traffic- 198 marking of packets according to the rules specified in [RFC5670], 199 and any additional rules specified in the applicable encoding 200 extension document; 202 According to [RFC5696], the encoding extension documents should 203 specify the allowable transitions between marking states. However, 204 to be absolutely clear, these allowable transitions are specified 205 here. At any interior node, the only permitted transitions are 206 these: 208 o a PCN packet which is not-marked (NM) MAY be threshold-marked 209 (ThM) or excess-traffic-marked (ETM); 211 o a PCN packet which is threshold-marked (ThM) MAY be excess- 212 traffic-marked (ETM). 214 An interior node MUST NOT perform any of the following: 216 o re-mark a packet from PCN to non-PCN, or from non-PCN to PCN; 218 o re-mark a PCN packet from threshold-marked (ThM) to not-marked 219 (NM); 221 o re-mark a PCN packet from excess-traffic-marked (ETM) to not- 222 marked (NM) or threshold-marked (ThM). 224 3. Node Behaviours 226 3.1. Overview 228 This section describes the behaviour of the PCN ingress and egress 229 nodes and the Decision Point (which may be collocated with the 230 ingress node). The PCN egress node collects and reports the rates of 231 not-marked, threshold-marked, and excess-traffic-marked PCN traffic 232 to the Decision Point. It may also identify individual flows that 233 have experienced excess-traffic-marking. For a detailed description, 234 see Section 3.2. 236 The PCN ingress node enforces flow admission and termination 237 decisions. It also reports the rate of PCN traffic admitted to a 238 given ingress-egress aggregate when requested by the Decision Point. 239 For details, see Section 3.4. 241 Finally, the Decision Point makes flow admission decisions and 242 selects flows to terminate based on the information provided by the 243 ingress and egress nodes for a given ingress-egress-aggregate. For 244 details, see Section 3.3. 246 3.2. Behaviour of the PCN-Egress- Node 248 3.2.1. Data Collection 250 The PCN-egress-node MUST meter received PCN traffic in order to 251 derive periodically the following rates for each ingress-egress- 252 aggregate passing through it: 254 o NM-rate: octets per second of PCN traffic in packets which are not 255 PCN-marked; 257 o ThM-rate: octets per second of PCN traffic in PCN-threshold- 258 marked packets; 260 o ETM-rate: octets per second of PCN traffic in PCN-excess-marked 261 packets. 263 It is RECOMMENDED that the interval, Tcalc, between calculation of 264 these quantities be in the range of 100 to 500 ms to provide a 265 reasonable tradeoff between signalling demands on the network and the 266 time taken to react to impending congestion. 268 The PCN-traffic SHOULD be metered continuously and the intervals 269 themselves SHOULD be of equal length, to minimize the statistical 270 variance introduced by the measurement process itself. 272 As a configurable option, the PCN-egress-node MAY record flow 273 identifiers of the individual flows for which excess- traffic-marked 274 packets have been observed. These can be used by the Decision Point 275 when it selects flows for termination. 277 In networks using multipath routing it is possible that congestion 278 is not occurring on all paths carrying a given ingress-egress- 279 aggregate. Assuming that specific flows are routed via specific 280 paths, identifying the flows that are experiencing excess-traffic- 281 marking helps to avoid termination of flows not contributing to 282 congestion. 284 3.2.2. Reporting the PCN Data 286 If the report suppression option described in the next sub-section is 287 not enabled, the PCN-egress-node MUST report the latest values of NM- 288 rate, ThM-rate, and ETM-rate to the Decision Point each time that it 289 calculates them. 291 If so configured (e.g., because multi-path routing is being used, as 292 explained in the previous section), the PCN-egress-node MUST also 293 report the set of flow identifiers of flows for which excess-traffic- 294 marking was observed in the most recent measurement interval. 296 3.2.3. Optional Report Suppression 298 Report suppression MUST be provided as a configurable option. If 299 this option is enabled, the PCN-egress-node MUST NOT send a report to 300 the Decision Point for a given ingress-egress-aggregate whenever all 301 of the following conditions are satisfied: 303 o ThM-rate and ETM-rate were zero in the latest interval. 305 o ThM-rate and ETM-rate were zero in the next most recent interval. 307 o Less than time Tmaxnorep has elapsed since the last time the PCN- 308 egress-node sent a report to the Decision Point for the given 309 aggregate, where Tmaxnorep is a configurable value. 311 The above procedure ensures that at least one report is sent per 312 period Tmaxnorep. This provides some protection against loss of 313 egress reports and also demonstrates to the Decision Point that both 314 the PCN-egress-node and the communication path between the two nodes 315 are in operation. However, depending on the transport used for 316 reporting, the operator may choose to set Tmaxnorep to an effectively 317 infinite value. For example, the transport may include its own keep- 318 alive signalling at a sufficient frequency that PCN keep-alive is 319 redundant. 321 3.2.4. Optional Calculation and Reporting of Congestion Level Estimate 323 Congestion level estimate (CLE) calculation and reporting MUST be 324 provided as a configurable option. If this option is enabled, then 325 before sending any report, the PCN-egress-node MUST also calculate a 326 congestion level estimate (CLE) for the measurement interval, for 327 each ingress-egress-aggregate. The CLE is equal to the ratio: 329 (ThM-Rate + ETM-Rate) / (NM-rate + ThM-rate + ETM-rate) 331 if any PCN traffic was observed, or zero otherwise. The PCN-egress- 332 node MUST report the calculated CLE along with the values of NM-rate, 333 ThM-rate, and ETM-rate for the interval. 335 3.3. Behaviour at the Decision Point 337 Operators may choose to deploy just flow admission, or just flow 338 termination, or both. The Decision Point MUST implement both 339 mechanisms, but configurable options MUST be provided to activate or 340 deactivate PCN- based flow admission and flow termination 341 independently of each other at a given Decision Point. 343 3.3.1. Flow Admission 345 The Decision Point determines the PCN-admission-state for a given 346 ingress-egress-aggregate each time it receives a report from the 347 egress node. It makes this determination on the basis of the 348 congestion level estimate (CLE), calculated as described in 349 Section 3.2.4. If the CLE is provided in the egress node report, the 350 Decision Point SHOULD use the reported value. If the CLE was not 351 provided in the report, the Decision Point MUST calculate it. The 352 Decision Point MUST compare the reported or calculated CLE to an 353 admission decision threshold CLElimit. If the CLE is less than the 354 threshold, the PCN-admission-state for that aggregate MUST be set to 355 "admit"; otherwise it MUST be set to "block". 357 The outcome of the comparison is not very sensitive to the value 358 of CLElimit in practice, because when marking occurs it tends to 359 persist long enough that marked traffic becomes a large proportion 360 of the received traffic in a given interval. 362 If the PCN-admission-state for a given ingress-egress-aggregate is 363 "admit", the Decision Point SHOULD allow new flows to be admitted to 364 that aggregate. If the PCN-admission-state for a given ingress- 365 egress-aggregate is "block", the Decision Point SHOULD NOT allow new 366 flows to be admitted to that aggregate. These actions MAY be 367 modified by policy in specific cases, but such policy intervention 368 risks defeating the purpose of using PCN. 370 3.3.2. Flow Termination 372 When the report from the egress node includes a non-zero value of the 373 ETM-Rate for the given ingress-egress-aggregate, the Decision Point 374 MUST request the PCN-ingress-node to provide an estimate of the rate 375 (Admit-Rate) at which PCN-traffic is being admitted to the aggregate. 377 If the Decision Point is collocated with the ingress node, the 378 request and response are internal operations. 380 The Decision Point MUST then wait, for both the requested rate from 381 the ingress node and the next report from the egress node. If this 382 next egress node report also includes a non-zero value for the ETM- 383 Rate, the Decision Point MUST determine an amount of flow to 384 terminate in the following steps: 386 1. The sustainable aggregate rate (SAR) for the given ingress- 387 egress- aggregate is estimated by the sum: 389 SAR = NM-Rate + ThM-Rate 391 for the latest reported interval. 393 2. The amount of traffic that should be terminated is the 394 difference: 396 Admit-Rate - SAR, 398 where Admit-Rate is the value provided by the ingress node. 400 If the difference calculated in the second step is positive, the 401 Decision Point SHOULD select flows to terminate, until it determines 402 that the PCN traffic admission rate will no longer be greater than 403 the estimated sustainable aggregate rate. If the Decision Point 404 knows the bandwidth required by individual flows (e.g., from resource 405 signalling used to establish the flows), it MAY choose to complete 406 its selection of flows to terminate in a single round of decisions. 408 Alternatively, the Decision Point MAY spread flow termination over 409 multiple rounds to avoid over-termination. If this is done, it is 410 RECOMMENDED that enough time elapse between successive rounds of 411 termination to allow the effects of previous rounds to be reflected 412 in the measurements upon which the termination decisions are based 413 (see [I-D.satoh-pcn-performance-termination] and sections 4.2 and 4.3 414 of [Menth08-sub-9]). 416 If the egress node has supplied a list of flow identifiers 417 (Section 3.2), the Decision Point SHOULD first consider terminating 418 flows in that list. In general, the selection of flows for 419 termination MAY be guided by policy. 421 3.3.3. Decision Point Action For Missing Egress Node Reports 423 If the Decision Point fails to receive reports from a given egress 424 node for a configurable interval Tfail, it SHOULD cease to admit 425 flows to that aggregate and raise an alarm to management. This 426 provides some protection against the case where congestion is 427 preventing the transfer of reports from the egress node to the 428 Decision Point. If a report is subsequently received from the egress 429 node concerned, the Decision Point MUST restart failure timing and 430 resume making admission and termination decisions based on the 431 reports it receives. 433 3.4. Behaviour of the Ingress Node 435 The PCN-ingress-node MUST provide the estimated current rate of 436 admitted PCN traffic (octets per second) for a specific ingress- 437 egress-aggregate when the Decision Point requests it. The way this 438 rate estimate is derived is a matter of implementation. 440 For example, the rate that the PCN-ingress-node supplies MAY be 441 based on a quick sample taken at the time the information is 442 required. It is RECOMMENDED that such a sample be based on 443 observation of at least 30 PCN packets to achieve reasonable 444 statistical reliability. 446 3.5. Summary of Timers 448 Table 1 summarizes the timers implied by the preceding procedures. 449 Tcol and Trep are reset upon expiry. Tmon is reset by management 450 action or by receipt of a report from the egress node concerned. 452 +-------+----------+--------------+-----------+---------------------+ 453 | Timer | Location | Incidence | Limit | Action on Expiry | 454 +-------+----------+--------------+-----------+---------------------+ 455 | Tcol | Egress | One per node | Tcalc | Calculate and | 456 | | node | | | possibly report | 457 | | | | | NM-rate, ThM-rate, | 458 | | | | | ETM-rate and | 459 | | | | | optionally CLE for | 460 | | | | | each IEA. | 461 | - | - | - | - | - | 462 | Trep | Egress | One per IEA | Tmaxnorep | Send a report for | 463 | | node | if report | | that IEA at the | 464 | | | suppression | | next expiry of | 465 | | | is enabled. | | Tcol. | 466 | - | - | - | - | - | 467 | Tmon | Decision | One per | Tfail | Assume failure and | 468 | | point | egress node | | cease to admit | 469 | | | | | flows passing | 470 | | | | | through that egress | 471 | | | | | node. | 472 +-------+----------+--------------+-----------+---------------------+ 474 IEA = ingress-egress-aggregate 476 Table 1: Timers Used For the CL Edge Behaviour 478 The value of Tcalc SHOULD be configurable, and is RECOMMENDED to be 479 of the order of 100 to 500 ms. 481 Trep is active only when report suppression is enabled. The value of 482 Tmaxnorep SHOULD be configurable. The appropriate value depends on 483 the transport used to carry the egress node reports. For unreliable 484 transport, Tmaxnorep is RECOMMENDED to be of the order of one second. 486 The value of Tfail MUST be configurable. When unreliable transport 487 is used, the value of Tfail is RECOMMENDED to be of the order of 3 * 488 Tmaxnorep if report suppression is enabled, and of the order of 3 * 489 Tcalc if report suppression is not enabled. When reliable transport 490 is used, the operator may choose to provide similar values for Tfail 491 or may choose to disable report timing by setting an effectively 492 infinite value for Tfail. 494 4. Identifying Ingress and Egress Nodes for PCN Traffic 496 The operation of PCN depends on the ability of the ingress node to 497 identify the ingress-egress-aggregate to which each new flow belongs 498 and the ability of the egress node to identify the aggregate to which 499 each received PCN packet belongs. If the Decision Point is 500 collocated with the ingress node, the egress node also needs to 501 associate each aggregate with the address of the ingress node to 502 which it must send its reports. 504 The means by which this is done depends on the packet routing 505 technology in use in the network. In general, classification of 506 individual packets at the ingress node (for enforcement and metering 507 of admission rates) and at the egress node must use the content of 508 the outer packet header. The process may well require configuration 509 of routing information in the ingress and egress nodes. 511 5. Specification of Diffserv Per- Domain Behaviour 513 This section provides the specification required by [RFC3086] for a 514 per-domain behaviour. 516 5.1. Applicability 518 This section draws heavily upon points made in the PCN architecture 519 document, [RFC5559]. 521 The PCN CL boundary node behaviour specified in this document is 522 applicable to inelastic traffic (particularly video and voice) where 523 quality of service for admitted flows is protected primarily by 524 admission control at the ingress to the domain. In exceptional 525 circumstances (e.g. due to network failures) already-admitted flows 526 may be terminated to protect the quality of service of the remaining 527 flows. The CL boundary node behaviour is less likely to terminate 528 too many flows under such circumstances than the SM boundary node 529 behaviour ([I-D.SM-edge-behaviour]). 531 5.2. Technical Specification 533 The technical specification of the PCN CL per domain behaviour is 534 provided by the contents of [RFC5559], [RFC5696], [RFC5670], the 535 specification of the encoding extension (e.g. [ID.PCN3state], 536 [ID.PCN3in1]), and the present document. 538 5.3. Attributes 540 The purpose of this per-domain behaviour is to achieve low loss and 541 jitter for the target class of traffic. Recovery from overloads 542 through the use of flow termination should happen within 1-3 seconds. 544 5.4. Parameters 546 In the list that follows, note that most PCN-ingress-nodes are also 547 egress nodes, and vice versa. Furthermore, the ingress nodes may be 548 collocated with Decision Points. 550 Parameters at the PCN-ingress-node: 552 o Filters for distinguishing PCN from non-PCN inbound traffic. 554 o The DSCP(s) to be used to mark PCN traffic. 556 o Reference rates on each inward link for the PCN-threshold-rate and 557 PCN-excess-rate; see Section 2. 559 o The information needed to distinguish PCN traffic belonging to a 560 given ingress-egress-aggregate. 562 Parameters at the PCN-egress-node: 564 o The calculation interval Tcalc. 566 o Whether report suppression is enabled and, if so, the value of 567 Tmaxnorep, the maximum interval between reports for a given 568 ingress-egress- aggregate. 570 o Whether calculation and reporting of congestion level estimates is 571 enabled at the PCN-egress-node. 573 o Whether individual flow identifiers must be reported for excess- 574 traffic-marked PCN traffic. 576 o The information needed to distinguish PCN traffic belonging to a 577 given ingress-egress-aggregate. 579 o The marking rules for re-marking PCN traffic leaving the PCN 580 domain. 582 Parameters at each interior node: 584 o Reference rates on each link for the PCN-threshold-rate and PCN- 585 excess-rate; see Section 2. 587 Parameters at the Decision Point: 589 o Activation/deactivation of PCN-based flow admission. 591 o Activation/deactivation of PCN-based flow termination. 593 o The admission decision threshold CLElimit. 595 o The maximum interval Tfail between reports from a given egress 596 node, for detecting failure of communications with that node. 598 o The information needed to map between each ingress-egress- 599 aggregate and its edgepoints, particularly the corresponding 600 ingress node. 602 5.5. Assumptions 604 Assumed that a specific portion of link capacity has been reserved 605 for PCN traffic. 607 5.6. Example Uses 609 The PCN CL behaviour may be used to carry real-time traffic, 610 particularly voice and video. 612 5.7. Environmental Concerns 614 The PCN CL per-domain behaviour may interfere with the use of end- 615 to-end ECN due to reuse of ECN bits for PCN marking. See the 616 applicable PCN marking specifications for details. 618 5.8. Security Considerations 620 Please see the security considerations in Section 6 as well as those 621 in [RFC2474] and [RFC2475]. 623 6. Security Considerations 625 [RFC5559] provides a general description of the security 626 considerations for PCN. This memo introduces no new considerations. 628 7. IANA Considerations 630 This memo includes no request to IANA. 632 8. Acknowledgements 634 The content of this memo bears a family resemblance to 635 [ID.briscoe-CL]. The authors of that document were Bob Briscoe, 636 Philip Eardley, and Dave Songhurst of BT, Anna Charny and Francois Le 637 Faucheur of Cisco, Jozef Babiarz, Kwok Ho Chan, and Stephen Dudley of 638 Nortel, Giorgios Karagiannis of U. Twente and Ericsson, and Attila 639 Bader and Lars Westberg of Ericsson. 641 Ruediger Geib, Philip Eardley, and Bob Briscoe have helped to shape 642 the present document with their comments. 644 9. References 646 9.1. Normative References 648 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 649 "Definition of the Differentiated Services Field (DS 650 Field) in the IPv4 and IPv6 Headers", RFC 2474, 651 December 1998. 653 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 654 and W. Weiss, "An Architecture for Differentiated 655 Services", RFC 2475, December 1998. 657 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 658 Architecture", RFC 5559, June 2009. 660 [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- 661 Nodes", RFC 5670, November 2009. 663 [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline 664 Encoding and Transport of Pre-Congestion Information", 665 RFC 5696, November 2009. 667 9.2. Informative References 669 [I-D.SM-edge-behaviour] 670 Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T. 671 Taylor, "PCN Boundary Node Behaviour for the Single 672 Marking (SM) Mode of Operation (Work in progress)", 673 June 2010. 675 [I-D.babiarz-pcn-explicit-marking] 676 Liu, X. and J. Babiarz, "Simulations Results for 3sM 677 (expired Internet Draft)", July 2007. 679 [I-D.satoh-pcn-performance-termination] 680 Satoh, D., Ueno, H., and M. Menth, "Performance Evaluation 681 of Termination in CL-Algorithm (Work in progress)", 682 July 2009. 684 [I-D.zhang-pcn-performance-evaluation] 685 Zhang, X., "Performance Evaluation of CL-PHB Admission and 686 Termination Algorithms (expired Internet Draft)", 687 July 2007. 689 [ID.PCN3in1] 690 Briscoe, B., "PCN 3-State Encoding Extension in a single 691 DSCP (Work in progress)", February 2010. 693 [ID.PCN3state] 694 Moncaster, T., Briscoe, B., and M. Menth, "A PCN encoding 695 using 2 DSCPs to provide 3 or more states (Work in 696 progress)", February 2010. 698 [ID.briscoe-CL] 699 Briscoe, B., "An edge-to-edge Deployment Model for Pre- 700 Congestion Notification: Admission Control over a 701 DiffServ Region (expired Internet Draft)", 2006. 703 [Menth08-sub-9] 704 Menth, M. and F. Lehrieder, "PCN-Based Measured Rate 705 Termination", July 2009, . 709 [Menth08f] 710 Menth, M. and F. Lehrieder, "Performance Evaluation of 711 PCN-Based Admission Control", in Proceedings of the 16th 712 International Workshop on Quality of Service (IWQoS)", 713 June 2008, . 716 [RFC3086] Nichols, K. and B. Carpenter, "Definition of 717 Differentiated Services Per Domain Behaviors and Rules for 718 their Specification", RFC 3086, April 2001. 720 Authors' Addresses 722 Anna Charny 723 Cisco Systems 724 300 Apollo Drive 725 Chelmsford, MA 01824 726 USA 728 Email: acharny@cisco.com 730 Fortune Huang 731 Huawei Technologies 732 Section F, Huawei Industrial Base, 733 Bantian Longgang, Shenzhen 518129 734 P.R. China 736 Phone: +86 15013838060 737 Email: fqhuang@huawei.com 739 Georgios Karagiannis 740 U. Twente 742 Phone: 743 Email: karagian@cs.utwente.nl 745 Michael Menth 746 University of Wuerzburg 747 Am Hubland 748 Wuerzburg D-97074 749 Germany 751 Phone: +49-931-888-6644 752 Email: menth@informatik.uni-wuerzburg.de 753 Tom Taylor (editor) 754 Huawei Technologies 755 1852 Lorraine Ave 756 Ottawa, Ontario K1H 6Z8 757 Canada 759 Phone: +1 613 680 2675 760 Email: tom111.taylor@bell.net