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]