One document matched: draft-ietf-tsvwg-diffserv-class-aggr-07.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?Pub Inc?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" ipr="full3978" docName="draft-ietf-tsvwg-diffserv-class-aggr-07">
<front><?Pub Caret?>
<title abbrev="Document">Aggregation of DiffServ Service Classes</title>
<author initials="K.H." surname="Chan" fullname="Kwok Ho Chan">
<organization>Nortel</organization>
<address>
<postal>
<street>600 Technology Park Drive</street>
<city>Billerica</city>
<code>01821</code>
<region>MA</region>
<country>US</country>
</postal>
<phone>+1-978-288-8175</phone>
<facsimile>+1-978-288-8700</facsimile>
<email>khchan@nortel.com</email>
</address>
</author>
<author initials="J.Z." surname="Babiarz" fullname="Jozef Z. Babiarz">
<organization>Nortel</organization>
<address>
<postal>
<street>3500 Carling Avenue</street>
<city>Ottawa</city>
<code>K2H 8E9</code>
<region>Ont.</region>
<country>Canada</country>
</postal>
<phone>+1-613-763-6098</phone>
<facsimile>+1-613-768-2231</facsimile>
<email>babiarz@nortel.com</email>
</address>
</author>
<author initials="F.J." surname="Baker" fullname="Fred Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>1121 Via Del Rey</street>
<city>Santa Barbara</city>
<code>93117</code>
<region>CA</region>
<country>US</country>
</postal>
<phone>+1-408-526-4257</phone>
<facsimile>+1-413-473-2403</facsimile>
<email> fred@cisco.com </email>
</address>
</author>
<date month="November" date="5" year="2007"/>
<area>Transport Area</area>
<workgroup>TSVWG</workgroup>
<abstract>
<t>
In the core of a high capacity network, service differentiation may still be needed to support
applications' utilization of the network.
Applications with similar traffic characteristics and performance requirements are mapped into diffserv service classes based on end-to-end behavior requirements of the applications. However, some network segments may be configured in such a way that a single forwarding treatment may satisfy the traffic characteristics and performance requirements
of two or more service classes. In these cases, it may be desirable to aggregate two or more diffserv service classes into a single forwarding treatment. This document provides guidelines for the aggregation of diffserv service classes into forwarding treatments.
</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>
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 (Service Level Agreements).
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 (Multi Protocol Label Switching) protection-mode switching) has occurred.
</t>
<t>
Over-provisioning is generally considered to meet the requirements of all traffic without further QoS treatment, and in the general case that is true in high capacity backbones. However, as the process of network convergence continues, and with the increasing speed of the access networks, certain services may still have issues. Delay, jitter, and occasional loss are perfectly acceptable for elastic applications. However, sub-second surges that occur in the best-designed of networks <xref target="MOON"></xref> affect real-time applications. Moreover, DOS loads, worms, and network disruptions such as that of 11 September 2001 affect routing <xref target="RENESYS"></xref>. Our objective is to prevent disruption to routing (which in turn affects all services), protect real-time jitter-sensitive services, while minimizing
loss and delay of sensitive elastic traffic.
</t>
<t>
The document <xref target="RFC4594">"Diffserv Service Classes"</xref> defines a set of 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 application payload’s tolerance to packet loss, delay, and delay variation (jitter). Different degrees of these criteria form the foundation for supporting the needs of real-time and elastic traffic. The <xref target="RFC4594">"Diffserv Service Classes"</xref> 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.
Having the IP traffic belonging to service classes, expressed using the DSCP (DiffServ Code
Point), as described by <xref target="RFC4594">"Diffserv Service Classes"</xref>.
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. A domain may 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 or other reasons (e.g. operational considerations).
</t>
<t>
In this document, we've provided:
<list style="symbols">
<t>definitions for terminology we use in this document,</t>
<t>requirements for performing this aggregation,</t>
<t>an example of performing the aggregation when four treatment aggregates are used,</t>
<t>an example (in the appendix) of performing this aggregation over MPLS using E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP).</t>
</list>
</t>
<t>
The treatment aggregate recommendations are designed
to aggregate the <xref target="RFC4594">service classes</xref>
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. The recommendation given is one possible
way of performing the aggregation, there may be other way of aggregation,
for example into fewer treatment aggregates or more treatment aggregates.
</t>
<t>
In the appendix, an example of aggregation over MPLS networks using E-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.
This example only considers aggregation of IP traffic into E-LSP. The use of E-LSP by none-IP traffic is not discussed.
</t>
<section anchor="Notation" title="Requirements Notation">
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section anchor="Terminology" title="Terminology">
<t>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 references information defined in
RFCs for existing terms not commonly used in differentiated services.</t>
<t>For new terms introduced by this document, we provide the definition here:
<list style="symbols">
<t>Treatment Aggregate. This term is defined as the aggregate of <xref target="RFC4594">DiffServ service classes</xref>. A Treatment Aggregate is concerned only with the forwarding treatment of the
aggregated traffic, which may be marked with multiple DSCPs. A Treatment Aggregate differs from
Behavior Aggregate <xref target="RFC2474"></xref> and Traffic Aggregate <xref target="RFC3086"></xref>, each of which indicate the aggregated traffic having a single diffserv codepoint and utilizing a single PHB.</t>
</list>
</t>
<t>For terms from existing RFCs, we provide the reference to the appropriate section of the relevant RFC that contain the definition:
<list style="symbols">
<t>Real-Time and Elastic Applications and their traffic. Section 3.1 of
<xref target="RFC1633">RFC 1633</xref>.</t>
<t>Diffserv Service Class. Section 1.3 of <xref target="RFC4594">RFC 4594</xref>.</t>
<t>MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP). Section 1.2 of <xref target="RFC3270">RFC 3270</xref>.</t>
<t>MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP). Section 1.3 of <xref target="RFC3270">RFC 3270</xref>.</t>
</list>
</t>
</section>
<section anchor="Overview" title="Overview of Service Class Aggregation">
<t>In diffserv domains where less fine-grained traffic treatment differentiation is provided, aggregation of the different
<xref target="RFC4594">service classes</xref>
may be required.</t>
<t>These aggregations have the following requirements:<list style="numbers">
<t>The end-to-end network performance characteristic required by the application MUST be supported.
This performance characteristic is represented by the use of <xref target="RFC4594">Diffserv Service Classes</xref>.</t>
<t>The treatment aggregate MUST meet the strictest requirements of its member service classes.</t>
<t>The treatment aggregate SHOULD only contain member service classes with similar traffic characteristic and performance requirements.</t>
<t>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. One possible way of achieving this is with the use of tunnels to encapsulate the end-to-end traffic.</t>
<t>Each treatment aggregate has limited resources, hence traffic conditioning and/or admission control SHOULD be performed for
each service class aggregated into the treatment aggregate. Additional admission control and policing may be used on the sum of all traffic aggregated into the treatment aggregate.</t>
</list> </t>
<t>In addition to the above requirements, we have the following suggestions:<list style="numbers">
<t>The treatment aggregate and assigned resources may consider historical traffic patterns and the variability of these patterns. For example, a point-point service (e.g., pseudowire) may have a very predictable pattern, while a multipoint service (e.g., VPLS, Virtual Private LAN Service) may have a much less predictable pattern.</t>
<t>In addition to Diffserv, other controls are available to influence the traffic level offered to a particular traffic aggregate. These include adjustment of routing metrics, usage of MPLS-based traffic engineering techniques.</t>
</list></t>
<t>This document only describes the aggregation of IP traffic based on the use of
<xref target="RFC4594">Diffserv Service Classes</xref>.</t>
</section>
<section anchor="classtoTAmap" title="Service Classes to Treatment Aggregate Mapping">
<t>
The service class and DSCP selection in <xref target="RFC4594">"Diffserv Service Classes"</xref>
has been defined to allow, in many instances, mapping of two or
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 effects 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, assuming link utilization is within the engineered level.
</t>
<section anchor="classto4TAmap" title="Mapping Service Classes into Four Treatment Aggregates">
<t>
This section
provides an example of mapping all the service classes defined in <xref target="RFC4594">RFC 4594</xref> into four treatment aggregates. The use of four treatment
aggregates assumes that the resources allocated to each treatment aggregate
are sufficient to honor the required behavior of each <xref target="RFC4594">service class</xref>
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
<xref target="RFC1633">RFC 1633</xref>
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 <xref target="RFC4594">Diffserv Service Classes</xref>.
</t>
<t>
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.
</t>
<t>
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 fewer 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.
Hence this example of four treatment aggregates does not represent a minimum required set of treatment
aggregates one must implement; nor does it represent the maximum set of treatment aggregates one
can implement.
</t>
<figure anchor="TASCPerf" title="Treatment Aggregate and Service Class Performance Requirements">
<artwork name="TASCPerf">
---------------------------------------------------------------------
|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 | | | |
---------------------------------------------------------------------
</artwork>
</figure>
<t>
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 Aggregate should have, and the DSCP field marking
of the packets that should be classified into each of the treatment
aggregates.
</t>
<figure anchor="TABehavior" title="Treatment Aggregate Behavior">
<artwork name="TABehavior">
------------------------------------------------------------
|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 |
------------------------------------------------------------
</artwork>
</figure>
<t>
Notes for Figure 2: For Assured Elastic and Elastic Treatment Aggregates, please see
sections 4.1.3 and 4.1.4, respectively, for details on additional priority within the Treatment
Aggregate.
</t>
<section anchor="NetworkControlTA" title="Network Control Treatment Aggregate">
<t>
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 <xref target="RFC4594">"Diffserv Service Classes"</xref> characterizes as being included in the Network Control Service Class.
</t>
<t>
Traffic
in the Network Control treatment aggregate should be carried in
a common queue or class with a PHB as described in
<xref target="RFC2474">RFC 2474</xref> section 4.2.2.2 for Class Selector (CS).
This treatment aggregate should have a lower probability of packet loss, bearing a relatively deep
target mean queue depth (min-threshold if RED (Random Early Detection) is being used).
</t>
<t>
Please notice this Network Control Treatment Aggregate is meant to be used for the
customer's network control traffic. The provider may choose to treat its own network
control traffic differently, perhaps in its own service class that is not aggregated with
the customer's network control traffic.
</t>
</section>
<section anchor="RealTimeTA" title="Real Time Treatment Aggregate">
<t>
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 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.
The predictability of traffic level may be based upon admission control for a well known community of interest (e.g., a point-point service) and/or based upon historical measurements.
</t>
<t>
This treatment aggregate may include the following service classes from the <xref target="RFC4594">Diffserv Service Classes</xref>, in addition to other locally defined classes: Telephony, Signaling, Multimedia Conferencing, Real-time Interactive, Broadcast Video.
</t>
<t>
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 traffic aggregated into this treatment aggregate.
</t>
<t>
Traffic in the Real Time treatment aggregate should be carried in a common queue or class with a PHB (Per Hop Behavior) as described in
<xref target="RFC3246">RFC 3246</xref> and <xref target="RFC3247">RFC 3247</xref>.
</t>
</section>
<section anchor="AssuredElasticTA" title="Assured Elastic Treatment Aggregate">
<t>
The Assured Elastic Treatment Aggregate aggregates all elastic traffic that
uses the Assured Forwarding model as described in <xref target="RFC2597">RFC 2597</xref>. 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 <xref target="RFC2309">Active Queue Management (AQM)</xref> or Explicit Congestion Notification (ECN) marking <xref target="RFC3168"></xref> for the portion of traffic deemed to be in excess.
</t>
<t>
This treatment aggregate may include the following service classes from the <xref target="RFC4594">Diffserv Service Classes</xref>, in addition to other locally defined classes: Multimedia Streaming, Low Latency Data, OAM, High Throughput Data.
</t>
<t>
The DSCP values belonging to the AF PHB group and class selector 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.
In addition, the class selector DSCP value should not be changed.
Traffic bearing these DSCPs is carried in a common queue or class with a PHB as described in
<xref target="RFC2597">RFC 2597</xref>.
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 and CS2 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, <xref target="RFC2309">Active Queue
Management</xref> should be used primarily to reduce the forwarding rate to the
minimum assured rate at congestion points. The probability of 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.
</t>
<t>
If RED <xref target="RFC2309"></xref> is used as an AQM algorithm, the
min-threshold specifies a target queue depth for each of AFn1+CS2, 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:<list style="symbols">
<t>min-threshold AFn3 < max-threshold AFn3</t>
<t>max-threshold AFn3 <= min-threshold AFn2</t>
<t>min-threshold AFn2 < max-threshold AFn2</t>
<t>max-threshold AFn2 <= min-threshold AFn1+CS2</t>
<t>min-threshold AFn1+CS2 < max-threshold AFn1+CS2</t>
<t>max-threshold AFn1+CS2 <= memory assigned to the queue</t>
</list>Note: This configuration tends to drop AFn3 traffic before AFn2 and
AFn2 before AFn1 and CS2. Many other AQM algorithms exist and are used; they should
be configured to achieve a similar result.
</t>
</section>
<section anchor="ElasticTA" title="Elastic Treatment Aggregate">
<t>
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 <xref target="RFC2309">AQM</xref> or <xref target="RFC3168">ECN flagging</xref> is appropriate for such traffic.</t>
<t>
This treatment aggregate may include the following service classes from the <xref target="RFC4594">Diffserv Service Classes</xref>, in addition to other locally defined classes: Standard, Low Priority Data.
</t>
<t>
Treatment aggregates should be well specified, each indicating the service classes it will handle. But in cases where
unspecified or unknown service classes are encountered, they may be dropped or be treated using
the Elastic Treatment Aggregate. The choice of how to treat unspecified service classes should be
well defined, based on some agreements.
</t>
<t>
Traffic in the Elastic treatment aggregate should be carried in a common queue or class with a PHB as described in
<xref target="RFC2474">RFC 2474</xref> 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 not a
requirement.
</t>
</section>
</section>
</section>
<section anchor="TAInterProvider" title="Treatment Aggregates and Inter-Provider Relationships">
<t>
When Treatment Aggregates are used at provider boundaries, we recommend that the Inter-Provider Relationship be based on <xref target="RFC4594">Diffserv Service Classes</xref>. 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.
</t>
<t>
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.
</t>
<t>
Some additional work on Inter-Provider Relationships is provided by
<xref target="MITCFPInterProviderQoS">Inter-provider QoS</xref>, where details on supporting realtime services between service providers are discussed. Some related work in ITU-T provided by Appendix VI of Y.1541 <xref target="ITU.Y1541.Feb2006"></xref> may also help with inter-provider relationships, especially with international providers.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
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.
</t>
<t>
As this document is based on <xref target="RFC4594">Diffserv Service Classes</xref>,
the Security Consideration discussion of no new security issues indicated by
<xref target="RFC4594">Diffserv Service Classes</xref> also applies to treatment aggregates of this document.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document does not request any IANA considerations.</t>
</section>
<section anchor="Acknowledge" title="Acknowledgements">
<t>
This document has benefited from discussions with numerous people, especially Shane Amante, Brian Carpenter, and Dave McDysan. It has also benefited from detailed reviews by David Black, Marvin Krym, Bruce Davie, Fil Dickinson, and Julie Ann Connary.
</t>
</section>
<appendix anchor="TAMPLS" title="Using MPLS for Treatment Aggregates">
<t>
RFC 2983 on <xref target="RFC2983">DiffServ and Tunnels</xref> and
RFC 3270 on <xref target="RFC3270">MPLS Support of DiffServ</xref>
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
<xref target="RFC3270">MPLS Support of DiffServ</xref> for realizing the
Treatment Aggregates.
</t>
<t>
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.
</t>
<figure anchor="TAEXP" title="Treatment Aggregate and MPLS EXP Field Usage">
<artwork name="TAEXP">
-------------------------------------------
|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 |
-------------------------------------------
</artwork>
</figure>
<t>
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).
</t>
<t>
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 supported Treatment Aggregates.
</t>
<appendix anchor="NetworkControlELSP" title="Network Control Treatment Aggregate with E-LSP">
<t>
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 <xref target="RFC4594">"Diffserv Service Classes"</xref>. 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.
</t>
</appendix>
<appendix anchor="RealTimeELSP" title="Real Time Treatment Aggregate with E-LSP">
<t>
In addition to the recommendations provided in section 4.1.2 of this document and in member service classes' sections of <xref target="RFC4594">"Diffserv Service Classes"</xref>, 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.
</t>
</appendix>
<appendix anchor="AssuredElasticELSP" title="Assured Elastic Treatment Aggregate with E-LSP">
<t>
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.
If the domain chooses to support only one drop precedence for this treatment aggregate, we recommend the use of 010 for EXP field marking.
</t>
</appendix>
<appendix anchor="ElasticELSP" title="Elastic Treatment Aggregate with E-LSP">
<t>
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.
If the domain chooses to support only one drop precedence for this treatment aggregate, we recommend the use of 000 for EXP field marking.
</t>
</appendix>
<appendix anchor="TALLSP" title="Treatment Aggregates and L-LSP">
<t>
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.
</t>
</appendix>
</appendix>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2474" ?>
<?rfc include="reference.RFC.4594" ?>
<?rfc include="reference.RFC.1633" ?>
<?rfc include="reference.RFC.2983" ?>
<?rfc include="reference.RFC.3270" ?>
<?rfc include="reference.RFC.2309" ?>
<?rfc include="reference.RFC.2597" ?>
<?rfc include="reference.RFC.3246" ?>
<?rfc include="reference.RFC.3247" ?>
<?rfc include="reference.RFC.3168" ?>
</references>
<references title="Informative References">
<reference anchor="MOON"
target="http://www.ieee-infocom.org/2004/Papers/37_4.PDF">
<front>
<title>Analysis of Point-To-Point Packet Delay in an Operational Network </title>
<author fullname="Baek-Young Choi" initials="B.Y." surname="Choi">
<organization></organization>
</author>
<author fullname="Sue Moon" initials="S." surname="Moon">
<organization></organization>
</author>
<author fullname="Zhi-Li Zhang" initials="Z.L." surname="Zhang">
<organization></organization>
</author>
<author fullname="Konstantina Papagiannaki" initials="K." surname="Papagiannaki">
<organization></organization>
</author>
<author fullname="Christophe Diot" initials="C." surname="Diot">
<organization></organization>
</author>
<date month="March" year="2004" />
</front>
<seriesInfo name='INFOCOMM' value='2004' />
</reference>
<reference anchor="RENESYS"
target="http://www.renesys.com/tech/presentations/pdf/renesys-030502-NRC-911.pdf">
<front>
<title>Internet Routing Behavior on 9/11</title>
<author fullname="Andy Ogielski" initials="A." surname="Ogielski">
<organization></organization>
</author>
<author fullname="Jim Cowie" initials="J." surname="Cowie">
<organization></organization>
</author>
<date day="5" month="March" year="2002" />
</front>
</reference>
<?rfc include="reference.RFC.3086" ?>
<reference anchor="MITCFPInterProviderQoS"
target="
http://cfp.mit.edu/resources/papers/Interprovider QoS MIT_CFP_WP_9_14_06.pdf">
<front>
<title>Inter-provider Quality of Service</title>
<author>
<organization>MIT Communications Futures Program</organization>
</author>
<date day="17" month="November" year="2006" />
</front>
</reference>
<reference anchor="ITU.Y1541.Feb2006">
<front>
<title>Network performance objectives for IP-based services</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="February" year="2006"></date>
</front>
</reference>
</references>
</back>
</rfc>
<?Pub *0000024293?>
| PAFTECH AB 2003-2026 | 2026-04-23 22:53:48 |