Network Working Group K. Chan
Request for Comments: 5127 J. Babiarz
Category: Informational Nortel
F. Baker
Cisco Systems
February 2008
Network Working Group K. Chan
Request for Comments: 5127 J. Babiarz
Category: Informational Nortel
F. Baker
Cisco Systems
February 2008
Aggregation of Diffserv Service Classes
区分服务类的聚合
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
In the core of a high-capacity network, service differentiation may still be needed to support applications' utilization of the network. Applications with similar traffic characteristics and performance requirements are mapped into Diffserv service classes based on end-to-end behavior requirements of the applications. However, some network segments may be configured in such a way that a single forwarding treatment may satisfy the traffic characteristics and performance requirements of two or more service classes. In these cases, it may be desirable to aggregate two or more Diffserv service classes into a single forwarding treatment. This document provides guidelines for the aggregation of Diffserv service classes into forwarding treatments.
在高容量网络的核心，可能仍然需要服务差异化来支持应用程序对网络的利用。基于应用程序的端到端行为需求，将具有相似流量特征和性能需求的应用程序映射到Diffserv服务类中。然而，一些网段可以这样配置，使得单个转发处理可以满足两个或更多服务类别的业务特性和性能要求。在这些情况下，可能需要将两个或多个Diffserv服务类聚合到单个转发处理中。本文档提供了将Diffserv服务类聚合为转发处理的指南。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Service Class Aggregation . . . . . . . . . . . . 5
4. Service Classes to Treatment Aggregate Mapping . . . . . . . . 6
4.1. Mapping Service Classes into Four Treatment Aggregates . . 7
4.1.1. Network Control Treatment Aggregate . . . . . . . . . 9
4.1.2. Real-Time Treatment Aggregate . . . . . . . . . . . . 10
4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . 10
4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 12
5. Treatment Aggregates and Inter-Provider Relationships . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Using MPLS for Treatment Aggregates . . . . . . . . 15
A.1. Network Control Treatment Aggregate with E-LSP . . . . . . 17
A.2. Real-Time Treatment Aggregate with E-LSP . . . . . . . . . 17
A.3. Assured Elastic Treatment Aggregate with E-LSP . . . . . . 17
A.4. Elastic Treatment Aggregate with E-LSP . . . . . . . . . . 17
A.5. Treatment Aggregates and L-LSP . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Service Class Aggregation . . . . . . . . . . . . 5
4. Service Classes to Treatment Aggregate Mapping . . . . . . . . 6
4.1. Mapping Service Classes into Four Treatment Aggregates . . 7
4.1.1. Network Control Treatment Aggregate . . . . . . . . . 9
4.1.2. Real-Time Treatment Aggregate . . . . . . . . . . . . 10
4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . 10
4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 12
5. Treatment Aggregates and Inter-Provider Relationships . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Using MPLS for Treatment Aggregates . . . . . . . . 15
A.1. Network Control Treatment Aggregate with E-LSP . . . . . . 17
A.2. Real-Time Treatment Aggregate with E-LSP . . . . . . . . . 17
A.3. Assured Elastic Treatment Aggregate with E-LSP . . . . . . 17
A.4. Elastic Treatment Aggregate with E-LSP . . . . . . . . . . 17
A.5. Treatment Aggregates and L-LSP . . . . . . . . . . . . . . 18
In the core of a high capacity network, it is common for the network to be engineered in such a way that a major link, switch, or router can fail, and the result will be a routed network that still meets ambient Service Level Agreements (SLAs). The implications are that there is sufficient capacity on any given link such that all SLAs sold can be simultaneously supported at their respective maximum rates, and that this remains true after re-routing (either IP re-routing or Multiprotocol Label Switching (MPLS) protection-mode switching) has occurred.
在高容量网络的核心中，网络的设计通常会导致主链路、交换机或路由器出现故障，其结果将是一个仍符合环境服务水平协议（SLA）的路由网络。这意味着在任何给定链路上都有足够的容量，以便可以以各自的最大速率同时支持所有销售的SLA，并且在发生重新路由（IP重新路由或多协议标签交换（MPLS）保护模式切换）后仍然如此。
Over-provisioning is generally considered to meet the requirements of all traffic without further quality of service (QoS) treatment, and in the general case, that is true in high-capacity backbones. However, as the process of network convergence continues, and with the increasing speed of the access networks, certain services may still have issues. Delay, jitter, and occasional loss are perfectly acceptable for elastic applications. However, sub-second surges that occur in the best-designed of networks [12] affect real-time applications. Moreover, denial of service (DoS) loads, worms, and network disruptions such as that of 11 September 2001 affect routing [13]. Our objective is to prevent disruption to routing (which in turn affects all services) and to protect real-time jitter-sensitive services, while minimizing loss and delay of sensitive elastic traffic.
过度资源调配通常被认为可以满足所有流量的要求，而无需进一步的服务质量（QoS）处理，在一般情况下，在高容量主干网中也是如此。然而，随着网络融合进程的继续，以及接入网络速度的提高，某些服务可能仍然存在问题。延迟、抖动和偶尔的损耗对于弹性应用是完全可以接受的。然而，在设计最佳的网络[12]中出现的亚秒级浪涌会影响实时应用。此外，拒绝服务（DoS）负载、蠕虫和网络中断（如2001年9月11日）会影响路由[13]。我们的目标是防止路由中断（这反过来会影响所有服务），并保护实时抖动敏感服务，同时最小化敏感弹性流量的损失和延迟。
RFC 4594 [3] 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. RFC 4594 [3] 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. This entails having the IP traffic belonging to service classes, expressed using the DSCP (Differentiated Services Code Point), as described by RFC 4594 [3]. 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
RFC 4594[3]从需要网络特定端到端行为的应用程序的角度定义了一组基本的区分服务类。根据应用程序有效负载对数据包丢失、延迟和延迟变化（抖动）的容忍度来区分服务类别。这些标准的不同程度为支持实时和弹性交通的需求奠定了基础。RFC 4594[3]还提供了这些服务类别的处理方法建议。但是，在端到端路径的某些网段上，网络处理差异的级别数可能小于网段需要支持的服务类别数。在这种情况下，该网段可以使用相同的处理来支持多个服务类别。在本文档中，我们提供了关于如何将多个服务类聚合为转发处理聚合的指南。这要求IP流量属于服务类，使用DSCP（区分服务代码点）表示，如RFC 4594[3]所述。注意，在给定域中，我们可能建议将支持的服务类聚合为转发处理聚合；但是，这并不意味着需要支持所有服务类，因此也不需要支持所有转发处理聚合。域名可以
support a fewer or greater number of forwarding treatment aggregates than recommended by this document. 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).
支持数量少于或多于本文件建议数量的转发处理聚合。域支持哪些服务类别和哪些转发处理聚合取决于域管理，并且可能受业务原因或其他原因（例如，运营考虑）的影响。
In this document, we've provided:
在本文件中，我们提供了：
o definitions for terminology we use in this document,
o 我们在本文件中使用的术语定义，
o requirements for performing this aggregation,
o 执行此聚合的要求，
o an example of performing the aggregation when four treatment aggregates are used, and
o 使用四种处理骨料时执行聚合的示例，以及
o an example (in the appendix) of performing this aggregation over MPLS using E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP).
o 使用E-LSP在MPLS上执行此聚合的示例（见附录），EXP推断PHB调度类（PSC）标签交换路径（LSP）。
The treatment aggregate recommendations are designed to aggregate the service classes [3] 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 ways of aggregation, for example, into fewer treatment aggregates or more treatment aggregates.
处理聚合建议旨在以保护实时通信量和路由的方式聚合服务类[3]，前提是实时会话通过在边缘的接纳而相互保护。给出的建议是执行聚合的一种可能方式；可能存在其他聚合方式，例如，聚合为更少的处理聚合或更多的处理聚合。
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 non-IP traffic is not discussed.
在附录中，提供了使用E-LSP在MPLS网络上进行聚合以实现治疗聚合的示例。注意，MPLS E-LSP只是一个示例；本文件不排除使用其他方法。此示例仅考虑将IP流量聚合到E-LSP中。未讨论非IP通信使用E-LSP的问题。
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 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
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.
本文档假设读者熟悉差异化服务中使用的术语。本文档提供了本文档引入的新术语的定义，并参考了RFCs中定义的现有术语信息，这些术语在差异化服务中不常用。
For new terms introduced by this document, we provide the definition here:
对于本文件引入的新术语，我们在此处提供定义：
o Treatment Aggregate. This term is defined as the aggregate of Diffserv service classes [3]. 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 [2] and Traffic Aggregate [14], each of which indicate the aggregated traffic having a single Diffserv codepoint and utilizing a single Per Hop Behavior (PHB).
o 处理骨料。该术语定义为Diffserv服务类的集合[3]。处理聚合只涉及聚合流量的转发处理，聚合流量可以用多个DSCP标记。处理聚合不同于行为聚合[2]和流量聚合[14]，其中每个聚合表示具有单个区分服务码点并利用单个每跳行为（PHB）的聚合流量。
For terms from existing RFCs, we provide the reference to the appropriate section of the relevant RFC that contain the definition:
对于现有RFC中的术语，我们提供了相关RFC中包含以下定义的适当部分的参考：
o Real-Time and Elastic Applications and their traffic. Section 3.1 of RFC 1633 [4].
o 实时和弹性应用程序及其流量。RFC 1633[4]第3.1节。
o Diffserv Service Class. Section 1.3 of RFC 4594 [3].
o 区分服务类。RFC 4594[3]第1.3节。
o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP). Section 1.2 of RFC 3270 [6].
o MPLS E-LSP，EXP推断PHB调度类（PSC）标签交换路径（LSP）。RFC 3270[6]第1.2节。
o MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP). Section 1.3 of RFC 3270 [6].
o MPLS L-LSP，仅标签推断PHB调度类（PSC）标签交换路径（LSP）。RFC 3270[6]第1.3节。
In Diffserv domains where less fine-grained traffic treatment differentiation is provided, aggregation of the different service classes [3] may be required.
在提供较少细粒度流量处理差异的Diffserv域中，可能需要聚合不同的服务类[3]。
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 [3].
1. 必须支持应用程序所需的端到端网络性能特征。此性能特征通过使用Diffserv服务类来表示[3]。
2. The treatment aggregate MUST meet the strictest requirements of its member service classes.
2. 处理骨料必须满足其成员服务等级的最严格要求。
3. The treatment aggregate SHOULD only contain member service classes with similar traffic characteristic and performance requirements.
3. 处理骨料应仅包含具有类似交通特征和性能要求的成员服务类别。
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
4. 在执行聚合时，不能破坏单个端到端服务类的概念。基于原始端到端服务类，端到端路径上的每个域可以不同地执行聚合。我们推荐一种简单的方法
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.
通过不改变用于指示端到端服务类的DSCP来实现这一点的方法。但一些行政领域可能需要使用自己的标记；需要时，必须在退出此类管理域时恢复原始的端到端服务类指示。实现这一点的一种可能方法是使用隧道来封装端到端的流量。
5. 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.
5. 每个处理骨料的资源有限；因此，应对聚合到处理聚合中的每个服务类别执行交通调节和/或准入控制。可对聚合到治疗总量中的所有流量总和使用额外的准入控制和监管。
In addition to the above requirements, we have the following suggestions:
除上述要求外，我们还有以下建议：
1. 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.
1. 处理总量和分配资源可以考虑历史交通模式和这些模式的可变性。例如，点服务（例如，伪线）可能具有非常可预测的模式，而多点服务（例如，VPLS，虚拟专用LAN服务）可能具有非常不可预测的模式。
2. 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, and usage of MPLS-based traffic engineering techniques.
2. 除了Diffserv之外，还可以使用其他控件来影响提供给特定流量聚合的流量级别。这些包括路由度量的调整，以及基于MPLS的流量工程技术的使用。
This document only describes the aggregation of IP traffic based on the use of Diffserv service classes [3].
本文档仅描述基于Diffserv服务类的IP流量聚合[3]。
The service class and DSCP selection in RFC 4594 [3] 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 the aggregation's impacts on loss, delay, and jitter. This depends 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. 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.
RFC 4594[3]中的服务类和DSCP选择已定义为在许多情况下允许将两个或可能更多的服务类映射到单个转发处理聚合中。请注意，链路速度、队列深度、延迟和抖动之间存在关系/权衡。聚集程度以及治疗聚集的数量将取决于聚集对损失、延迟和抖动的影响。这取决于用于实现聚合的链路速度和调度器行为是否能够将不同数据包大小和传输速率的混合流量对队列深度的影响降至最低。一般的经验法则是，假设链路利用率在工程水平内，较高的链路速度允许更多的聚合/更少的处理聚合。
This section provides an example of mapping all the service classes defined in RFC 4594 [3] 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 service class [3]. We use the performance requirement (tolerance to loss, delay, and jitter) from the application/end-user as a guide on how to map the service classes into treatment aggregates. We have also used section 3.1 of RFC 1633 [4] 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" and "Tolerance to Loss/ Delay/Jitter" are from Figure 2 of RFC 4594 [3].
本节提供了将RFC 4594[3]中定义的所有服务类映射为四个处理聚合的示例。使用四个处理聚合假设分配给每个处理聚合的资源足以满足每个服务类别的所需行为[3]。我们使用应用程序/最终用户的性能要求（对丢失、延迟和抖动的容忍度）作为如何将服务类映射到处理聚合的指南。我们还使用了RFC 1633[4]的第3.1节，为我们提供了实时和弹性应用程序定义的指导。图1概述了服务类和四个处理聚合之间的映射，映射基于性能需求。在图1中，“服务等级”和“损耗/延迟/抖动容忍度”的右侧列来自RFC 4594[3]的图2。
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, i.e., 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.
建议将某些服务类别映射到特定的处理集合中。但这并不意味着需要支持为该处理聚合推荐的所有服务类。因此，对于给定域，处理聚合可能仅包含本文档中推荐的服务类的子集，即该域支持的服务类。域对不受支持的服务类的处理应基于域的本地策略。本本地政策可能受其与客户的协议的影响。这种处理可以使用弹性处理集料、丢弃分组或一些其他布置。
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 than the four recommended. For example, a domain may support only three treatment aggregates and map 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.
我们的四个处理聚合示例基于应用程序/最终用户角度的性能需求的基本差异。一个域可以选择支持多于或少于四个推荐的处理聚合。例如，一个域可能只支持三个处理聚合，并将任何网络控制流量映射到保证的弹性处理聚合中。这是管理域的一个选择。因此，四种处理集料的示例并不代表必须实施的最低要求处理集料；它也不代表一个人可以实施的最大处理总量。
---------------------------------------------------------------------
|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 | | | |
---------------------------------------------------------------------
---------------------------------------------------------------------
|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
图1：处理骨料和服务类性能要求
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
由于我们建议保留单个端到端服务类别的概念，我们还建议在使用处理集料时不要更改原始DSCP字段标记。相反，应使用基于DSCP字段内容选择数据包的分类器将数据包从成员Diffserv服务类定向到处理每个处理聚合的队列中，而无需标记数据包的DSCP字段。这是
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.
如图2所示，其中显示了每个处理聚合应具有的行为，以及应分类到每个处理聚合中的数据包的DSCP字段标记。
------------------------------------------------------------
|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 |
------------------------------------------------------------
------------------------------------------------------------
|Treatment |Treatment || DSCP |
|Aggregate |Aggregate || |
| |Behavior || |
|==========+==========++=====================================|
| Network | CS || CS6 |
| Control |(RFC 2474)|| |
|==========+==========++=====================================|
| Real- | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 |
| Time |(RFC 3246)|| |
|==========+==========++=====================================|
| Assured | AF || CS2, AF31, AF21, AF11 |
| Elastic |(RFC 2597)||-------------------------------------|
| | || AF32, AF22, AF12 |
| | ||-------------------------------------|
| | || AF33, AF23, AF13 |
|==========+==========++=====================================|
| Elastic | Default || Default, (CS0) |
| |(RFC 2474)||-------------------------------------|
| | || CS1 |
------------------------------------------------------------
Figure 2: Treatment Aggregate Behavior
图2：处理骨料行为
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.
图2注释：对于保证弹性和弹性处理骨料，请分别参见第4.1.3节和第4.1.4节，以了解处理骨料中额外优先级的详细信息。
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 RFC 4594 [3] characterizes as being included in the Network Control service class.
网络控制处理聚合了在DoS攻击或其他高流量负载间隔期间网络生存所必需的所有服务类别。该理论认为，无论其他情况如何，网络都必须保护自己。这包括RFC 4594[3]描述为包含在网络控制服务类中的流量。
Traffic in the Network Control Treatment Aggregate should be carried in a common queue or class with a PHB as described in RFC 2474 [2], section 4.2.2.2 for Class Selector (CS). This treatment aggregate should have a lower probability of packet loss and bear a relatively deep target mean queue depth (min-threshold if RED (Random Early Detection) is being used).
网络控制处理聚合中的流量应按照RFC 2474[2]第4.2.2.2节“类别选择器（CS）”中所述的PHB在公共队列或类别中传输。该处理聚合应具有较低的数据包丢失概率，并具有相对较深的目标平均队列深度（如果使用RED（随机早期检测），则最小阈值）。
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.
请注意，此网络控制处理聚合旨在用于客户的网络控制流量。提供商可以选择不同地对待其自己的网络控制流量，可能在其自己的服务类别中，该服务类别不与客户的网络控制流量聚合。
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. 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.
实时处理聚合聚合所有实时（非弹性）服务类。其理论是，在某种模型下，实时流量被接纳，并在聚合之前由网络边缘管理的SLA控制。因此，可以进入这样一个队列的流量有一个可预测且可执行的上限，为了提供可预测的延迟变化，必须保护它不受突发弹性流量的影响。流量水平的可预测性可基于对著名的感兴趣社区（例如，点-点服务）的接纳控制和/或基于历史测量。
This treatment aggregate may include the following service classes from the Diffserv service classes [3], in addition to other locally defined classes: Telephony, Signaling, Multimedia Conferencing, Real-time Interactive, and Broadcast Video.
除了其他本地定义的类别外，该处理集合还可以包括来自Diffserv服务类别[3]的以下服务类别：电话、信令、多媒体会议、实时交互和广播视频。
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.
将要聚合到处理聚合中的每个服务类别中的流量应在聚合之前进行调节。建议使用每个服务类别的准入控制程序，然后进行每个服务类别的监管，以便任何单个服务类别不会产生超过其允许的数量。此外，可以对聚合到该处理聚合中的所有流量总和使用额外的准入控制和监管。
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 RFC 3246 [9] and RFC 3247 [10].
实时处理聚合中的流量应按照RFC 3246[9]和RFC 3247[10]中所述，在具有PHB（每跳行为）的公共队列或类中进行。
The Assured Elastic Treatment Aggregate aggregates all elastic traffic that uses the Assured Forwarding model as described in RFC 2597 [8]. The premise of such a service is that an SLA that is negotiated 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 Active Queue Management (AQM) [7] or Explicit Congestion Notification (ECN) marking [11] for the portion of traffic deemed to be in excess.
Assured Elastic Treatment聚合使用RFC 2597[8]中所述的Assured转发模型的所有弹性流量。此类服务的前提是，协商的SLA包括“承诺速率”和超过该速率（可能还有第二个“超额速率”）的能力，以换取使用主动队列管理（AQM）[7]或显式拥塞通知（ECN）标记的更高丢失概率[11]对于被视为超额的交通量部分。
This treatment aggregate may include the following service classes from the Diffserv service classes [3], in addition to other locally defined classes: Multimedia Streaming, Low Latency Data, OAM, and High-Throughput Data.
除了其他本地定义的类之外，该处理聚合还可以包括来自Diffserv服务类[3]的以下服务类：多媒体流、低延迟数据、OAM和高吞吐量数据。
The DSCP values belonging to the Assured Forwarding (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 RFC 2597 [8]. 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, Active Queue Management [7] 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.
属于保证转发（AF）PHB组和原始服务类的类选择器的DSCP值仍然是一个重要的考虑因素，应该在聚合期间保留。该处理集料应保持原始数据包的AF PHB组标记。例如，AF3x标记的数据包应在该处理聚合中保持AF3x标记。此外，不应更改类选择器DSCP值。承载这些DSCP的流量在公共队列或类中承载，带有RFC 2597[8]中所述的PHB。实际上，在边缘应用了适当的目标速率阈值，将流量划分为AFn1（已提交，对于任意值n）、AFn2和AFn3（超额）。服务的设计应确保AFn1和CS2标记的数据包流在网络中具有足够的带宽，以提供高的传输保证。由于流量是弹性的，并对数据包丢失作出动态响应，因此主动队列管理[7]应主要用于在拥塞点将转发速率降低到最小保证速率。AFn1和CS2流量的丢失概率不得超过AFn2流量的丢失概率，而AFn2流量的丢失概率又不得超过AFn3流量的丢失概率。
If RED [7] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each of AFn1+CS2, AFn2, and 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:
如果红色[7]用作AQM算法，则最小阈值为AFn1+CS2、AFn2和AFn3中的每一个指定目标队列深度，最大阈值指定队列深度，在该深度以上，具有此类DSCP的所有流量都将被丢弃或标记为ECN。因此，在此处理聚合中，队列配置中应存在以下不等式：
o min-threshold AFn3 < max-threshold AFn3
o 最小阈值AFn3<最大阈值AFn3
o max-threshold AFn3 <= min-threshold AFn2
o 最大阈值AFn3<=最小阈值AFn2
o min-threshold AFn2 < max-threshold AFn2
o 最小阈值AFn2<最大阈值AFn2
o max-threshold AFn2 <= min-threshold AFn1+CS2
o 最大阈值AFn2<=最小阈值AFn1+CS2
o min-threshold AFn1+CS2 < max-threshold AFn1+CS2
o 最小阈值AFn1+CS2<最大阈值AFn1+CS2
o max-threshold AFn1+CS2 <= memory assigned to the queue
o 最大阈值AFn1+CS2<=分配给队列的内存
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.
注意：此配置倾向于在AFn2之前丢弃AFn3流量，在AFn1和CS2之前丢弃AFn2流量。存在并使用了许多其他AQM算法；应将其配置为实现类似的结果。
The Elastic Treatment Aggregate aggregates all remaining elastic traffic. The premise of such a service is that there is no intrinsic SLA differentiation of traffic, but that AQM [7] or ECN flagging [11] is appropriate for such traffic.
弹性处理骨料将所有剩余的弹性流量聚集在一起。这种服务的前提是，流量没有固有的SLA差异，但AQM[7]或ECN标记[11]适用于这种流量。
This treatment aggregate may include the following service classes from the Diffserv service classes [3], in addition to other locally defined classes: Standard and Low-Priority Data.
除了其他本地定义的类外，此处理聚合还可以包括来自Diffserv服务类[3]的以下服务类：标准和低优先级数据。
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.
应明确规定处理集料，每种集料均应指明其将处理的服务类别。但在遇到未指定或未知的服务类的情况下，可以删除它们或使用弹性处理聚合进行处理。如何处理未指定的服务类的选择应该根据一些协议进行定义。
Traffic in the Elastic Treatment Aggregate should be carried in a common queue or class with a PHB as described in RFC 2474 [2], 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.
弹性处理聚合中的流量应按照RFC 2474[2]第4.1节“默认PHB”中的描述，在具有PHB的公共队列或类别中进行。弹性业务的AQM阈值可以单独设置，以便在标准业务之前丢弃低优先级数据业务，但这不是要求。
When treatment aggregates are used at provider boundaries, we recommend that the inter-provider relationship be based on Diffserv service classes [3]. 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.
当在提供者边界使用处理聚合时，我们建议提供者之间的关系基于Diffserv服务类[3]。这允许进入提供商域的每个处理聚合的准入控制基于进入支持的服务类的流量准入控制，如本文档第4节中的讨论所示。
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.
如果提供商之间的关系需要基于本文件规定的处理聚合，则对等提供商必须同意确切的处理聚合内容和表示。
Some additional work on inter-provider relationships is provided by inter-provider QoS [15], where details on supporting real-time services between service providers are discussed. Some related work in ITU-T provided by Appendix VI of Y.1541 [16] may also help with inter-provider relationships, especially with international providers.
提供商间QoS[15]提供了一些关于提供商间关系的额外工作，其中讨论了支持服务提供商之间实时服务的细节。Y.1541[16]附录六提供的ITU-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.
本文档讨论使用区分服务及其服务类的策略。如果按照所述实施，则应要求网络不做任何网络不允许的事情。如果是这样的话，那么使用这样的策略不应该产生新的安全问题。
As this document is based on RFC 4594 [3], the Security Consideration discussion of no new security issues indicated by RFC 4594 [3] also applies to treatment aggregates of this document.
由于本文件以RFC 4594[3]为基础，RFC 4594[3]中关于无新安全问题的安全考虑讨论也适用于本文件的处理集合。
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.
本文件得益于与许多人的讨论，特别是Shane Amante、Brian Carpenter和Dave McDysan。它还得益于大卫·布莱克、马文·克里姆、布鲁斯·戴维斯、菲尔·迪金森和朱莉·安·康纳利的详细评论。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] 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.
[2] Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[3] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
[3] Babiarz，J.，Chan，K.，和F.Baker，“区分服务服务类的配置指南”，RFC 45942006年8月。
[4] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[4] Braden，B.，Clark，D.和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC16331994年6月。
[5] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[5] Black，D.，“差异化服务和隧道”，RFC 2983，2000年10月。
[6] 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.
[6] Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[7] 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.
[7] 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.，和L.Zhang，“关于互联网中队列管理和拥塞避免的建议”，RFC 2309，1998年4月。
[8] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[8] Heinanen，J.，Baker，F.，Weiss，W.，和J.Wroclawski，“保证货运PHB集团”，RFC 25971999年6月。
[9] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[9] Davie，B.，Charny，A.，Bennet，J.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[10] 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.
[10] Charny，A.，Bennet，J.，Benson，K.，Boudec，J.，Chiu，A.，Courtney，W.，Davari，S.，Firoiu，V.，Kalmanek，C.，和K.Ramakrishnan，“EF PHB（每跳快速转发行为）新定义的补充信息”，RFC 3247，2002年3月。
[11] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[11] Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[12] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot, "Analysis of Point-To-Point Packet Delay in an Operational Network", INFOCOMM 2004, March 2004, <http://www.ieee-infocom.org/2004/Papers/37_4.PDF>.
[12] Choi，B.，Moon，S.，Zhang，Z.，Papagiannaki，K.，和C.Diot，“运营网络中点对点数据包延迟的分析”，INFOCOMM 2004，2004年3月<http://www.ieee-infocom.org/2004/Papers/37_4.PDF>.
[13] Ogielski, A. and J. Cowie, "Internet Routing Behavior on 9/11", March 2002, <http://www.renesys.com/tech/presentations/pdf/ renesys-030502-NRC-911.pdf>.
[13] Ogielski，A.和J.Cowie，“9/11事件中的互联网路由行为”，2002年3月<http://www.renesys.com/tech/presentations/pdf/ renesys-030502-NRC-911.pdf>。
[14] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[14] Nichols，K.和B.Carpenter，“按域区分服务行为的定义及其规范规则”，RFC 3086，2001年4月。
[15] 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>.
[15] 麻省理工学院通信未来计划，“供应商间服务质量”，2006年11月，<http://cfp.mit.edu/resources/papers/Interprovider QoS MIT\u CFP\u WP\u 9\u 14\u 06.pdf>。
[16] International Telecommunications Union, "Network Performance Objectives for IP-Based Services", Recommendation Y.1541, February 2006.
[16] 国际电信联盟，“基于IP的服务的网络性能目标”，建议Y.1541，2006年2月。
RFC 2983 on Diffserv and Tunnels [5] and RFC 3270 on MPLS Support of Diffserv [6] provide a very good background on this topic. This document provides an example of using the E-LSP, EXP Inferred PHB Scheduled Class (PSC) Label Switched Path (LSP), defined by MPLS Support of Diffserv [6] for realizing the Treatment Aggregates.
关于Diffserv和隧道[5]的RFC 2983和关于Diffserv的MPLS支持[6]的RFC 3270为这一主题提供了非常好的背景。本文档提供了一个使用E-LSP的示例，即EXP推断PHB调度类（PSC）标签交换路径（LSP），该路径由Diffserv[6]的MPLS支持定义，用于实现治疗聚合。
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.
当使用EXP推断的PSC LSP在MPLS中表示治疗聚合时，我们建议对治疗聚合使用以下MPLS EXP字段。
-------------------------------------------
|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 |
-------------------------------------------
-------------------------------------------
|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
图3：处理聚合和MPLS EXP字段使用情况
* Note: 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).
* 注：对于保证弹性（和弹性）处理骨料，使用010或011（000或001）作为EXP字段值取决于下降概率。EXP字段为011（001）的LSP中的数据包比EXP字段为010（000）的数据包具有更高的丢弃概率。
The above table indicates the recommended usage of EXP fields for treatment aggregates. Because many deployments of MPLS are on a per-domain basis, each domain has total control of its EXP usage and each domain may use a different EXP field allocation for the domain's supported treatment aggregates.
上表显示了处理骨料EXP字段的建议使用情况。由于MPLS的许多部署都是基于每个域的，因此每个域都可以完全控制其EXP使用，并且每个域可以为域的受支持治疗聚合使用不同的EXP字段分配。
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 RFC 4594 [3]. 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.
将E-LSP用于网络控制处理骨料需要遵守本文件第4.1.1节和RFC 4594[3]第3.2节中的建议。为了加强这些建议，不应存在与用于网络控制处理聚合的MPLS PSC相关联的丢弃优先级，因为应防止网络控制处理聚合流量的丢弃。
In addition to the recommendations provided in section 4.1.2 of this document and in member service classes' sections of RFC 4594 [3], 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.
除了本文件第4.1.2节和RFC 4594[3]的成员服务类章节中提供的建议外，我们还想指出，不应丢弃实时处理聚合流量，因为在实时处理聚合中承载流量的一些应用程序对丢弃的数据包反应不好。如本文件第4.1.2节所述，应对构成实时处理聚合的每个服务类别执行准入控制，以防止由于分配给实时处理聚合的资源不足而导致数据包丢失。此外，还可以对聚合到该处理聚合中的所有流量的总和应用准入控制和监管。
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.
010和011的EXP现场标记用于确保弹性处理骨料。这两种编码用于提供两个级别的丢弃优先级指示，010编码的业务具有比011编码的业务更低的丢弃概率。这提供了CS2、AF31、AF21和AF11到EXP 010的映射；将AF32、AF22、AF12和AF33、AF23、AF13放入EXP 011。如果域选择仅支持此处理聚合的一个drop优先级，我们建议使用010作为EXP字段标记。
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
EXP字段标记000和001用于弹性处理骨料。这两种编码用于提供两个级别的丢弃优先级指示，000编码的通信量丢弃的概率低于001编码的通信量。这提供了默认/CS0到000的映射；和CS1到001。注意
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.
通过这种映射，在拥塞期间，CS1标记的流量可能会不足。如果域选择仅支持此处理聚合的一个drop优先级，我们建议使用000作为EXP字段标记。
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 administration.
由于L-LSP（仅标签推断的PSC LSP）支持每个LSP一个PSC，因此每个处理聚合的支持基于每个LSP。本文件未进一步规定治疗聚合到L-LSP映射的任何其他建议（超出本文件第4节所述内容），将其留给各个MPLS域管理部门。
Authors' Addresses
作者地址
Kwok Ho Chan Nortel 600 Technology Park Drive Billerica, MA 01821 US
美国马萨诸塞州比勒里卡市郭河陈北电600科技园路01821号
Phone: +1-978-288-8175
Fax: +1-978-288-8700
EMail: khchan@nortel.com
Phone: +1-978-288-8175
Fax: +1-978-288-8700
EMail: khchan@nortel.com
Jozef Z. Babiarz Nortel 3500 Carling Avenue Ottawa, Ont. K2H 8E9 Canada
安大略省渥太华市卡林大道3500号Jozef Z.Babiarz北电。K2H 8E9加拿大
Phone: +1-613-763-6098
Fax: +1-613-768-2231
EMail: babiarz@nortel.com
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
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara，加利福尼亚州，美国93117
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.