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]