idnits 2.17.1 draft-taylor-pcn-cl-edge-behaviour-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (March 2, 2009) is 5534 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: September 3, 2009 Huawei Technologies 6 M. Menth 7 University of Wuerzburg 8 T. Taylor, Ed. 9 Huawei Technologies 10 March 2, 2009 12 PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of 13 Operation 14 draft-taylor-pcn-cl-edge-behaviour-00 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 3, 2009. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 Precongestion notification (PCN) is a means for protecting quality of 53 service for inelastic traffic admitted to a Diffserv domain. The 54 overall PCN architecture is described in ID.PCNArch. This memo is 55 one of a series describing possible boundary node behaviours for a 56 PCN domain. The behaviour described here is that for three-state 57 measurement-based load control, known informally as CL. The 58 requirement for three encoding states means that CL is for 59 experimental use only pending further standards action. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Assumed Core Network Behaviour for CL . . . . . . . . . . . . 4 68 3. Node Behaviours . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Measurement Requirements . . . . . . . . . . . . . . . . . 5 70 3.2. Decision-Making Behaviour . . . . . . . . . . . . . . . . 6 71 3.2.1. Determining Whether Flow Termination Is Required . . . 6 72 3.2.2. Estimating the Amount of Traffic To Terminate . . . . 7 73 3.2.3. Flow Admission Decisions . . . . . . . . . . . . . . . 7 74 4. Assumed Signalling Flows . . . . . . . . . . . . . . . . . . . 8 75 4.1. Assumed Signalling To Support Classification . . . . . . . 8 76 4.2. Assumed Signalling Of Measurements . . . . . . . . . . . . 8 77 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 84 Appendix A. Operation With Standalone PCN-Decision-Node . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 87 1. Introduction 89 Precongestion notification (PCN) is a means for protecting quality of 90 service (QoS) for inelastic traffic admitted to a Diffserv domain. 91 The overall PCN architecture is described in [ID.PCNArch]. In the 92 general case, QoS is protected by restricting admission of PCN- 93 traffic to the PCN-domain when precongestion indications are first 94 detected. In the case of catastrophic failures or a sudden increase 95 in traffic offered by admitted flows, QoS is protected by terminating 96 PCN-flows to the point where traffic falls to a level which appears 97 to be supportable in current conditions. Detection of congestion 98 status, the making of admission decisions, and the making of 99 termination decisions are all done on the basis of the ingress- 100 egress-aggregate as defined in [ID.PCNArch]. 102 Boundary node behaviours specify how the PCN-ingress-node and PCN- 103 egress-node make use of the PCN mechanisms to achieve QoS protection. 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 1.2. Terminology 113 In addition to the terms defined in [ID.PCNArch], this document uses 114 the following terms: 116 o Measurement period - the period of time over which a measurement 117 or set of measurements is accumulated. 119 o PCN-sent-traffic - the total PCN-traffic, measured in octets per 120 period, that is admitted to a given ingress-egress-aggregate by 121 the PCN-ingress-node. 123 o Edge-to-edge supportable rate of PCN-traffic - the maximum rate of 124 PCN-traffic that can be carried through the PCN network for a 125 given ingress-egress-aggregate at a given moment of time. 126 Estimated by the rate of PCN-traffic received at the egress node 127 without excess-traffic-marking during measurement periods in which 128 excess-traffic-marked packets are received. 130 o PCN-decision-node - the node that makes admission and flow 131 termination decisions based on an evaluation of the traffic 132 measurements for a given ingress-egress aggregate. The main body 133 of this document assumes that the PCN-decision-node is the same as 134 the PCN-ingress-node. Appendix A considers the alternative where 135 the PCN-decision-node is a separate entity. 137 1.3. Summary 139 The remainder of this document describes the assumed core node 140 behaviour for the CL mode, the behaviour of the ingress and egress 141 nodes, the signalling requirements between the nodes, and the 142 deployment considerations specific to the CL mode. As mentioned 143 already, Appendix A describes the operation of CL mode when the PCN- 144 decision-node is separate from the PCN-ingress-node. 146 2. Assumed Core Network Behaviour for CL 148 This section describes the assumed behaviour for nodes of the PCN- 149 domain when acting in their role as PCN-interior-nodes. The CL mode 150 of operation assumes that: 152 o encoding of PCN status within individual packets is based on 153 [ID.PCN-baseline], extended to provide a third encoding state. 154 Possible extensions for this purpose are documented in 155 [ID.PCN3state] or alternatively [ID.PCN3in1]; 157 o the domain satisfies the conditions specified in the applicable 158 extension document; 160 o each link has been configured with a PCN-threshold-rate having a 161 value equal to the PCN-admissible-rate for the link; 163 o each link has been configured with a PCN-excess-rate having a 164 value equal to the PCN-supportable-rate for the link; 166 o PCN-interior-nodes perform threshold-marking and excess-traffic- 167 marking of packets according to the rules specified in 168 [ID.PCN-marking], and any additional rules specified in the 169 applicable extension document; 171 According to [ID.PCN-baseline], the extension documents should 172 specify the allowable transitions between marking states. However, 173 to be absolutely clear, these allowable transitions are specified 174 here. At any interior node, the only permitted transitions are 175 these: 177 o a PCN packet which is not marked (NM) MAY be threshold-marked 178 (ThM) or excess-traffic-marked (ETM); 180 o a PCN packet which is threshold-marked (ThM) MAY be excess- 181 traffic-marked (ETM). 183 An interior node MUST NOT re-mark a packet from PCN to non-PCN, or 184 vice versa. 186 3. Node Behaviours 188 3.1. Measurement Requirements 190 [We need to think about the units. Will octet counts exceed 2 ** 32 191 per second?] 193 For each ingress-egress-aggregate, the egress node MUST continuously 194 measure the following quantities: 196 o NM-count: number of octets of PCN-traffic contained in received 197 packets which are neither threshold-marked nor excess-traffic- 198 marked; 200 o ThM-count: number of octets of PCN-traffic contained in received 201 packets which are threshold-marked; 203 o ETM-count: number of octets of PCN-traffic contained in received 204 packets which are excess-traffic-marked. 206 The egress node MUST capture its observations as octet counts per 207 measurement period but convert them to rates (octets per second) for 208 reporting purposes. The egress node MUST report these quantities to 209 the ingress node as soon as possible after the end of the measurement 210 period. The egress node MUST also include the duration D of the 211 measurement period in milliseconds in this report. 213 To avoid measurement bias, successive measurement periods MUST be of 214 the same duration, and the end of one measurement period MUST be the 215 beginning of the next one, independently of current flow conditions. 216 It is RECOMMENDED that the length of the measurement period lie 217 between 100 and 500 ms, to provide a reasonable tradeoff between 218 signalling demands on the network and the time taken to react to 219 impending congestion. 221 Note that, according to the logic presented in the next section, 222 the choice of measurement period duration also determines the 223 increment of time during which a policy of "admit" or "block" 224 persists for new flows offered to the ingress-egress-aggregate. 226 The ingress node MUST determine the current rate of PCN-sent-traffic 227 (octets per second) through measurement, but only when it receives a 228 report for a given ingress-egress-aggregate that contains a non-zero 229 count of excess-marked packets. It MAY do this by measuring 230 continuously and recording observations per measurement period in the 231 same way as the egress node, then selecting the rate calculated for 232 the most recent measurement period. See Section 3.2.2 for how this 233 quantity is used to calculate the amount of traffic to be terminated. 235 3.2. Decision-Making Behaviour 237 This section describes the behaviour required to make decisions on 238 when to admit flows, when to block them, and when to terminate flows 239 already admitted, for a given ingress-egress-aggregate. This is the 240 role of the PCN-decision-node, which in the main body of this memo is 241 assumed to coincide with the PCN-ingress-node. The decision cycle is 242 repeated each time a set of measurements is received from the egress 243 node. The outcome of the decision is a flow termination state (flow 244 termination required/not required), an admission state (accept or 245 block new flows), and, when flow termination is required, an estimate 246 of the amount of traffic that must be terminated. The steps in the 247 process are as follows: 249 1. Determine whether flow termination is required. 251 2. If flow termination is required: 253 A. Set the admission state to "block". 255 B. Estimate the amount of traffic that must be terminated. 257 C. Select currently admitted flows based on policy and terminate 258 them until the termination quota has been reached. 260 3. If flow termination is not required, determine whether the 261 admission state is "admit" or "block". 263 4. While the admission state is "block", block all new flows offered 264 to the ingress-egress-aggregate unless policy overrides this 265 decision for specific flows. 267 In the next few sections, the symbols NM-rate, ThM-rate, and ETM-rate 268 designate the rates reported by an egress node for the most recent 269 measurement period, for unmarked, threshold-marked, and excess- 270 traffic-marked PCN-traffic respectively. 272 3.2.1. Determining Whether Flow Termination Is Required 274 If the value ETM-rate for the measurement period is greater than zero 275 (i.e., excess-traffic-marked packets were observed), flow termination 276 is required. 278 3.2.2. Estimating the Amount of Traffic To Terminate 280 To determine how much traffic to terminate, the ingress node must 281 first measure the rate of PCN-traffic being sent (octets per second) 282 as discussed in Section 3.1. Call this quantity the Send-rate. 284 The estimate of how much traffic to terminate is based on the 285 assumption that the sum: 287 NM-rate + ThM-rate 289 of unmarked and threshold-marked PCN-traffic represents the current 290 edge-to-edge supportable rate of flow of PCN-traffic. The estimate 291 of how much traffic to terminate is then the difference: 293 Send-rate - (NM-rate + ThM-rate). 295 3.2.3. Flow Admission Decisions 297 This section describes the logic used to set the flow admission state 298 in periods when flow termination is not taking place. 300 Two running estimates ThMavg and Totavg are maintained, of the 301 average rate of threshold-marked traffic and the average rate of 302 total traffic received. These estimates MUST NOT be updated in 303 periods when excess-marked traffic is observed (hence ETM-rate will 304 be 0 and can be ignored). Because traffic rates will be time- 305 varying, the average rates SHOULD be calculated using exponential 306 smoothing, as follows: 308 ThMavg(updated) = (1-a)*ThMavg(previous) + a*ThM-rate; and 310 Totavg(updated) = (1-a)*Totavg(previous) + a*(NM-rate + ThM-rate), 312 The constant a is tuned to provide the optimal tradeoff between 313 tracking current traffic conditions and eliminating excessive 314 volatility. The appropriate value is in the order of 1000/D to 315 3000/D, where D is the reported measurement period duration in 316 milliseconds. 318 Following the update of the running estimates the ratio 320 ThMavg / Totavg 322 is calculated. If this ratio exceeds a configured decision value (of 323 the order of 0.5), the admission state MUST be set to "block". If 324 the ratio is less than or equal to the decision value, the admission 325 state is set to "admit". The admission state remains in effect until 326 new measurements in the next or a later period cause the ratio to 327 drop below (rise above, respectively) the decision value. 329 4. Assumed Signalling Flows 331 4.1. Assumed Signalling To Support Classification 333 In all boundary node behaviours, it is necessary for the edge nodes 334 to be provided with the means to distinguish between the flows for 335 different ingress-egress-aggregates. The means by which the PCN- 336 egress-node obtains this information is deployment-dependent. For 337 instance, if aggregates are passed directly from ingress to egress 338 using tunnels, the tunnel identifier can be used for packet 339 classification. Alternatively, ingress and egress may exchange 340 signalling to provide each other with the necessary classifying 341 information. 343 4.2. Assumed Signalling Of Measurements 345 This memo specifies signalling from egress to ingress to report the 346 values of NM-rate, ThM-rate, and ETM-rate at the end of each 347 measurement period, along with the measurement period duration D. 349 5. Deployment Considerations 351 Have to pull these together. 353 6. Security Considerations 355 [ID.PCNArch] provides a general description of the security 356 considerations for PCN. This memo introduces no new considerations. 358 7. IANA Considerations 360 This memo includes no request to IANA. 362 8. Acknowledgements 364 Excluding the appendices, the content of this memo is drawn from 365 [ID.briscoe-CL]. The authors of that document were Bob Briscoe, 366 Philip Eardley, and Dave Songhurst of BT, Anna Charny and Francois Le 367 Faucheur of Cisco, Jozef Babiarz, Kwok Ho Chan, and Stephen Dudley of 368 Nortel, Giorgios Karagiannis of U. Twente and Ericsson, and Attila 369 Bader and Lars Westberg of Ericsson. 371 9. References 373 9.1. Normative References 375 [ID.PCN-baseline] 376 Moncaster, T., Briscoe, B., and M. Menth, "Baseline 377 Encoding and Transport of Pre-Congestion Information (Work 378 in progress)", 2009. 380 [ID.PCN-marking] 381 Eardley, P., "Marking behaviour of PCN-nodes (Work in 382 progress)", 2008. 384 [ID.PCNArch] 385 Eardley, P., "Pre-Congestion Notification (PCN) 386 Architecture (Work in progress)", 2009. 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, March 1997. 391 9.2. Informative References 393 [ID.PCN3in1] 394 Briscoe, B., "PCN 3-State Encoding Extension in a single 395 DSCP (Work in progress)", 2008. 397 [ID.PCN3state] 398 Moncaster, T., Briscoe, B., and M. Menth, "A three state 399 extended PCN encoding scheme (Work in progress)", 2008. 401 [ID.briscoe-CL] 402 Briscoe, B., "An edge-to-edge Deployment Model for Pre- 403 Congestion Notification: Admission Control over a 404 DiffServ Region (expired Internet Draft)", 2006. 406 Appendix A. Operation With Standalone PCN-Decision-Node 408 This Appendix describes a mode of operation that falls outside the 409 current charter of the PCN Working Group, but reflects an 410 architecture being considered by the ITU-T. 412 If the PCN-decision node is a separate entity, the following 413 modifications apply to the description in the main body of this memo: 415 o The PCN-egress-node reports its measurements to the PCN-decision- 416 node rather than the PCN-ingress-node. As a result, it MAY report 417 results for multiple ingress-egress-aggregates at once, suitably 418 labelled, if their measurement periods all end at the same time. 420 o When the PCN-decision-node receives a report that indicates a non- 421 zero rate of excess-traffic-marking, it must acquire the value of 422 Send-rate from the PCN-ingress node in order to calculate how much 423 traffic to terminate. It may do this by sending a request and 424 receiving the value in a response. Alternatively, the PCN- 425 ingress-node may measure PCN-sent-traffic continuously and report 426 Send-rate to the PCN-decision-node at the end of each measurement 427 period for each ingress-egress-aggregate it deals with. The 428 appropriate approach is an open issue. 430 o The PCN-decision-node selects the flows for termination when this 431 is required and pushes the necessary policy updates to the PCN- 432 ingress-node. 434 o Depending on whether the push or pull model is applicable, the 435 PCN-decision-node pushes changes to current admission policy for a 436 given ingress-egress-aggregate to the PCN-ingress-node, or the 437 PCN-ingress-node requests a decision for each new flow. 439 Authors' Addresses 441 Anna Charny 442 Cisco Systems 443 300 Apollo Drive 444 Chelmsford, MA 01824 445 USA 447 Email: acharny@cisco.com 449 Fortune Huang 450 Huawei Technologies 451 Section F, Huawei Industrial Base, 452 Bantian Longgang, Shenzhen 518129 453 P.R. China 455 Phone: +86 15013838060 456 Email: fqhuang@huawei.com 457 Michael Menth 458 University of Wuerzburg 459 Am Hubland 460 Wuerzburg D-97074 461 Germany 463 Phone: +49-931-888-6644 464 Email: menth@informatik.uni-wuerzburg.de 466 Tom Taylor (editor) 467 Huawei Technologies 468 1852 Lorraine Ave 469 Ottawa, Ontario K1H 6Z8 470 Canada 472 Phone: +1 613 680 2675 473 Email: tom.taylor@rogers.com