draft-ietf-tsvwg-diffserv-class-aggr-01.txt   draft-ietf-tsvwg-diffserv-class-aggr-02.txt 
TSVWG K. Chan TSVWG K. Chan
Internet-Draft J. Babiarz Internet-Draft J. Babiarz
Intended status: Informational Nortel Networks Intended status: Informational Nortel Networks
Expires: April 23, 2007 F. Baker Expires: September 6, 2007 F. Baker
Cisco Systems Cisco Systems
October 20, 2006 March 5, 2007
Aggregation of DiffServ Service Classes Aggregation of DiffServ Service Classes
draft-ietf-tsvwg-diffserv-class-aggr-01 draft-ietf-tsvwg-diffserv-class-aggr-02
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 April 23, 2007. This Internet-Draft will expire on September 6, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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
requirements are mapped into diffserv service classes based on end- requirements are mapped into diffserv service classes based on end-
to-end behavior requirements of the applications as indicated by to-end behavior requirements of the applications as indicated by
Diffserv Service Classes [5]. However, some network segments may be Diffserv Service Classes [5]. However, some network segments may be
configured in such a way that a single forwarding treatment may configured in such a way that a single forwarding treatment may
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 . . . . . . . . 6 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 . . . . . . . . . 9
4.1.2. Real Time Treatment Aggregate . . . . . . . . . . . . 9 4.1.2. Real Time Treatment Aggregate . . . . . . . . . . . . 9
4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . 9 4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . 10
4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 10 4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 11
5. Using MPLS for Treatment Aggregates . . . . . . . . . . . . . 11 5. Using MPLS for Treatment Aggregates . . . . . . . . . . . . . 12
5.1. Network Control Treatment Aggregate with E-LSP . . . . . . 13 5.1. Network Control Treatment Aggregate with E-LSP . . . . . . 14
5.2. Real Time Treatment Aggregate with E-LSP . . . . . . . . . 13 5.2. Real Time Treatment Aggregate with E-LSP . . . . . . . . . 14
5.3. Assured Elastic Treatment Aggregate with E-LSP . . . . . . 13 5.3. Assured Elastic Treatment Aggregate with E-LSP . . . . . . 14
5.4. Elastic Treatment Aggregate with E-LSP . . . . . . . . . . 13 5.4. Elastic Treatment Aggregate with E-LSP . . . . . . . . . . 14
5.5. Treatment Aggregates and L-LSP . . . . . . . . . . . . . . 14 5.5. Treatment Aggregates and L-LSP . . . . . . . . . . . . . . 15
6. Treatment Aggregates and Inter-Provider Relationships . . . . 14 6. Treatment Aggregates and Inter-Provider Relationships . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19
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
skipping to change at page 3, line 44 skipping to change at page 3, line 44
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 With the IP traffic belonging to service classes, expressed using the
service classes be aggregated into forwarding treatment aggregates; DSCP, as described by "Diffserv Service Classes" [5]. Note that in a
however, this does not mean all service classes need to be supported given domain, we may recommend that the supported service classes be
and hence not all forwarding treatment aggregates need to be aggregated into forwarding treatment aggregates; however, this does
supported. Which service classes and which forwarding treatment not mean all service classes need to be supported and hence not all
aggregates are supported by a domain is up to the domain forwarding treatment aggregates need to be supported. A domain may
administration and may be influenced by business reasons. support fewer or greater number of forwarding treatment aggregates.
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: In this document, we've provided:
o definitions for terminology we use in this document, o definitions for terminology we use in this document,
o requirements for performing this aggregation, o requirements for performing this aggregation,
o an example of performing this aggregation over MPLS using E-LSP. o an example of performing this aggregation over MPLS using E-LSP.
The treatment aggregate recommendations are designed to aggregate the The treatment aggregate recommendations are designed to aggregate the
service classes [5] in such a manner as to protect real-time traffic service classes [5] in such a manner as to protect real-time traffic
and routing, on the assumption that real-time sessions are protected and routing, on the assumption that real-time sessions are protected
from each other by admission at the edge. from each other by admission at the edge.
An example of aggregation over MPLS networks using E-LSP, EXP An example of aggregation over MPLS networks using E-LSP, EXP
Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP), to Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP), to
realize the treatment aggregates is provided. Note that the MPLS realize the treatment aggregates is provided. Note that the MPLS
E-LSP is just an example; this document does not exclude the use of E-LSP is just an example; this document does not exclude the use of
other methods. other methods. This example only considers aggregation of IP traffic
into E-LSP. The use of E-LSP by none-IP traffic is not discussed.
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. document are to be interpreted as described in RFC 2119 [3].
2. Terminology 2. Terminology
This document assumes the reader is familiar with the terms used in This document assumes the reader is familiar with the terms used in
skipping to change at page 5, line 5 skipping to change at page 5, line 11
traffic is marked, and hence does not put a restriction on the traffic is marked, and hence does not put a restriction on the
aggregated traffic having a single diffserv codepoint that have a aggregated traffic having a single diffserv codepoint that have a
single PHB. single PHB.
For terms from existing RFCs, we provide the reference to the For terms from existing RFCs, we provide the reference to the
appropriate section of the relevant RFC that contain the definition: appropriate section of the relevant RFC that contain the definition:
o Real-Time and Elastic Applications and their traffic. Section 3.1 o Real-Time and Elastic Applications and their traffic. Section 3.1
of RFC 1633 [6]. of RFC 1633 [6].
o Diffserv Service Class. Section 1.3 of o Diffserv Service Class. Section 1.3 of RFC 4594 [5].
draft-ietf-tsvwg-diffserv-service-classes-02.txt [5].
o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched
Path (LSP). Section 1.2 of RFC 3270 [8]. Path (LSP). Section 1.2 of RFC 3270 [8].
o MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) Label o MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) Label
Switched Path (LSP). Section 1.3 of RFC 3270 [8]. Switched Path (LSP). Section 1.3 of RFC 3270 [8].
3. Overview of Service Class Aggregation 3. Overview of Service Class Aggregation
In diffserv domains where less granular traffic treatment In diffserv domains where less granular traffic treatment
skipping to change at page 6, line 13 skipping to change at page 6, line 19
patterns. For example, a point-point service (e.g., pseudowire) patterns. For example, a point-point service (e.g., pseudowire)
may have a very predictable pattern, while a multipoint service may have a very predictable pattern, while a multipoint service
(e.g., VPLS) may have a much less predictable pattern. Even the (e.g., VPLS) may have a much less predictable pattern. Even the
traffic patterns within the Internet may vary widely. traffic patterns within the Internet may vary widely.
2. In addition to Diffserv, other controls are available to 2. In addition to Diffserv, other controls are available to
influence the traffic level offered to a particular traffic influence the traffic level offered to a particular traffic
aggregate. These include adjustment of routing metrics, usage of aggregate. These include adjustment of routing metrics, usage of
MPLS-based traffic engineering techniques. MPLS-based traffic engineering techniques.
This document only describes the aggregation of IP traffic based on
the use of Diffserv Service Classes [5].
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
traffic with different packet sizes and transmit rates on queue traffic with different packet sizes and transmit rates on queue
depth. And their impacts on loss, delay, and jitter. A general depth. And their impacts on loss, delay, and jitter. A general
rule-of-thumb is that higher link speeds allow for more aggregation/ rule-of-thumb is that higher link speeds allow for more aggregation/
smaller number of treatment aggregates. smaller number of treatment aggregates.
4.1. Mapping Service Classes into Four Treatment Aggregates 4.1. Mapping Service Classes into Four Treatment Aggregates
This section explains one way of performing this aggregation by using This section provides an example of mapping all the service classes
four treatment aggregates. The use of four treatment aggregates defined in RFC 4594 [5] into four treatment aggregates. The use of
assumes that the resources allocated to each treatment aggregate is four treatment aggregates assumes that the resources allocated to
sufficient to honor the required behavior of each service class [5] each treatment aggregate is sufficient to honor the required behavior
in each of the four treatment aggregates. We use the performance of each service class [5] in each of the four treatment aggregates.
requirement (tolerance to loss, delay, and jitter) from the We use the performance requirement (tolerance to loss, delay, and
application/end-user as a guide on how to map the service classes jitter) from the application/end-user as a guide on how to map the
into treatment aggregates. We have also used Section 3.1 of RFC 1633 service classes into treatment aggregates. We have also used Section
[6] to provide us with guidance on the definition of Real-Time and 3.1 of RFC 1633 [6] to provide us with guidance on the definition of
Elastic applications. An overview of the mapping between service Real-Time and Elastic applications. An overview of the mapping
classes and the four treatment aggregates is provided by Figure 1, between service classes and the four treatment aggregates is provided
with the mapping being based on performance requirements. In Figure by Figure 1, with the mapping being based on performance
1, the right side columns of "Service Class", "Tolerance to Loss/ requirements. In Figure 1, the right side columns of "Service
Delay/Jitter" are from Figure 2 of Diffserv Service Classes [5]. 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 It is recommended that certain service classes be mapped into
specific treatment aggregates. But this does not mean that all the specific treatment aggregates. But this does not mean that all the
service classes recommended for that treatment aggregate need to be service classes recommended for that treatment aggregate need to be
supported. Hence, for a given domain, a treatment aggregate may supported. Hence, for a given domain, a treatment aggregate may
contain only a subset of the service classes recommended in this contain only a subset of the service classes recommended in this
document, they being the service classes supported by that domain. A document, they being the service classes supported by that domain. A
domain's treatment of non-supported service classes should be based domain's treatment of non-supported service classes should be based
on the domain's local policy. This local policy may be influenced by on the domain's local policy. This local policy may be influenced by
its agreement with its customers. Such treatment may use the Elastic its agreement with its customers. Such treatment may use the Elastic
Treatment Aggregate, dropping the packets, or some other Treatment Aggregate, dropping the packets, or some other
arrangements. arrangements.
Our example of four treatment aggregates is based on the basic
differences in performance requirement from the application/end-user
perspective. A domain may choose to support more or less treatment
aggregates. For example, only supporting three treatment aggregates,
and with mapping any network control traffic into the Assured Elastic
treatment aggregate. This is a choice the administrative domain has.
--------------------------------------------------------------------- ---------------------------------------------------------------------
|Treatment | Tolerance to ||Service Class | Tolerance to | |Treatment | Tolerance to ||Service Class | Tolerance to |
|Aggregate | Loss |Delay |Jitter|| | Loss |Delay |Jitter| |Aggregate | Loss |Delay |Jitter|| | Loss |Delay |Jitter|
|==========+======+======+======++===============+======+======+======| |==========+======+======+======++===============+======+======+======|
| Network | Low | Low | Yes || Network | Low | Low | Yes | | Network | Low | Low | Yes || Network | Low | Low | Yes |
| Control | | | || Control | | | | | Control | | | || Control | | | |
|==========+======+======+======++===============+======+======+======| |==========+======+======+======++===============+======+======+======|
| Real | Very | Very | Very || Telephony | VLow | VLow | VLow | | Real | Very | Very | Very || Telephony | VLow | VLow | VLow |
| Time | Low | Low | Low ||---------------+------+------+------| | Time | Low | Low | Low ||---------------+------+------+------|
| | | | || Signaling | Low | Low | Yes | | | | | || Signaling | Low | Low | Yes |
skipping to change at page 10, line 5 skipping to change at page 10, line 46
which includes a "committed rate" and the ability to exceed that rate which includes a "committed rate" and the ability to exceed that rate
(and perhaps a second "excess rate") in exchange for a higher (and perhaps a second "excess rate") in exchange for a higher
probability of loss using AQM [9] or ECN flagging [13] for the probability of loss using AQM [9] or ECN flagging [13] for the
portion of traffic deemed to be in excess. portion of traffic deemed to be in excess.
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: Multimedia Streaming, Low Latency Data, OAM, High defined classes: Multimedia Streaming, Low Latency Data, OAM, High
Throughput Data. Throughput Data.
The DSCP values belonging to the AF PHB group of the original service The DSCP values belonging to the AF PHB group and class selector of
classes remain an important consideration and should be preserved the original service classes remain an important consideration and
during aggregation. This treatment aggregate should maintain the AF should be preserved during aggregation. This treatment aggregate
PHB group marking of the original packet. For example, AF3x marked should maintain the AF PHB group marking of the original packet. For
packets should remain AF3x marked within this treatment aggregate. example, AF3x marked packets should remain AF3x marked within this
Traffic bearing these DSCPs is carried in a common queue or class treatment aggregate. In addition, the class selector DSCP value
with a PHB as described in RFC 2597 [10]. In effect, appropriate should not be changed. Traffic bearing these DSCPs is carried in a
target rate thresholds have been applied at the edge, dividing common queue or class with a PHB as described in RFC 2597 [10]. In
traffic into AFn1 (committed, for any value of n), AFn2, and AFn3 effect, appropriate target rate thresholds have been applied at the
(excess). The service should be engineered so that AFn1 marked edge, dividing traffic into AFn1 (committed, for any value of n),
packet flows have sufficient bandwidth in the network to provide high AFn2, and AFn3 (excess). The service should be engineered so that
assurance of delivery. Since the traffic is elastic and responds AFn1 and CS2 marked packet flows have sufficient bandwidth in the
dynamically to packet loss, Active Queue Management [9] should be network to provide high assurance of delivery. Since the traffic is
used primarily to reduce the forwarding rate to the minimum assured elastic and responds dynamically to packet loss, Active Queue
rate at congestion points. The probability of loss of AFn1 traffic Management [9] should be used primarily to reduce the forwarding rate
must not exceed the probability of loss of AFn2 traffic, which in to the minimum assured rate at congestion points. The probability of
turn must not exceed the probability of loss of AFn3 traffic. loss of AFn1 and CS2 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 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- target queue depth for each of AFn1+CS2, AFn2, AFn3, and the max-
threshold specifies the queue depth above which all traffic with such threshold specifies the queue depth above which all traffic with such
a DSCP is dropped or ECN marked. Thus, in this Treatment Aggregate, a DSCP is dropped or ECN marked. Thus, in this Treatment Aggregate,
the following inequalities should hold in queue configurations: the following inequalities should hold in queue configurations:
o min-threshold AFn3 < max-threshold AFn3 o min-threshold AFn3 < max-threshold AFn3
o max-threshold AFn3 <= min-threshold AFn2 o max-threshold AFn3 <= min-threshold AFn2
o min-threshold AFn2 < max-threshold AFn2 o min-threshold AFn2 < max-threshold AFn2
o max-threshold AFn2 <= min-threshold AFn1 o max-threshold AFn2 <= min-threshold AFn1+CS2
o min-threshold AFn1 < max-threshold AFn1 o min-threshold AFn1+CS2 < max-threshold AFn1+CS2
o max-threshold AFn1 <= memory assigned to the queue o max-threshold AFn1+CS2 <= memory assigned to the queue
Note: This configuration tends to drop AFn3 traffic before AFn2 and Note: This configuration tends to drop AFn3 traffic before AFn2 and
AFn2 before AFn1. Many other AQM algorithms exist and are used; they AFn2 before AFn1 and CS2. Many other AQM algorithms exist and are
should be configured to achieve a similar result. used; they should be configured to achieve a similar result.
4.1.4. Elastic Treatment Aggregate 4.1.4. Elastic Treatment Aggregate
The Elastic Treatment Aggregate aggregates all remaining elastic The Elastic Treatment Aggregate aggregates all remaining elastic
traffic. The premise of such a service is that there is no intrinsic 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] SLA differentiation of traffic, but that AQM [9] or ECN flagging [13]
is appropriate for such traffic. is appropriate for such traffic.
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
skipping to change at page 13, line 38 skipping to change at page 14, line 38
applied on the sum of all traffic aggregated into this treatment applied on the sum of all traffic aggregated into this treatment
aggregate. aggregate.
5.3. Assured Elastic Treatment Aggregate with E-LSP 5.3. Assured Elastic Treatment Aggregate with E-LSP
EXP field markings of 010 and 011 are used for the Assured Elastic EXP field markings of 010 and 011 are used for the Assured Elastic
Treatment Aggregate. The two encodings are used to provide two Treatment Aggregate. The two encodings are used to provide two
levels of drop precedence indications, with 010 encoded traffic levels of drop precedence indications, with 010 encoded traffic
having a lower probability of being dropped than 011 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 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. 010; and AF32, AF22, AF12 and AF33, AF23, AF13 into EXP 011. If the
domain chooses to support only one drop precedence for this treatment
aggregate, we recommend the use of 010 for EXP field marking.
5.4. Elastic Treatment Aggregate with E-LSP 5.4. Elastic Treatment Aggregate with E-LSP
EXP field markings of 000 and 001 are used for the Elastic Treatment 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 Aggregate. The two encodings are used to provide two levels of drop
precedence indications, with 000 encoded traffic having a lower precedence indications, with 000 encoded traffic having a lower
probability of being dropped than 001 encoded traffic. This provides probability of being dropped than 001 encoded traffic. This provides
for the mapping of Default/CS0 into 000; and CS1 into 001. Notice for the mapping of Default/CS0 into 000; and CS1 into 001. Notice
that with this mapping, during congestion, CS1 marked traffic may be that with this mapping, during congestion, CS1 marked traffic may be
starved. starved. If the domain chooses to support only one drop precedence
for this treatment aggregate, we recommend the use of 000 for EXP
field marking.
5.5. Treatment Aggregates and L-LSP 5.5. Treatment Aggregates and L-LSP
Because L-LSP (Label Only Inferred PSC LSP) supports a single PSC per 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. LSP, the support of each Treatment Aggregate is on a per LSP basis.
This document does not further specify any additional recommendation This document does not further specify any additional recommendation
(beyond what has been indicated in section 4 of this document) for (beyond what has been indicated in section 4 of this document) for
Treatment Aggregate to L-LSP mapping, leaving this to each individual Treatment Aggregate to L-LSP mapping, leaving this to each individual
MPLS domain administrations. MPLS domain administrations.
skipping to change at page 14, line 28 skipping to change at page 15, line 29
Service Classes [5]. This allows the admission control into each Service Classes [5]. This allows the admission control into each
Treatment Aggregate of a provider domain to be based on the admission Treatment Aggregate of a provider domain to be based on the admission
control of traffic into the supported Service Classes, as indicated control of traffic into the supported Service Classes, as indicated
by the discussion in section 4 of this document. by the discussion in section 4 of this document.
If the Inter-Provider Relationship needs to be based on Treatment If the Inter-Provider Relationship needs to be based on Treatment
Aggregates specified by this document, then the exact Treatment Aggregates specified by this document, then the exact Treatment
Aggregate content and representation must be agreed to by the peering Aggregate content and representation must be agreed to by the peering
providers. providers.
Some additional work on Inter-Provider Relationships is provided by
Inter-provider QoS [16], where details on supporting realtime
services between service providers are discussed. Some related work
in ITU-T provided by Appendix VI of Y.1541 [17] may also help with
inter-provider relationships, especially with international
providers.
7. Security Considerations 7. Security Considerations
This document discusses the policy of using Differentiated Services This document discusses the policy of using Differentiated Services
and its service classes. If implemented as described, it should and its service classes. If implemented as described, it should
require that the network do nothing that the network has not already require that the network do nothing that the network has not already
allowed. If that is the case, no new security issues should arise allowed. If that is the case, no new security issues should arise
from the use of such a policy. from the use of such a policy.
It is possible for the policy to be applied incorrectly, or for a It is possible for the policy to be applied incorrectly, or for a
wrong policy to be applied in the network for the defined wrong policy to be applied in the network for the defined
skipping to change at page 16, line 37 skipping to change at page 17, line 46
[14] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot, [14] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot,
"Analysis of Point-To-Point Packet Delay in an Operational "Analysis of Point-To-Point Packet Delay in an Operational
Network", INFOCOMM 2004, March 2004, Network", INFOCOMM 2004, March 2004,
<http://www.ieee-infocom.org/2004/Papers/37_4.PDF>. <http://www.ieee-infocom.org/2004/Papers/37_4.PDF>.
[15] Ogielski, A. and J. Cowie, "Internet Routing Behavior on 9/11", [15] Ogielski, A. and J. Cowie, "Internet Routing Behavior on 9/11",
March 2002, <http://www.renesys.com/tech/presentations/pdf/ March 2002, <http://www.renesys.com/tech/presentations/pdf/
renesys-030502-NRC-911.pdf>. renesys-030502-NRC-911.pdf>.
[16] MIT Communications Futures Program, "Inter-provider Quality of
Service", November 2006, <
http://cfp.mit.edu/resources/papers/Interprovider QoS
MIT_CFP_WP_9_14_06.pdf>.
[17] International Telecommunications Union, "Network performance
objectives for IP-based services", February 2006.
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 7 skipping to change at page 19, line 7
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 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
 End of changes. 25 change blocks. 
77 lines changed or deleted 112 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/