idnits 2.17.1 draft-ietf-pcn-cl-edge-behaviour-11.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (December 19, 2011) is 4510 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'CL-specific' is mentioned on line 1263, but not defined == Missing Reference: 'CL-Specific' is mentioned on line 310, but not defined == Missing Reference: 'CLE-specific' is mentioned on line 435, but not defined == Unused Reference: 'RFC6040' is defined on line 1408, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5696 (Obsoleted by RFC 6660) -- No information found for draft-tsvwg-rsvp-pcn - is the name correct? Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 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: Experimental F. Huang 5 Expires: June 21, 2012 Huawei Technologies 6 G. Karagiannis 7 U. Twente 8 M. Menth 9 University of Tuebingen 10 T. Taylor, Ed. 11 Huawei Technologies 12 December 19, 2011 14 PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of 15 Operation 16 draft-ietf-pcn-cl-edge-behaviour-11 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 June 21, 2012. 47 Copyright Notice 48 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 65 2. [CL-Specific] Assumed Core Network Behaviour for CL . . . . . 9 66 3. Node Behaviours . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.2. Behaviour of the PCN-Egress-Node . . . . . . . . . . . . . 10 69 3.2.1. Data Collection . . . . . . . . . . . . . . . . . . . 10 70 3.2.2. Reporting the PCN Data . . . . . . . . . . . . . . . . 11 71 3.2.3. Optional Report Suppression . . . . . . . . . . . . . 11 72 3.3. Behaviour at the Decision Point . . . . . . . . . . . . . 12 73 3.3.1. Flow Admission . . . . . . . . . . . . . . . . . . . . 13 74 3.3.2. Flow Termination . . . . . . . . . . . . . . . . . . . 13 75 3.3.3. Decision Point Action For Missing 76 PCN-Boundary-Node Reports . . . . . . . . . . . . . . 14 77 3.4. Behaviour of the Ingress Node . . . . . . . . . . . . . . 16 78 3.5. Summary of Timers and Associated Configurable Durations . 16 79 3.5.1. Recommended Values For the Configurable Durations . . 18 80 4. Specification of Diffserv Per-Domain Behaviour . . . . . . . . 18 81 4.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 18 82 4.2. Technical Specification . . . . . . . . . . . . . . . . . 19 83 4.2.1. Classification and Traffic Conditioning . . . . . . . 19 84 4.2.2. PHB Configuration . . . . . . . . . . . . . . . . . . 19 85 4.3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 20 86 4.4. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 20 87 4.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 20 88 4.6. Example Uses . . . . . . . . . . . . . . . . . . . . . . . 20 89 4.7. Environmental Concerns . . . . . . . . . . . . . . . . . . 20 90 4.8. Security Considerations . . . . . . . . . . . . . . . . . 20 91 5. Operational and Management Considerations . . . . . . . . . . 20 92 5.1. Deployment of the CL Edge Behaviour . . . . . . . . . . . 21 93 5.1.1. Selection of Deployment Options and Global 94 Parameters . . . . . . . . . . . . . . . . . . . . . . 21 95 5.1.2. Specification of Node- and Link-Specific Parameters . 22 96 5.1.3. Installation of Parameters and Policies . . . . . . . 23 97 5.1.4. Activation and Verification of All Behaviours . . . . 24 98 5.2. Management Considerations . . . . . . . . . . . . . . . . 25 99 5.2.1. Event Logging In the PCN Domain . . . . . . . . . . . 25 100 5.2.1.1. Logging Loss and Restoration of Contact . . . . . 25 101 5.2.1.2. Logging Flow Termination Events . . . . . . . . . 27 102 5.2.2. Provision and Use of Counters . . . . . . . . . . . . 28 103 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 105 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 106 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 107 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31 108 9.2. Informative References . . . . . . . . . . . . . . . . . . 31 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 112 1. Introduction 114 The objective of Pre-Congestion Notification (PCN) is to protect the 115 quality of service (QoS) of inelastic flows within a Diffserv domain, 116 in a simple, scalable, and robust fashion. Two mechanisms are used: 117 admission control, to decide whether to admit or block a new flow 118 request, and (in abnormal circumstances) flow termination to decide 119 whether to terminate some of the existing flows. To achieve this, 120 the overall rate of PCN-traffic is metered on every link in the PCN- 121 domain, and PCN-packets are appropriately marked when certain 122 configured rates are exceeded. These configured rates are below the 123 rate of the link thus providing notification to PCN-boundary-nodes 124 about incipient overloads before any congestion occurs (hence the 125 "pre" part of "pre-congestion notification"). The level of marking 126 allows decisions to be made about whether to admit or terminate PCN- 127 flows. For more details see [RFC5559]. 129 Section 3 of this document specifies a detailed set of algorithms and 130 procedures used to implement the PCN mechanisms for the CL mode of 131 operation. Since the algorithms depend on specific metering and 132 marking behaviour at the interior nodes, it is also necessary to 133 specify the assumptions made about PCN-interior-node behaviour 134 (Section 2). Finally, because PCN uses DSCP values to carry its 135 markings, a specification of PCN-boundary-node behaviour MUST include 136 the per domain behaviour (PDB) template specified in [RFC3086], 137 filled out with the appropriate content (Section 4). 139 [RFC EDITOR'S NOTE: you may choose to delete the following paragraph 140 and the "[CL-specific]" tags throughout this document when publishing 141 it, since they are present primarily to aid reviewers. RFCyyyy is 142 the published version of draft-ietf-pcn-sm-edge-behaviour.] 144 A companion document [RFCyyyy] specifies the Single Marking (SM) PCN- 145 boundary-node behaviour. This document and [RFCyyyy] have a great 146 deal of text in common. To simplify the task of the reader, the text 147 in the present document that is specific to the CL PCN-boundary-node 148 behaviour is preceded by the phrase: "[CL-specific]". A similar 149 distinction for SM-specific text is made in [RFCyyyy]. 151 1.1. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 This document uses the following terms defined in Section 2 of 158 [RFC5559]: 160 o PCN-domain; 162 o PCN-ingress-node; 164 o PCN-egress-node; 166 o PCN-interior-node; 168 o PCN-boundary-node; 170 o PCN-flow; 172 o ingress-egress-aggregate (IEA); 174 o [CL-specific] PCN-threshold-rate; 176 o PCN-excess-rate; 178 o PCN-admissible-rate; 180 o PCN-supportable-rate; 182 o PCN-marked; 184 o [CL-specific] threshold-marked; 186 o excess-traffic-marked. 188 It also uses the terms PCN-traffic and PCN-packet, for which the 189 definition is repeated from [RFC5559] because of their importance to 190 the understanding of the text that follows: 192 PCN-traffic, PCN-packets, PCN-BA 193 A PCN-domain carries traffic of different Diffserv behaviour 194 aggregates (BAs) [RFC2474]. The PCN-BA uses the PCN mechanisms to 195 carry PCN-traffic, and the corresponding packets are PCN-packets. 196 The same network will carry traffic of other Diffserv BAs. The 197 PCN-BA is distinguished by a combination of the Diffserv codepoint 198 and the ECN field. 200 This document uses the following terms from [RFC5670]: 202 o [CL-specific] threshold-meter; 204 o excess-traffic-meter. 206 To complete the list of borrowed terms, this document reuses the 207 following terms and abbreviations defined in Section 3 of [RFC5696]: 209 o not-PCN codepoint; 211 o Not-marked (NM) codepoint; 213 o PCN-marked (PM) codepoint; 215 o [CL-specific] Experimental (EXP) codepoint. 217 This document defines the following additional terms: 219 Decision Point 220 The node that makes the decision about which flows to admit and to 221 terminate. In a given network deployment, this can be the PCN- 222 ingress-node or a centralized control node. In either case, the 223 PCN-ingress-node is the point where the decisions are enforced. 225 NM-rate 226 The rate of not-marked PCN-traffic received at a PCN-egress-node 227 for a given ingress-egress-aggregate in octets per second. For 228 further details see Section 3.2.1. 230 [CL-specific] ThM-rate 231 The rate of threshold-marked PCN-traffic received at a PCN-egress- 232 node for a given ingress-egress-aggregate in octets per second. 233 For further details see Section 3.2.1. 235 ETM-rate 236 The rate of excess-traffic-marked PCN-traffic received at a PCN- 237 egress-node for a given ingress-egress-aggregate in octets per 238 second. For further details see Section 3.2.1. 240 PCN-sent-rate 241 The rate of PCN-traffic received at a PCN-ingress-node and 242 destined for a given ingress-egress-aggregate in octets per 243 second. For further details see Section 3.4. 245 Congestion level estimate (CLE) 246 The ratio of PCN-marked to total PCN-traffic (measured in octets) 247 received for a given ingress-egress-aggregate during a given 248 measurement period. The CLE is used to derive the PCN-admission- 249 state (Section 3.3.1) and is also used by the report suppression 250 procedure (Section 3.2.3) if report suppression is activated. 252 PCN-admission-state 253 The state ("admit" or "block") derived by the Decision Point for a 254 given ingress-egress-aggregate based on PCN packet marking 255 statistics. The Decision Point decides to admit or block new 256 flows offered to the aggregate based on the current value of the 257 PCN-admission-state. For further details see Section 3.3.1. 259 Sustainable aggregate rate (SAR) 260 The estimated maximum rate of PCN-traffic that can be carried in a 261 given ingress-egress-aggregate at a given moment without risking 262 degradation of quality of service for the admitted flows. The 263 intention is that if the PCN-sent-rate of every ingress-egress- 264 aggregate passing through a given link is limited to its 265 sustainable aggregate rate, the total rate of PCN-traffic flowing 266 through the link will be limited to the PCN-supportable-rate for 267 that link. An estimate of the sustainable aggregate rate for a 268 given ingress-egress-aggregate is derived as part of the flow 269 termination procedure, and is used to determine how much PCN- 270 traffic needs to be terminated. For further details see 271 Section 3.3.2. 273 CLE-reporting-threshold 274 A configurable value against which the CLE is compared as part of 275 the report suppression procedure. For further details, see 276 Section 3.2.3. 278 CLE-limit 279 A configurable value against which the CLE is compared to 280 determine the PCN-admission-state for a given ingress-egress- 281 aggregate. For further details, see Section 3.3.1. 283 T-meas 284 A configurable time interval that defines the measurement period 285 over which the PCN-egress-node collects statistics relating to 286 PCN-traffic marking. At the end of the interval the PCN-egress- 287 node calculates the values NM-rate, [CL-specific] ThM-rate, and 288 ETM-rate as defined above and sends a report to the Decision 289 Point, subject to the operation of the report suppression feature. 290 For further details see Section 3.2. 292 T-maxsuppress 293 A configurable time interval after which the PCN-egress-node MUST 294 send a report to the Decision Point for a given ingress-egress- 295 aggregate regardless of the most recent values of the CLE. This 296 mechanism provides the Decision Point with a periodic confirmation 297 of liveness when report suppression is activated. For further 298 details, see Section 3.2.3. 300 T-fail 301 An interval after which the Decision Point concludes that 302 communication from a given PCN-egress-node has failed if it has 303 received no reports from the PCN-egress-node during that interval. 304 For further details see Section 3.3.3. 306 T-crit 307 A configurable interval used in the calculation of T-fail. For 308 further details see Section 3.3.3. 310 2. [CL-Specific] Assumed Core Network Behaviour for CL 312 This section describes the assumed behaviour for PCN-interior-nodes 313 in the PCN-domain. The CL mode of operation assumes that: 315 o PCN-interior-nodes perform both threshold-marking and excess- 316 traffic-marking of PCN-packets, according to the rules specified 317 in [RFC5670]; 319 o excess-traffic-marking of PCN-packets uses the PCN-Marked (PM) 320 codepoint defined in [RFC5696]; 322 o threshold-marking of PCN-packets uses the EXP codepoint defined in 323 [RFC5696]; 325 o the PCN-domain satisfies the conditions specified in [RFC5696]; 327 o on each link the reference rate for the threshold-meter is 328 configured to be equal to the PCN-admissible-rate for the link; 330 o on each link the reference rate for the excess-traffic-meter is 331 configured to be equal to the PCN-supportable-rate for the link; 333 o the set of valid codepoint transitions is as shown in Section 4.2 334 of [RFC5696]. 336 3. Node Behaviours 338 3.1. Overview 340 This section describes the behaviour of the PCN-ingress-node, PCN- 341 egress-node, and the Decision Point (which MAY be collocated with the 342 PCN-ingress-node). 344 The PCN-egress-node collects the rates of not-marked, [CL-specific] 345 threshold-marked, and excess-traffic-marked PCN-traffic for each 346 ingress-egress-aggregate and reports them to the Decision Point. 347 [CL-specific] It MAY also identify and report PCN-flows that have 348 experienced excess-traffic-marking. For a detailed description, see 349 Section 3.2. 351 The PCN-ingress-node enforces flow admission and termination 352 decisions. It also reports the rate of PCN-traffic sent to a given 353 ingress-egress-aggregate when requested by the Decision Point. For 354 details, see Section 3.4. 356 Finally, the Decision Point makes flow admission decisions and 357 selects flows to terminate based on the information provided by the 358 PCN-ingress-node and PCN-egress-node for a given ingress-egress- 359 aggregate. For details, see Section 3.3. 361 Specification of a signaling protocol to report rates to the Decision 362 Point is out of scope of this document. If the PCN-ingress-node is 363 chosen as the Decision Point, [I-D.tsvwg-rsvp-pcn] specifies an 364 appropriate signaling protocol. 366 3.2. Behaviour of the PCN-Egress-Node 368 3.2.1. Data Collection 370 The PCN-egress-node MUST meter the PCN-traffic it receives in order 371 to calculate the following rates for each ingress-egress-aggregate 372 passing through it. These rates SHOULD be calculated at the end of 373 each measurement period based on the PCN-traffic observed during that 374 measurement period. The duration of a measurement period is equal to 375 the configurable value T-meas. 377 o NM-rate: octets per second of PCN-traffic in PCN-packets that are 378 not-marked (i.e., marked with the NM codepoint); 380 o [CL-specific] ThM-rate: octets per second of PCN-traffic in PCN- 381 packets that are threshold-marked (i.e., marked with the EXP 382 codepoint); 384 o ETM-rate: octets per second of PCN-traffic in PCN-packets that are 385 excess-traffic-marked (i.e., marked with the PM codepoint). 387 Informative note: metering the PCN-traffic continuously and using 388 equal-length measurement intervals minimizes the statistical variance 389 introduced by the measurement process itself. On the other hand, the 390 operation of PCN is not affected if the starting and ending times of 391 the measurement intervals for different ingress-egress-aggregates are 392 different. 394 [CL-specific] As a configurable option, the PCN-egress-node MAY 395 record flow identifiers of the PCN-flows for which excess-traffic- 396 marked packets have been observed during this measurement interval. 397 If this set is large (e.g., more than 20 flows), the PCN-egress-node 398 MAY record only the most recently excess-traffic-marked PCN-flow 399 identifiers rather than the complete set. 401 These can be used by the Decision Point when it selects flows for 402 termination. In networks using multipath routing it is possible 403 that congestion is not occurring on all paths carrying a given 404 ingress-egress-aggregate. Assuming that specific PCN-flows are 405 routed via specific paths, identifying the PCN-flows that are 406 experiencing excess-traffic-marking helps to avoid termination of 407 PCN-flows not contributing to congestion. 409 3.2.2. Reporting the PCN Data 411 Unless the report suppression option described in Section 3.2.3 is 412 activated, the PCN-egress-node MUST report the latest values of NM- 413 rate, [CL-specific] ThM-rate, and ETM-rate to the Decision Point each 414 time that it calculates them. 416 [CL-specific] If the PCN-egress-node recorded a set of flow 417 identifiers of PCN-flows for which excess-traffic-marking was 418 observed in the most recent measurement interval, then it MUST also 419 include these identifiers in the report. 421 3.2.3. Optional Report Suppression 423 Report suppression MUST be provided as a configurable option, along 424 with two configurable parameters, the CLE-reporting-threshold and the 425 maximum report suppression interval T-maxsuppress. The default value 426 of the CLE-reporting-threshold is zero. The CLE-reporting-threshold 427 MUST NOT exceed the CLE-limit configured at the Decision Point. For 428 further information on T-maxsuppress see Section 3.5. 430 If the report suppression option is enabled, the PCN-egress-node MUST 431 apply the following procedure to decide whether to send a report to 432 the Decision Point, rather than sending a report automatically at the 433 end of each measurement interval. 435 1. As well as the quantities NM-rate, [CLE-specific] ThM-rate, and 436 ETM-rate, the PCN-egress-node MUST calculate the congestion level 437 estimate (CLE) for each measurement interval. The CLE is 438 computed as: 440 [CL-specific] 441 CLE = (ThM-rate + ETM-rate) / (NM-rate + ThM-rate + ETM-rate) 443 if any PCN-traffic was observed, or CLE = 0 if all the rates are 444 zero. 446 2. If the CLE calculated for the latest measurement interval is 447 greater than the CLE-reporting-threshold and/or the CLE 448 calculated for the immediately previous interval was greater than 449 the CLE-reporting-threshold, then the PCN-egress-node MUST send a 450 report to the Decision Point. The contents of the report are 451 described below. 453 The reason for taking into account the CLE of the previous 454 interval is to ensure that the Decision Point gets immediate 455 feedback if the CLE has dropped below CLE-reporting-threshold. 456 This is essential if the Decision Point is running the flow 457 termination procedure and observing whether (further) flow 458 termination is needed. See Section 3.3.2. 460 3. If an interval T-maxsuppress has elapsed since the last report 461 was sent to the Decision Point, then the PCN-egress-node MUST 462 send a report to the Decision Point regardless of the CLE value. 464 4. If neither of the preceding conditions holds, the PCN-egress-node 465 MUST NOT send a report for the latest measurement interval. 467 Each report sent to the Decision Point when report suppression has 468 been activated MUST contain the values of NM-rate, [CL-specific] ThM- 469 rate, ETM-rate, and CLE that were calculated for the most recent 470 measurement interval. [CL-specific] If the PCN-egress-node recorded 471 a set of flow identifiers of PCN-flows for which excess-traffic- 472 marking was observed in the most recent measurement interval, then it 473 MUST also include these identifiers in the report. 475 The above procedure ensures that at least one report is sent per 476 interval (T-maxsuppress + T-meas). This demonstrates to the Decision 477 Point that both the PCN-egress-node and the communication path 478 between that node and the Decision Point are in operation. 480 3.3. Behaviour at the Decision Point 482 Operators can choose to use PCN procedures just for flow admission, 483 or just for flow termination, or for both. A compliant Decision 484 Point MUST implement both mechanisms, but configurable options MUST 485 be provided to activate or deactivate PCN-based flow admission and 486 flow termination independently of each other at a given Decision 487 Point. 489 If PCN-based flow termination is enabled but PCN-based flow admission 490 is not, flow termination operates as specified in this document. 492 Logically, some other system of flow admission control is in 493 operation, but the description of such a system is out of scope of 494 this document and depends on local arrangements. 496 3.3.1. Flow Admission 498 The Decision Point determines the PCN-admission-state for a given 499 ingress-egress-aggregate each time it receives a report from the 500 egress node. It makes this determination on the basis of the 501 congestion level estimate (CLE). If the CLE is provided in the 502 egress node report, the Decision Point SHOULD use the reported value. 503 If the CLE was not provided in the report, the Decision Point MUST 504 calculate it based on the other values provided in the report, using 505 the formula: 507 [CL-specific] 508 CLE = (ThM-rate + ETM-rate) / (NM-rate + ThM-rate + ETM-rate) 510 if any PCN-traffic was observed, or CLE = 0 if all the rates are 511 zero. 513 The Decision Point MUST compare the reported or calculated CLE to a 514 configurable value, the CLE-limit. If the CLE is less than the CLE- 515 limit, the PCN-admission-state for that aggregate MUST be set to 516 "admit"; otherwise it MUST be set to "block". 518 If the PCN-admission-state for a given ingress-egress-aggregate is 519 "admit", the Decision Point SHOULD allow new flows to be admitted to 520 that aggregate. If the PCN-admission-state for a given ingress- 521 egress-aggregate is "block", the Decision Point SHOULD NOT allow new 522 flows to be admitted to that aggregate. These actions MAY be 523 modified by policy in specific cases, but such policy intervention 524 risks defeating the purpose of using PCN. 526 A performance study of this admission control method is presented in 527 [MeLe12]. 529 3.3.2. Flow Termination 531 [CL-specific] When the report from the PCN-egress-node includes a 532 non-zero value of the ETM-rate for some ingress-egress-aggregate, the 533 Decision Point MUST request the PCN-ingress-node to provide an 534 estimate of the rate (PCN-sent-rate) at which the PCN-ingress-node is 535 receiving PCN-traffic that is destined for the given ingress-egress- 536 aggregate. 538 If the Decision Point is collocated with the PCN-ingress-node, the 539 request and response are internal operations. 541 The Decision Point MUST then wait, for both the requested rate from 542 the PCN-ingress-node and the next report from the PCN-egress-node for 543 the ingress-egress-aggregate concerned. If this next egress node 544 report also includes a non-zero value for the ETM-rate, the Decision 545 Point MUST determine the amount of PCN-traffic to terminate using the 546 following steps: 548 1. [CL-specific] The sustainable aggregate rate (SAR) for the given 549 ingress-egress-aggregate is estimated by the sum: 551 SAR = NM-rate + ThM-rate 553 for the latest reported interval. 555 2. The amount of traffic to be terminated is the difference: 557 PCN-sent-rate - SAR, 559 where PCN-sent-rate is the value provided by the PCN-ingress- 560 node. 562 See Section 3.3.3 for a discussion of appropriate actions if the 563 Decision Point fails to receive a timely response to its request for 564 the PCN-sent-rate. 566 If the difference calculated in the second step is positive, the 567 Decision Point SHOULD select PCN-flows to terminate, until it 568 determines that the PCN-traffic admission rate will no longer be 569 greater than the estimated sustainable aggregate rate. If the 570 Decision Point knows the bandwidth required by individual PCN-flows 571 (e.g., from resource signalling used to establish the flows), it MAY 572 choose to complete its selection of PCN-flows to terminate in a 573 single round of decisions. 575 Alternatively, the Decision Point MAY spread flow termination over 576 multiple rounds to avoid over-termination. If this is done, it is 577 RECOMMENDED that enough time elapse between successive rounds of 578 termination to allow the effects of previous rounds to be reflected 579 in the measurements upon which the termination decisions are based. 580 (See [IEEE-Satoh] and sections 4.2 and 4.3 of [MeLe10].) 582 In general, the selection of flows for termination MAY be guided by 583 policy. [CL-specific] If the egress node has supplied a list of 584 identifiers of PCN-flows that experienced excess-traffic-marking 585 (Section 3.2), the Decision Point SHOULD first consider terminating 586 PCN-flows in that list. 588 3.3.3. Decision Point Action For Missing PCN-Boundary-Node Reports 590 The Decision Point SHOULD start a timer t-recvFail when it receives a 591 report from the PCN-egress-node. t-recvFail is reset each time a new 592 report is received from the PCN-egress-node. t-recvFail expires if it 593 reaches the value T-fail. T-fail is calculated according to the 594 following logic: 596 a. T-fail = the configurable duration T-crit, if report suppression 597 is not deployed; 599 b. T-fail = T-crit also if report suppression is deployed and the 600 last report received from the PCN-egress-node contained a CLE 601 value greater than CLE-reporting-threshold (Section 3.2.3); 603 c. T-fail = 3 * T-maxsuppress (Section 3.2.3) if report suppression 604 is deployed and the last report received from the PCN-egress-node 605 contained a CLE value less than or equal to CLE-reporting- 606 threshold. 608 If timer t-recvFail expires for a given PCN-egress-node, the Decision 609 Point SHOULD notify management. A Decision Point collocated with a 610 PCN-ingress-node SHOULD cease to admit PCN-flows to the ingress- 611 egress-aggregate associated with the given PCN-egress-node, until it 612 again receives a report from that node. A centralized Decision Point 613 MAY cease to admit PCN-flows to all ingress-egress-aggregates 614 destined to the PCN-egress-node concerned, until it again receives a 615 report from that node. 617 A centralized Decision Point SHOULD start a timer t-sndFail when it 618 sends a request for the estimated value of PCN-sent-rate to a given 619 PCN-ingress-node. If the Decision Point fails to receive a response 620 from the PCN-ingress-node before t-sndFail reaches the configurable 621 value T-crit, the Decision Point SHOULD repeat the request but MAY 622 also use ETM-rate as an estimate of the amount of traffic to be 623 terminated in place of the quantity 625 PCN-sent-rate - SAR 627 specified in Section 3.3.2. Because this will over-estimate the 628 amount of traffic to be terminated due to dropping of PCN-packets by 629 interior nodes, the Decision Point SHOULD use multiple rounds of 630 termination under these circumstances. If the second request to the 631 PCN-ingress-node also fails, the Decision Point SHOULD notify 632 management. 634 The use of T-crit is an approximation. A more precise limit would 635 be of the order of two round-trip times, plus an allowance for 636 processing at each end, plus an allowance for variance in these 637 values. 639 See Section 3.5 for suggested values of the configurable durations 640 T-crit and T-maxsuppress. 642 3.4. Behaviour of the Ingress Node 644 The PCN-ingress-node MUST provide the estimated current rate of PCN- 645 traffic received at that node and destined for a given ingress- 646 egress-aggregate in octets per second (the PCN-sent-rate) when the 647 Decision Point requests it. The way this rate estimate is derived is 648 a matter of implementation. 650 For example, the rate that the PCN-ingress-node supplies MAY be 651 based on a quick sample taken at the time the information is 652 required. 654 3.5. Summary of Timers and Associated Configurable Durations 656 Here is a summary of the timers used in the procedures just 657 described: 659 t-meas 661 Where used: PCN-egress-node. 663 Used in procedure: data collection (Section 3.2.1). 665 Incidence: one per ingress-egress-aggregate. 667 Reset: immediately on expiry. 669 Expiry: when it reaches the configurable duration T-meas. 671 Action on expiry: calculate NM-rate, [CL-specific] ThM-rate, 672 and ETM-rate and proceed to the applicable reporting procedure 673 (Section 3.2.2 or Section 3.2.3). 675 t-maxsuppress 677 Where used: PCN-egress-node. 679 Used in procedure: report suppression (Section 3.2.3). 681 Incidence: one per ingress-egress-aggregate. 683 Reset: when the next report is sent, either after expiry or 684 because the CLE has exceeded the reporting threshold. 686 Expiry: when it reaches the configurable duration 687 T-maxsuppress. 689 Action on expiry: send a report to the Decision Point the next 690 time the reporting procedure (Section 3.2.3) is invoked, 691 regardless of the value of CLE. 693 t-recvFail 695 Where used: Decision Point. 697 Used in procedure: failure detection (Section 3.3.3). 699 Incidence: one per ingress-egress-aggregate. 701 Reset: when a report is received for the ingress-egress- 702 aggregate. 704 Expiry: when it reaches the calculated duration T-fail. As 705 described in Section 3.3.3, T-fail is equal either to the 706 configured duration T-crit or to the calculated value 3 * 707 T-maxsuppress, where T-maxsuppress is a configured duration. 709 Action on expiry: notify management, and possibly other 710 actions. 712 t-sndFail 714 Where used: centralized Decision Point. 716 Used in procedure: failure detection (Section 3.3.3). 718 Incidence: only as required, one per outstanding request to a 719 PCN-ingress-node. 721 Started: when a request for the value of PCN-sent-traffic for a 722 given ingress-egress-aggregate is sent to the PCN-ingress-node. 724 Terminated without action: when a response is received before 725 expiry. 727 Expiry: when it reaches the configured duration T-crit. 729 Action on expiry: repeat the request, but use an approximation 730 for the estimate of amount of traffic to terminate. After two 731 failures, notify management and stop repeating the request. 733 3.5.1. Recommended Values For the Configurable Durations 735 The timers just described depend on three configurable durations, 736 T-meas, T-maxsuppress, and T-crit. The recommendations given below 737 for the values of these durations are all related to the intended PCN 738 reaction time of 1 to 3 seconds. However, they are based on 739 judgement rather than operational experience or mathematical 740 derivation. 742 The value of T-meas is RECOMMENDED to be of the order of 100 to 500 743 ms to provide a reasonable tradeoff between demands on network 744 resources (PCN-egress-node and Decision Point processing, network 745 bandwidth) and the time taken to react to impending congestion. 747 The value of T-maxsuppress is RECOMMENDED to be on the order of 3 to 748 6 seconds, for similar reasons to those for the choice of T-meas. 750 The value of T-crit SHOULD NOT be less than 3 * T-meas. Otherwise it 751 could cause too many management notifications due to transient 752 conditions in the PCN-egress-node or along the signalling path. A 753 reasonable upper bound on T-crit is in the order of 3 seconds. 755 4. Specification of Diffserv Per-Domain Behaviour 757 This section provides the specification required by [RFC3086] for a 758 per-domain behaviour. 760 4.1. Applicability 762 This section quotes [RFC5559]. 764 The PCN CL boundary node behaviour specified in this document is 765 applicable to inelastic traffic (particularly video and voice) where 766 quality of service for admitted flows is protected primarily by 767 admission control at the ingress to the domain. 769 In exceptional circumstances (e.g., due to rerouting as a result of 770 network failures) already-admitted flows MAY be terminated to protect 771 the quality of service of the remaining flows. [CL-specific] The 772 performance results in, e.g., [MeLe10], indicate that the CL boundary 773 node behaviour provides better service outcomes under such 774 circumstances than the SM boundary node behaviour described in 775 [RFCyyyy], because CL is less likely to terminate PCN-flows 776 unnecessarily. 778 [RFC EDITOR'S NOTE: please replace RFCyyyy above by the reference to 779 the published version of draft-ietf-pcn-sm-edge-behaviour.] 781 4.2. Technical Specification 783 4.2.1. Classification and Traffic Conditioning 785 This section paraphrases the applicable portions of Sections 3.6 and 786 4.2 of [RFC5559]. 788 Packets at the ingress to the domain are classified as either PCN or 789 non-PCN. Non-PCN packets MAY share the network with PCN packets 790 within the domain. Because the encoding specified in [RFC5696] and 791 used in this document requires the use of the ECN fields, PCN- 792 ingress-nodes MUST prevent ECN-capable traffic that uses the same 793 DSCP as PCN from entering the PCN-domain directly. The PCN-ingress- 794 node can accomplish this in three ways. The choice between these 795 depends on local policy. 797 o ECN-capable traffic MAY be dropped. This policy is NOT 798 RECOMMENDED, since it prevents the proper operation of end-to-end 799 ECN as a means of controlling congestion. 801 o ECN-capable traffic MAY be assigned a different DSCP from PCN 802 traffic. This could mean that it is relegated to a lower-priority 803 behaviour aggregate. 805 o ECN-capable traffic MAY be tunneled across the PCN-domain. If 806 this is done, the PCN-ingress-node MUST mark packets as either 807 not-PCN or PCN-not-marked only after the encapsulation of the 808 packet, including any initial setting of the ECN field, has been 809 completed. 811 PCN packets are further classified as belonging or not belonging to 812 an admitted flow. PCN packets not belonging to an admitted flow are 813 dropped. Packets belonging to an admitted flow are policed to ensure 814 that they adhere to the rate or flowspec that was negotiated during 815 flow admission. 817 4.2.2. PHB Configuration 819 The PCN CL boundary node behaviour is a metering and marking 820 behaviour rather than a scheduling behaviour. As a result, while the 821 encoding uses a single DSCP value, that value MAY vary from one 822 deployment to another. The PCN working group suggests using 823 admission control for the following service classes (defined in 824 [RFC4594]): 826 o Telephony (EF) 827 o Real-time interactive (CS4) 829 o Broadcast Video (CS3) 831 o Multimedia Conferencing (AF4) 833 For a fuller discussion, see Section A.1 of Appendix A of [RFC5696]. 835 4.3. Attributes 837 The purpose of this per-domain behaviour is to achieve low loss and 838 jitter for the target class of traffic. The design requirement for 839 PCN was that recovery from overloads through the use of flow 840 termination SHOULD happen within 1-3 seconds. PCN probably performs 841 better than that. 843 4.4. Parameters 845 The set of parameters that needs to be configured at each PCN-node 846 and at the Decision Point is described in Section 5.1. 848 4.5. Assumptions 850 It is assumed that a specific portion of link capacity has been 851 reserved for PCN-traffic. 853 4.6. Example Uses 855 The PCN CL behaviour MAY be used to carry real-time traffic, 856 particularly voice and video. 858 4.7. Environmental Concerns 860 The PCN CL per-domain behaviour can interfere with the use of end-to- 861 end ECN due to reuse of ECN bits for PCN marking. See Appendix B of 862 [RFC5696] for details. 864 4.8. Security Considerations 866 Please see the security considerations in [RFC5559] as well as those 867 in [RFC2474] and [RFC2475]. 869 5. Operational and Management Considerations 870 5.1. Deployment of the CL Edge Behaviour 872 Deployment of the PCN Controlled Load edge behaviour requires the 873 following steps: 875 o selection of deployment options and global parameter values; 877 o derivation of per-node and per-link information; 879 o installation, but not activation, of parameters and policies at 880 all of the nodes in the PCN domain; 882 o activation and verification of all behaviours. 884 5.1.1. Selection of Deployment Options and Global Parameters 886 The first set of decisions affects the operation of the network as a 887 whole. To begin with, the operator needs to make basic design 888 decisions such as whether the Decision Point is centralized or 889 collocated with the PCN-ingress-nodes, and whether per-flow and 890 aggregate resource signalling as described in [I-D.tsvwg-rsvp-pcn] is 891 deployed in the network. After that, the operator needs to decide: 893 o whether PCN packets will be forwarded unencapsulated or in tunnels 894 between the PCN-ingress-node and the PCN-egress-node. 895 Encapsulation preserves incoming ECN settings and simplifies the 896 PCN-egress-node's job when it comes to relating incoming packets 897 to specific ingress-egress-aggregates, but lowers the path MTU and 898 imposes the extra labour of encapsulation/decapsulation on the 899 PCN-edge-nodes. 901 o which service classes will be subject to PCN control and what 902 Diffserv code point (DSCP) will be used for each. (See [RFC5696] 903 Appendix A.1 for advice on this topic.) 905 o the markings to be used at all nodes in the PCN domain to indicate 906 Not-Marked (NM), [CL-specific] Threshold-Marked (ThM), and Excess- 907 Traffic-Marked (ETM) PCN packets; 909 o The marking rules for re-marking PCN-traffic leaving the PCN 910 domain; 912 o whether PCN-based flow admission is enabled; 914 o whether PCN-based flow termination is enabled. 916 The following parameters affect the operation of PCN itself. The 917 operator needs to choose: 919 o the value of CLE-limit if PCN-based flow admission is enabled. 920 [CL-specific] The operation of flow admission is not very 921 sensitive to the value of the CLE-limit in practice, because when 922 threshold-marking occurs it tends to persist long enough that 923 threshold-marked traffic becomes a large proportion of the 924 received traffic in a given interval. 926 o the value of the collection interval T-meas. For a recommended 927 range of values see Section 3.5.1 above. 929 o whether report suppression is to be enabled at the PCN-egress- 930 nodes and if so, the values of CLE-reporting-threshold and 931 T-maxsuppress. It is reasonable to leave CLE-reporting-threshold 932 at its default value (zero, as specified in Section 3.2.3). For a 933 recommended range of values of T-maxsuppress see Section 3.5.1 934 above. 936 o the value of the duration T-crit, which the Decision Point uses in 937 deciding whether communications with a given PCN-edge-node have 938 failed. For a recommended range of values of T-crit see 939 Section 3.5.1 above. 941 o [CL-specific] Activation/deactivation of recording of individual 942 flow identifiers when excess-traffic-marked PCN-traffic is 943 observed. Reporting these identifiers has value only if PCN-based 944 flow termination is activated and Equal Cost Multi-Path (ECMP) 945 routing is enabled in the PCN-domain. 947 5.1.2. Specification of Node- and Link-Specific Parameters 949 Each PCN-ingress-node needs filters to classify incoming PCN packets 950 according to ingress-egress-aggregate, both to satisfy Decision Point 951 requests for sent traffic rates and, if applicable, to support 952 encapsulation. If PCN packets are being tunneled to the PCN-egress- 953 nodes (encapsulation), the PCN-ingress-node also needs the address of 954 the PCN-egress-node for each ingress-egress-aggregate. 956 Each PCN-egress-node needs filters to classify incoming PCN packets 957 by ingress-egress-aggregate, in order to gather measurements on a 958 per-aggregate basis. The PCN-egress-node also needs to know the 959 address of the Decision Point to which it sends reports for each 960 ingress-egress-aggregate. 962 If [I-D.tsvwg-rsvp-pcn] is deployed and the Decision Points are 963 collocated with the PCN-ingress-nodes, this information can be built 964 up dynamically from the contents of the end-to-end RSVP signalling 965 and does not have to be pre-configured. Otherwise the filters have 966 to be derived from the routing tables in use in the domain, and the 967 address of the peer at the other end of each ingress-egress-aggregate 968 has to be tabulated for each PCN-edge-node. 970 A centralized Decision Point needs to have the address of the PCN- 971 ingress-node corresponding to each ingress-egress-aggregate. 972 Security considerations require that information also be prepared for 973 a centralized Decision Point and each PCN-edge-node to allow them to 974 authenticate each other. 976 Turning to link-specific parameters, the operator needs to derive 977 values for the PCN-supportable-rate and [CL-specific] PCN-admissible- 978 rate on each link in the network. The first two paragraphs of 979 Section 5.2.2 of [RFC5559] discuss how these values may be derived. 981 5.1.3. Installation of Parameters and Policies 983 As discussed in the previous two sections, every PCN node needs to be 984 provisioned with a number of parameters and policies relating to its 985 behaviour in processing incoming packets. The Diffserv MIB [RFC3289] 986 can be useful for this purpose, although it needs to be extended in 987 some cases. This MIB covers packet classification, metering, 988 counting, policing and dropping, and marking. The required 989 extensions specifically include objects for re-marking the ECN field 990 at the PCN-ingress-node and an extension to the classifiers to 991 include the ECN field at PCN-interior and PCN-egress-nodes. In 992 addition, the MIB has to be extended to include a potential 993 encapsulation action following re-classification by ingress-egress- 994 aggregate. Finally, new metering algorithms may need to be defined 995 at the PCN-interior-nodes to handle threshold-marking and packet- 996 size-independent excess-traffic-marking. 998 Values for the PCN-supportable-rate and [CL-specific] PCN-admissible- 999 rate on each link on a node appear as metering parameters. Operators 1000 should take note of the need to deploy meters of a given type 1001 (threshold or excess-traffic) either on the ingress side or the 1002 egress of each interior link, but not both (Appendix B.2 of 1003 [RFC5670]. 1005 The following additional information has to be configured by other 1006 means (e.g., additional MIBs, NETCONF models). 1008 At the PCN-egress-node: 1010 o the measurement interval T-meas (units of ms, range 50 to 1000); 1012 o whether specific flow identifiers must be captured when excess- 1013 traffic-marked packets are observed; 1015 o whether report suppression is to be applied; 1017 o if so, the interval T-maxsuppress (units of 100 ms, range 1 to 1018 100) and the CLE-reporting-threshold (units of tenths of one 1019 percent, range 0 to 1000, default value 0); 1021 o the address of the PCN-ingress-node for each ingress-egress- 1022 aggregate, if the Decision Point is collocated with the PCN- 1023 ingress-node and [I-D.tsvwg-rsvp-pcn] is not deployed. 1025 o the address of the centralized Decision Point to which it sends 1026 its reports, if there is one. 1028 At the Decision Point: 1030 o whether PCN-based flow admission is enabled; 1032 o whether PCN-based flow termination is enabled. 1034 o the value of CLE-limit (units of tenths of one percent, range 0 to 1035 1000); 1037 o the value of the interval T-crit (units of 100 ms, range 1 to 1038 100); 1040 o whether report suppression is to be applied; 1042 o if so, the interval T-maxsuppress (units of 100 ms, range 1 to 1043 100) and the CLE-reporting-threshold (units of tenths of one 1044 percent, range 0 to 1000, default value 0). These MUST be the 1045 same values that are provisioned in the PCN-egress-nodes; 1047 o if the Decision Point is centralized, the address of the PCN- 1048 ingress-node (and any other information needed to establish a 1049 security association) for each ingress-egress-aggregate. 1051 Depending on the testing strategy, it may be necessary to install the 1052 new configuration data in stages. This is discussed further below. 1054 5.1.4. Activation and Verification of All Behaviours 1056 It is certainly not within the scope of this document to advise on 1057 testing strategy, which operators undoubtedly have well in hand. 1058 Quite possibly an operator will prefer an incremental approach to 1059 activation and testing. Implementing the PCN marking scheme at PCN- 1060 ingress-nodes, corresponding scheduling behaviour in downstream 1061 nodes, and re-marking at the PCN-egress-nodes is a large enough step 1062 in itself to require thorough testing before going further. 1064 Testing will probably involve the injection of packets at individual 1065 nodes and tracking of how the node processes them. This work can 1066 make use of the counter capabilities included in the Diffserv MIB. 1067 The application of these capabilities to the management of PCN is 1068 discussed in the next section. 1070 5.2. Management Considerations 1072 This section focuses on the use of event logging and the use of 1073 counters supported by the Diffserv MIB [RFC3289] for the various 1074 monitoring tasks involved in management of a PCN network. 1076 5.2.1. Event Logging In the PCN Domain 1078 It is anticipated that event logging using SYSLOG [RFC5424] will be 1079 needed for fault management and potentially for capacity management. 1080 Implementations MUST be capable of generating logs for the following 1081 events: 1083 o detection of loss of contact between a Decision Point and a PCN- 1084 edge-node, as described in Section 3.3.3; 1086 o successful receipt of a report from a PCN-egress-node, following 1087 detection of loss of contact with that node; 1089 o flow termination events. 1091 All of these logs are generated by the Decision Point. There is a 1092 strong likelihood in the first and third cases that the events are 1093 correlated with network failures at a lower level. This has 1094 implications for how often specific event types should be reported, 1095 so as not to contribute unnecessarily to log buffer overflow. 1096 Recommendations on this topic follow for each event report type. 1098 5.2.1.1. Logging Loss and Restoration of Contact 1100 Section 3.3.3 describes the circumstances under which the Decision 1101 Point may determine that it has lost contact, either with a PCN- 1102 ingress-node or a PCN-egress-node, due to failure to receive an 1103 expected report. Loss of contact with a PCN-ingress-node is a case 1104 primarily applicable when the Decision Point is in a separate node. 1105 However, implementations MAY implement logging in the collocated case 1106 if the implementation is such that non-response to a request from the 1107 Decision Point function can occasionally occur due to processor load 1108 or other reasons. 1110 The log reporting the loss of contact with a PCN-egress-node MUST 1111 include the following content: 1113 o The HOSTNAME field MUST identify the Decision Point issuing the 1114 log. 1116 o A STRUCTURED-DATA element MUST be present, containing parameters 1117 identifying the node for which an expected report has not been 1118 received and the type of report lost (ingress or egress). It is 1119 RECOMMENDED that the SD-ID for the STRUCTURED-DATA element have 1120 the form "PCNNode" (without the quotes), which has been registered 1121 with IANA. The node identifier PARAM-NAME is RECOMMENDED to be 1122 "ID" (without the quotes). The identifier itself is subject to 1123 the preferences expressed in Section 6.2.4 of [RFC5424] for the 1124 HOSTNAME field. The report type PARAM-NAME is RECOMMENDED to be 1125 "RTyp" (without the quotes). The PARAM-VALUE for the RTyp field 1126 MUST be either "ingr" or "egr". 1128 The following values are also RECOMMENDED for the indicated fields in 1129 this log, subject to local practice: 1131 o PRI initially set to 115, representing a Facility value of (14) 1132 "log alert" and a Severity level of (3) "Error Condition". Note 1133 that loss of contact with a PCN-egress-node implies that no new 1134 flows will be admitted to one or more ingress-egress-aggregates 1135 until contact is restored. The reason a higher severity level 1136 (lower value) is not proposed for the initial log is because any 1137 corrective action would probably be based on alerts at a lower 1138 subsystem level. 1140 o APPNAME set to "PCN" (without the quotes). 1142 o MSGID set to "LOST" (without the quotes). 1144 If contact is not regained with a PCN-egress-node in a reasonable 1145 period of time (say, one minute), the log SHOULD be repeated, this 1146 time with a PRI value of 113, implying a Facility value of (14) "log 1147 alert" and a Severity value of (1) "Alert: action must be taken 1148 immediately". The reasoning is that by this time, any more general 1149 conditions should have been cleared, and the problem lies 1150 specifically with the PCN-egress-node concerned and the PCN 1151 application in particular. 1153 Whenever a loss-of-contact log is generated for a PCN-egress-node, a 1154 log indicating recovery SHOULD be generated when the Decision Point 1155 next receives a report from the node concerned. The log SHOULD have 1156 the same content as just described for the loss-of-contact log, with 1157 the following differences: 1159 o PRI changes to 117, indicating a Facility value of (14) "log 1160 alert" and a Severity of (5) "Notice: normal but significant 1161 condition". 1163 o MSGID changes to "RECVD" (without the quotes). 1165 5.2.1.2. Logging Flow Termination Events 1167 Section 3.3.2 describes the process whereby the Decision Point 1168 decides that flow termination is required for a given ingress-egress- 1169 aggregate, calculates how much flow to terminate, and selects flows 1170 for termination. This section describes a log that SHOULD be 1171 generated each time such an event occurs. (In the case where 1172 termination occurs in multiple rounds, one log SHOULD be generated 1173 per round.) The log may be useful in fault management, to indicate 1174 the service impact of a fault occuring in a lower-level subsystem. 1175 In the absence of network failures, it may also be used as an 1176 indication of an urgent need to review capacity utilization along the 1177 path of the ingress-egress-aggregate concerned. 1179 The log reporting a flow termination event MUST include the following 1180 content: 1182 o The HOSTNAME field MUST identify the Decision Point issuing the 1183 log. 1185 o A STRUCTURED-DATA element MUST be present, containing parameters 1186 identifying the ingress and egress nodes for the ingress-egress- 1187 aggregate concerned, indicating the total amount of flow being 1188 terminated, and giving the number of flows terminated to achieve 1189 that objective. 1191 It is RECOMMENDED that the SD-ID for the STRUCTURED-DATA element 1192 have the form: "PCNTerm" (without the quotes), which has been 1193 registered with IANA. The parameter identifying the ingress node 1194 for the ingress-egress-aggregate is RECOMMENDED to have PARAM-NAME 1195 "IngrID" (without the quotes). This parameter MAY be omitted if 1196 the Decision Point is collocated with that PCN-ingress-node. The 1197 parameter identifying the egress node for the ingress-egress- 1198 aggregate is RECOMMENDED to have PARAM-NAME "EgrID" (without the 1199 quotes). Both identifiers are subject to the preferences 1200 expressed in Section 6.2.4 of [RFC5424] for the HOSTNAME field. 1202 The parameter giving the total amount of flow being terminated is 1203 RECOMMENDED to have PARAM-NAME "TermRate" (without the quotes). 1204 The PARAM-VALUE MUST be the target rate as calculated according to 1205 the procedures of Section 3.3.2, as an integer value in millions 1206 of octets per second. The parameter giving the number of flows 1207 selected for termination is RECOMMENDED to have PARAM-NAME "FCnt" 1208 (without the quotes). The PARAM-VALUE for this parameter MUST be 1209 an integer, the number of flows selected. 1211 The following values are also RECOMMENDED for the indicated fields in 1212 this log, subject to local practice: 1214 o PRI initially set to 116, representing a Facility value of (14) 1215 "log alert" and a Severity level of (4) "Warning: warning 1216 conditions". 1218 o APPNAME set to "PCN" (without the quotes). 1220 o MSGID set to "TERM" (without the quotes). 1222 5.2.2. Provision and Use of Counters 1224 The Diffserv MIB [RFC3289] allows for the provision of counters along 1225 the various possible processing paths associated with an interface 1226 and flow direction. It is RECOMMENDED that the PCN-nodes be 1227 instrumented as described below. It is assumed that the cumulative 1228 counts so obtained will be collected periodically for use in 1229 debugging, fault management, and capacity management. 1231 PCN-ingress-nodes SHOULD provide the following counts for each 1232 ingress-egress-aggregate. Since the Diffserv MIB installs counters 1233 by interface and direction, aggregation of counts over multiple 1234 interfaces may be necessary to obtain total counts by ingress-egress- 1235 aggregate. It is expected that such aggregation will be performed by 1236 a central system rather than at the PCN-ingress-node. 1238 o total PCN packets and octets received for that ingress-egress- 1239 aggregate but dropped; 1241 o total PCN packets and octets admitted to that aggregate. 1243 PCN-interior-nodes SHOULD provide the following counts for each 1244 interface, noting that a given packet MUST NOT be counted more than 1245 once as it passes through the node: 1247 o total PCN packets and octets dropped; 1249 o total PCN packets and octets forwarded without re-marking; 1251 o [CL-specific] total PCN packets and octets re-marked to Threshold- 1252 Marked; 1254 o total PCN packets and octets re-marked to Excess-Traffic-Marked. 1256 PCN-egress-nodes SHOULD provide the following counts for each 1257 ingress-egress-aggregate. As with the PCN-ingress-node, so with the 1258 PCN-egress-node it is expected that any necessary aggregation over 1259 multiple interfaces will be done by a central system. 1261 o total Not-Marked PCN packets and octets received; 1263 o [CL-specific] total Threshold-Marked PCN packets and octets 1264 received; 1266 o total Excess-Traffic-Marked PCN packets and octets received. 1268 The following continuously cumulative counters SHOULD be provided as 1269 indicated, but require new MIBs to be defined. If the Decision Point 1270 is not collocated with the PCN-ingress-node, the latter SHOULD 1271 provide a count of the number of requests for PCN-sent-rate received 1272 from the Decision Point and the number of responses returned to the 1273 Decision Point. The PCN-egress-node SHOULD provide a count of the 1274 number of reports sent to each Decision Point. Each Decision Point 1275 SHOULD provide the following: 1277 o total number of requests for PCN-sent-rate sent to each PCN- 1278 ingress-node with which it is not collocated; 1280 o total number of reports received from each PCN-egress-node; 1282 o total number of loss-of-contact events detected for each PCN- 1283 boundary-node; 1285 o total cumulative duration of "block" state in hundreds of 1286 milliseconds for each ingress-egress-aggregate; 1288 o total number of rounds of flow termination exercised for each 1289 ingress-egress-aggregate. 1291 6. Security Considerations 1293 [RFC5559] provides a general description of the security 1294 considerations for PCN. This memo introduces no new considerations. 1296 7. IANA Considerations 1298 This document requests IANA to add the following entries to the 1299 syslog Structured Data ID Values registry. RFCxxxx is this document 1300 when published. 1302 Structured Data ID: PCNNode OPTIONAL 1304 Structured Data Parameter: ID MANDATORY 1306 Structured Data Parameter: Rtyp MANDATORY 1308 Reference: RFCxxxx 1310 Structured Data ID: PCNTerm OPTIONAL 1312 Structured Data Parameter: IngrID CONDITIONAL 1314 Structured Data Parameter: EgrID MANDATORY 1316 Structured Data Parameter: TermRate MANDATORY 1318 Structured Data Parameter: FCnt MANDATORY 1320 Reference: RFCxxxx 1322 8. Acknowledgements 1324 The content of this memo bears a family resemblance to 1325 [ID.briscoe-CL]. The authors of that document were Bob Briscoe, 1326 Philip Eardley, and Dave Songhurst of BT, Anna Charny and Francois Le 1327 Faucheur of Cisco, Jozef Babiarz, Kwok Ho Chan, and Stephen Dudley of 1328 Nortel, Giorgios Karagiannis of U. Twente and Ericsson, and Attila 1329 Bader and Lars Westberg of Ericsson. 1331 Ruediger Geib, Philip Eardley, and Bob Briscoe have helped to shape 1332 the present document with their comments. Toby Moncaster gave a 1333 careful review to get it into shape for Working Group Last Call. 1335 Amongst the authors, Michael Menth deserves special mention for his 1336 constant and careful attention to both the technical content of this 1337 document and the manner in which it was expressed. 1339 Finally, David Harrington's careful AD review resulted not only in 1340 necessary changes throughout the document, but also the addition of 1341 the operations and management considerations (Section 5). 1343 9. References 1344 9.1. Normative References 1346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1347 Requirement Levels", BCP 14, RFC 2119, March 1997. 1349 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1350 "Definition of the Differentiated Services Field (DS 1351 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1352 December 1998. 1354 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1355 and W. Weiss, "An Architecture for Differentiated 1356 Services", RFC 2475, December 1998. 1358 [RFC3086] Nichols, K. and B. Carpenter, "Definition of 1359 Differentiated Services Per Domain Behaviors and Rules for 1360 their Specification", RFC 3086, April 2001. 1362 [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information 1363 Base for the Differentiated Services Architecture", 1364 RFC 3289, May 2002. 1366 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 1368 [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) 1369 Architecture", RFC 5559, June 2009. 1371 [RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN- 1372 Nodes", RFC 5670, November 2009. 1374 [RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline 1375 Encoding and Transport of Pre-Congestion Information", 1376 RFC 5696, November 2009. 1378 9.2. Informative References 1380 [I-D.tsvwg-rsvp-pcn] 1381 Karagiannis, G. and A. Bhargava, "Generic Aggregation of 1382 Resource ReSerVation Protocol (RSVP) for IPv4 And IPv6 1383 Reservations over PCN domains", July 2011. 1385 [ID.briscoe-CL] 1386 Briscoe, B., "An edge-to-edge Deployment Model for Pre- 1387 Congestion Notification: Admission Control over a DiffServ 1388 Region (expired Internet Draft)", 2006. 1390 [IEEE-Satoh] 1391 Satoh, D. and H. Ueno, ""Cause and Countermeasure of 1392 Overtermination for PCN-Based Flow Termination", 1393 Proceedings of IEEE Symposium on Computers and 1394 Communications (ISCC '10), pp. 155-161, Riccione, Italy", 1395 June 2010. 1397 [MeLe10] Menth, M. and F. Lehrieder, "PCN-Based Measured Rate 1398 Termination", Computer Networks Journal (Elsevier) vol. 1399 54, no. 13, pages 2099 - 2116, September 2010. 1401 [MeLe12] Menth, M. and F. Lehrieder, "Performance of PCN-Based 1402 Admission Control under Challenging Conditions", 2012. 1404 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1405 Guidelines for DiffServ Service Classes", RFC 4594, 1406 August 2006. 1408 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 1409 Notification", RFC 6040, November 2010. 1411 [RFCyyyy] Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T. 1412 Taylor, "PCN Boundary Node Behaviour for the Single 1413 Marking (SM) Mode of Operation (Work in progress)", 1414 December 2010. 1416 Authors' Addresses 1418 Anna Charny 1419 Cisco Systems 1420 300 Apollo Drive 1421 Chelmsford, MA 01824 1422 USA 1424 Email: acharny@cisco.com 1426 Fortune Huang 1427 Huawei Technologies 1428 Section F, Huawei Industrial Base, 1429 Bantian Longgang, Shenzhen 518129 1430 P.R. China 1432 Phone: +86 15013838060 1433 Email: fqhuang@huawei.com 1434 Georgios Karagiannis 1435 U. Twente 1437 Phone: 1438 Email: karagian@cs.utwente.nl 1440 Michael Menth 1441 University of Tuebingen 1442 Sand 13 1443 Tuebingen D-72076 1444 Germany 1446 Phone: +49-7071-2970505 1447 Email: menth@informatik.uni-tuebingen.de 1449 Tom Taylor (editor) 1450 Huawei Technologies 1451 1852 Lorraine Ave 1452 Ottawa, Ontario K1H 6Z8 1453 Canada 1455 Email: tom.taylor.stds@gmail.com