draft-ietf-tsvwg-diffserv-class-aggr-00.txt   draft-ietf-tsvwg-diffserv-class-aggr-01.txt 
TSVWG K. Chan TSVWG K. Chan
Internet-Draft J. Babiarz Internet-Draft J. Babiarz
Expires: December 18, 2006 Nortel Networks Intended status: Informational Nortel Networks
F. Baker Expires: April 23, 2007 F. Baker
Cisco Systems Cisco Systems
June 16, 2006 October 20, 2006
Aggregation of DiffServ Service Classes Aggregation of DiffServ Service Classes
draft-ietf-tsvwg-diffserv-class-aggr-00 draft-ietf-tsvwg-diffserv-class-aggr-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 18, 2006. This Internet-Draft will expire on April 23, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
In the core of a high capacity network, service differentiation is In the core of a high capacity network, service differentiation is
still needed to support applications' utilization of the network. still needed to support applications' utilization of the network.
Applications with similar traffic characteristics and performance Applications with similar traffic characteristics and performance
skipping to change at page 2, line 18 skipping to change at page 2, line 18
forwarding treatment. This document provides guidelines for the forwarding treatment. This document provides guidelines for the
aggregation of Diffserv Service Classes [5] into forwarding aggregation of Diffserv Service Classes [5] into forwarding
treatments. treatments.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Service Class Aggregation . . . . . . . . . . . . 5 3. Overview of Service Class Aggregation . . . . . . . . . . . . 5
4. Service Classes to Treatment Aggregate Mapping . . . . . . . . 5 4. Service Classes to Treatment Aggregate Mapping . . . . . . . . 6
4.1. Mapping Service Classes into Four Treatment Aggregates . . 6 4.1. Mapping Service Classes into Four Treatment Aggregates . . 6
4.1.1. Network Control Treatment Aggregate . . . . . . . . . 8 4.1.1. Network Control Treatment Aggregate . . . . . . . . . 8
4.1.2. Real Time Treatment Aggregate . . . . . . . . . . . . 8 4.1.2. Real Time Treatment Aggregate . . . . . . . . . . . . 9
4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . 9 4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . 9
4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 10 4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 10
5. Using MPLS for Treatment Aggregates . . . . . . . . . . . . . 11 5. Using MPLS for Treatment Aggregates . . . . . . . . . . . . . 11
5.1. Network Control Treatment Aggregate with E-LSP . . . . . . 13 5.1. Network Control Treatment Aggregate with E-LSP . . . . . . 13
5.2. Real Time Treatment Aggregate with E-LSP . . . . . . . . . 13 5.2. Real Time Treatment Aggregate with E-LSP . . . . . . . . . 13
5.3. Assured Elastic Treatment Aggregate with E-LSP . . . . . . 13 5.3. Assured Elastic Treatment Aggregate with E-LSP . . . . . . 13
5.4. Elastic Treatment Aggregate with E-LSP . . . . . . . . . . 13 5.4. Elastic Treatment Aggregate with E-LSP . . . . . . . . . . 13
5.5. Treatment Aggregates and L-LSP . . . . . . . . . . . . . . 14 5.5. Treatment Aggregates and L-LSP . . . . . . . . . . . . . . 14
6. Treatment Aggregates and Inter-Provider Relationships . . . . 14 6. Treatment Aggregates and Inter-Provider Relationships . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
In the core of a high capacity network, it is common for the network 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 to be engineered in such a way that a major link, switch, or router
can fail and the result will be a routed network that still meets can fail and the result will be a routed network that still meets
ambient SLAs. The implication of this is that there is sufficient ambient SLAs. The implication of this is that there is sufficient
capacity on any given link such that all SLAs sold can be capacity on any given link such that all SLAs sold can be
simultaneously supported at their respective maximum rates, and that simultaneously supported at their respective maximum rates, and that
this remains true after re-routing (either IP re-routing or MPLS this remains true after re-routing (either IP re-routing or MPLS
protection-mode switching) has occurred. protection-mode switching) has occurred.
It is frequently argued that such over provisioning meets the Over-provisioning is generally considered to meet the requirements of
requirements of all traffic without further QoS treatment, and from a all traffic without further QoS treatment, and in the general case
certain perspective that is true. However, as the process of network that is true in high capacity backbones. However, as the process of
convergence continues, certain services still have issues. While network convergence continues, and with the increasing speed of the
delay and jitter are perfectly acceptable for elastic applications, access networks, certain services still have issues. Delay, jitter,
real-time applications are negatively affected, and in extreme cases and occasional loss are perfectly acceptable for elastic
(such as some reported around the September 2001 attacks on the US applications. However, sub-second surges that occur in the best-
East Coast, or under extreme DOS load) such surges could disrupt designed of networks [14] affect real-time applications. Moreover,
routing. DOS loads, worms, and network disruptions such as that of 11
September 2001 affect routing [15]. Our objective is to prevent
disruption to routing (which in turn affects all services), and
jitter-sensitive services that may be revenue-bearing.
The document "Diffserv Service Classes" [5] defines the basic The document "Diffserv Service Classes" [5] defines the basic
diffserv classes from the points of view of the application requiring diffserv classes from the points of view of the application requiring
specific end-to-end behaviors from the network. The service classes specific end-to-end behaviors from the network. The service classes
are differentiated based on the traffic-payload's tolerance to packet are differentiated based on the traffic-payload's tolerance to packet
loss, delay, and delay variation (jitter). Different degrees of loss, delay, and delay variation (jitter). Different degrees of
these criterions form the foundation for supporting the needs of these criterions form the foundation for supporting the needs of
real-time and elastic traffic. The Diffserv Service Classes [5] real-time and elastic traffic. The "Diffserv Service Classes" [5]
document also provides recommendations for the treatment method of document also provides recommendations for the treatment method of
these service classes. But, at some network segments of the end-to- these service classes. But, at some network segments of the end-to-
end path, the number of levels of network treatment differentiation end path, the number of levels of network treatment differentiation
may be less than the number of service classes that the network may be less than the number of service classes that the network
segment needs to support. In such a situation, that network segment segment needs to support. In such a situation, that network segment
may use the same treatment to support more than one service class. may use the same treatment to support more than one service class.
In this document we provide guidelines on how multiple service In this document we provide guidelines on how multiple service
classes may be aggregated into a forwarding treatment aggregate. classes may be aggregated into a forwarding treatment aggregate.
Note that in a given domain, we may recommend that the supported Note that in a given domain, we may recommend that the supported
service classes be aggregated into forwarding treatment aggregates; service classes be aggregated into forwarding treatment aggregates;
skipping to change at page 5, line 47 skipping to change at page 5, line 47
way to accomplish this by not altering the DSCP used to indicate way to accomplish this by not altering the DSCP used to indicate
the end-to-end service class. But some administrative domains the end-to-end service class. But some administrative domains
may require the use of their own marking; when this is needed, may require the use of their own marking; when this is needed,
the original end-to-end service class indication must be restored the original end-to-end service class indication must be restored
upon exiting such administrative domains. upon exiting such administrative domains.
5. Each treatment aggregate has limited resources, hence traffic 5. Each treatment aggregate has limited resources, hence traffic
conditioning and/or admission control must be performed for each conditioning and/or admission control must be performed for each
service class aggregated into the treatment aggregate. service class aggregated into the treatment aggregate.
with the following suggestions:
1. The treatment aggregate and assigned resources may consider
historical traffic patterns and the variability of these
patterns. For example, a point-point service (e.g., pseudowire)
may have a very predictable pattern, while a multipoint service
(e.g., VPLS) may have a much less predictable pattern. Even the
traffic patterns within the Internet may vary widely.
2. In addition to Diffserv, other controls are available to
influence the traffic level offered to a particular traffic
aggregate. These include adjustment of routing metrics, usage of
MPLS-based traffic engineering techniques.
4. Service Classes to Treatment Aggregate Mapping 4. Service Classes to Treatment Aggregate Mapping
The service class and DSCP selection in "Diffserv Service Classes" The service class and DSCP selection in "Diffserv Service Classes"
[5] has been defined to allow, in many instances, mapping of two or [5] has been defined to allow, in many instances, mapping of two or
possibly more service classes into a single forwarding treatment possibly more service classes into a single forwarding treatment
aggregate. Notice that there is a relationship/trade-off between aggregate. Notice that there is a relationship/trade-off between
link speed, queue depth, delay, and jitter. The degree of link speed, queue depth, delay, and jitter. The degree of
aggregation and hence the number of treatment aggregates will depend aggregation and hence the number of treatment aggregates will depend
on whether the speed of the links and scheduler behavior, being used on whether the speed of the links and scheduler behavior, being used
to implement the aggregation, can minimize the affects of mixing to implement the aggregation, can minimize the affects of mixing
skipping to change at page 9, line 8 skipping to change at page 9, line 14
threshold if RED is being used). threshold if RED is being used).
4.1.2. Real Time Treatment Aggregate 4.1.2. Real Time Treatment Aggregate
The Real Time Treatment Aggregate aggregates all real-time The Real Time Treatment Aggregate aggregates all real-time
(inelastic) service classes. The theory is that real-time traffic is (inelastic) service classes. The theory is that real-time traffic is
admitted under some model and controlled by a SLA managed at the edge admitted under some model and controlled by a SLA managed at the edge
of the network prior to aggregation. As such, there is a predictable of the network prior to aggregation. As such, there is a predictable
and enforceable upper bound on the traffic that can enter such a and enforceable upper bound on the traffic that can enter such a
queue, and to provide predictable variation in delay it must be queue, and to provide predictable variation in delay it must be
protected from bursts of elastic traffic. protected from bursts of elastic traffic. The predictability of
traffic level may be based upon admission control for a well known
community of interest (e.g., a point-point service) and/or based upon
historical measurements.
This treatment aggregate may include the following service classes This treatment aggregate may include the following service classes
from the Diffserv Service Classes [5], in addition to other locally from the Diffserv Service Classes [5], in addition to other locally
defined classes: Telephony, Signaling, Multimedia Conferencing, Real- defined classes: Telephony, Signaling, Multimedia Conferencing, Real-
time Interactive, Broadcast Video. time Interactive, Broadcast Video.
Traffic in each service class that is going to be aggregated into the Traffic in each service class that is going to be aggregated into the
treatment aggregate should be conditioned prior to aggregation. It treatment aggregate should be conditioned prior to aggregation. It
is recommended that per service class admission control procedures be is recommended that per service class admission control procedures be
used followed by per service class policing so that any individual used followed by per service class policing so that any individual
skipping to change at page 15, line 12 skipping to change at page 15, line 12
known technical way to respond to or act upon a data stream that has 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 been admitted for service but that it is not intended for
authenticated use. authenticated use.
8. IANA Considerations 8. IANA Considerations
This document does not request any IANA considerations. This document does not request any IANA considerations.
9. Acknowledgements 9. Acknowledgements
This document have benefitted from discussions with numerous people, This document has benefited from discussions with numerous people,
especially Shane Amante and Brian Carpenter. This document have also especially Shane Amante, Brian Carpenter, and Dave McDysan. It has
benefitted from David Black's comments and guidance. And also benefited from detailed reviews by David Black and Marvin Krym.
improvements from Marvin Krym's recommendations.
10. Normative References 10. References
10.1. Normative References
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, [1] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[2] Bradner, S., "The Internet Standards Process -- Revision 3", [2] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of [4] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998. IPv6 Headers", RFC 2474, December 1998.
[5] Babiarz, J., "Configuration Guidelines for DiffServ Service [5] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines
Classes", draft-ietf-tsvwg-diffserv-service-classes-02 (work in for DiffServ Service Classes", RFC 4594, August 2006.
progress), February 2006.
[6] Braden, B., Clark, D., and S. Shenker, "Integrated Services in [6] Braden, B., Clark, D., and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994. the Internet Architecture: an Overview", RFC 1633, June 1994.
[7] Black, D., "Differentiated Services and Tunnels", RFC 2983, [7] Black, D., "Differentiated Services and Tunnels", RFC 2983,
October 2000. October 2000.
[8] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., [8] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P.,
Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol
Label Switching (MPLS) Support of Differentiated Services", Label Switching (MPLS) Support of Differentiated Services",
skipping to change at page 17, line 5 skipping to change at page 16, line 26
[12] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., [12] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A.,
Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K.
Ramakrishnan, "Supplemental Information for the New Definition Ramakrishnan, "Supplemental Information for the New Definition
of the EF PHB (Expedited Forwarding Per-Hop Behavior)", of the EF PHB (Expedited Forwarding Per-Hop Behavior)",
RFC 3247, March 2002. RFC 3247, March 2002.
[13] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of [13] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168, Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001. September 2001.
10.2. Informative References
[14] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot,
"Analysis of Point-To-Point Packet Delay in an Operational
Network", INFOCOMM 2004, March 2004,
<http://www.ieee-infocom.org/2004/Papers/37_4.PDF>.
[15] Ogielski, A. and J. Cowie, "Internet Routing Behavior on 9/11",
March 2002, <http://www.renesys.com/tech/presentations/pdf/
renesys-030502-NRC-911.pdf>.
Authors' Addresses Authors' Addresses
Kwok Ho Chan Kwok Ho Chan
Nortel Networks Nortel Networks
600 Technology Park Drive 600 Technology Park Drive
Billerica, MA 01821 Billerica, MA 01821
US US
Phone: +1-978-288-8175 Phone: +1-978-288-8175
Fax: +1-978-288-8700 Fax: +1-978-288-8700
skipping to change at page 18, line 5 skipping to change at page 18, line 5
Fred Baker Fred Baker
Cisco Systems Cisco Systems
1121 Via Del Rey 1121 Via Del Rey
Santa Barbara, CA 93117 Santa Barbara, CA 93117
US US
Phone: +1-408-526-4257 Phone: +1-408-526-4257
Fax: +1-413-473-2403 Fax: +1-413-473-2403
Email: fred@cisco.com Email: fred@cisco.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 18, line 29 skipping to change at page 18, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. 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 (2006). 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 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 18 change blocks. 
45 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/