Internet Engineering Task Force A. Charny Internet-Draft Cisco Systems Intended status: Informational F. Huang Expires: September 3, 2009 Huawei Technologies M. Menth University of Wuerzburg T. Taylor, Ed. Huawei Technologies March 2, 2009 PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation draft-taylor-pcn-cl-edge-behaviour-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 3, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Charny, et al. Expires September 3, 2009 [Page 1] Internet-Draft PCN CL Boundary Node Behaviour March 2009 Abstract Precongestion notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in ID.PCNArch. This memo is one of a series describing possible boundary node behaviours for a PCN domain. The behaviour described here is that for three-state measurement-based load control, known informally as CL. The requirement for three encoding states means that CL is for experimental use only pending further standards action. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Assumed Core Network Behaviour for CL . . . . . . . . . . . . 4 3. Node Behaviours . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Measurement Requirements . . . . . . . . . . . . . . . . . 5 3.2. Decision-Making Behaviour . . . . . . . . . . . . . . . . 6 3.2.1. Determining Whether Flow Termination Is Required . . . 6 3.2.2. Estimating the Amount of Traffic To Terminate . . . . 7 3.2.3. Flow Admission Decisions . . . . . . . . . . . . . . . 7 4. Assumed Signalling Flows . . . . . . . . . . . . . . . . . . . 8 4.1. Assumed Signalling To Support Classification . . . . . . . 8 4.2. Assumed Signalling Of Measurements . . . . . . . . . . . . 8 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Operation With Standalone PCN-Decision-Node . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Charny, et al. Expires September 3, 2009 [Page 2] Internet-Draft PCN CL Boundary Node Behaviour March 2009 1. Introduction Precongestion notification (PCN) is a means for protecting quality of service (QoS) for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in [ID.PCNArch]. In the general case, QoS is protected by restricting admission of PCN- traffic to the PCN-domain when precongestion indications are first detected. In the case of catastrophic failures or a sudden increase in traffic offered by admitted flows, QoS is protected by terminating PCN-flows to the point where traffic falls to a level which appears to be supportable in current conditions. Detection of congestion status, the making of admission decisions, and the making of termination decisions are all done on the basis of the ingress- egress-aggregate as defined in [ID.PCNArch]. Boundary node behaviours specify how the PCN-ingress-node and PCN- egress-node make use of the PCN mechanisms to achieve QoS protection. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. Terminology In addition to the terms defined in [ID.PCNArch], this document uses the following terms: o Measurement period - the period of time over which a measurement or set of measurements is accumulated. o PCN-sent-traffic - the total PCN-traffic, measured in octets per period, that is admitted to a given ingress-egress-aggregate by the PCN-ingress-node. o Edge-to-edge supportable rate of PCN-traffic - the maximum rate of PCN-traffic that can be carried through the PCN network for a given ingress-egress-aggregate at a given moment of time. Estimated by the rate of PCN-traffic received at the egress node without excess-traffic-marking during measurement periods in which excess-traffic-marked packets are received. o PCN-decision-node - the node that makes admission and flow termination decisions based on an evaluation of the traffic measurements for a given ingress-egress aggregate. The main body of this document assumes that the PCN-decision-node is the same as the PCN-ingress-node. Appendix A considers the alternative where Charny, et al. Expires September 3, 2009 [Page 3] Internet-Draft PCN CL Boundary Node Behaviour March 2009 the PCN-decision-node is a separate entity. 1.3. Summary The remainder of this document describes the assumed core node behaviour for the CL mode, the behaviour of the ingress and egress nodes, the signalling requirements between the nodes, and the deployment considerations specific to the CL mode. As mentioned already, Appendix A describes the operation of CL mode when the PCN- decision-node is separate from the PCN-ingress-node. 2. Assumed Core Network Behaviour for CL This section describes the assumed behaviour for nodes of the PCN- domain when acting in their role as PCN-interior-nodes. The CL mode of operation assumes that: o encoding of PCN status within individual packets is based on [ID.PCN-baseline], extended to provide a third encoding state. Possible extensions for this purpose are documented in [ID.PCN3state] or alternatively [ID.PCN3in1]; o the domain satisfies the conditions specified in the applicable extension document; o each link has been configured with a PCN-threshold-rate having a value equal to the PCN-admissible-rate for the link; o each link has been configured with a PCN-excess-rate having a value equal to the PCN-supportable-rate for the link; o PCN-interior-nodes perform threshold-marking and excess-traffic- marking of packets according to the rules specified in [ID.PCN-marking], and any additional rules specified in the applicable extension document; According to [ID.PCN-baseline], the extension documents should specify the allowable transitions between marking states. However, to be absolutely clear, these allowable transitions are specified here. At any interior node, the only permitted transitions are these: o a PCN packet which is not marked (NM) MAY be threshold-marked (ThM) or excess-traffic-marked (ETM); o a PCN packet which is threshold-marked (ThM) MAY be excess- traffic-marked (ETM). Charny, et al. Expires September 3, 2009 [Page 4] Internet-Draft PCN CL Boundary Node Behaviour March 2009 An interior node MUST NOT re-mark a packet from PCN to non-PCN, or vice versa. 3. Node Behaviours 3.1. Measurement Requirements [We need to think about the units. Will octet counts exceed 2 ** 32 per second?] For each ingress-egress-aggregate, the egress node MUST continuously measure the following quantities: o NM-count: number of octets of PCN-traffic contained in received packets which are neither threshold-marked nor excess-traffic- marked; o ThM-count: number of octets of PCN-traffic contained in received packets which are threshold-marked; o ETM-count: number of octets of PCN-traffic contained in received packets which are excess-traffic-marked. The egress node MUST capture its observations as octet counts per measurement period but convert them to rates (octets per second) for reporting purposes. The egress node MUST report these quantities to the ingress node as soon as possible after the end of the measurement period. The egress node MUST also include the duration D of the measurement period in milliseconds in this report. To avoid measurement bias, successive measurement periods MUST be of the same duration, and the end of one measurement period MUST be the beginning of the next one, independently of current flow conditions. It is RECOMMENDED that the length of the measurement period lie between 100 and 500 ms, to provide a reasonable tradeoff between signalling demands on the network and the time taken to react to impending congestion. Note that, according to the logic presented in the next section, the choice of measurement period duration also determines the increment of time during which a policy of "admit" or "block" persists for new flows offered to the ingress-egress-aggregate. The ingress node MUST determine the current rate of PCN-sent-traffic (octets per second) through measurement, but only when it receives a report for a given ingress-egress-aggregate that contains a non-zero count of excess-marked packets. It MAY do this by measuring Charny, et al. Expires September 3, 2009 [Page 5] Internet-Draft PCN CL Boundary Node Behaviour March 2009 continuously and recording observations per measurement period in the same way as the egress node, then selecting the rate calculated for the most recent measurement period. See Section 3.2.2 for how this quantity is used to calculate the amount of traffic to be terminated. 3.2. Decision-Making Behaviour This section describes the behaviour required to make decisions on when to admit flows, when to block them, and when to terminate flows already admitted, for a given ingress-egress-aggregate. This is the role of the PCN-decision-node, which in the main body of this memo is assumed to coincide with the PCN-ingress-node. The decision cycle is repeated each time a set of measurements is received from the egress node. The outcome of the decision is a flow termination state (flow termination required/not required), an admission state (accept or block new flows), and, when flow termination is required, an estimate of the amount of traffic that must be terminated. The steps in the process are as follows: 1. Determine whether flow termination is required. 2. If flow termination is required: A. Set the admission state to "block". B. Estimate the amount of traffic that must be terminated. C. Select currently admitted flows based on policy and terminate them until the termination quota has been reached. 3. If flow termination is not required, determine whether the admission state is "admit" or "block". 4. While the admission state is "block", block all new flows offered to the ingress-egress-aggregate unless policy overrides this decision for specific flows. In the next few sections, the symbols NM-rate, ThM-rate, and ETM-rate designate the rates reported by an egress node for the most recent measurement period, for unmarked, threshold-marked, and excess- traffic-marked PCN-traffic respectively. 3.2.1. Determining Whether Flow Termination Is Required If the value ETM-rate for the measurement period is greater than zero (i.e., excess-traffic-marked packets were observed), flow termination is required. Charny, et al. Expires September 3, 2009 [Page 6] Internet-Draft PCN CL Boundary Node Behaviour March 2009 3.2.2. Estimating the Amount of Traffic To Terminate To determine how much traffic to terminate, the ingress node must first measure the rate of PCN-traffic being sent (octets per second) as discussed in Section 3.1. Call this quantity the Send-rate. The estimate of how much traffic to terminate is based on the assumption that the sum: NM-rate + ThM-rate of unmarked and threshold-marked PCN-traffic represents the current edge-to-edge supportable rate of flow of PCN-traffic. The estimate of how much traffic to terminate is then the difference: Send-rate - (NM-rate + ThM-rate). 3.2.3. Flow Admission Decisions This section describes the logic used to set the flow admission state in periods when flow termination is not taking place. Two running estimates ThMavg and Totavg are maintained, of the average rate of threshold-marked traffic and the average rate of total traffic received. These estimates MUST NOT be updated in periods when excess-marked traffic is observed (hence ETM-rate will be 0 and can be ignored). Because traffic rates will be time- varying, the average rates SHOULD be calculated using exponential smoothing, as follows: ThMavg(updated) = (1-a)*ThMavg(previous) + a*ThM-rate; and Totavg(updated) = (1-a)*Totavg(previous) + a*(NM-rate + ThM-rate), The constant a is tuned to provide the optimal tradeoff between tracking current traffic conditions and eliminating excessive volatility. The appropriate value is in the order of 1000/D to 3000/D, where D is the reported measurement period duration in milliseconds. Following the update of the running estimates the ratio ThMavg / Totavg is calculated. If this ratio exceeds a configured decision value (of the order of 0.5), the admission state MUST be set to "block". If the ratio is less than or equal to the decision value, the admission state is set to "admit". The admission state remains in effect until Charny, et al. Expires September 3, 2009 [Page 7] Internet-Draft PCN CL Boundary Node Behaviour March 2009 new measurements in the next or a later period cause the ratio to drop below (rise above, respectively) the decision value. 4. Assumed Signalling Flows 4.1. Assumed Signalling To Support Classification In all boundary node behaviours, it is necessary for the edge nodes to be provided with the means to distinguish between the flows for different ingress-egress-aggregates. The means by which the PCN- egress-node obtains this information is deployment-dependent. For instance, if aggregates are passed directly from ingress to egress using tunnels, the tunnel identifier can be used for packet classification. Alternatively, ingress and egress may exchange signalling to provide each other with the necessary classifying information. 4.2. Assumed Signalling Of Measurements This memo specifies signalling from egress to ingress to report the values of NM-rate, ThM-rate, and ETM-rate at the end of each measurement period, along with the measurement period duration D. 5. Deployment Considerations Have to pull these together. 6. Security Considerations [ID.PCNArch] provides a general description of the security considerations for PCN. This memo introduces no new considerations. 7. IANA Considerations This memo includes no request to IANA. 8. Acknowledgements Excluding the appendices, the content of this memo is drawn from [ID.briscoe-CL]. The authors of that document were Bob Briscoe, Philip Eardley, and Dave Songhurst of BT, Anna Charny and Francois Le Faucheur of Cisco, Jozef Babiarz, Kwok Ho Chan, and Stephen Dudley of Nortel, Giorgios Karagiannis of U. Twente and Ericsson, and Attila Charny, et al. Expires September 3, 2009 [Page 8] Internet-Draft PCN CL Boundary Node Behaviour March 2009 Bader and Lars Westberg of Ericsson. 9. References 9.1. Normative References [ID.PCN-baseline] Moncaster, T., Briscoe, B., and M. Menth, "Baseline Encoding and Transport of Pre-Congestion Information (Work in progress)", 2009. [ID.PCN-marking] Eardley, P., "Marking behaviour of PCN-nodes (Work in progress)", 2008. [ID.PCNArch] Eardley, P., "Pre-Congestion Notification (PCN) Architecture (Work in progress)", 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [ID.PCN3in1] Briscoe, B., "PCN 3-State Encoding Extension in a single DSCP (Work in progress)", 2008. [ID.PCN3state] Moncaster, T., Briscoe, B., and M. Menth, "A three state extended PCN encoding scheme (Work in progress)", 2008. [ID.briscoe-CL] Briscoe, B., "An edge-to-edge Deployment Model for Pre- Congestion Notification: Admission Control over a DiffServ Region (expired Internet Draft)", 2006. Appendix A. Operation With Standalone PCN-Decision-Node This Appendix describes a mode of operation that falls outside the current charter of the PCN Working Group, but reflects an architecture being considered by the ITU-T. If the PCN-decision node is a separate entity, the following modifications apply to the description in the main body of this memo: Charny, et al. Expires September 3, 2009 [Page 9] Internet-Draft PCN CL Boundary Node Behaviour March 2009 o The PCN-egress-node reports its measurements to the PCN-decision- node rather than the PCN-ingress-node. As a result, it MAY report results for multiple ingress-egress-aggregates at once, suitably labelled, if their measurement periods all end at the same time. o When the PCN-decision-node receives a report that indicates a non- zero rate of excess-traffic-marking, it must acquire the value of Send-rate from the PCN-ingress node in order to calculate how much traffic to terminate. It may do this by sending a request and receiving the value in a response. Alternatively, the PCN- ingress-node may measure PCN-sent-traffic continuously and report Send-rate to the PCN-decision-node at the end of each measurement period for each ingress-egress-aggregate it deals with. The appropriate approach is an open issue. o The PCN-decision-node selects the flows for termination when this is required and pushes the necessary policy updates to the PCN- ingress-node. o Depending on whether the push or pull model is applicable, the PCN-decision-node pushes changes to current admission policy for a given ingress-egress-aggregate to the PCN-ingress-node, or the PCN-ingress-node requests a decision for each new flow. Authors' Addresses Anna Charny Cisco Systems 300 Apollo Drive Chelmsford, MA 01824 USA Email: acharny@cisco.com Fortune Huang Huawei Technologies Section F, Huawei Industrial Base, Bantian Longgang, Shenzhen 518129 P.R. China Phone: +86 15013838060 Email: fqhuang@huawei.com Charny, et al. Expires September 3, 2009 [Page 10] Internet-Draft PCN CL Boundary Node Behaviour March 2009 Michael Menth University of Wuerzburg Am Hubland Wuerzburg D-97074 Germany Phone: +49-931-888-6644 Email: menth@informatik.uni-wuerzburg.de Tom Taylor (editor) Huawei Technologies 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada Phone: +1 613 680 2675 Email: tom.taylor@rogers.com Charny, et al. Expires September 3, 2009 [Page 11]