TSVWG K. Chan Internet-Draft J. Babiarz Expires: August 23, 2005 Nortel Networks F. Baker Cisco Systems February 19, 2005 Aggregation of DiffServ Service Classes draft-chan-tsvwg-diffserv-class-aggr-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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 August 23, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract In the core of a high capacity network, service differentiation is still needed to support applications' utilization of the network. Applications with similar traffic characteristics and performance requirements are mapped into different diffserv service classes based Chan, et al. Expires August 23, 2005 [Page 1] Internet-Draft Document February 2005 on end-to-end behavior requirements of the applications. However, some network segments may be configured in such a way that a single forwarding treatment satisfy the traffic characteristics and performance requirements of two or more service classes. For such cases, it may be desirable to aggregate two or more service classes into a forwarding treatment. This document provides guidelines for aggregation of service classes into forwarding treatments. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Requirements Notation . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Service Class Aggregation . . . . . . . . . . . . 4 4. Service Classes to Treatment Aggregate Mapping . . . . . . . . 4 4.1 Mapping Service Classes into Four Treatment Aggregates . . 5 4.1.1 Network Control Treatment Aggregate . . . . . . . . . 6 4.1.2 Real Time Treatment Aggregate . . . . . . . . . . . . 6 4.1.3 Assured Elastic Treatment Aggregate . . . . . . . . . 7 4.1.4 Elastic Treatment Aggregate . . . . . . . . . . . . . 8 5. Treatment Aggregates and Inter Provider Relationships . . . . 8 5.1 Treatment Aggregates and IP based Inter Provider Relationships . . . . . . . . . . . . . . . . . . . . . . 8 5.2 Treatment Aggregates and MPLS based Inter Provider Relationships . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 12 Chan, et al. Expires August 23, 2005 [Page 2] Internet-Draft Document February 2005 1. Introduction In the core of a high capacity network, it is common for the network to be engineered in such a way that a major link, switch, or router can fail and the result be a routed network that still meets ambient SLAs. The implication of this is that there is sufficient capacity on any given link that all SLAs sold can be simultaneously supported at their respective maximum rates, and this remains true after re-routing (either IP re-routing or MPLS protection-mode switching) has occurred. It is frequently argued that such over provisioning meets the requirements of all traffic without further QoS treatment, and from a certain perspective that is true. However, as the process of network convergence continues, certain services still have issues. While delay and jitter is perfectly acceptable for elastic applications, real time applications are negatively affected, and in extreme cases (such as some reported around the September 2001 attacks on the US East Coast, or under extreme DDOS load) such surges could disrupt routing. The treatment aggregates recommended herein are designed to aggregate the service classes in Diffserv Service Classes [5] in such a manner as to protect real-time traffic and routing, on the assumption that real-time sessions are protected from each other by admission at the edge, and provide a staged response to stress. The document Diffserv Service Classes [5] provides the basic diffserv classes from the points of view of the application requiring specific end-to-end behaviors from the network. At some network segments of the end-to-end path, the number of levels of network treatment differentiation may be less than the number of service classes that the network segment needs to support. In such situation, that network segment needs to use the same treatment to support more than one service class. In this document we provide guidelines of how multiple service classes may be aggregated into a forwarding treatment aggregate. We also provide some terminology and requirement for performing this aggregation. 1.1 Requirements Notation 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 [3]. 2. Terminology We try to use existing definition of terms from current RFCs. We Chan, et al. Expires August 23, 2005 [Page 3] Internet-Draft Document February 2005 have also added new definition of terms here when necessary. o Treatment Aggregate. This term is used here to indicate the aggregate of DiffServ service classes. This is different from Behavior Aggregate and Traffic Aggregate because Treatment Aggregate is only concerned with the treatment of the aggregated traffic. It does not concern with how the aggregated traffic is marked, and hence does not put a restriction on the aggregated traffic having a single codepoint that have a single PHB. 3. Overview of Service Class Aggregation In some deployments, especially in the middle of the network where network capacity is higher, traffic treatment differentiation may be less granular. In these deployments, aggregation of the different service classes may be more practical. These aggregations have the following requirements: 1. The end-to-end network performance characteristic required by the application must be supported. This performance characteristic is represented by the use of Diffserv Service Classes [5]. 2. The treatment aggregate must exhibit the strictest requirement of its member service classes. 3. The treatment aggregate should only contain member service classes with similar traffic characteristic and performance requirements. 4. The notion of the individual end-to-end service classes must not be destroyed when aggregation is performed. Each domain along the end-to-end path may perform aggregation differently, based on the original end-to-end service classes. Hence the DSCP used to indicate the end-to-end service class must not be altered. 5. Each treatment aggregate have limited resource, hence traffic conditioning and/or admission control must be performed for each service class aggregating into the treatment aggregate. 4. Service Classes to Treatment Aggregate Mapping The service class and DSCP selection in Diffserv Service Classes [5] has been defined to allow in many instances mapping of two or possibly more service classes into a single treatment aggregate. Noticing there is a physical-space/time relationship between link Chan, et al. Expires August 23, 2005 [Page 4] Internet-Draft Document February 2005 speed, queue depth, delay, and jitter. The degree of aggregation, hence the number of treatment aggregates, will depend on if the domain implementing the aggregation will have link speed high enough to minimize the affects of mixing traffic with different packet size, differnet transmit rates on buffering/queue depth, and finally its impact on loss, delay, and jitter. With the general rule of thumb being higher link speeds allows higher degree of aggregation/smaller number of treatment aggregates. But all requires some forms of traffic conditioning and/or admission control. 4.1 Mapping Service Classes into Four Treatment Aggregates For most of today's high speed links, the use of one network control traffic treatment aggregate and three user traffic treatment aggregates is sufficient to handle the requirement of all the service classes indicated in Diffserv Service Classes [5]. We use the performance requirement (tolerance to loss, delay, and jitter) from the application/end user as the guidance on how to map the service classes into treatment aggregates. We have also used Section 3.1 of RFC 1633 [6] to provide us with guidance on the definition of Real Time and Elastic application requirements. An overview of the mapping between service classes and four treatment aggregates is provided by Figure 1, with the mapping based on performance requirement. --------------------------------------------------------------------- |Treatment | Tolerance to ||Service Class | Tolerance to | |Aggregate | Loss |Delay |Jitter|| | Loss |Delay |Jitter| |==========+======+======+======++===============+======+======+======| | Network | Low | Low | Yes || Network | Low | Low | Yes | | Control | | | || Control | | | | |==========+======+======+======++===============+======+======+======| | Real | Very | Very | Very || Telephony | VLow | VLow | VLow | | Time | Low | Low | Low ||---------------+------+------+------| | | | | || Signaling | Low | Low | Yes | | | | | ||---------------+------+------+------| | | | | || Multimedia |Low - | Very | Low | | | | | || Conferencing |Medium| Low | | | | | | ||---------------+------+------+------| | | | | || Real-time | Low | Very | Low | | | | | || Interactive | | Low | | | | | | ||---------------+------+------+------| | | | | || Broadcast | Very |Medium| Low | | | | | || Video | Low | | | |==========+======+======+======++===============+======+======+======| | Assured | Low |Low - | Yes || Multimedia |Low - |Medium| Yes | | Elastic | |Medium| || Streaming |Medium| | | | | | | ||---------------+------+------+------| Chan, et al. Expires August 23, 2005 [Page 5] Internet-Draft Document February 2005 | | | | || Low Latency | Low |Low - | Yes | | | | | || Data | |Medium| | | | | | ||---------------+------+------+------| | | | | || OAM | Low |Medium| Yes | | | | | ||---------------+------+------+------| | | | | ||High Throughput| Low |Medium| Yes | | | | | || Data | |- High| | |==========+======+======+======++===============+======+======+======| | Elastic | Not Specified || Standard | Not Specified | | | | | ||---------------+------+------+------| | | | | || Low Priority | High | High | Yes | | | | | || Data | | | | --------------------------------------------------------------------- Figure 1: Treatment Aggregate and Service Class Performance Requirements 4.1.1 Network Control Treatment Aggregate The Network Control Traffic Aggregate aggregates all services classes that is functionally necessary for the survival of a network during a DDOS or other high traffic load interval. The theory is that whatever else is true, the network must protect itself. This includes the traffic that Diffserv Service Classes [5] characterizes as in the Network Control Service Class. The DSCP of such traffic is not over-ridden, as in other places in the network or in other networks the original service class remains an important consideration. Rather, traffic bearing these DSCPs is carried in a common queue or class with a PHB as described in RFC 2309 [7] and RFC 2474 [4] for CS6, and bearing a relatively deep target mean queue depth (min-threshold if RED is being used). 4.1.2 Real Time Treatment Aggregate The Real Time Treatment Aggregate aggregates all real time (inelastic) service classes. The theory is that real-time traffic is admitted under some model and controlled by an SLA managed at the edge of the network. As such, there is a predictable upper bound on the traffic that can enter such a queue, and to provide predictable variation in delay it must be protected from bursts of elastic traffic. This treatment aggregate may include: o Telephony Chan, et al. Expires August 23, 2005 [Page 6] Internet-Draft Document February 2005 o Signaling o Multimedia Conferencing o Real-time Interactive o Broadcast Video service classes as defined in Diffserv Service Classes [5]. Traffic in each Service class that is going to be aggregated into the treatment aggregate should be conditioned prior to aggregating. It is recommended that per service class admission control procedure be used followed with per service class policing so that any individual service class does not generate more than what it is allowed. Further the admission control and policing may be used on the sum of all service classes aggregated. The DSCP of such traffic is not over-ridden, as in other places in the network or in other networks the original service class remains an important consideration. Rather, traffic bearing these DSCPs is carried in a common queue or class with a PHB as described in RFC 3246 [9] and RFC 3247 [10]. 4.1.3 Assured Elastic Treatment Aggregate The Assured Elastic Treatment Aggregate aggregates all elastic traffic that uses the Assured Forwarding model as described in RFC 2597 [8]. The premise of such service is that an SLA is negotiated that includes a "committed rate" and the ability to exceed that rate (and perhaps a second "excess rate") in exchange for a higher probability of loss using AQM [7] or ECN flagging [11] for the portion of traffic deemed to be in excess. This treatment aggregate may include: o Multimedia Streaming o Low Latency Data o OAM o High Throughput Data service classes as defined in Diffserv Service Classes [5]. The DSCP of such traffic is not over-ridden, as in other places in the network or in other networks the original service class remains Chan, et al. Expires August 23, 2005 [Page 7] Internet-Draft Document February 2005 an important consideration. Rather, traffic bearing these DSCPs is carried in a common queue or class with a PHB as described in RFC 2597 [8]. In effect, appropriate target rate thresholds have been applied at the edge, dividing traffic into AFn1 (committed, for any value of n), AFn2 (excess), and AFn3 (violating). The AQM thresholds for Assured Elastic traffic should correspondingly be set such that: o AFn3 traffic is dropped before AFn2 traffic, o if any AFn2 traffic is being dropped then all AFn3 traffic is being dropped, o AFn2 traffic is dropped before AFn1 traffic, and o if any AFn1 traffic is being dropped then all AFn2 traffic is being dropped. 4.1.4 Elastic Treatment Aggregate The Elastic Treatment Aggregate aggregates all remaining elastic traffic. The premise of such service is that there is no intrinsic SLA differentiation of traffic, but that AQM [7] or ECN flagging [11] is appropriate for such traffic. This treatment aggregate may include: o Standard o Low Priority Data service classes as defined in Diffserv Service Classes [5]. The DSCP of such traffic is not over-ridden, as in other places in the network or in other networks the original service class remains an important consideration. Rather, traffic bearing these DSCPs is carried in a common queue or class with a PHB as described in RFC 2309 [7]. The AQM thresholds for Elastic traffic MAY be separately set, so that Low Priority traffic is dropped before Standard traffic, but this is not a requirement. 5. Treatment Aggregates and Inter Provider Relationships 5.1 Treatment Aggregates and IP based Inter Provider Relationships Chan, et al. Expires August 23, 2005 [Page 8] Internet-Draft Document February 2005 5.2 Treatment Aggregates and MPLS based Inter Provider Relationships 6. Security Considerations This document discusses policy of using Differentiated Services and its service classes. If implemented as described, it should require the network to do nothing that the network has not already allowed. If that is the case, no new security issues should arise from the use of such a policy. It is possible for the policy to be applied incorrectly, or for a wrong policy to be applied in the network for the defined aggregation. In that case, a policy issue exists that the network must detect, assess, and deal with. This is a known security issue in any network dependent on policy-directed behavior. A well known flaw appears when bandwidth is reserved or enabled for a service (for example, voice transport) and another service or an attacking traffic stream uses it. This possibility is inherent in DiffServ technology, which depends on appropriate packet markings. When bandwidth reservation or a priority queuing system is used in a vulnerable network, the use of authentication and flow admission is recommended. To the author's knowledge, there is no known technical way to respond to or act upon a data stream that has been admitted for service but that it is not intended for authenticated use. 7. IANA Considerations To be completed. 8. Acknowledgements 9. Normative References [1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. Chan, et al. Expires August 23, 2005 [Page 9] Internet-Draft Document February 2005 [5] Babiarz, J., "Configuration Guidelines for DiffServ Service Classes", Internet-Draft draft-ietf-tsvwg-diffserv-service-classes-00, February 2005. [6] Braden, B., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [7] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998. [8] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [9] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [10] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C. and K. Ramakrishnan, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", RFC 3247, March 2002. [11] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. Authors' Addresses Kwok Ho Chan Nortel Networks 600 Technology Park Drive Billerica, MA 01821 US Phone: +1-978-288-8175 Fax: +1-978-288-4690 Email: khchan@nortel.com Chan, et al. Expires August 23, 2005 [Page 10] Internet-Draft Document February 2005 Jozef Z. Babiarz Nortel Networks 3500 Carling Avenue Ottawa, Ont. K2H 8E9 Canada Phone: +1-613-763-6098 Fax: +1-613-768-2231 Email: babiarz@nortel.com Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US Phone: +1-408-526-4257 Fax: +1-413-473-2403 Email: fred@cisco.com Chan, et al. Expires August 23, 2005 [Page 11] Internet-Draft Document February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Chan, et al. Expires August 23, 2005 [Page 12]