Internet Engineering Task Force T. Taylor, Ed. Internet-Draft Huawei Technologies Intended status: Informational October 19, 2009 Expires: April 22, 2010 The PCN Piggybacking Edge Behaviour draft-taylor-pcn-piggyback-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 April 22, 2010. 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. 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 RFC 5559. This memo Taylor Expires April 22, 2010 [Page 1] Internet-Draft Piggybacking Edge Behaviour October 2009 describes a behaviour for PCN egress nodes known as the "piggybacking" edge behaviour, because it "piggybacks" PCN information in resource signalling messages. This version of the memo describes two alternatives, where piggybacking is derived from the CL edge behaviour and where it is derived from the SM edge behaviour. The SM and CL edge behaviours are specified in companion documents. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. Measurement Behaviour . . . . . . . . . . . . . . . . . . . . . 3 3. Assumed Domain Behaviour . . . . . . . . . . . . . . . . . . . 4 4. Egress Node Behaviour . . . . . . . . . . . . . . . . . . . . . 4 5. Ingress Node Behaviour . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Taylor Expires April 22, 2010 [Page 2] Internet-Draft Piggybacking Edge Behaviour October 2009 1. Introduction The main objective of Pre-Congestion Notification (PCN) is to support the quality of service (QoS) of inelastic flows within a Diffserv domain, in a simple, scalable, and robust fashion. Two mechanisms are used: admission control and flow termination. Admission control is used to decide whether to admit or block a new flow request, while flow termination is used in abnormal circumstances to decide whether to terminate some of the existing flows. To support these two features the overall rate of PCN-traffic is metered on every link in the domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. These configured rates are below the rate of the link thus providing notification to boundary nodes about overloads before any congestion occurs (hence "pre-congestion" notification). The level of marking allows boundary nodes to make decisions about whether to admit or terminate. For more details see [RFC5559]. The CL and SM edge node behaviours, described in [I-D.CL-edge-behaviour] and [I-D.SM-edge-behaviour], specify assumptions on the marking behaviour within the PCN domain, the measurements to be taken at ingress and egress nodes respectively, and the processing of those measurements to allow the making of flow admisssion and flow termination decisions. In both edge behaviours, the decision point for individual flows is either the ingress node or a centralized policy server. This document specifies an edge behaviour where the admission decision for individual flows is taken at the egress node. This is accomplished by using resource signalling (e.g., RSVP) to carry the per-flow decision back to the ingress node for enforcement. Flow termination requires input from both the ingress node and egress node, hence the resource signalling is also used to carry part of the necessary information from the egress node to the ingress node. This usage of resource signalling for the additional purpose of carrying PCN measurement data is the reason for calling this the "piggybacking" edge behaviour. 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 RFC 2119 [RFC2119]. 2. Measurement Behaviour The ingress and egress nodes to a PCN domain have particular roles to play in supporting the PCN mechanisms. These are described in general terms in [RFC5559]. This edge behaviour specification Taylor Expires April 22, 2010 [Page 3] Internet-Draft Piggybacking Edge Behaviour October 2009 assumes that both ingress and egress nodes meter PCN traffic continuously. Based on this metering, the ingress node periodically calculates and records the rate of PCN traffic it admits to each ingress-egress aggregate, in octets per second. Similarly, the egress node periodically calculates and records the rate of PCN traffic it receives from each ingress-egress aggregate, in octets per second. In both of the scenarios considered below, it records the rate of traffic received in PCN-unmarked packets and in PCN-excess- marked packets. In the CL-like behaviour scenario, it also records the rate of traffic received in PCN-threshold-marked packets. 3. Assumed Domain Behaviour The key assumption made in the piggybacking edge behaviour is that resource availabilty for flow admission is determined through the use of resource signalling (e.g., RSVP) to reserve resources along the flow path. It is assumed that for flows within a given ingress- egress aggregate, all such signalling passes through the ingress and egress nodes defining the aggregate, in both directions. Beyond this, this specification considers two alternative scenarios. In the CL-like scenario, three-state PCN marking is used, so that packets arriving at the egress node may be PCN-unmarked, PCN- threshold-marked, or PCN-excess-marked. Marking behaviour is as specified in [I-D.CL-edge-behaviour]. In the SM-like scenario, two- state PCN marking is used, so that packets arriving at the egress node may be PCN-unmarked or PCN-excess-marked only. Marking behaviour is as specified in [I-D.CL-edge-behaviour]. 4. Egress Node Behaviour As each new set of measurements becomes available, the egress node calculates the ratio of PCN-unmarked octets to total PCN traffic received subtracts this ratio from 1, and updates an exponentially- smoothed average of the result. That is: New ratio = 1 - (Unmarked traffic rate / Total traffic rate) New smoothed average = w * new ratio + (1-w) * old smoothed average where w is a suitable smoothing weight. See simulation results documented in TBD for reasonable values of w. The egress node compares the new smoothed average to a pre-configured threshold to determine its current admission state. If the smoothed Taylor Expires April 22, 2010 [Page 4] Internet-Draft Piggybacking Edge Behaviour October 2009 average exceeds the threshold, the egress node enters "block" state until the next set of measurements becomes available. If the smoothed average does not exceed the configured threshold, the egress node is in "admit" state until the next set of measurements becomes available. Each time the egress node processes a resource signalling message where the egress node will propagate the message toward the ingress node, the egress node consults its current admission state. If the admission state is "admit", the egress node propagates the resource signalling without any further action beyond that required by the signalling system itself. If the admission state is "block", the egress node adds an indication in the message it propagates that resources are unavailable for the flow being signalled. It also adds two numbers to the message: the latest measured rate of total PCN traffic received, and the rate of PCN-excess-marked traffic received, both in octets per second. 5. Ingress Node Behaviour Ingress node behaviour with respect to admission is the same for both the CL-like and the SM-like scenario. The ingress node admits the new flow if the returning resource signalling message indicates resources available, and blocks it if the returning resource signalling message indicates that insufficient resources are unavailable. Behaviour with respect to flow termination differs slightly between the two scenarios. Flow termination is considered in either case only if the received resource signalling message indicates not only that insufficient resources are available to admit the flow, but also reports a non-zero level of excess-marked traffic. If these conditions are satisfied: o in the CL-like scenario, the ingress node computes an estimate of the edge-to-edge supportable rate of PCN traffic equal to the difference between the total traffic rate reported in the resource signalling message and the PCN-excess-marked traffic rate. o in the SM-like scenario the ingress node calculates the difference between the total traffic rate reported in the resource signalling message and the PCN-excess-marked traffic rate, but then computes an estimate of the edge-to-edge supportable rate of PCN traffic equal to this difference multiplied by a pre-configured factor U, which is the same for all ingress-egress aggregates. The ingress node terminates flows amounting to a total traffic rate Taylor Expires April 22, 2010 [Page 5] Internet-Draft Piggybacking Edge Behaviour October 2009 equal to the difference between the most-recently measured rate of admitted PCN traffic at the ingress node and the estimate of the edge-to-edge supportable rate calculated as just described. In the CL-like case, termination is always required if the preconditions for this calculation have been met. In the SM-like case, termination may not be required. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations To be written. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.CL-edge-behaviour] Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. Taylor, Ed., "PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation (Work in progress)", 2009. [I-D.SM-edge-behaviour] Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T. Taylor, Ed., "PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation (Work in progress)", 2009. [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009. Appendix A. Additional Stuff This becomes an Appendix. Taylor Expires April 22, 2010 [Page 6] Internet-Draft Piggybacking Edge Behaviour October 2009 Author's Address Tom Taylor (editor) Huawei Technologies 1852 Lorraine Ave Ottawa Canada Email: tom111.taylor@bell.net Taylor Expires April 22, 2010 [Page 7]