Internet Engineering Task Force T. Taylor, Ed. Internet-Draft Huawei Technologies Intended status: Informational March 8, 2010 Expires: September 9, 2010 The PCN Piggybacking Edge Behaviour draft-taylor-pcn-piggybacking-edge-behaviour-01 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 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. 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 9, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the Taylor Expires September 9, 2010 [Page 1] Internet-Draft Piggybacking Edge Behaviour March 2010 document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Assumed Signalling Behaviour . . . . . . . . . . . . . . . . . 4 3. Assumed Behaviour at Interior Nodes . . . . . . . . . . . . . . 4 4. Edge Node Behaviours . . . . . . . . . . . . . . . . . . . . . 4 4.1. Egress Node Behaviour . . . . . . . . . . . . . . . . . . . 4 4.1.1. Data Collection . . . . . . . . . . . . . . . . . . . . 4 4.1.2. Reporting . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Ingress Node Behaviour . . . . . . . . . . . . . . . . . . 6 4.3. Decision Point Behaviour . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Taylor Expires September 9, 2010 [Page 2] Internet-Draft Piggybacking Edge Behaviour March 2010 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 decisions to be made about whether to admit or terminate individual flows. For more details see [RFC5559]. Boundary node behaviours specify a detailed set of algorithms and edge node behaviours used to implement the PCN mechanisms. The piggybacking edge behaviour which is the subject of this memo introduces no new behaviours and algorithms beyond those provided by the SM and CL edge behaviours ([I-D.SM-Edge-Behaviour] and [I-D.CL-Edge-Behaviour] respectively). Instead, it provides an alternative method of signalling whereby the egress node reports the rates it has calculated as an addition to resource signalling rather than using a separate protocol. This has implications both for the operation of the resource signalling and the operation of the PCN mechanisms. 1.1. Terminology 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]. In addition to the terms defined in [RFC5559], this document uses the following terms: decision point The node that makes the decision about which flows to admit and to terminate. In a given network deployment, this may be the ingress node or a centralized control node. Decisions are enforced by the ingress node. In contrast to the signalling architecture considered in [I-D.SM-Edge-Behaviour] and [I-D.CL-Edge-Behaviour], in the piggybacking case the egress node always sends its information to the ingress node rather than the decision point. The ingress node then forwards the PCN reports to the decision Taylor Expires September 9, 2010 [Page 3] Internet-Draft Piggybacking Edge Behaviour March 2010 point if they are not collocated. The decision point returns its decisions to the ingress node as usual. NM-Rate, ThM-Rate, ETM-Rate The calculated rate at which PCN traffic has been received in unmarked packets, threshold-marked packets (CL mode only), and excess-traffic-marked packets respectively. See the descriptions of egress node behaviour in [I-D.SM-Edge-Behaviour] and [I-D.CL-Edge-Behaviour] for further details. 2. Assumed Signalling Behaviour For the piggybacking edge behaviour, it is assumed that applications are using a resource signalling protocol (e.g., RSVP, NSIS) to request resources from the network. The PCN domain is viewed as a building block in the complete end-to-end path. Resource signalling is processed by the edge nodes of the PCN domain, but not by the interior nodes. Thus the passage from the PCN-ingress-node to the PCN-egress-node or vice versa is viewed as a single hop. It is assumed that a request for resources for a given flow requires at least one message passing through the PCN-egress-node toward the PCN-ingress-node. This is consistent with RSVP and some cases of NSIS, but rules out "Basic Sender Initiated Reservation" as described in Section 4.1 of [I-D.NSLP]. 3. Assumed Behaviour at Interior Nodes It is assumed that nodes interior to the PCN domain do not participate in the resource signalling, but simply forward that signalling toward the edge. Beyond that, the applicable assumptions are as described in [I-D.SM-Edge-Behaviour] and [I-D.CL-Edge-Behaviour] respectively. 4. Edge Node Behaviours 4.1. Egress Node Behaviour 4.1.1. Data Collection The PCN-egress-node MUST meter received PCN traffic per ingress- egress-aggregate and periodically calculate the rate at which unmarked, threshold-marked (for the CL behaviour), and excess- traffic-marked traffic is received, all as described in [I-D.SM-Edge-Behaviour] and [I-D.CL-Edge-Behaviour] respectively. Taylor Expires September 9, 2010 [Page 4] Internet-Draft Piggybacking Edge Behaviour March 2010 The interval between successive calculations SHOULD be a constant value of the order of 100 to 500 ms, as described in the CL and SM documents. If so configured, when operating in CL mode, the PCN-egress-node MUST also save the identities of flows experiencing excess-traffic-marking during the latest measurement interval. 4.1.2. Reporting The PCN-egress-node reports its measured results according to the following rules: o When the PCN-egress-node receives resource signalling for a new flow, it processes that message according to the rules of the protocol. However, if the message is to be forwarded in the direction of the PCN-ingress-node, the egress node MUST add to the message an object containing its latest calculated values of NM- rate, ThM-Rate (for CL mode only) and ETM-Rate for the ingress- egress-aggregate which that flow would join. In addition, if operating in CL mode and so configured, if the ETM-Rate is greater than zero the PCN-egress-node SHOULD add to the message an object identifying individual flows within the aggregate that experienced excess-traffic marking. There may not be space for this within the message. o If the PCN-egress-node receives resource signalling refreshing state for an established flow, it again processes the message according to the rules of the protocol. OPEN ISSUE: Should it attach the latest values of the calculated rates, or should it attach the values that were placed into the original message establishing that flow? The latter was suggested by [I-D.lefaucheur-rsvp-ecn], to make it easier for implementations to distinguish refresh messages. o If the calculated ETM-Rate for an interval is greater than zero and no resource signalling in the direction of the PCN-ingress- node was received during that interval relating to the ingress- egress-aggregate concerned, the PCN-egress-node SHOULD generate an autonomous report identifying the ingress-egress-aggregate, giving the calculated values of NM-Rate, ThM-Rate, and ETM-Rate, and, if so configured, a list of individual flows that were excess- traffic-marked in the interval just concluded. The condition of no message in the right direction in the previous interval is a heuristic for predicting whether one will come along in the next interval. Taylor Expires September 9, 2010 [Page 5] Internet-Draft Piggybacking Edge Behaviour March 2010 OPEN ISSUE 1: can this use a message within the resource protocol? RSVP messages are associated with individual flows. Can an RSVP session between ingress and egress be set up specifically for the aggregate, so that messages like this relate to the aggregate as a whole? OPEN ISSUE 2: does the message have to be delivered reliably? 4.2. Ingress Node Behaviour When the PCN-ingress-node receives resource signalling from the direction of the PCN-egress-node, it processes the message as required by the resource protocol. Before forwarding it, it removes any PCN-related information added by the egress node and forwards that information to the decision point. If the ingress node and the decision point are collocated, the exchanges between them are an internal operation. The PCN-ingress-node MUST provide the estimated current rate of admitted PCN traffic (octets per second) for a specific ingress- egress-aggregate when the decision point requests it, as described in [I-D.SM-Edge-Behaviour] and [I-D.CL-Edge-Behaviour]. 4.3. Decision Point Behaviour Behaviour at the decision point is exactly as documented in [I-D.SM-Edge-Behaviour] or [I-D.CL-Edge-Behaviour] as applicable. 5. Acknowledgements draft-lefaucheur-rsvp-ecn-01.txt ([I-D.lefaucheur-rsvp-ecn]) covered this ground in much greater detail, three and a half years ago. The author borrowed some of the information from that document, but the document itself should probably be revised to fit the present shape of PCN if there is interest in this work. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations To be written. Taylor Expires September 9, 2010 [Page 6] Internet-Draft Piggybacking Edge Behaviour March 2010 8. References 8.1. Normative 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)", 2010. [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)", 2010. [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.NSLP] Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Quality-of-Service Signaling (Work in progress)", January 2010. [I-D.lefaucheur-rsvp-ecn] Le Faucheur, F., Charny, A., Briscoe, B., Eardley, P., Chan, K., and J. Babiarz, "RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification (PCN) (Work in progress)", June 2006. [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009. Author's Address Tom Taylor (editor) Huawei Technologies 1852 Lorraine Ave Ottawa Canada Email: tom111.taylor@bell.net Taylor Expires September 9, 2010 [Page 7]