TSVWG K. Chan
Internet-Draft J. Babiarz
Expires: July 22, 2006 Nortel Networks
F. Baker
Cisco Systems
January 18, 2006
Aggregation of DiffServ Service Classes
draft-chan-tsvwg-diffserv-class-aggr-03
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 July 22, 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 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
Chan, et al. Expires July 22, 2006 [Page 1]
Internet-Draft Document January 2006
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 . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Service Class Aggregation . . . . . . . . . . . . 4
4. Service Classes to Treatment Aggregate Mapping . . . . . . . . 5
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 . . . . . . . . . . . . 7
4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . 7
4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 8
4.2. Treatment Aggregate Summary . . . . . . . . . . . . . . . 9
5. Using MPLS for Treatment Aggregates . . . . . . . . . . . . . 9
5.1. Network Control Treatment Aggregate with E-LSP . . . . . . 11
5.2. Real Time Treatment Aggregate with E-LSP . . . . . . . . . 11
5.3. Assured Elastic Treatment Aggregate with E-LSP . . . . . . 11
5.4. Elastic Treatment Aggregate with E-LSP . . . . . . . . . . 11
5.5. Treatment Aggregates and L-LSP . . . . . . . . . . . . . . 12
6. Treatment Aggregates and Inter Provider Relationships . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
10. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Chan, et al. Expires July 22, 2006 [Page 2]
Internet-Draft Document January 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 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 DOS 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. Notice in a given domain, we recommend the
supported service classes be aggregated into forwarding treatment
aggregates, this does not mean all service classes needs to be
supported and hence not all forwarding treatment aggregates needs to
be supported. Which service classes and which forwarding treatement
aggregates is supported by a domain is up to the domain
administration and may be influenced by business reasons. We've also
provided some terminology and requirement for performing this
aggregation.
Chan, et al. Expires July 22, 2006 [Page 3]
Internet-Draft Document January 2006
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 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. 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,
Chan, et al. Expires July 22, 2006 [Page 4]
Internet-Draft Document January 2006
the original end-to-end service class indication MUST be restored
upon exit of such administrative domains.
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
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,
different 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.
Notice we recommended certain service classes be mapped into specific
treatment aggregates. But this does not mean that all the service
classes recommended for that treatment aggregate needs to be
supported. Hence for a domain, a treatment aggregate may contain a
subset of the service classes recommended in this document, they
being the service classes supported by that domain. A domain's
treatment of none-supported service classes is that domain's local
policy. This local policy may be influenced by its agreement with
its customers. Such treatment may use the Elastic Treatment
Chan, et al. Expires July 22, 2006 [Page 5]
Internet-Draft Document January 2006
Aggregate, dropping the packets, or some other arrangements.
---------------------------------------------------------------------
|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
4.1.1. Network Control Treatment Aggregate
The Network Control Treatment Aggregate aggregates all service
classes that is functionally necessary for the survival of a network
during a DOS or other high traffic load interval. The theory is that
whatever else is true, the network must protect itself. This
Chan, et al. Expires July 22, 2006 [Page 6]
Internet-Draft Document January 2006
includes the traffic that Diffserv Service Classes [5] characterizes
as in the Network Control Service Class.
The DSCPs of the original service class 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 2309 [9] and RFC 2474 [4] for CS6. And for 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
admitted under some model and controlled by an 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 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 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, 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 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 [9] or ECN flagging [13] for the
portion of traffic deemed to be in excess.
Chan, et al. Expires July 22, 2006 [Page 7]
Internet-Draft Document January 2006
This treatment aggregate may include the following service classes
from Diffserv Service Classes [5], in addition to other locally
defined classes: Multimedia Streaming, Low Latency Data, OAM, High
Throughput 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 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 (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 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.
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 inequality 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 service is that there is no intrinsic
SLA differentiation of traffic, but that AQM [9] or ECN flagging [13]
is appropriate for such traffic.
Chan, et al. Expires July 22, 2006 [Page 8]
Internet-Draft Document January 2006
This treatment aggregate may include the following service classes
from 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 2309 [9]. The AQM thresholds for Elastic traffic
MAY be separately set, so that Low Priority Data traffic is dropped
before Standard traffic, but this is not a requirement.
4.2. Treatment Aggregate Summary
The behavior for the above mentioned Treatment Aggregates are
summarized in the following table:
------------------------------------------------------------
|Treatment |Treatment || DSCP name |
|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 |
| | ||-------------------------------------|
| | || AF13, AF23, AF33 |
|==========+==========++=====================================|
| Elastic | Default || Default, (CS0) |
| |(RFC 2474)||-------------------------------------|
| | || CS1 |
------------------------------------------------------------
Figure 2: Treatment Aggregate Behavior Summary
5. Using MPLS for Treatment Aggregates
RFC 2983 on DiffServ and Tunnels [7] and RFC 3270 on MPLS Support of
DiffServ [8] provided 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), notion indicated in
MPLS Support of DiffServ [8] for Treatment Aggregates.
Chan, et al. Expires July 22, 2006 [Page 9]
Internet-Draft Document January 2006
When Treatment Aggregates are represented in MPLS using EXP Inferred
PSC LSP, we recommend the following usage of MPLS EXP field for
Treatment Aggregates.
-------------------------------------------
|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) depends on the drop probability.
The above table indicates the recommended usage of EXP field for
Treatment Aggregates. Because many deployment of MPLS is on a per
Chan, et al. Expires July 22, 2006 [Page 10]
Internet-Draft Document January 2006
domain basis, each domain have total control of its EXP usage, each
domain may use a different EXP field allocation for the domain's
supported Treatment Aggregates.
5.1. Network Control Treatment Aggregate with E-LSP
The usage of E-LSP for Network Control Treatment Aggregate needs to
cohere 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 Diffserv Service Classes [5], we want to indicate
that Real Time Treatment Aggregate traffic should not be dropped, as
some of the traffic carried in the Real Time Treatment Aggregate does
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 resource 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 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 drop then 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 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 drop then 001 encoded traffic. This provides
for the mapping of Default/CS0 into 000; and CS1 into 001. Notice
with this mapping, during congestion, CS1 marked traffic may be
starved.
Chan, et al. Expires July 22, 2006 [Page 11]
Internet-Draft Document January 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 had been indicated in section 4 of this document) for
Treatment Aggregate to L-LSP mapping, leaving this to each individual
MPLS domain administration.
6. Treatment Aggregates and Inter Provider Relationships
When Treatment Aggregates are used at the provider boundaries, we
recommend the Inter Provider Relationship be based on Diffserv
Service Classes [5]. This allows the admission control into each
Treatment Aggregate of a provider domain be based on the admission
control of traffic into the supported Service Classes, as indicated
by the discussions in section 4 of this document.
If the Inter Provider Relationship needs to be based on Treatment
Aggregates specified by this document, the exact Treatment Aggregate
content and representation must be agreed between the peering
providers.
7. 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.
Chan, et al. Expires July 22, 2006 [Page 12]
Internet-Draft Document January 2006
8. IANA Considerations
To be completed.
9. Acknowledgements
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-01 (work in
progress), July 2005.
[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,
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
Chan, et al. Expires July 22, 2006 [Page 13]
Internet-Draft Document January 2006
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 July 22, 2006 [Page 14]
Internet-Draft Document January 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-4690
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 July 22, 2006 [Page 15]
Internet-Draft Document January 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 July 22, 2006 [Page 16]