INTERNET DRAFT N. Seddigh Internet Engineering Task Force B. Nandy Differentiated Services Working Group Nortel Networks Expires August, 2001 J. Heinanen Telia Finland February, 2001 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. 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 parameters such as the peak information Seddigh, Nandy, Heinanen [Page 1] INTERNET DRAFT draft-ietf-diffserv-pdb-ar-00.txt August 2001 rate (PIR) to place additional constraints for packets to which the assurance applies or to further differentiate packets which exceed the CIR. This PDB is referred to as the Assured Rate (AR) PDB and is defined in accordance with the guidelines in [PDBDEF]. It may be possible to determine delay and jitter bounds for traffic aggregates using the AR PDB. However, such parameters are beyond the scope of this PDB definition and no attempt is made to characterize them. Development of a mathematical model to predict delay and jitter for the AR PDB is left as a subject of future research and investigation. 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 document uses "one-to-one" to describe a traffic aggregate entering via a single ingress point of a domain and exiting from a single egress point for the domain. One-to-any refers to a traffic aggregate with single entry point and multiple (any) exit points in the domain. One-to-few refers to a traffic aggregate with single ingress point and fixed set of egress points within a domain. The possibility of obtaining excess bandwidth allows development of various novel SLA models. For example, 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 definitions are outside the scope of this document. They are 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 Seddigh, Nandy, Heinanen [Page 2] INTERNET DRAFT draft-ietf-diffserv-pdb-ar-00.txt August 2001 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 Technical Specification The specification for this PDB consist of two parts: 1. A set of Edge rules that classifies packets arriving at the domain ingress into a traffic aggregate, performs metering/policing on the aggregate and associates 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 interface 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 colouring 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. Seddigh, Nandy, Heinanen [Page 3] INTERNET DRAFT draft-ietf-diffserv-pdb-ar-00.txt August 2001 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 N. N is the number of AF classes supported by the routers in the domain. The service provider may utilize any policer algorithm to colour the packets as long as it adheres to the general colouring principles outlined above. Examples of such policers include [SRTCM] [TRTCM] or [TSWTCM]. 3.2 PHB Configuration As described above, the AR traffic aggregate is to be treated using PHBs AFx1, AFx2 and AFx3 from a single AF class x. 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 N AF classes may be selected to treat this PDB. This makes it possible to create in a single DS domain, multiple instances of the AR PDB, each with their own minimum forwarding resources. However, all aggregates using the same instance of the PDB in a single domain SHOULD utilize the same AF class PHB set. 4.0 Attributes of AR PDB The attributes of this PDB include a rate that is assured and low drop probability for the traffic conformant to this rate. Seddigh, Nandy, Heinanen [Page 4] INTERNET DRAFT draft-ietf-diffserv-pdb-ar-00.txt August 2001 5.0 Parameters The AR PDB MUST have the following parameters: - A committed information rate (CIR) that is assured with high probability. The AR PDB specification does not define "high" quantitatively, but an SLS MAY do so. - Traffic parameters that are needed to measure CIR. The AR PDB specification 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 AR PDB MAY have other, optional 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 Deployment of the AR PDB requires an assumption that the network is well-provisioned enough so that the likelyhood of green packets being dropped in case of congestion is very low. This draft does not dictate a particular method to achieve the above objective. Various traffic engineering methods may be used. As an example, the network operator monitors the level of green packets in the selected AF class on all links and takes appropriate action to limit the green packet loss. The PDB also assumes that there is relatively stable routing within the domain. 7.0 Security There are no specific security exposures for this PDB. See the general security considerations in the Diffserv Header RFC [RFC2474] and the Diffserv Architecture RFC [RFC2475]. All the security concerns expressed in [RFC 2597] apply for the AR PDB. 8.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. Seddigh, Nandy, Heinanen [Page 5] INTERNET DRAFT draft-ietf-diffserv-pdb-ar-00.txt August 2001 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 egress nodes where packets are sent from an ingress node during the measurement interval. These measurements then have to be correlated to determine the cumulative bandwidth of the aggregate as it exits the domain. 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. 9.0 Acknowledgements The authors would like to thank the following individuals for their helpful comments and suggestions: Brian Carpenter, Shahram Davari and Alper Demir. 10.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 Seddigh, Nandy, Heinanen [Page 6] INTERNET DRAFT draft-ietf-diffserv-pdb-ar-00.txt August 2001 [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 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]