INTERNET DRAFT N. Seddigh Internet Engineering Task Force B. Nandy Differentiated Services Working Group Nortel Networks Expires June, 2001 J. Heinanen Telia Finland December, 2000 An Assured Rate Per-Domain Behaviour for Differentiated Services Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Distribution of this memo is unlimited. Abstract This document describes a diffserv per-domain behaviour (PDB) called Assured Rate (AR). The AR PDB is suitable for carrying traffic aggregates that require rate assurance but do not require delay and jitter bounds. The traffic aggregate will also have the opportunity to obtain excess bandwidth beyond the assured rate. The PDB can be created using the diffserv AF PHB along with suitable policers at the domain ingress nodes. 1.0 Description of the Assured Rate PDB This document defines a differentiated services per-domain behaviour (PDB) suitable for traffic aggregates that require rate assurance but do not require delay and jitter bounds. This PDB ensures that traffic conforming to a committed information rate (CIR) will incur low drop probability. The aggregate will have the opportunity of obtaining excess bandwidth beyond the CIR but there is no assurance. In addition to the CIR, the edge rules may also include other traffic Seddigh, Nandy, Heinanen [Page 1] INTERNET DRAFT draft-ietf-seddigh-pdb-ar-00.txt June 2001 parameters such as the peak information rate (PIR) to place additional constraints for packets to which the assurance applies or to further differentiate packets which exceed the CIR. The PDB tries to avoid packet reordering within microflows. The PDB is applicable for a one-to-one, one-to-few as well as one-to-any types of service. This PDB is referred to as the Assured Rate (AR) PDB and is defined in accordance with the guidelines in [PDBDEF]. The possibility of obtaining excess bandwidth allows development of various novel SLA models. e.g. Excess bandwidth is charged at a higher rate than assured bandwidth; Excess bandwidth is cheaper than assured bandwidth; Excess bandwith is charged proportionally etc. Development and discussion of such service and charging models are beyond the scope of this document. 2.0 Applicability The Assured Rate PDB is intended to carry traffic aggregates that require assurance for a specific bandwidth level. This document does not restrict the PDB to any particular application or traffic type. Regardless of the traffic mix, the CIR for the aggregate will be assured. However, it is also possible to use this PDB to create a service for an aggregate consisting only of TCP microflows or non-responsive UDP microflows. The provider may wish to create a TCP-only service for a variety of reasons such as traffic isolation, better treatment of individual short microflows within an aggregate, greater fairness among TCP and UDP microflows access to the excess bandwidth allowed for the aggregate. Such service definition is outside the scope of this document. It is mentioned here simply to show that the PDB can be used to create diverse services. The governing attributes of the PDB are only expressed in relation to the entire traffic aggregate. The PDB specification does not specify any attributes for the individual microflows within an aggregate. The grouping of microflows into the traffic aggregate can be done either at the customer site or by the provider's ingress router on behalf of the customer. The AR PDB definition can be used in either scenario. It is the responsibility of the service provider to specify which approach is adopted in the service level specification (SLS). 3.0 Rules The rule specification for this PDB consist of two parts: 1. A set of Edge rules that classifies packets arriving at Seddigh, Nandy, Heinanen [Page 2] INTERNET DRAFT draft-ietf-seddigh-pdb-ar-00.txt June 2001 the domain ingress into a traffic aggregate, perform metering/policing on the aggregate and associate a packet marking with the aggregate. Traffic shaping does not need to be performed on the aggregate as it enters the domain. 2. Per-node PHB treatment for the traffic aggregate as it weaves its way from the domain ingress to the domain egress. 3.1 Edge Rules As packets enter the domain they will be classified into a traffic aggregate based on the specified filter at the domain ingress port of the border router. The filter MUST be associated with a traffic profile that specifies committed information rate (CIR) AND a description on how it is to be measured. For example, the measurement may be based on a committed burst size (CBS) or an averaging time interval (T1). The traffic profile MAY also include other traffic parameters. These parameters MAY place additional constraints on packets to which the assurance applies or MAY further differentiate traffic that exceeds the CIR. Such parameters could include: peak information rate (PIR), peak burst size (PBS), excess burst size (EBS) or even a second averaging time interval (T2). The policer causes each packet arriving into the domain to be marked with one of up to three levels of drop precedence, which we call (in the increasing order) green, yellow, red. The packets to which the assurance applies, MUST be marked green. The excess packets MUST be marked as either yellow or red. The details of packet marking are dependent on the specific policer utilized at the ingress router. Red colour packets SHOULD be delivered with equal or lower probability than yellow colour packets. A special case of this is that all red colour packets are discarded by the ingress policer. Yellow packets SHOULD not be dropped by the ingress policer. They MAY be dropped by the buffer management mechanisms of the ingress router but that will be due to PHB treatment. The green, yellow and red packets MUST be marked with the DSCP for AFx1, AFx2 and AFx3 PHBs respectively, where x MUST be any one value from 1 to 4. The service provider may utilize any marker algorithm to colour the packets as long as it adheres to the general colouring principles outlined above. Examples of such markers include [SRTCM] [TRTCM] or [TSWTCM]. Seddigh, Nandy, Heinanen [Page 3] INTERNET DRAFT draft-ietf-seddigh-pdb-ar-00.txt June 2001 3.2 PHB Configuration The AR traffic aggregate is to be treated using one of three PHBs in the selected AF PHB class. Based on the The AR traffic aggregate is to be treated using PHBs from a single AF class. Based on the edge rules described previously, green, yellow and red packets will be treated with AFx1, AFx2 and AFx3 PHB respectively. The resultant combination of the edge rules and PHB treatment within a single AF class, will ensure that: "Within each AF class IP packets are marked (again by the customer or the provider DS domain) with one of three possible drop precedence values. In case of congestion, the drop precedence of a packet determines the relative importance of the packet within the AF class. A congested DS node tries to protect packets with a lower drop precedence value from being lost by preferably discarding packets with a higher drop precedence value." (taken from RFC 2597). The requirement to achieve the PDB is as follows: Nodes internal to the domain SHOULD not drop packets marked to receive treatment with AFx1. Under exceptional circumstances, network nodes MAY have to drop AFx1 packets for a short period. In such cases, they should only start dropping AFx1 packets after they have started dropping all AFx2 and AFx3 packets. See [TON98] for an example and justification of this approach. In the case where the AF class is lightly loaded, AFx2 and/or AFx3 packets MAY also be transmitted successfully through the node. This will allow the aggregate to obtain excess bandwidth beyond its assured rate. As mentioned previously, any of the 4 AF classes may be selected to treat this PDB. However, all aggregates using this PDB in a single domain SHOULD utilize the same AF class PHB set. At each node, a certain portion of the forwarding resources should be pre-allocated for the AF class. The level of this resource should not be pre-empted by other PHBs. For example, if AF1 PHB class is allocated a minimum 15% of a link's bandwidth, this should not be starved by another PHB due to over-use by higher priority traffic within the node. 4.0 Attributes of AR PDB The attributes of this PDB include a throughput rate that is assured and low drop probability for the traffic conformant to this rate. 5.0 Parameters This PDB MUST have the following parameters: Seddigh, Nandy, Heinanen [Page 4] INTERNET DRAFT draft-ietf-seddigh-pdb-ar-00.txt June 2001 - A committed information rate (CIR) that is assured with high probability. The PDB does not define "high" quantitatively, but an SLS MAY do so. - Traffic parameters that are needed to measure CIR. The PDB does not define these parameters, since they depend on the policer used. Examples include a Committed Burst Size (CBS) and an averaging interval (T1). - A maximum packet size for the aggregate - MAX_PACKET_SIZE. In addition to the above, the PDB MAY have optional extra traffic parameters. These parameters MAY place further constraints on the packets to which the assurance applies or MAY further differentiate packets to which the assurance does not apply. The PDB does not define these parameters, since they depend on the policer used. Examples include a Peak Information Rate (PIR), a Peak Burst Size (PBS), an Excess Burst Size (EBS), and a second time averaging interval (T2). 6.0 Assumptions The assumption is that the network operator monitors the level of green packets in the selected AF class on all links and, if necessary, takes traffic engineering actions to keep the level low enough so that the likelyhood of green packets being dropped in case of congestion is very low. 7.0 Example Uses In this section, we provide only a few example services that are possible with this PDB - the list is not exhaustive. Example services that can be created out of this PDB include: (i) one-to-one or one-to-few VPN-like services and (ii) one-to-any general service. In the case of VPN-like services, the PDB can be utilized to assure a rate for a traffic aggregate between an ingress and an egress within a domain or from one ingress to few different egress points in the domain. In the case of one-to-any services, the PDB can be utilized to assure a rate for a traffic aggregate that originates from one ingress node but whose individual five-tuple flows may exit the domain at any of the egress nodes. It is easier for a provider to demonstrate conformance with the SLS in the one-to-one service since all measurements can be performed at a single egress point. In the case of a one-to-any service, measurements need to be performed at all the egress nodes visited by individual five-tuple flows within the aggregate. These measurements then have to be correlated to determine the cumulative bandwidth of the aggregate as it exits the domain. Seddigh, Nandy, Heinanen [Page 5] INTERNET DRAFT draft-ietf-seddigh-pdb-ar-00.txt June 2001 Such a measurement approach is made viable because a larger sampling interval may be acceptable to the customer. e.g. sample egress rates may be obtained once every half hour with random sampling at that time. The measurements would be performed over averaging intervals as specified in the SLS. The AR definition allows coupling of the PDB parameters with probabilities for statistical assurance. For example, the SLS MAY specify a Y% assurance for the CIR (with CBS/T1) when sampled every X minutes. 8.0 References [TON98] D.D. Clark, W. Fang, "Explicit Allocation of Best Effort Packet Delivery Service", IEEE/ACM Transactions on Networking, August 1998, Vol 6. No. 4, pp. 362-373. [RFC2474] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", Internet RFC 2474, December 1998. [RFC2475] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and W. Weiss, "An Architecture for Differentiated Services", Internet RFC 2475, December 1998. [AFPHB] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999 [PDBDEF] Nichols K and Carpenter B, "Definition of Differentiated Services Per Domain Behaviours and Rules for their Specification", Internet Draft, October 2000 [SRTCM] J. Heinanen and R. Guerin, "A Single Rate Three Colour Marker", Internet RFC 2697, September 1999 [TRTCM] J. Heinanen and R. Guerin, "A Two Rate Three Colour Marker", Internet RFC 2698, September 1999 [TSWTCM] W. Fang, N. Seddigh and B. Nandy, "A Time Sliding Window Three Colour Marker", Internet RFC 2859, June 2000 9.0 Author Addresses Nabil Seddigh Nortel Networks, 3500 Carling Ave Ottawa, ON, K2H 8E9 Canada Email: nseddigh@nortelnetworks.com Seddigh, Nandy, Heinanen [Page 6] INTERNET DRAFT draft-ietf-seddigh-pdb-ar-00.txt June 2001 Biswajit Nandy Nortel Networks, 3500 Carling Ave Ottawa, ON, K2H 8E9 Canada Email: bnandy@nortelnetworks.com Juha Heinanen Telia Finland, Email: jh@telia.fi Seddigh, Nandy, Heinanen [Page 7]