TSVWG K. Chan
Internet-Draft J. Babiarz
Expires: December 18, 2006 Nortel Networks
F. Baker
Cisco Systems
June 16, 2006
Aggregation of DiffServ Service Classes
draft-ietf-tsvwg-diffserv-class-aggr-00
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 December 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 diffserv service classes based on end-
to-end behavior requirements of the applications as indicated by
Diffserv Service Classes [5]. However, some network segments may be
Chan, et al. Expires December 18, 2006 [Page 1]
Internet-Draft Document June 2006
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 [5] into a single
forwarding treatment. This document provides guidelines for the
aggregation of Diffserv Service Classes [5] into forwarding
treatments.
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 . . . . . . . . 5
4.1. Mapping Service Classes into Four Treatment Aggregates . . 6
4.1.1. Network Control Treatment Aggregate . . . . . . . . . 8
4.1.2. Real Time Treatment Aggregate . . . . . . . . . . . . 8
4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . 9
4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 10
5. Using MPLS for Treatment Aggregates . . . . . . . . . . . . . 11
5.1. Network Control 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.4. Elastic Treatment Aggregate with E-LSP . . . . . . . . . . 13
5.5. Treatment Aggregates and L-LSP . . . . . . . . . . . . . . 14
6. Treatment Aggregates and Inter-Provider Relationships . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Chan, et al. Expires December 18, 2006 [Page 2]
Internet-Draft Document June 2006
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 SLAs. The implication of this is 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 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 are 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 DOS load) such surges could disrupt
routing.
The document "Diffserv Service Classes" [5] defines the basic
diffserv classes from the points of view of the application requiring
specific end-to-end behaviors from the network. The service classes
are differentiated based on the traffic-payload's tolerance to packet
loss, delay, and delay variation (jitter). Different degrees of
these criterions form the foundation for supporting the needs of
real-time and elastic traffic. The Diffserv Service Classes [5]
document also provides recommendations for the treatment method of
these service classes. But, 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 a situation, that network segment
may use the same treatment to support more than one service class.
In this document we provide guidelines on how multiple service
classes may be aggregated into a forwarding treatment aggregate.
Note that in a given domain, we may recommend that the supported
service classes be aggregated into forwarding treatment aggregates;
however, this does not mean all service classes need to be supported
and hence not all forwarding treatment aggregates need to be
supported. Which service classes and which forwarding treatment
aggregates are supported by a domain is up to the domain
administration and may be influenced by business reasons.
In this document, we've provided:
o definitions for terminology we use in this document,
Chan, et al. Expires December 18, 2006 [Page 3]
Internet-Draft Document June 2006
o requirements for performing this aggregation,
o an example of performing this aggregation over MPLS using E-LSP.
The treatment aggregate recommendations are designed to aggregate the
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.
An example of aggregation over MPLS networks using E-LSP, EXP
Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP), to
realize the treatment aggregates is provided. Note that the MPLS
E-LSP is just an example; this document does not exclude the use of
other methods.
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
This document assumes the reader is familiar with the terms used in
differentiated services. This document provides the definitions for
new terms introduced by this document and referencing information for
existing none differentiated services terms defined in existing RFCs.
For new terms introduced by this document, we provide the definition
here:
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 itself with how the aggregated
traffic is marked, and hence does not put a restriction on the
aggregated traffic having a single diffserv codepoint that have a
single PHB.
For terms from existing RFCs, we provide the reference to the
appropriate section of the relevant RFC that contain the definition:
o Real-Time and Elastic Applications and their traffic. Section 3.1
of RFC 1633 [6].
Chan, et al. Expires December 18, 2006 [Page 4]
Internet-Draft Document June 2006
o Diffserv Service Class. Section 1.3 of
draft-ietf-tsvwg-diffserv-service-classes-02.txt [5].
o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched
Path (LSP). Section 1.2 of RFC 3270 [8].
o MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) Label
Switched Path (LSP). Section 1.3 of RFC 3270 [8].
3. Overview of Service Class Aggregation
In diffserv domains where less granular traffic treatment
differentiation is provided, aggregation of the different service
classes [5] may be required.
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. We recommend an easy
way to accomplish this by not altering the DSCP used to indicate
the end-to-end service class. But some administrative domains
may require the use of their own marking; when this is needed,
the original end-to-end service class indication must be restored
upon exiting such administrative domains.
5. Each treatment aggregate has limited resources, hence traffic
conditioning and/or admission control must be performed for each
service class aggregated 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
Chan, et al. Expires December 18, 2006 [Page 5]
Internet-Draft Document June 2006
possibly more service classes into a single forwarding treatment
aggregate. Notice that there is a relationship/trade-off between
link speed, queue depth, delay, and jitter. The degree of
aggregation and hence the number of treatment aggregates will depend
on whether the speed of the links and scheduler behavior, being used
to implement the aggregation, can minimize the affects of mixing
traffic with different packet sizes and transmit rates on queue
depth. And their impacts on loss, delay, and jitter. A general
rule-of-thumb is that higher link speeds allow for more aggregation/
smaller number of treatment aggregates.
4.1. Mapping Service Classes into Four Treatment Aggregates
This section explains one way of performing this aggregation by using
four treatment aggregates. The use of four treatment aggregates
assumes that the resources allocated to each treatment aggregate is
sufficient to honor the required behavior of each service class [5]
in each of the four treatment aggregates. We use the performance
requirement (tolerance to loss, delay, and jitter) from the
application/end-user as a guide 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 applications. An overview of the mapping between service
classes and the four treatment aggregates is provided by Figure 1,
with the mapping being based on performance requirements. In Figure
1, the right side columns of "Service Class", "Tolerance to Loss/
Delay/Jitter" are from Figure 2 of Diffserv Service Classes [5].
It is recommended that certain service classes be mapped into
specific treatment aggregates. But this does not mean that all the
service classes recommended for that treatment aggregate need to be
supported. Hence, for a given domain, a treatment aggregate may
contain only a subset of the service classes recommended in this
document, they being the service classes supported by that domain. A
domain's treatment of non-supported service classes should be based
on the domain's local policy. This local policy may be influenced by
its agreement with its customers. Such treatment may use the Elastic
Treatment Aggregate, dropping the packets, or some other
arrangements.
Chan, et al. Expires December 18, 2006 [Page 6]
Internet-Draft Document June 2006
---------------------------------------------------------------------
|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| | |
| | | | ||---------------+------+------+------|
| | | | || 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
As we are recommending to preserve the notion of the individual end-
to-end service classes, we also recommend that the original DSCP
field marking not be changed when treatment aggregates are used.
Instead, classifiers that select packets based on the contents of the
DSCP field should be used to direct packets from the member DiffServ
Service Classes into the queue that handles each of the treatment
aggregates, without remarking the DSCP field of the packets. This is
summarized in Figure 2, which shows the behavior each Treatment
Chan, et al. Expires December 18, 2006 [Page 7]
Internet-Draft Document June 2006
Aggregate should have, and the DSCP field marking of the packets that
should be classified into each of the treatment aggregates.
------------------------------------------------------------
|Treatment |Treatment || DSCP |
|Aggregate |Aggregate || |
| |Behavior || |
|==========+==========++=====================================|
| Network | CS || CS6 |
| Control |(RFC 2474)|| |
|==========+==========++=====================================|
| Real | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 |
| Time |(RFC 3246)|| |
|==========+==========++=====================================|
| Assured | AF || CS2, AF31, AF21, AF11 |
| Elastic |(RFC 2597)||-------------------------------------|
| | || AF32, AF22, AF12 |
| | ||-------------------------------------|
| | || AF33, AF23, AF13 |
|==========+==========++=====================================|
| Elastic | Default || Default, (CS0) |
| |(RFC 2474)||-------------------------------------|
| | || CS1 |
------------------------------------------------------------
Figure 2: Treatment Aggregate Behavior
4.1.1. Network Control Treatment Aggregate
The Network Control Treatment Aggregate aggregates all service
classes that are functionally necessary for the survival of a network
during a DOS attack 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 being included in the Network Control Service Class.
The DSCPs of the original service class remain an important
consideration and should be preserved during aggregation. Traffic in
the Network Control treatment aggregate should be carried in a common
queue or class with a PHB as described in RFC 2474 [4] section
4.2.2.2. This treatment aggregate should have a lower probability of
packet loss, 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
Chan, et al. Expires December 18, 2006 [Page 8]
Internet-Draft Document June 2006
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
and enforceable 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 the following service classes
from the Diffserv Service Classes [5], in addition to other locally
defined classes: Telephony, Signaling, Multimedia Conferencing, Real-
time Interactive, Broadcast Video.
Traffic in each service class that is going to be aggregated into the
treatment aggregate should be conditioned prior to aggregation. It
is recommended that per service class admission control procedures be
used followed by per service class policing so that any individual
service class does not generate more than what it is allowed.
Furthermore, additional admission control and policing may be used on
the sum of all service classes aggregated.
The DSCPs of the original service classes remain an important
consideration and should be preserved during aggregation. Traffic
bearing these DSCPs is carried in a common queue or class with a PHB
as described in RFC 3246 [11] and RFC 3247 [12].
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 [10]. The premise of such a service is that a SLA is negotiated
which 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 [9] or ECN flagging [13] for the
portion of traffic deemed to be in excess.
This treatment aggregate may include the following service classes
from the Diffserv Service Classes [5], in addition to other locally
defined classes: Multimedia Streaming, Low Latency Data, OAM, High
Throughput Data.
The DSCP values belonging to the AF PHB group of the original service
classes remain an important consideration and should be preserved
during aggregation. This treatment aggregate should maintain the AF
PHB group marking of the original packet. For example, AF3x marked
packets should remain AF3x marked within this treatment aggregate.
Traffic bearing these DSCPs is carried in a common queue or class
with a PHB as described in RFC 2597 [10]. In effect, appropriate
target rate thresholds have been applied at the edge, dividing
traffic into AFn1 (committed, for any value of n), AFn2, and AFn3
Chan, et al. Expires December 18, 2006 [Page 9]
Internet-Draft Document June 2006
(excess). The service should be engineered so that AFn1 marked
packet flows have sufficient bandwidth in the network to provide high
assurance of delivery. Since the traffic is elastic and responds
dynamically to packet loss, Active Queue Management [9] should be
used primarily to reduce the forwarding rate to the minimum assured
rate at congestion points. The probability of loss of AFn1 traffic
must not exceed the probability of loss of AFn2 traffic, which in
turn must not exceed the probability of loss of AFn3 traffic.
If RED [9] is used as an AQM algorithm, the min-threshold specifies a
target queue depth for each of AFn1, AFn2, AFn3, and the max-
threshold specifies the queue depth above which all traffic with such
a DSCP is dropped or ECN marked. Thus, in this Treatment Aggregate,
the following inequalities should hold in queue configurations:
o min-threshold AFn3 < max-threshold AFn3
o max-threshold AFn3 <= min-threshold AFn2
o min-threshold AFn2 < max-threshold AFn2
o max-threshold AFn2 <= min-threshold AFn1
o min-threshold AFn1 < max-threshold AFn1
o max-threshold AFn1 <= memory assigned to the queue
Note: This configuration tends to drop AFn3 traffic before AFn2 and
AFn2 before AFn1. Many other AQM algorithms exist and are used; they
should be configured to achieve a similar result.
4.1.4. Elastic Treatment Aggregate
The Elastic Treatment Aggregate aggregates all remaining elastic
traffic. The premise of such a service is that there is no intrinsic
SLA differentiation of traffic, but that AQM [9] or ECN flagging [13]
is appropriate for such traffic.
This treatment aggregate may include the following service classes
from the Diffserv Service Classes [5], in addition to other locally
defined classes: Standard, Low Priority Data.
The DSCPs of the original service classes remain an important
consideration and should be preserved during aggregation. Traffic
bearing these DSCPs is carried in a common queue or class with a PHB
as described in RFC 2474 [4] section 4.1: A Default PHB. The AQM
thresholds for Elastic traffic MAY be separately set, so that Low
Priority Data traffic is dropped before Standard traffic, but this is
Chan, et al. Expires December 18, 2006 [Page 10]
Internet-Draft Document June 2006
not a requirement.
5. Using MPLS for Treatment Aggregates
RFC 2983 on DiffServ and Tunnels [7] and RFC 3270 on MPLS Support of
DiffServ [8] provide a very good background on this topic. This
document provides an example of using the E-LSP, EXP Inferred PHB
Scheduled Class (PSC) Label Switched Path (LSP), defined by MPLS
Support of DiffServ [8] for realizing the Treatment Aggregates.
When Treatment Aggregates are represented in MPLS using EXP Inferred
PSC LSP, we recommend the following usage of the MPLS EXP field for
Treatment Aggregates.
Chan, et al. Expires December 18, 2006 [Page 11]
Internet-Draft Document June 2006
-------------------------------------------
|Treatment || MPLS || DSCP | DSCP |
|Aggregate || EXP || name | value |
|==========++======++=========|=============|
| Network || 110 || CS6 | 110000 |
| Control || || | |
|==========++======++=========|=============|
| Real || 100 || EF | 101110 |
| Time || ||---------|-------------|
| || || CS5 | 101000 |
| || ||---------|-------------|
| || ||AF41,AF42|100010,100100|
| || || AF43 | 100110 |
| || ||---------|-------------|
| || || CS4 | 100000 |
| || ||---------|-------------|
| || || CS3 | 011000 |
|==========++======++=========|=============|
| Assured || 010* || CS2 | 010000 |
| Elastic || || AF31 | 011010 |
| || || AF21 | 010010 |
| || || AF11 | 001010 |
| ||------||---------|-------------|
| || 011* || AF32 | 011100 |
| || || AF22 | 010100 |
| || || AF12 | 001100 |
| || || AF33 | 011110 |
| || || AF23 | 010110 |
| || || AF13 | 001110 |
|==========++======++=========|=============|
| Elastic || 000* || Default | 000000 |
| || || (CS0) | |
| ||------||---------|-------------|
| || 001* || CS1 | 001000 |
-------------------------------------------
Figure 3: Treatment Aggregate and MPLS EXP Field Usage
Notes *: For Assured Elastic (and Elastic) Treatment Aggregate, the
usage of 010 or 011 (000 or 001) as EXP field value depends on the
drop probability. Packets in the LSP with EXP field of 011 (001)
have a higher probability of being dropped than packets with an EXP
field of 010 (000).
The above table indicates the recommended usage of EXP fields for
Treatment Aggregates. Because many deployments of MPLS are on a per
domain basis, each domain has total control of its EXP usage and each
domain may use a different EXP field allocation for the domain's
Chan, et al. Expires December 18, 2006 [Page 12]
Internet-Draft Document June 2006
supported Treatment Aggregates.
5.1. Network Control Treatment Aggregate with E-LSP
The usage of E-LSP for Network Control Treatment Aggregate needs to
adhere to the recommendations indicated in section 4.1.1 of this
document and section 3.2 of "Diffserv Service Classes" [5].
Reinforcing these recommendations, there should be no drop precedence
associated with the MPLS PSC used for Network Control Treatment
Aggregate because dropping of Network Control Treatment Aggregate
traffic should be prevented.
5.2. Real Time Treatment Aggregate with E-LSP
In addition to the recommendations provided in section 4.1.2 of this
document and in member service classes' sections of "Diffserv Service
Classes" [5], we want to indicate that Real Time Treatment Aggregate
traffic should not be dropped, as some of the applications whose
traffic is carried in the Real Time Treatment Aggregate do not react
well to dropped packets. As indicated in section 4.1.2 of this
document, admission control should be performed on each Service Class
contributing to the Real Time Treatment Aggregate to prevent packet
loss due to insufficient resources allocated to Real Time Treatment
Aggregate. Further, admission control and policing may also be
applied on the sum of all traffic aggregated into this treatment
aggregate.
5.3. Assured Elastic Treatment Aggregate with E-LSP
EXP field markings of 010 and 011 are used for the Assured Elastic
Treatment Aggregate. The two encodings are used to provide two
levels of drop precedence indications, with 010 encoded traffic
having a lower probability of being dropped than 011 encoded traffic.
This provides for the mapping of CS2, AF31, AF21, and AF11 into EXP
010; and AF32, AF22, AF12 and AF33, AF23, AF13 into EXP 011.
5.4. Elastic Treatment Aggregate with E-LSP
EXP field markings of 000 and 001 are used for the Elastic Treatment
Aggregate. The two encodings are used to provide two levels of drop
precedence indications, with 000 encoded traffic having a lower
probability of being dropped than 001 encoded traffic. This provides
for the mapping of Default/CS0 into 000; and CS1 into 001. Notice
that with this mapping, during congestion, CS1 marked traffic may be
starved.
Chan, et al. Expires December 18, 2006 [Page 13]
Internet-Draft Document June 2006
5.5. Treatment Aggregates and L-LSP
Because L-LSP (Label Only Inferred PSC LSP) supports a single PSC per
LSP, the support of each Treatment Aggregate is on a per LSP basis.
This document does not further specify any additional recommendation
(beyond what has been indicated in section 4 of this document) for
Treatment Aggregate to L-LSP mapping, leaving this to each individual
MPLS domain administrations.
6. Treatment Aggregates and Inter-Provider Relationships
When Treatment Aggregates are used at provider boundaries, we
recommend that the Inter-Provider Relationship be based on Diffserv
Service Classes [5]. This allows the admission control into each
Treatment Aggregate of a provider domain to be based on the admission
control of traffic into the supported Service Classes, as indicated
by the discussion in section 4 of this document.
If the Inter-Provider Relationship needs to be based on Treatment
Aggregates specified by this document, then the exact Treatment
Aggregate content and representation must be agreed to by the peering
providers.
7. Security Considerations
This document discusses the policy of using Differentiated Services
and its service classes. If implemented as described, it should
require that the network 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 best of the authors' 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
Chan, et al. Expires December 18, 2006 [Page 14]
Internet-Draft Document June 2006
authenticated use.
8. IANA Considerations
This document does not request any IANA considerations.
9. Acknowledgements
This document have benefitted from discussions with numerous people,
especially Shane Amante and Brian Carpenter. This document have also
benefitted from David Black's comments and guidance. And
improvements from Marvin Krym's recommendations.
10. 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., "Configuration Guidelines for DiffServ Service
Classes", draft-ietf-tsvwg-diffserv-service-classes-02 (work in
progress), February 2006.
[6] Braden, B., Clark, D., and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[7] Black, D., "Differentiated Services and Tunnels", RFC 2983,
October 2000.
[8] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P.,
Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol
Label Switching (MPLS) Support of Differentiated Services",
RFC 3270, May 2002.
[9] 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,
Chan, et al. Expires December 18, 2006 [Page 15]
Internet-Draft Document June 2006
J., and L. Zhang, "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April 1998.
[10] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured
Forwarding PHB Group", RFC 2597, June 1999.
[11] 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.
[12] 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.
[13] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
Chan, et al. Expires December 18, 2006 [Page 16]
Internet-Draft Document June 2006
Authors' Addresses
Kwok Ho Chan
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821
US
Phone: +1-978-288-8175
Fax: +1-978-288-8700
Email: khchan@nortel.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@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 December 18, 2006 [Page 17]
Internet-Draft Document June 2006
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 (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
Funding for the RFC Editor function is currently provided by the
Internet Society.
Chan, et al. Expires December 18, 2006 [Page 18]
