Aggregation of Diffserv Service Classes
RFC 5127
|
| Document |
Type |
|
RFC - Informational
(February 2008; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Replaces |
|
draft-chan-tsvwg-diffserv-class-aggr
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5127 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Magnus Westerlund
|
|
Send notices to |
|
(None)
|
Network Working Group K. Chan
Request for Comments: 5127 J. Babiarz
Category: Informational Nortel
F. Baker
Cisco Systems
February 2008
Aggregation of Diffserv Service Classes
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract
In the core of a high-capacity network, service differentiation may
still be needed to support applications' utilization of the network.
Applications with similar traffic characteristics and performance
requirements are mapped into 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 may satisfy the traffic characteristics and
performance requirements of two or more service classes. In these
cases, it may be desirable to aggregate two or more Diffserv service
classes into a single forwarding treatment. This document provides
guidelines for the aggregation of Diffserv service classes into
forwarding treatments.
Chan, et al. Informational [Page 1]
RFC 5127 Aggregation of Diffserv Service Classes February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Service Class Aggregation . . . . . . . . . . . . 5
4. Service Classes to Treatment Aggregate Mapping . . . . . . . . 6
4.1. Mapping Service Classes into Four Treatment Aggregates . . 7
4.1.1. Network Control Treatment Aggregate . . . . . . . . . 9
4.1.2. Real-Time Treatment Aggregate . . . . . . . . . . . . 10
4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . 10
4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 12
5. Treatment Aggregates and Inter-Provider Relationships . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Using MPLS for Treatment Aggregates . . . . . . . . 15
A.1. Network Control Treatment Aggregate with E-LSP . . . . . . 17
A.2. Real-Time Treatment Aggregate with E-LSP . . . . . . . . . 17
A.3. Assured Elastic Treatment Aggregate with E-LSP . . . . . . 17
A.4. Elastic Treatment Aggregate with E-LSP . . . . . . . . . . 17
A.5. Treatment Aggregates and L-LSP . . . . . . . . . . . . . . 18
Chan, et al. Informational [Page 2]
RFC 5127 Aggregation of Diffserv Service Classes February 2008
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 will be a routed network that still meets
ambient Service Level Agreements (SLAs). The implications are that
there is sufficient capacity on any given link such that all SLAs
sold can be simultaneously supported at their respective maximum
rates, and that this remains true after re-routing (either IP re-
routing or Multiprotocol Label Switching (MPLS) protection-mode
switching) has occurred.
Over-provisioning is generally considered to meet the requirements of
all traffic without further quality of service (QoS) treatment, and
in the general case, that is true in high-capacity backbones.
However, as the process of network convergence continues, and with
the increasing speed of the access networks, certain services may
still have issues. Delay, jitter, and occasional loss are perfectly
acceptable for elastic applications. However, sub-second surges that
occur in the best-designed of networks [12] affect real-time
applications. Moreover, denial of service (DoS) loads, worms, and
network disruptions such as that of 11 September 2001 affect routing
[13]. Our objective is to prevent disruption to routing (which in
turn affects all services) and to protect real-time jitter-sensitive
Show full document text