TSVWG K. Chan Internet-Draft J. Babiarz Expires: April 18, 2005 Nortel Networks October 18, 2004 Aggregation of DiffServ Service Classes draft-chan-tsvwg-diffserv-class-aggr-00 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 April 18, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract Applications with similar traffic characteristics and performance requirements are mapped into different diffserv service classes based 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 Chan & Babiarz Expires April 18, 2005 [Page 1] Internet-Draft Document October 2004 into a forwarding treatment. This draft 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 . . . . . . . . . . . . 3 3.1 Service Classes to Aggregate Mapping . . . . . . . . . . . 4 3.1.1 Mapping Service Classes into Four Aggregates . . . . . 4 3.1.2 Mapping Service Classes into Six Aggregates . . . . . 4 3.1.3 Mapping Service Classes into Eight Aggregates . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . 7 Chan & Babiarz Expires April 18, 2005 [Page 2] Internet-Draft Document October 2004 1. Introduction 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 some examples and 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 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 only concerns with the treatment of the aggregated traffic. It does not concern with how the aggregated traffic are marked, and hence does not put a restriction on the aggregated traffic having a single codepoint that have a single PHB. This document uses "Aggregate" as a short form of "Treatment Aggregate". 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. Chan & Babiarz Expires April 18, 2005 [Page 3] Internet-Draft Document October 2004 2. The aggregate must exhibit the strictest requirement of its member service classes. 3. The aggregate should contain member service classes with similar performance characteristic requirements. 4. The notion of the individual service classes (the end to end notion) must not be destroyed when aggregation is used. Each domain 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 aggregate have limited resource, hence admission control must be performed for each aggregate. This may be based on the service classes the aggregate contains and the resource used to implement the aggregate. 3.1 Service Classes to 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 aggregate. Noticing there is a physical-space/time relationship between link speed, queue depth, delay, and jitter. The degree of aggregation, hence the number of 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 aggregates. But all requires some forms of admission control. 3.1.1 Mapping Service Classes into Four Aggregates We provide an example and some guidelines on mapping different service classes into four aggregates. 3.1.2 Mapping Service Classes into Six Aggregates We provide an example and some guidelines on mapping different service classes into six aggregates. 3.1.3 Mapping Service Classes into Eight Aggregates We provide an example and some guidelines on mapping different service classes into eight aggregates. Chan & Babiarz Expires April 18, 2005 [Page 4] Internet-Draft Document October 2004 4. 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. 5. IANA Considerations To be completed. 6. Acknowledgements 7 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. [5] Babiarz, J., Chan, K. and F. Baker, "Configuration Guidelines for DiffServ Service Classes", draft-baker-diffserv-basic-classes-04 (work in progress), October 2004. Chan & Babiarz Expires April 18, 2005 [Page 5] Internet-Draft Document October 2004 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@nortelnetworks.com 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@nortelnetworks.com Chan & Babiarz Expires April 18, 2005 [Page 6] Internet-Draft Document October 2004 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 (2004). 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 & Babiarz Expires April 18, 2005 [Page 7]