idnits 2.17.1 draft-ietf-pcn-cl-edge-behaviour-07.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 (September 4, 2010) is 4983 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5696 (Obsoleted by RFC 6660) -- No information found for draft-SM-edge-behaviour - is the name correct? Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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: March 8, 2011 Huawei Technologies 6 G. Karagiannis 7 U. Twente 8 M. Menth 9 University of Wuerzburg 10 T. Taylor, Ed. 11 Huawei Technologies 12 September 4, 2010 14 PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of 15 Operation 16 draft-ietf-pcn-cl-edge-behaviour-07 18 Abstract 20 Pre-congestion notification (PCN) is a means for protecting the 21 quality of service for inelastic traffic admitted to a Diffserv 22 domain. The overall PCN architecture is described in RFC 5559. This 23 memo is one of a series describing possible boundary node behaviours 24 for a PCN-domain. The behaviour described here is that for a form of 25 measurement-based load control using three PCN marking states, not- 26 marked, threshold-marked, and excess-traffic-marked. This behaviour 27 is known informally as the Controlled Load (CL) PCN-boundary-node 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 March 8, 2011. 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 . . . . . . . . . . . . 6 66 3. Node Behaviours . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.2. Behaviour of the PCN-Egress-Node . . . . . . . . . . . . . 8 69 3.2.1. Data Collection . . . . . . . . . . . . . . . . . . . 8 70 3.2.2. Reporting the PCN Data . . . . . . . . . . . . . . . . 9 71 3.2.3. Optional Report Suppression . . . . . . . . . . . . . 9 72 3.3. Behaviour at the Decision Point . . . . . . . . . . . . . 10 73 3.3.1. Flow Admission . . . . . . . . . . . . . . . . . . . . 10 74 3.3.2. Flow Termination . . . . . . . . . . . . . . . . . . . 11 75 3.3.3. Decision Point Action For Missing 76 PCN-Boundary-Node Reports . . . . . . . . . . . . . . 12 77 3.4. Behaviour of the Ingress Node . . . . . . . . . . . . . . 12 78 3.5. Summary of Timers . . . . . . . . . . . . . . . . . . . . 13 79 4. Identifying Ingress and Egress Nodes for PCN Traffic . . . . . 14 80 5. Specification of Diffserv Per-Domain Behaviour . . . . . . . . 14 81 5.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 14 82 5.2. Technical Specification . . . . . . . . . . . . . . . . . 15 83 5.3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 15 84 5.4. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 15 85 5.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 16 86 5.6. Example Uses . . . . . . . . . . . . . . . . . . . . . . . 16 87 5.7. Environmental Concerns . . . . . . . . . . . . . . . . . . 17 88 5.8. Security Considerations . . . . . . . . . . . . . . . . . 17 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 94 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 98 1. Introduction 100 The objective of Pre-Congestion Notification (PCN) is to protect the 101 quality of service of inelastic flows within a Diffserv domain, in a 102 simple, scalable, and robust fashion. Two mechanisms are used: 103 admission control, to decide whether to admit or block a new flow 104 request, and (in abnormal circumstances) flow termination to decide 105 whether to terminate some of the existing flows. To achieve this, 106 the overall rate of PCN-traffic is metered on every link in the PCN- 107 domain, and PCN-packets are appropriately marked when certain 108 configured rates are exceeded. These configured rates are below the 109 rate of the link thus providing notification to PCN-boundary-nodes 110 about incipient overloads before any congestion occurs (hence the 111 "pre" part of pre-congestion notification). The level of marking 112 allows decisions to be made on whether to admit or terminate PCN- 113 flows. For more details see [RFC5559]. 115 PCN-boundary-node behaviours specify a detailed set of algorithms and 116 procedures used to implement the PCN mechanisms. Since the 117 algorithms depend on specific metering and marking behaviour at the 118 interior nodes, it is also necessary to specify the assumptions made 119 about PCN-interior-node behaviour. Finally, because PCN uses DSCP 120 values to carry its markings, a specification of PCN-boundary-node 121 behaviour must include the per domain behaviour (PDB) template 122 specified in [RFC3086], filled out with the appropriate content. The 123 present document accomplishes these tasks for the controlled load 124 (CL) mode of operation. 126 1.1. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC2119 [RFC2119]. 132 In addition to the terms defined in [RFC5559], this document uses the 133 following terms: 135 Decision Point 136 The node that makes the decision about which flows to admit and to 137 terminate. In a given network deployment, this may be the PCN- 138 ingress-node or a centralized control node. Regardless of the 139 location of the Decision Point, the ingress node is the point 140 where the decisions are enforced. 142 NM-rate 143 The rate of not-marked PCN-traffic received at a PCN-egress-node 144 for a given ingress-egress-aggregate in octets per second. For 145 further details see Section 3.2.1. 147 ThM-rate 148 The rate of threshold-marked PCN-traffic received at a PCN-egress- 149 node for a given ingress-egress-aggregate in octets per second. 150 For further details see Section 3.2.1. 152 ETM-rate 153 The rate of excess-traffic-marked PCN-traffic received at a PCN- 154 egress-node for a given ingress-egress-aggregate in octets per 155 second. For further details see Section 3.2.1. 157 PCN-sent-rate 158 The rate of PCN-traffic received at a PCN-ingress-node and 159 destined for a given ingress-egress-aggregate in octets per 160 second. For further details see Section 3.4. 162 Congestion level estimate (CLE) 163 A value derived from the measurement of PCN packets received at a 164 PCN-egress-node for a given ingress-egress-aggregate, representing 165 the ratio of marked to total PCN-traffic (measured in octets) over 166 a short period. The CLE is used to derive the PCN-admission-state 167 (Section 3.3.1) and also by the report suppression procedure 168 (Section 3.2.3) if report suppression is activated. 170 PCN-admission-state 171 The state ("admit" or "block") derived by the Decision Point for a 172 given ingress-egress-aggregate based on PCN packet marking 173 statistics. The Decision Point decides to admit or block new 174 flows offered to the aggregate based on the current value of the 175 PCN-admission-state. For further details see Section 3.3.1. 177 Sustainable aggregate rate (SAR) 178 The estimated maximum rate of PCN-traffic that can be admitted to 179 a given ingress-egress-aggregate at a given moment without risking 180 degradation of quality of service for the admitted flows. The 181 intention is that if the PCN-sent-rate of every ingress-egress- 182 aggregate passing through a given link is limited to its 183 sustainable aggregate rate, the total rate of PCN-traffic flowing 184 through the link will be limited to the PCN-supportable-rate for 185 that link. An estimate of the sustainable aggregate rate for a 186 given ingress-egress-aggregate is derived as part of the flow 187 termination procedure, and is used to determine how much PCN- 188 traffic must be terminated. For further details see 189 Section 3.3.2. 191 CLE-reporting-threshold 192 A configurable value against which the CLE is compared as part of 193 the report suppression procedure. For further details, see 194 Section 3.2.3. 196 CLE-limit 197 A configurable value against which the CLE is compared in order to 198 derive the PCN-admission-state for a given ingress-egress- 199 aggregate. For further details, see Section 3.3.1. 201 T-meas 202 An interval, the value of which is configurable, defining the 203 measurement period at the PCN-egress-node during which statistics 204 relating to PCN-traffic marking are collected. At the end of the 205 interval the values NM-rate, ThM-rate, and ETM-rate as defined 206 above are calculated and a report is sent to the Decision Point, 207 subject to the operation of the report suppression feature. For 208 further details see Section 3.2. 210 T-maxsuppress 211 An interval, the value of which is configurable, after which the 212 PCN-egress-node must send a report to the Decision Point for a 213 given ingress-egress-aggregate regardless of the most recent 214 values of the CLE. This is used as a keep-alive mechanism for 215 signalling between the PCN-egress-node and the Decision Point when 216 report suppression is activated. For further details, see 217 Section 3.2.3. 219 T-fail 220 An interval, the value of which is configurable, after which the 221 Decision Point concludes that communication from a given PCN- 222 egress-node has failed if it has received no reports from the PCN- 223 egress-node during that interval. For further details see 224 Section 3.3.3. 226 2. Assumed Core Network Behaviour for CL 228 This section describes the assumed behaviour for nodes of the PCN- 229 domain when acting in their role as PCN-interior-nodes. The CL mode 230 of operation assumes that: 232 o PCN-interior-nodes perform threshold-marking and excess-traffic- 233 marking of packets according to the rules specified in [RFC5670], 234 and any additional rules specified in the applicable encoding 235 extension document; 237 o encoding of PCN status within individual packets is based on 238 [RFC5696], extended to provide a third PCN encoding state. A 239 possible extension is documented in [ID.PCN3in1]; 241 o the PCN-domain satisfies the conditions specified in the 242 applicable encoding extension document; 244 o on each link the reference rate for the threshold-meter is 245 configured to be equal to the PCN-admissible-rate for the link; 247 o on each link the reference rate for the excess traffic meter is 248 configured to be equal to the PCN-supportable-rate for the link; 250 According to [RFC5696], the encoding extension documents should 251 specify the allowable transitions between marking states. However, 252 to be absolutely clear, these allowable transitions are specified 253 here. At any interior node, the only permitted transitions are 254 these: 256 o a PCN-packet that is not-marked (NM) MAY be threshold-marked (ThM) 257 or excess-traffic-marked (ETM); 259 o a PCN-packet that is threshold-marked (ThM) MAY be excess-traffic- 260 marked (ETM). 262 An interior node MUST NOT perform any of the following: 264 o re-mark a packet from PCN to non-PCN, or from non-PCN to PCN; 266 o re-mark a PCN-packet from threshold-marked (ThM) to not-marked 267 (NM); 269 o re-mark a PCN-packet from excess-traffic-marked (ETM) to not- 270 marked (NM) or threshold-marked (ThM). 272 3. Node Behaviours 274 3.1. Overview 276 This section describes the behaviour of the PCN-ingress-node, PCN- 277 egress-node, and the Decision Point (which may be collocated with the 278 PCN-ingress-node). 280 The PCN-egress-node collects the rates of not-marked, threshold- 281 marked, and excess-traffic-marked PCN-traffic for each ingress- 282 egress-aggregate and reports them to the Decision Point. It may also 283 identify PCN-flows that have experienced excess-traffic-marking. For 284 a detailed description, see Section 3.2. 286 The PCN-ingress-node enforces flow admission and termination 287 decisions. It also reports the rate of PCN-traffic sent to a given 288 ingress-egress-aggregate when requested by the Decision Point. For 289 details, see Section 3.4. 291 Finally, the Decision Point makes flow admission decisions and 292 selects flows to terminate based on the information provided by the 293 PCN-ingress-node and PCN-egress-node for a given ingress-egress- 294 aggregate. For details, see Section 3.3. 296 3.2. Behaviour of the PCN-Egress-Node 298 3.2.1. Data Collection 300 The PCN-egress-node MUST meter received PCN-traffic in order to 301 derive periodically the following rates for each ingress-egress- 302 aggregate passing through it: 304 o NM-rate: octets per second of PCN-traffic in PCN-packets that are 305 not-marked; 307 o ThM-rate: octets per second of PCN-traffic in PCN-packets that are 308 threshold-marked; 310 o ETM-rate: octets per second of PCN-traffic in PCN-packets that are 311 excess-traffic-marked. 313 It is RECOMMENDED that the measurement interval, T-meas, between 314 successive calculations of these quantities be in the range of 100 to 315 500 ms to provide a reasonable tradeoff between signalling demands on 316 the network and the time taken to react to impending congestion. 318 The PCN-traffic SHOULD be metered continuously and the intervals 319 themselves SHOULD be of equal length, to minimize the statistical 320 variance introduced by the measurement process itself. The starting 321 and ending times of the measurement intervals for different ingress- 322 egress-aggregates MAY be the same or MAY be different. 324 As a configurable option, the PCN-egress-node MAY record flow 325 identifiers of the PCN-flows for which excess-traffic-marked packets 326 have been observed. These can be used by the Decision Point when it 327 selects flows for termination. 329 In networks using multipath routing it is possible that congestion 330 is not occurring on all paths carrying a given ingress-egress- 331 aggregate. Assuming that specific PCN-flows are routed via 332 specific paths, identifying the PCN-flows that are experiencing 333 excess-traffic-marking helps to avoid termination of PCN-flows not 334 contributing to congestion. 336 3.2.2. Reporting the PCN Data 338 If the report suppression option described in the next sub-section is 339 not activated, the PCN-egress-node MUST report the latest values of 340 NM-rate, ThM-rate, and ETM-rate to the Decision Point each time that 341 it calculates them. 343 If so configured (e.g., because multipath routing is being used, as 344 explained in the previous section), the PCN-egress-node MUST also 345 report the set of flow identifiers of PCN-flows for which excess- 346 traffic-marking was observed in the most recent measurement interval. 347 If this set is large, the PCN-egress-node MAY report only the most 348 recently excess-traffic-marked PCN-flows rather than the complete 349 set. 351 3.2.3. Optional Report Suppression 353 Report suppression MUST be provided as a configurable option, along 354 with two configurable parameters, the CLE-reporting-threshold and the 355 maximum report suppression interval T-maxsuppress. The default value 356 of the CLE-reporting-threshold is zero. T-maxsuppress is discussed 357 further at the end of this sub-section, but functions as a keep-alive 358 mechanism for signalling between the PCN-egress-node and the Decision 359 Point. 361 If the report suppression option is enabled, the PCN-egress-node MUST 362 apply the following procedure to decide whether to send a report to 363 the Decision Point, rather than sending a report automatically at the 364 end of each measurement interval. 366 1. As well as the quantities NM-rate, ThM-rate, and ETM-rate, the 367 PCN-egress-node MUST calculate the congestion level estimate 368 (CLE) for each measurement interval. The CLE is equal to the 369 ratio: 371 (ThM-rate + ETM-rate) / (NM-rate + ThM-rate + ETM-rate) 373 if any PCN-traffic was observed, or zero otherwise. 375 2. If the calculated CLE for the latest measurement interval or for 376 the immediately previous interval is greater than the CLE- 377 reporting-threshold, then the PCN-egress-node MUST send a report 378 to the Decision Point. The contents of the report are described 379 below. 381 3. If an interval T-maxsuppress has elapsed since the last report 382 was sent to the Decision Point, then the PCN-egress-node MUST 383 send a report to the Decision Point regardless of the CLE value. 385 4. If neither of the preceding conditions holds, the PCN-egress-node 386 MUST NOT send a report for the latest measurement interval. 388 Each report sent to the Decision Point when report suppression has 389 been activated MUST contain the values of NM-rate, ThM-rate, ETM- 390 rate, and CLE that were calculated for the most recent measurement 391 interval. If so configured, the PCN-egress-node MUST also report the 392 set of flow identifiers of PCN-flows for which excess-traffic-marking 393 was observed in the most recent measurement interval. 395 The above procedure ensures that at least one report is sent per 396 interval (T-maxsuppress + T-meas). This provides some protection 397 against loss of egress reports and also demonstrates to the Decision 398 Point that both the PCN-egress-node and the communication path 399 between the two nodes are in operation. However, depending on the 400 transport used for reporting, the operator may choose to set 401 T-maxsuppress to an effectively infinite value. For example, the 402 transport may include its own keep-alive signalling at a frequency 403 such that PCN keep-alive signalling is redundant. 405 3.3. Behaviour at the Decision Point 407 Operators may choose to use PCN procedures just for flow admission, 408 or just for flow termination, or for both. The Decision Point MUST 409 implement both mechanisms, but configurable options MUST be provided 410 to activate or deactivate PCN-based flow admission and flow 411 termination independently of each other at a given Decision Point. 413 If PCN-based flow termination is enabled but PCN-based flow admission 414 is not, flow termination operates as specified in this document. 415 Logically, some other system of flow admission control must be in 416 operation, but the description of such a system is out of scope of 417 this document and depends on local arrangements. 419 3.3.1. Flow Admission 421 The Decision Point determines the PCN-admission-state for a given 422 ingress-egress-aggregate each time it receives a report from the 423 egress node. It makes this determination on the basis of the 424 congestion level estimate (CLE). If the CLE is provided in the 425 egress node report, the Decision Point SHOULD use the reported value. 426 If the CLE was not provided in the report, the Decision Point MUST 427 calculate it based on the other values provided in the report, using 428 the formula 430 CLE = (ThM-rate + ETM-rate) / (NM-rate + ThM-rate + ETM-rate) 432 if any PCN-traffic was observed, or CLE = 0 if all the rates are 433 zero. 435 The Decision Point MUST compare the reported or calculated CLE to a 436 configurable value, the CLE-limit. If the CLE is less than the CLE- 437 limit, the PCN-admission-state for that aggregate MUST be set to 438 "admit"; otherwise it MUST be set to "block". 440 The outcome of the comparison is not very sensitive to the value 441 of the CLE-limit in practice, because when threshold-marking 442 occurs it tends to persist long enough that threshold-marked 443 traffic becomes a large proportion of the received traffic in a 444 given interval. 446 If the PCN-admission-state for a given ingress-egress-aggregate is 447 "admit", the Decision Point SHOULD allow new flows to be admitted to 448 that aggregate. If the PCN-admission-state for a given ingress- 449 egress-aggregate is "block", the Decision Point SHOULD NOT allow new 450 flows to be admitted to that aggregate. These actions MAY be 451 modified by policy in specific cases, but such policy intervention 452 risks defeating the purpose of using PCN. 454 3.3.2. Flow Termination 456 When the report from the PCN-egress-node includes a non-zero value of 457 the ETM-rate for some ingress-egress-aggregate, the Decision Point 458 MUST request the PCN-ingress-node to provide an estimate of the rate 459 (PCN-sent-rate) at which the PCN-ingress-node is receiving PCN- 460 traffic that is destined for the given ingress-egress-aggregate. 462 If the Decision Point is collocated with the PCN-ingress-node, the 463 request and response are internal operations. 465 The Decision Point MUST then wait for both the requested rate from 466 the PCN-ingress-node and the next report from the PCN-egress-node for 467 the ingress-egress-aggregate concerned. If the next egress node 468 report also includes a non-zero value for the ETM-rate, the Decision 469 Point MUST determine an amount of flow to terminate using the 470 following steps: 472 1. The sustainable aggregate rate (SAR) for the given ingress- 473 egress-aggregate is estimated by the sum: 475 SAR = NM-rate + ThM-rate 477 for the latest reported interval. 479 2. The amount of traffic that should be terminated is the 480 difference: 482 PCN-sent-rate - SAR, 484 where PCN-sent-rate is the value provided by the PCN-ingress- 485 node. 487 If the difference calculated in the second step is positive, the 488 Decision Point SHOULD select PCN-flows to terminate, until it 489 determines that the PCN-traffic admission rate will no longer be 490 greater than the estimated sustainable aggregate rate. If the 491 Decision Point knows the bandwidth required by individual PCN-flows 492 (e.g., from resource signalling used to establish the flows), it MAY 493 choose to complete its selection of PCN-flows to terminate in a 494 single round of decisions. 496 Alternatively, the Decision Point MAY spread flow termination over 497 multiple rounds to avoid over-termination. If this is done, it is 498 RECOMMENDED that enough time elapse between successive rounds of 499 termination to allow the effects of previous rounds to be reflected 500 in the measurements upon which the termination decisions are based 501 (see [IEEE-Satoh] and sections 4.2 and 4.3 of [Menth08-sub-9]). 503 If the egress node has supplied a list of PCN-flow identifiers 504 (Section 3.2), the Decision Point SHOULD first consider terminating 505 PCN-flows in that list. In general, the selection of flows for 506 termination MAY be guided by policy. 508 3.3.3. Decision Point Action For Missing PCN-Boundary-Node Reports 510 If the Decision Point fails to receive any report from a given PCN- 511 egress-node for a configurable interval T-fail, it SHOULD raise an 512 alarm to management. A Decision Point collocated with a PCN-ingress- 513 node SHOULD cease to admit PCN-flows to the ingress-egress-aggregate 514 passing from the PCN-ingress-node to the given PCN-egress-node, until 515 it again receives a report from that node. A centralized Decision 516 Point MAY cease to admit PCN-flows to all ingress-egress-aggregates 517 destined to the PCN-egress-node concerned, until it again receives a 518 report from that node. 520 If a centralized Decision Point fails to receive a reply within a 521 reasonable period of time to a request for a PCN-sent-rate value sent 522 to a given PCN-ingress-node, it SHOULD raise an alarm to management. 524 3.4. Behaviour of the Ingress Node 526 The PCN-ingress-node MUST provide the estimated rate of PCN-traffic 527 received at that node and destined for a given ingress-egress- 528 aggregate in octets per second (the PCN-sent-rate) when the Decision 529 Point requests it. The way this rate estimate is derived is a matter 530 of implementation. 532 For example, the rate that the PCN-ingress-node supplies MAY be 533 based on a quick sample taken at the time the information is 534 required. It is RECOMMENDED that such a sample be based on 535 observation of at least 30 PCN-packets to achieve reasonable 536 statistical reliability. 538 3.5. Summary of Timers 540 Table 1 summarizes the timers implied by the preceding procedures. 541 The three limits T-meas, T-maxsuppress, and T-fail apply to the three 542 timers t-meas, t-maxsuppress, and t-fail respectively. t-meas and 543 t-maxsuppress are reset upon expiry. t-fail is reset by management 544 action or by receipt of a report from the PCN-egress-node concerned. 546 +-------------+---------+-------------+--------------+--------------+ 547 | Timer | Locatio | Incidence | Limit | Action on | 548 | | n | | | Expiry | 549 +-------------+---------+-------------+--------------+--------------+ 550 | t-meas | Egress | One per | T-meas | Calculate | 551 | | node | node | | and possibly | 552 | | | | | report | 553 | | | | | NM-rate, | 554 | | | | | ThM-rate, | 555 | | | | | ETM-rate and | 556 | | | | | conditionall | 557 | | | | | yCLE for eac | 558 | | | | | hIEA. | 559 | - | - | - | - | - | 560 | t-maxsuppre | Egress | One per IEA | T-maxsuppres | Send a | 561 | ss | node | if report | s | report for | 562 | | | suppression | | that IEA at | 563 | | | is enabled. | | the next | 564 | | | | | expiry of | 565 | | | | | T-meas. | 566 | - | - | - | - | - | 567 | t-fail | Decisio | One per | T-fail | Assume | 568 | | npoint | egress node | | failure and | 569 | | | | | cease to | 570 | | | | | admit flows | 571 | | | | | passing | 572 | | | | | through that | 573 | | | | | egress node. | 574 +-------------+---------+-------------+--------------+--------------+ 576 IEA = ingress-egress-aggregate 578 Table 1: Timers Used For the CL Boundary Node Behaviour 580 The value of T-meas SHOULD be configurable, and is RECOMMENDED to be 581 of the order of 100 to 500 ms. 583 t-maxsuppress is active only when report suppression is enabled. The 584 value of T-maxsuppress SHOULD be configurable. The appropriate value 585 depends on the transport used to carry the egress node reports. For 586 unreliable transport, T-maxsuppress is RECOMMENDED to be of the order 587 of one second. 589 The value of T-fail MUST be configurable. When unreliable transport 590 is used, the value of T-fail is RECOMMENDED to be of the order of 3 * 591 T-maxsuppress if report suppression is enabled, and of the order of 3 592 * T-meas if report suppression is not enabled. When reliable 593 transport is used, the operator may choose to provide similar values 594 for T-fail or may choose to disable report timing by setting an 595 effectively infinite value for T-fail. 597 4. Identifying Ingress and Egress Nodes for PCN Traffic 599 The operation of PCN depends on the ability of the PCN-ingress-node 600 to identify the ingress-egress-aggregate to which each new PCN-flow 601 belongs and the ability of the egress node to identify the ingress- 602 egress-aggregate to which each received PCN-packet belongs. If the 603 Decision Point is collocated with the PCN-ingress-node, the PCN- 604 egress-node also needs to associate each ingress-egress-aggregate 605 with the address of the PCN-ingress-node to which it must send its 606 reports. 608 The means by which this is done depends on the packet routing 609 technology in use in the network. The procedure to provide the 610 required information is out of the scope of this document. 612 5. Specification of Diffserv Per-Domain Behaviour 614 This section provides the specification required by [RFC3086] for a 615 per-domain behaviour. 617 5.1. Applicability 619 This section draws heavily upon points made in the PCN architecture 620 document, [RFC5559]. 622 The PCN CL boundary node behaviour specified in this document is 623 applicable to inelastic traffic (particularly video and voice) where 624 quality of service for admitted flows is protected primarily by 625 admission control at the ingress to the domain. In exceptional 626 circumstances (e.g. due to network failures) already-admitted flows 627 may be terminated to protect the quality of service of the remaining 628 flows. The CL boundary node behaviour is less likely to terminate 629 too many flows under such circumstances than the SM boundary node 630 behaviour ([I-D.SM-edge-behaviour]). 632 5.2. Technical Specification 634 The technical specification of the PCN CL per domain behaviour is 635 provided by the contents of [RFC5559], [RFC5696], [RFC5670], the 636 specification of the encoding extension (e.g., [ID.PCN3in1]), and the 637 present document. 639 5.3. Attributes 641 The purpose of this per-domain behaviour is to achieve low loss and 642 jitter for the target class of traffic. The design requirement for 643 PCN was that recovery from overloads through the use of flow 644 termination should happen within 1-3 seconds. PCN probably performs 645 better than that. 647 5.4. Parameters 649 In the list that follows, note that most PCN-ingress-nodes are also 650 PCN-egress-nodes, and vice versa. Furthermore, the PCN-ingress-nodes 651 may be collocated with Decision Points. 653 Parameters at the PCN-ingress-node: 654 ----------------------------------- 656 o Filters for distinguishing PCN from non-PCN inbound traffic. 658 o The markings to be applied to PCN-traffic. 660 o Reference rates on each inward link for the PCN-threshold-rate and 661 PCN-excess-rate; see Section 2. 663 o The information needed to distinguish PCN-traffic belonging to a 664 given ingress-egress-aggregate. 666 Parameters at the PCN-egress-node: 667 ---------------------------------- 669 o The measurement interval T-meas. 671 o Whether report suppression is enabled and, if so, the values of 672 the CLE-reporting-threshold and T-maxsuppress. 674 o Whether individual flow identifiers must be reported for excess- 675 traffic-marked PCN-traffic. 677 o The information needed to distinguish PCN-traffic belonging to a 678 given ingress-egress-aggregate. 680 o The marking rules for re-marking PCN-traffic leaving the PCN 681 domain. 683 Parameters at each interior node: 684 --------------------------------- 686 o Reference rates on each link for the PCN-threshold-rate and PCN- 687 excess-rate; see Section 2. 689 o The markings to be applied to PCN-traffic, including the 690 identification of PCN-packets and the encodings to indicate 691 threshold-marking and excess-traffic-marking.. 693 Parameters at the Decision Point: 694 --------------------------------- 696 o Activation/deactivation of PCN-based flow admission. 698 o Activation/deactivation of PCN-based flow termination. 700 o The value of CLE-limit. 702 o The maximum interval T-fail between reports from a given PCN- 703 egress-node, for detecting failure of communications with that 704 node. 706 o The information needed to map between each ingress-egress- 707 aggregate and the corresponding PCN-ingress-node and PCN-egress- 708 node. 710 5.5. Assumptions 712 Assumed that a specific portion of link capacity has been reserved 713 for PCN-traffic. 715 5.6. Example Uses 717 The PCN CL behaviour may be used to carry real-time traffic, 718 particularly voice and video. 720 5.7. Environmental Concerns 722 The PCN CL per-domain behaviour may interfere with the use of end-to- 723 end ECN due to reuse of ECN bits for PCN marking. See the applicable 724 PCN marking specifications for details. 726 5.8. Security Considerations 728 Please see the security considerations in Section 6 as well as those 729 in [RFC2474] and [RFC2475]. 731 6. Security Considerations 733 [RFC5559] provides a general description of the security 734 considerations for PCN. This memo introduces no new considerations. 736 7. IANA Considerations 738 This memo includes no request to IANA. 740 8. Acknowledgements 742 The content of this memo bears a family resemblance to 743 [ID.briscoe-CL]. The authors of that document were Bob Briscoe, 744 Philip Eardley, and Dave Songhurst of BT, Anna Charny and Francois Le 745 Faucheur of Cisco, Jozef Babiarz, Kwok Ho Chan, and Stephen Dudley of 746 Nortel, Giorgios Karagiannis of U. Twente and Ericsson, and Attila 747 Bader and Lars Westberg of Ericsson. 749 Ruediger Geib, Philip Eardley, and Bob Briscoe have helped to shape 750 the present document with their comments. Toby Moncaster gave a 751 careful review to get it into shape for Working Group Last Call. 753 Amongst the authors, Michael Menth deserves special mention for his 754 constant and careful attention to both the technical content of this 755 document and the manner in which it was expressed. 757 9. References 759 9.1. Normative References 761 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 762 Requirement Levels", BCP 14, RFC 2119, March 1997. 764 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 765 "Definition of the Differentiated Services Field (DS 766 Field) in the IPv4 and IPv6 Headers", RFC 2474, 767 December 1998. 769 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 770 and W. Weiss, "An Architecture for Differentiated 771 Services", RFC 2475, December 1998. 773 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 774 Architecture", RFC 5559, June 2009. 776 [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- 777 Nodes", RFC 5670, November 2009. 779 [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline 780 Encoding and Transport of Pre-Congestion Information", 781 RFC 5696, November 2009. 783 9.2. Informative References 785 [I-D.SM-edge-behaviour] 786 Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T. 787 Taylor, "PCN Boundary Node Behaviour for the Single 788 Marking (SM) Mode of Operation (Work in progress)", 789 June 2010. 791 [ID.PCN3in1] 792 Briscoe, B., "PCN 3-State Encoding Extension in a single 793 DSCP (Work in progress)", July 2010. 795 [ID.briscoe-CL] 796 Briscoe, B., "An edge-to-edge Deployment Model for Pre- 797 Congestion Notification: Admission Control over a DiffServ 798 Region (expired Internet Draft)", 2006. 800 [IEEE-Satoh] 801 Satoh, D. and H. Ueno, ""Cause and Countermeasure of 802 Overtermination for PCN-Based Flow Termination", 803 Proceedings of IEEE Symposium on Computers and 804 Communications (ISCC '10), pp. 155-161, Riccione, Italy", 805 June 2010. 807 [Menth08-sub-9] 808 Menth, M. and F. Lehrieder, "PCN-Based Measured Rate 809 Termination", July 2009, 810 . 813 [RFC3086] Nichols, K. and B. Carpenter, "Definition of 814 Differentiated Services Per Domain Behaviors and Rules for 815 their Specification", RFC 3086, April 2001. 817 Authors' Addresses 819 Anna Charny 820 Cisco Systems 821 300 Apollo Drive 822 Chelmsford, MA 01824 823 USA 825 Email: acharny@cisco.com 827 Fortune Huang 828 Huawei Technologies 829 Section F, Huawei Industrial Base, 830 Bantian Longgang, Shenzhen 518129 831 P.R. China 833 Phone: +86 15013838060 834 Email: fqhuang@huawei.com 836 Georgios Karagiannis 837 U. Twente 839 Phone: 840 Email: karagian@cs.utwente.nl 842 Michael Menth 843 University of Wuerzburg 844 Am Hubland 845 Wuerzburg D-97074 846 Germany 848 Phone: +49-931-888-6644 849 Email: menth@informatik.uni-wuerzburg.de 850 Tom Taylor (editor) 851 Huawei Technologies 852 1852 Lorraine Ave 853 Ottawa, Ontario K1H 6Z8 854 Canada 856 Phone: +1 613 680 2675 857 Email: tom111.taylor@bell.net