Network Working Group F. Le Faucheur
Request for Comments: 3564 Cisco Systems, Inc.
Category: Informational W. Lai
AT&T
July 2003
Network Working Group F. Le Faucheur
Request for Comments: 3564 Cisco Systems, Inc.
Category: Informational W. Lai
AT&T
July 2003
Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering
支持区分服务感知MPLS流量工程的要求
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document presents Service Provider requirements for support of Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering (DS-TE).
本文档介绍了支持区分服务（Diff-Serv）感知MPLS流量工程（DS-TE）的服务提供商要求。
Its objective is to provide guidance for the definition, selection and specification of a technical solution addressing these requirements. Specification for this solution itself is outside the scope of this document.
其目的是为满足这些要求的技术解决方案的定义、选择和规范提供指导。此解决方案本身的规范不在本文档的范围内。
A problem statement is first provided. Then, the document describes example applications scenarios identified by Service Providers where existing MPLS Traffic Engineering mechanisms fall short and Diff-Serv-aware Traffic Engineering can address the needs. The detailed requirements that need to be addressed by the technical solution are also reviewed. Finally, the document identifies the evaluation criteria that should be considered for selection and definition of the technical solution.
首先提供问题陈述。然后，本文档描述了服务提供商确定的示例应用场景，其中现有MPLS流量工程机制存在不足，区分服务感知流量工程可以满足这些需求。还审查了技术解决方案需要解决的详细要求。最后，该文件确定了选择和定义技术解决方案时应考虑的评估标准。
Table of Contents
目录
Specification Requirements ....................................... 2
1. Introduction ................................................. 3
1.1. Problem Statement ...................................... 3
1.2. Definitions ............................................ 3
1.3. Mapping of traffic to LSPs ............................. 5
2. Application Scenarios ........................................ 6
2.1. Scenario 1: Limiting Proportion of Classes on a Link ... 6
2.2. Scenario 2: Maintain relative proportion of traffic .... 6
2.3. Scenario 3: Guaranteed Bandwidth Services .............. 8
3. Detailed Requirements for DS-TE .............................. 9
3.1. DS-TE Compatibility .................................... 9
3.2. Class-Types ............................................ 9
3.3. Bandwidth Constraints .................................. 11
3.4. Preemption and TE-Classes .............................. 12
3.5. Mapping of Traffic to LSPs ............................. 15
3.6. Dynamic Adjustment of Diff-Serv PHBs ................... 15
3.7. Overbooking ............................................ 16
3.8. Restoration ............................................ 16
4. Solution Evaluation Criteria ................................. 16
4.1. Satisfying detailed requirements ....................... 17
4.2. Flexibility ............................................ 17
4.3. Extendibility .......................................... 17
4.4. Scalability ............................................ 17
4.5. Backward compatibility/Migration ....................... 17
4.6. Bandwidth Constraints Model ............................ 18
5. Security Considerations ...................................... 18
6. Acknowledgment ............................................... 18
7. Normative References ......................................... 18
8. Informative References ....................................... 19
9. Contributing Authors ......................................... 20
10. Editors' Addresses ........................................... 21
11. Full Copyright Statement ..................................... 22
Specification Requirements ....................................... 2
1. Introduction ................................................. 3
1.1. Problem Statement ...................................... 3
1.2. Definitions ............................................ 3
1.3. Mapping of traffic to LSPs ............................. 5
2. Application Scenarios ........................................ 6
2.1. Scenario 1: Limiting Proportion of Classes on a Link ... 6
2.2. Scenario 2: Maintain relative proportion of traffic .... 6
2.3. Scenario 3: Guaranteed Bandwidth Services .............. 8
3. Detailed Requirements for DS-TE .............................. 9
3.1. DS-TE Compatibility .................................... 9
3.2. Class-Types ............................................ 9
3.3. Bandwidth Constraints .................................. 11
3.4. Preemption and TE-Classes .............................. 12
3.5. Mapping of Traffic to LSPs ............................. 15
3.6. Dynamic Adjustment of Diff-Serv PHBs ................... 15
3.7. Overbooking ............................................ 16
3.8. Restoration ............................................ 16
4. Solution Evaluation Criteria ................................. 16
4.1. Satisfying detailed requirements ....................... 17
4.2. Flexibility ............................................ 17
4.3. Extendibility .......................................... 17
4.4. Scalability ............................................ 17
4.5. Backward compatibility/Migration ....................... 17
4.6. Bandwidth Constraints Model ............................ 18
5. Security Considerations ...................................... 18
6. Acknowledgment ............................................... 18
7. Normative References ......................................... 18
8. Informative References ....................................... 19
9. Contributing Authors ......................................... 20
10. Editors' Addresses ........................................... 21
11. Full Copyright Statement ..................................... 22
Specification Requirements
规格要求
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Diff-Serv is used by some Service Providers to achieve scalable network designs supporting multiple classes of services.
一些服务提供商使用Diff-Serv来实现支持多类服务的可扩展网络设计。
In some such Diff-Serv networks, where optimization of transmission resources on a network-wide basis is not sought, MPLS Traffic Engineering (TE) mechanisms may not be used.
在一些这样的区分服务网络中，不寻求在网络范围内优化传输资源，因此可能不使用MPLS流量工程（TE）机制。
In other networks, where optimization of transmission resources is sought, Diff-Serv mechanisms [DIFF-MPLS] may be complemented by MPLS Traffic Engineering mechanisms [TE-REQ] [ISIS-TE] [OSPF-TE] [RSVP-TE] which operate on an aggregate basis across all Diff-Serv classes of service. In this case, Diff-Serv and MPLS TE both provide their respective benefits.
在寻求传输资源优化的其他网络中，Diff-Serv机制[Diff-MPLS]可以由MPLS流量工程机制[TE-REQ][ISIS-TE][OSPF-TE][RSVP-TE]来补充，该机制在所有Diff-Serv服务类别的聚合基础上运行。在这种情况下，Diff-Serv和MPLS-TE都提供了各自的好处。
To achieve fine-grained optimization of transmission resources and further enhanced network performance and efficiency, as discussed in [TEWG-FW], it may be desirable to perform traffic engineering at a per-class level instead of at an aggregate level. By mapping the traffic from a given Diff-Serv class of service on a separate LSP, it allows this traffic to utilize resources available to the given class on both shortest paths and non-shortest paths, and follow paths that meet engineering constraints which are specific to the given class. This is what we refer to as "Diff-Serv-aware Traffic Engineering (DS-TE)".
如[TEWG-FW]所述，为了实现传输资源的细粒度优化并进一步增强网络性能和效率，可能需要在每类级别而不是聚合级别执行流量工程。通过将给定区分服务类别的流量映射到单独的LSP上，它允许该流量利用给定类别在最短路径和非最短路径上的可用资源，并遵循满足特定于给定类别的工程约束的路径。这就是我们所说的“区分服务感知流量工程（DS-TE）”。
This document focuses exclusively on the specific environments which would benefit from DS-TE. Some examples include:
本文档专门关注将从DS-TE中受益的特定环境。一些例子包括：
- networks where bandwidth is scarce (e.g., transcontinental networks) - networks with significant amounts of delay-sensitive traffic - networks where the relative proportion of traffic across classes of service is not uniform
- 带宽不足的网络（例如，跨大陆网络）-具有大量延迟敏感流量的网络-跨服务类别的流量相对比例不一致的网络
This document focuses on intra-domain operation. Inter-domain operation is not considered.
本文档重点介绍域内操作。不考虑域间操作。
For the convenience of the reader, relevant Diff-Serv ([DIFF-ARCH], [DIFF-NEW] and [DIFF-PDB]) definitions are repeated herein.
为了方便读者，本文重复相关的Diff-Serv（[Diff-ARCH]、[Diff-NEW]和[Diff-PDB]）定义。
Behavior Aggregate (BA): a collection of packets with the same (Diff-Serv) codepoint crossing a link in a particular direction.
行为聚合（BA）：具有相同（区分服务）码点的数据包在特定方向上穿过链路的集合。
Per-Hop-Behavior (PHB): the externally observable forwarding behavior applied at a DS-compliant node to a Diff-Serv behavior aggregate.
每跳行为（PHB）：在符合DS的节点上应用于区分服务行为聚合的外部可观察的转发行为。
PHB Scheduling Class (PSC): A PHB group for which a common constraint is that ordering of at least those packets belonging to the same microflow must be preserved.
PHB调度类（PSC）：一个PHB组，它的一个共同约束是至少必须保留属于同一微流的那些数据包的顺序。
Ordered Aggregate (OA): a set of BAs that share an ordering constraint. The set of PHBs that are applied to this set of Behavior Aggregates constitutes a PHB scheduling class.
有序聚合（OA）：共享排序约束的一组BAs。应用于这组行为聚合的PHB集构成PHB调度类。
Traffic Aggregate (TA): a collection of packets with a codepoint that maps to the same PHB, usually in a DS domain or some subset of a DS domain. A traffic aggregate marked for the foo PHB is referred to as the "foo traffic aggregate" or "foo aggregate" interchangeably. This generalizes the concept of Behavior Aggregate from a link to a network.
流量聚合（TA）：具有映射到同一PHB的代码点的数据包集合，通常位于DS域或DS域的某个子集中。标记为foo PHB的流量聚合被互换地称为“foo流量聚合”或“foo聚合”。这将行为聚合的概念从链接推广到网络。
Per-Domain Behavior (PDB): the expected treatment that an identifiable or target group of packets will receive from "edge-to-edge" of a DS domain. A particular PHB (or, if applicable, list of PHBs) and traffic conditioning requirements are associated with each PDB.
每域行为（PDB）：可识别或目标数据包组将从DS域的“边到边”接收的预期处理。特定的PHB（或，如果适用，PHB列表）和交通调节要求与每个PDB相关。
We also repeat the following definition from [TE-REQ]:
我们还重复[TE-REQ]中的以下定义：
Traffic Trunk: an aggregation of traffic flows of the same class which are placed inside a Label Switched Path.
交通干线：放置在标签交换路径内的同类交通流的集合。
In the context of the present document, "flows of the same class" is to be interpreted as "flows from the same Forwarding Equivalence Class which are to be treated equivalently from the DS-TE perspective".
在本文件的上下文中，“同类流”将被解释为“来自相同转发等价类的流，这些流将从DS-TE的角度进行等价处理”。
We refer to the set of TAs corresponding to the set of PHBs of a given PSC, as a {TA}PSC. A given {TA}PSC will receive the treatment of the PDB associated with the corresponding PSC. In this document, we also loosely refer to a {TA}PSC as a "Diff-Serv class of service", or a "class of service". As an example, the set of packets within a DS domain with a codepoint that maps to the EF PHB may form one {TA}PSC in that domain. As another example, the set of packets within a DS domain with a codepoint that maps to the AF11 or AF12 or AF13 PHB may form another {TA}PSC in that domain.
我们将与给定PSC的PHB集相对应的TA集称为{TA}PSC。给定的{TA}PSC将接受与相应PSC相关的PDB治疗。在本文中，我们还将{TA}PSC松散地称为“区分服务类”或“服务类”。例如，DS域内具有映射到EF PHB的码点的分组集合可以在该域中形成一个{TA}PSC。作为另一示例，DS域内具有映射到AF11或AF12或AF13 PHB的码点的分组集合可以在该域中形成另一个{TA}PSC。
We refer to the collection of packets which belong to a given Traffic Aggregate and are associated with a given MPLS Forwarding Equivalence Class (FEC) ([MPLS-ARCH]) as a <FEC/TA>.
我们将属于给定流量聚合且与给定MPLS转发等价类（FEC）（[MPLS-ARCH]）关联的数据包集合称为<FEC/TA>。
We refer to the set of <FEC/TA> whose TAs belong to a given {TA}PSC as a <FEC/{TA}PSC>.
我们将其TA属于给定{TA}PSC的<FEC/TA>集合称为<FEC/{TA}PSC>。
A network may have multiple Traffic Aggregates (TAs) it wishes to service. Recalling from [DIFF-MPLS], there are several options on how the set of <FEC/{TA}PSC> of a given FEC can be split into Traffic Trunks for mapping onto LSPs when running MPLS Traffic Engineering.
一个网络可能有多个它希望服务的流量聚合（TA）。回顾[DIFF-MPLS]，在运行MPLS流量工程时，有几个选项可用于如何将给定FEC的<FEC/{TA}PSC>集拆分为流量中继，以便映射到LSP。
One option is to not split this set of <FEC/{TA}PSC> so that each Traffic Trunk comprises traffic from all the {TA}/PSC. This option is typically used when aggregate traffic engineering is deployed using current MPLS TE mechanisms. In that case, all the <FEC/{TA}PSC> of a given FEC are routed collectively according to a single shared set of constraints and will follow the same path. Note that the LSP transporting such a Traffic Trunk is, by definition, an E-LSP as defined in [DIFF-MPLS].
一种选择是不拆分这组<FEC/{TA}PSC>，以便每个流量主干包含来自所有{TA}/PSC的流量。此选项通常在使用当前MPLS TE机制部署聚合流量工程时使用。在这种情况下，给定FEC的所有<FEC/{TA}PSC>根据单个共享约束集集体路由，并将遵循相同的路径。注意，根据定义，传输这种业务中继的LSP是[DIFF-MPLS]中定义的E-LSP。
Another option is to split the different <FEC/{TA}PSC> of a given FEC into multiple Traffic Trunks on the basis of the {TA}PSC. In other words, traffic, from one given node to another, is split, based on the "classes of service", into multiple Traffic Trunks which are transported over separate LSP and can potentially follow different paths through the network. DS-TE takes advantage of this and computes a separate path for each LSP. In so doing, DS-TE can take into account the specific requirements of the Traffic Trunk transported on each LSP (e.g., bandwidth requirement, preemption priority). Moreover DS-TE can take into account the specific engineering constraints to be enforced for these sets of Traffic Trunks (e.g., limit all Traffic Trunks transporting a particular {TA}PSC to x% of link capacity). DS-TE achieves per LSP constraint based routing with paths that match specific objectives of the traffic while forming the corresponding Traffic Trunk.
另一种选择是基于{TA}PSC将给定FEC的不同<FEC/{TA}PSC>划分为多个业务中继。换言之，从一个给定节点到另一个节点的流量根据“服务类别”被分成多个流量中继，这些流量中继通过单独的LSP传输，并且可能通过网络遵循不同的路径。DS-TE利用这一点，为每个LSP计算单独的路径。在这样做时，DS-TE可以考虑在每个LSP上传输的业务中继的特定要求（例如，带宽要求、抢占优先级）。此外，DS-TE可以考虑对这些交通干线组实施的特定工程约束（例如，将传输特定{TA}PSC的所有交通干线限制为链路容量的x%）。DS-TE通过匹配特定业务目标的路径实现基于每LSP约束的路由，同时形成相应的业务主干。
For simplicity, and because this is the specific topic of this document, the above paragraphs in this section only considered splitting traffic of a given FEC into multiple Traffic Aggregates on the basis of {TA}PSC. However, it should be noted that, in addition to this, traffic from every {TA}PSC may also be split into multiple Traffic Trunks for load balancing purposes.
为简单起见，并且由于这是本文档的特定主题，本节中的上述段落仅考虑在{TA}PSC的基础上将给定FEC的流量拆分为多个流量聚合。然而，应当注意，除此之外，出于负载平衡的目的，来自每个{TA}PSC的流量也可以被分成多个流量中继。
An IP/MPLS network may need to carry a significant amount of VoIP traffic compared to its link capacity. For example, 10,000 uncompressed calls at 20ms packetization result in about 1Gbps of IP traffic, which is significant on an OC-48c based network. In case of topology changes such as link/node failure, VoIP traffic levels can even approach the full bandwidth on certain links.
与链路容量相比，IP/MPLS网络可能需要承载大量VoIP流量。例如，在20ms分组时，10000个未压缩的呼叫会导致大约1Gbps的IP流量，这在基于OC-48c的网络上非常重要。在发生拓扑变化（如链路/节点故障）的情况下，VoIP流量水平甚至可以接近某些链路上的全部带宽。
For delay/jitter reasons, some network administrators see it as undesirable to carry more than a certain percentage of VoIP traffic on any link. The rest of the available link bandwidth can be used to route other "classes of service" corresponding to delay/jitter insensitive traffic (e.g., Best Effort Internet traffic). The exact determination of this "certain" percentage is outside the scope of this requirements document.
由于延迟/抖动的原因，一些网络管理员认为在任何链路上承载超过一定百分比的VoIP流量是不可取的。剩余的可用链路带宽可用于路由与延迟/抖动不敏感流量（例如，尽力而为的互联网流量）相对应的其他“服务类别”。该“特定”百分比的准确确定不在本要求文件的范围内。
During normal operations, the VoIP traffic should be able to preempt other "classes of service" (if these other classes are designated as preemptable and they have lower preemption priority), so that it will be able to use the shortest available path, only constrained by the maximum defined link utilization ratio/percentage of the VoIP class.
在正常操作期间，VoIP流量应该能够抢占其他“服务类别”（如果这些其他类别被指定为可抢占，并且它们具有较低的抢占优先级），这样它将能够使用最短的可用路径，仅受VoIP类别的最大定义链路利用率/百分比的限制。
Existing TE mechanisms only allow constraint based routing of traffic based on a single bandwidth constraint common to all "classes of service", which does not satisfy the needs described here. This leads to the requirement for DS-TE to be able to enforce a different bandwidth constraint for different "classes of service". In the above example, the bandwidth constraint to be enforced for VoIP traffic may be the "certain" percentage of each link capacity, while the bandwidth constraint to be enforced for the rest of the "classes of service" might have their own constraints or have access to the rest of the link capacity.
现有TE机制仅允许基于所有“服务类别”通用的单个带宽约束的基于约束的流量路由，这不满足此处描述的需求。这就要求DS-TE能够对不同的“服务类别”实施不同的带宽约束。在上面的示例中，要为VoIP业务强制执行的带宽约束可以是每个链路容量的“特定”百分比，而要为其余的“服务类别”强制执行的带宽约束可以具有它们自己的约束或者可以访问其余的链路容量。
Suppose an IP/MPLS network supports 3 "classes of service". The network administrator wants to perform Traffic Engineering to distribute the traffic load. Also assume that proportion across "classes of service" varies significantly depending on the source/destination POPs.
假设一个IP/MPLS网络支持3个“服务类”。网络管理员希望执行流量工程来分配流量负载。还假设“服务类别”之间的比例因来源/目的地POP而显著不同。
With existing TE mechanisms, the proportion of traffic from each "class of service" on a given link will vary depending on multiple factors including:
在现有TE机制下，给定链路上每个“服务类别”的流量比例将根据多个因素而变化，包括：
- in which order the different TE-LSPs are established - the preemption priority associated with the different TE-LSPs - link/node failure situations
- 不同TE LSP的建立顺序-与不同TE LSP相关联的抢占优先级-链路/节点故障情况
This may make it difficult or impossible for the network administrator to configure the Diff-Serv PHBs (e.g., queue bandwidth) to ensure that each "class of service" gets the appropriate treatment. This leads again to the requirement for DS-TE to be able to enforce a different bandwidth constraint for different "classes of service". This could be used to ensure that, regardless of the order in which tunnels are routed, regardless of their preemption priority and regardless of the failure situation, the amount of traffic of each "class of service" routed over a link matches the Diff-Serv scheduler configuration on that link to the corresponding class (e.g., queue bandwidth).
这可能使网络管理员难以或不可能配置区分服务phb（例如，队列带宽），以确保每个“服务类别”都得到适当的处理。这再次要求DS-TE能够对不同的“服务类别”实施不同的带宽约束。这可用于确保，无论隧道的路由顺序如何，无论其抢占优先级如何，也无论故障情况如何，通过链路路由的每个“服务类别”的通信量都与该链路上的Diff-Serv调度程序配置与相应类别（例如，队列带宽）相匹配。
As an illustration of how DS-TE would address this scenario, the network administrator may configure the service rate of Diff-Serv queues to (45%,35%,20%) for "classes of service" (1,2,3) respectively. The administrator would then split the traffic into separate Traffic Trunks for each "class of service" and associate a bandwidth to each LSP transporting those Traffic Trunks. The network administrator may also want to configure preemption priorities of each LSP in order to give highest restoration priority to the highest priority "class of service" and medium priority to the medium "class of service". Then DS-TE could ensure that after a failure, "class of service" 1 traffic would be rerouted with first access at link capacity without exceeding its service rate of 45% of the link bandwidth. "Class of service" 2 traffic would be rerouted with second access at the link capacity without exceeding its allotment. Note that where "class of service" 3 is the Best-Effort service, the requirement on DS-TE may be to ensure that the total amount of traffic routed across all "classes of service" does not exceed the total link capacity of 100% (as opposed to separately limiting the amount of Best Effort traffic to 20 even if there was little "class of service" 1 and "class of service" 2 traffic).
作为DS-TE将如何解决该场景的说明，网络管理员可以将区分服务队列的服务率分别配置为（45%、35%、20%），用于“服务类别”（1、2、3）。然后，管理员将每个“服务类别”的流量拆分为单独的流量中继，并将带宽与传输这些流量中继的每个LSP相关联。网络管理员还可能希望配置每个LSP的抢占优先级，以便将最高优先级的恢复优先级赋予最高优先级的“服务类别”，将中等优先级赋予中等“服务类别”。然后，DS-TE可以确保在发生故障后，“服务类别”1流量将在链路容量的第一次访问时重新路由，而不会超过其45%链路带宽的服务率。“服务等级”2流量将在链路容量下通过第二次访问重新路由，而不超过其分配。注意，如果“服务等级”3是尽力而为的服务，则DS-TE的要求可能是确保所有“服务等级”路由的总流量不超过100%的总链路容量（而不是单独将尽力而为的流量限制在20%以内，即使“服务等级”很小1和“服务等级”2）。
In this scenario, DS-TE would allow for the maintenance of a more steady distribution of "classes of service", even during rerouting. This would rely on the required capability of DS-TE to adjust the amount of traffic of each "class of service" routed on a link based on the configuration of the scheduler and the amount of bandwidth available for each "class of service".
在这种情况下，DS-TE将允许维护更稳定的“服务类别”分布，即使在重新路由期间也是如此。这将取决于DS-TE根据调度器的配置和每个“服务类别”的可用带宽量来调整链路上路由的每个“服务类别”的流量的所需能力。
Alternatively, some network administrators may want to solve the problem by having the scheduler dynamically adjusted based on the amount of bandwidth of the LSPs admitted for each "class of service". This is an optional additional requirement on the DS-TE solution.
或者，一些网络管理员可能希望通过基于每个“服务类别”允许的lsp的带宽量动态调整调度器来解决该问题。这是DS-TE解决方案的可选附加要求。
In addition to the Best effort service, an IP/MPLS network operator may desire to offer a point-to-point "guaranteed bandwidth" service whereby the provider pledges to provide a given level of performance (bandwidth/delay/loss...) end-to-end through its network from an ingress port to an egress port. The goal is to ensure that all the "guaranteed" traffic under the scope of a subscribed service level specification, will be delivered within the tolerances of this service level specification.
除了尽力而为的服务外，IP/MPLS网络运营商可能希望提供点对点“保证带宽”服务，由此提供商保证通过其网络从入口端口到出口端口端到端提供给定水平的性能（带宽/延迟/损耗…）。目标是确保订阅的服务级别规范范围内的所有“保证”流量将在该服务级别规范的公差范围内交付。
One approach for deploying such "guaranteed" service involves:
部署此类“保证”服务的一种方法包括：
- dedicating a Diff-Serv PHB (or a Diff-Serv PSC as defined in [DIFF-NEW]) to the "guaranteed" traffic - policing guaranteed traffic on ingress against the traffic contract and marking the "guaranteed" packets with the corresponding DSCP/EXP value
- 将Diff-Serv PHB（或[Diff-NEW]中定义的Diff-Serv PSC]）专用于“保证”流量-根据流量合约对入口保证流量进行监控，并用相应的DSCP/EXP值标记“保证”数据包
Where a very high level of performance is targeted for the "guaranteed" service, it may be necessary to ensure that the amount of "guaranteed" traffic remains below a given percentage of link capacity on every link. Where the proportion of "guaranteed" traffic is high, constraint based routing can be used to enforce such a constraint.
如果“保证”服务的目标性能非常高，则可能需要确保“保证”通信量保持在每个链路上链路容量的给定百分比以下。在“保证”流量比例较高的情况下，可以使用基于约束的路由来实施此类约束。
However, the network operator may also want to simultaneously perform Traffic Engineering for the rest of the traffic (i.e., non-guaranteed traffic) which would require that constraint based routing is also capable of enforcing a different bandwidth constraint, which would be less stringent than the one for guaranteed traffic.
然而，网络运营商还可能希望同时对其余的流量（即，非保证流量）执行流量工程，这将要求基于约束的路由也能够实施不同的带宽约束，这将比保证流量的约束更为严格。
Again, this combination of requirements can not be addressed with existing TE mechanisms. DS-TE mechanisms allowing enforcement of a different bandwidth constraint for guaranteed traffic and for non-guaranteed traffic are required.
同样，这种需求组合不能用现有的TE机制来解决。需要允许对保证流量和非保证流量实施不同带宽约束的DS-TE机制。
This section specifies the functionality that the above scenarios require out of the DS-TE solution. Actual technical protocol mechanisms and procedures to achieve such functionality are outside the scope of this document.
本节指定了上述场景在DS-TE解决方案中需要的功能。实现此类功能的实际技术协议机制和程序不在本文件范围内。
Since DS-TE may impact scalability (as discussed later in this document) and operational practices, DS-TE is expected to be used when existing TE mechanisms combined with Diff-Serv cannot address the network design requirements (i.e., where constraint based routing is required and where it needs to enforce different bandwidth constraints for different "classes of service", such as in the scenarios described above in section 2). Where the benefits of DSTE are only required in a topological subset of their network, some network operators may wish to only deploy DS-TE in this topological subset.
由于DS-TE可能会影响可伸缩性（如本文档后面所讨论的）和操作实践，因此，当现有TE机制与Diff-Serv相结合无法满足网络设计要求时，预计将使用DS-TE（即，需要基于约束的路由，并且需要对不同的“服务类别”强制实施不同的带宽约束，如上文第2节所述的场景）。如果仅在其网络的拓扑子集中需要DSTE的好处，则一些网络运营商可能希望仅在该拓扑子集中部署DS-TE。
Thus, the DS-TE solution MUST be developed in such a way that:
因此，DS-TE解决方案的开发方式必须确保：
(i) it raises no interoperability issues with existing deployed TE mechanisms. (ii) it allows DS-TE deployment to the required level of granularity and scope (e.g., only in a subset of the topology, or only for the number of classes required in the considered network)
(i) 它与现有部署的TE机制没有互操作性问题。（ii）它允许DS-TE部署到所需的粒度和范围级别（例如，仅在拓扑的子集中，或仅针对所考虑的网络中所需的类数）
The fundamental requirement for DS-TE is to be able to enforce different bandwidth constraints for different sets of Traffic Trunks.
DS-TE的基本要求是能够对不同的流量中继集实施不同的带宽限制。
[TEWG-FW] introduces the concept of Class-Types when discussing operations of MPLS Traffic Engineering in a Diff-Serv environment.
[TEWG-FW]在讨论区分服务环境中MPLS流量工程的操作时，引入了类类型的概念。
We refine this definition into the following:
我们将此定义细化为以下内容：
Class-Type (CT): the set of Traffic Trunks crossing a link, that is governed by a specific set of Bandwidth constraints. CT is used for the purposes of link bandwidth allocation, constraint based routing and admission control. A given Traffic Trunk belongs to the same CT on all links.
类别类型（CT）：通过链路的一组交通干线，由一组特定的带宽约束控制。CT用于链路带宽分配、基于约束的路由和准入控制。给定的交通干线在所有链路上属于同一个CT。
Note that different LSPs transporting Traffic Trunks from the same CT may be using the same or different preemption priorities as explained in more details in section 3.4 below.
请注意，传输来自同一CT的交通干线的不同LSP可能使用相同或不同的抢占优先级，如下文第3.4节中的详细说明。
Mapping of {TA}PSC to Class-Types is flexible. Different {TA}PSC can be mapped to different CTs, multiple {TA}PSC can be mapped to the same CT and one {TA}PSC can be mapped to multiple CTs.
{TA}PSC到类类型的映射是灵活的。不同的{TA}PSC可以映射到不同的CT，多个{TA}PSC可以映射到同一CT，一个{TA}PSC可以映射到多个CT。
For illustration purposes, let's consider the case of a network running 4 Diff-Serv PDBs which are respectively based on the EF PHB [EF], the AF1x PSC [AF], the AF2x PSC and the Default (i.e., Best-Effort) PHB [DIFF-FIELD]. The network administrator may decide to deploy DS-TE in the following way:
为了说明的目的，让我们考虑一个运行4个Diff-Serv PDBS的网络的情况，它们分别基于EF PHB[EF]、AF1X PSC [AF ]、AF2X PSC和默认（即尽力）PHB[Diff-field ]。网络管理员可通过以下方式决定部署DS-TE：
o from every DS-TE Head-end to every DS-TE Tail-end, split the traffic into 4 Traffic Trunks: one for traffic of each {TA}PSC o because the QoS objectives for the AF1x PDB and for the AF2x PDB may be of similar nature (e.g., both targeting low loss albeit at different levels perhaps), the same (set of) Bandwidth Constraint(s) may be applied collectively over the AF1x Traffic Trunks and the AF2x Traffic Trunks. Thus, the network administrator may only define three CTs: one for the EF Traffic Trunks, one for the AF1x and AF2x Traffic Trunks and one for the Best Effort Traffic Trunks.
o 从每个DS-TE前端到每个DS-TE后端，将流量分成4个流量中继：一个用于每个{TA}PSC o的流量，因为AF1x PDB和AF2x PDB的QoS目标可能具有相似的性质（例如，两者都以低损耗为目标，尽管可能处于不同的级别），相同的（一组）带宽约束可在AF1x交通干线和AF2x交通干线上共同应用。因此，网络管理员只能定义三个CT：一个用于EF流量中继，一个用于AF1x和AF2x流量中继，一个用于尽力而为流量中继。
As another example of mapping of {TA}PSC to CTs, a network operator may split the traffic from the {TA}PSC associated with EF into two different sets of traffic trunks, so that each set of traffic trunks is subject to different constraints on the bandwidth it can access. In this case, two distinct CTs are defined for the EF {TA}PSC traffic: one for the traffic subset subject to the first (set of) bandwidth constraint(s), the other for the traffic subset subject to the second (set of) bandwidth constraint(s).
作为{TA}PSC到CTs的映射的另一个示例，网络运营商可以将来自与EF相关联的{TA}PSC的业务划分为两组不同的业务中继，使得每组业务中继在其可以访问的带宽上受到不同的约束。在这种情况下，为EF{TA}PSC业务定义了两个不同的ct：一个用于受第一（组）带宽约束的业务子集，另一个用于受第二（组）带宽约束的业务子集。
The DS-TE solution MUST support up to 8 CTs. Those are referred to as CTc, 0 <= c <= MaxCT-1 = 7. The DS-TE solution MUST be able to enforce a different set of Bandwidth Constraints for each CT. A DS-TE implementation MUST support at least 2 CTs, and MAY support up to 8 CTs.
DS-TE解决方案必须支持多达8个CT。这些被称为CTc，0<=c<=MaxCT-1=7。DS-TE解决方案必须能够为每个CT实施一组不同的带宽约束。DS-TE实现必须支持至少2个CT，并且最多可以支持8个CT。
In a given network, the DS-TE solution MUST NOT require the network administrator to always deploy the maximum number of CTs. The DS-TE solution MUST allow the network administrator to deploy only the number of CTs actually utilized.
在给定网络中，DS-TE解决方案不得要求网络管理员始终部署最大数量的CT。DS-TE解决方案必须允许网络管理员仅部署实际使用的CT数量。
We refer to a Bandwidth Constraint Model as the set of rules defining:
我们将带宽约束模型称为定义以下内容的规则集：
- the maximum number of Bandwidth Constraints; and - which CTs each Bandwidth Constraint applies to and how.
- 带宽限制的最大数量；和-每个带宽约束适用于哪些CT以及如何应用。
By definition of CT, each CT is assigned either a Bandwidth Constraint, or a set of Bandwidth Constraints.
根据CT的定义，每个CT分配一个带宽约束或一组带宽约束。
We refer to the Bandwidth Constraints as BCb, 0 <= b <= MaxBC-1
We refer to the Bandwidth Constraints as BCb, 0 <= b <= MaxBC-1
For a given Class-Type CTc, 0 <= c <= MaxCT-1, let us define "Reserved(CTc)" as the sum of the bandwidth reserved by all established LSPs which belong to CTc.
对于给定的类类型CTc，0<=c<=MaxCT-1，让我们将“保留（CTc）”定义为属于CTc的所有已建立LSP保留的带宽之和。
Different models of Bandwidth Constraints are conceivable for control of the CTs.
对于CTs的控制，可以设想不同的带宽约束模型。
For example, a model with one separate Bandwidth Constraint per CT could be defined. This model is referred to as the "Maximum Allocation Model" and is defined by:
例如，可以定义每个CT具有一个单独带宽约束的模型。该模型称为“最大分配模型”，定义如下：
- MaxBC= MaxCT - for each value of b in the range 0 <= b <= (MaxCT - 1): Reserved (CTb) <= BCb
- MaxBC=MaxCT-对于范围0<=b<=（MaxCT-1）中的每个b值：保留（CTb）<=BCb
For illustration purposes, on a link of 100 unit of bandwidth where three CTs are used, the network administrator might then configure BC0=20, BC1= 50, BC2=30 such that:
出于说明目的，在使用三个CT的100单位带宽的链路上，网络管理员可以配置BC0=20、BC1=50、BC2=30，以便：
- All LSPs supporting Traffic Trunks from CT2 use no more than 30 (e.g., Voice <= 30) - All LSPs supporting Traffic Trunks from CT1 use no more than 50 (e.g., Premium Data <= 50) - All LSPs supporting Traffic Trunks from CT0 use no more than 20 (e.g., Best Effort <= 20)
- 支持来自CT2的交通干线的所有LSP使用不超过30（例如，语音<=30）-支持来自CT1的交通干线的所有LSP使用不超过50（例如，高级数据<=50）-支持来自CT0的交通干线的所有LSP使用不超过20（例如，尽力而为<=20）
As another example, a "Russian Doll" model of Bandwidth Constraints may be defined whereby:
作为另一个示例，可以定义带宽约束的“俄罗斯玩偶”模型，其中：
- MaxBC= MaxCT - for each value of b in the range 0 <= b <= (MaxCT - 1): SUM (Reserved (CTc)) <= BCb, for all "c" in the range b <= c <= (MaxCT - 1)
- MaxBC=MaxCT-对于范围0<=b<=（MaxCT-1）中的每个b值：对于范围b<=c<=（MaxCT-1）中的所有“c”，求和（保留（CTc））<=BCb
For illustration purposes, on a link of 100 units of bandwidth where three CTs are used, the network administrator might then configure BC0=100, BC1= 80, BC2=60 such that:
出于说明目的，在使用三个CT的100个带宽单位的链路上，网络管理员可以配置BC0=100、BC1=80、BC2=60，以便：
- All LSPs supporting Traffic Trunks from CT2 use no more than 60 (e.g., Voice <= 60) - All LSPs supporting Traffic Trunks from CT1 or CT2 use no more than 80 (e.g., Voice + Premium Data <= 80) - All LSPs supporting Traffic Trunks from CT0 or CT1 or CT2 use no more than 100 (e.g., Voice + Premium Data + Best Effort <= 100).
- 支持来自CT2的交通干线的所有LSP使用不超过60（例如，语音<=60）-支持来自CT1或CT2的交通干线的所有LSP使用不超过80（例如，语音+高级数据<=80）-支持来自CT0或CT1或CT2的交通干线的所有LSP使用不超过100（例如，语音+高级数据+尽力而为<=100）。
Other Bandwidth Constraints model can also be conceived. Those could involve arbitrary relationships between BCb and CTc. Those could also involve additional concepts such as associating minimum reservable bandwidth to a CT.
还可以设想其他带宽约束模型。这些可能涉及BCb和CTc之间的任意关系。这些还可能涉及其他概念，如将最小可保留带宽与CT关联。
The DS-TE technical solution MUST have the capability to support multiple Bandwidth Constraints models. The DS-TE technical solution MUST specify at least one bandwidth constraint model and MAY specify multiple Bandwidth Constraints models. Additional Bandwidth Constraints models MAY also be specified at a later stage if deemed useful based on operational experience from DS-TE deployments. The choice of which (or which set of) Bandwidth Constraints model(s) is to be supported by a given DS-TE implementation, is an implementation choice. For simplicity, a network operator may elect to use the same Bandwidth Constraints Model on all the links of his/her network. However, if he/she wishes/needs to do so, the network operator may elect to use different Bandwidth Constraints models on different links in a given network.
DS-TE技术解决方案必须能够支持多种带宽约束模型。DS-TE技术解决方案必须指定至少一个带宽约束模型，并且可以指定多个带宽约束模型。如果根据DS-TE部署的运营经验认为有用，也可以在稍后阶段指定其他带宽限制模型。给定DS-TE实现将支持哪一个（或哪一组）带宽约束模型是一种实现选择。为简单起见，网络运营商可选择在其网络的所有链路上使用相同的带宽约束模型。然而，如果他/她希望/需要这样做，网络运营商可以选择在给定网络中的不同链路上使用不同的带宽约束模型。
Regardless of the Bandwidth Constraint Model, the DS-TE solution MUST allow support for up to 8 BCs.
无论带宽限制模型如何，DS-TE解决方案都必须支持多达8个BC。
[TEWG-FW] defines the notion of preemption and preemption priority. The DS-TE solution MUST retain full support of such preemption. However, a network administrator preferring not to use preemption for user traffic MUST be able to disable the preemption mechanisms described below.
[TEWG-FW]定义了抢占权和抢占优先权的概念。DS-TE解决方案必须完全支持这种抢占。但是，不希望对用户流量使用抢占的网络管理员必须能够禁用下面描述的抢占机制。
The preemption attributes defined in [TE-REQ] MUST be retained and applicable across all Class Types. The preemption attributes of setup priority and holding priority MUST retain existing semantics, and in particular these semantics MUST not be affected by the Ordered Aggregate transported by the LSP or by the LSP's Class Type. This means that if LSP1 contends with LSP2 for resources, LSP1 may preempt LSP2 if LSP1 has a higher set-up preemption priority (i.e., lower
[TE-REQ]中定义的抢占属性必须保留并适用于所有类类型。setup priority和holding priority的抢占属性必须保留现有语义，尤其是这些语义不得受LSP传输的有序聚合或LSP的类类型的影响。这意味着，如果LSP1与LSP2争夺资源，那么如果LSP1具有较高的设置抢占优先级（即，较低的优先级），LSP1可以抢占LSP2
numerical priority value) than LSP2's holding preemption priority regardless of LSP1's OA/CT and LSP2's OA/CT.
无论LSP1的OA/CT和LSP2的OA/CT如何，数字优先级值）都大于LSP2的持有抢占优先级。
We introduce the following definition:
我们引入以下定义：
TE-Class: A pair of: (i) a Class-Type (ii) a preemption priority allowed for that Class-Type. This means that an LSP transporting a Traffic Trunk from that Class-Type can use that preemption priority as the set-up priority, as the holding priority or both.
TE类：一对：（i）类类型（ii）该类类型允许的抢占优先级。这意味着从该类类型传输业务中继的LSP可以使用该抢占优先级作为设置优先级、保持优先级或两者兼而有之。
Note that by definition:
请注意，根据定义：
- for a given Class-Type, there may be one or multiple TE-classes using that Class-Type, each using a different preemption priority - for a given preemption priority, there may be one or multiple TE-Class(es) using that preemption priority, each using a different Class-Type.
- 对于给定的类类型，可能有一个或多个TE类使用该类类型，每个TE类使用不同的抢占优先级-对于给定的抢占优先级，可能有一个或多个TE类使用该抢占优先级，每个TE类使用不同的类类型。
The DS-TE solution MUST allow all LSPs transporting Traffic Trunks of a given Class-Type to use the same preemption priority. In other words, the DS-TE solution MUST allow a Class-Type to be used by single TE-Class. This effectively allows the network administrator to ensure that no preemption happens within that Class-Type, when so desired.
DS-TE解决方案必须允许所有传输给定类类型的流量中继的LSP使用相同的抢占优先级。换句话说，DS-TE解决方案必须允许单个TE类使用类类型。这有效地允许网络管理员在需要时确保该类类型中不会发生抢占。
As an example, the DS-TE solution MUST allow the network administrator to define a Class-Type comprising a single TE-class using preemption 0.
例如，DS-TE解决方案必须允许网络管理员使用抢占0定义包含单个TE类的类类型。
The DS-TE solution MUST allow two LSPs transporting Traffic Trunks of the same Class-Type to use different preemption priorities, and allow the LSP with higher (numerically lower) set-up priority to preempt the LSP with lower (numerically higher) holding priority when they contend for resources. In other words, the DS-TE solution MUST allow multiple TE-Classes to be defined for a given Class-Type. This effectively allows the network administrator to enable preemption within a Class-Type, when so desired.
DS-TE解决方案必须允许两个传输相同类别类型的业务中继的LSP使用不同的抢占优先级，并允许设置优先级较高（数值较低）的LSP在争夺资源时抢占持有优先级较低（数值较高）的LSP。换句话说，DS-TE解决方案必须允许为给定的类类型定义多个TE类。这有效地允许网络管理员在需要时在类类型内启用抢占。
As an example, the DS-TE solution MUST allow the network administrator to define a Class-Type comprising three TE-Classes; one using preemption 0, one using preemption 1 and one using preemption 4.
例如，DS-TE解决方案必须允许网络管理员定义包含三个TE类的类类型；一个使用抢占0，一个使用抢占1，一个使用抢占4。
The DS-TE solution MUST allow two LSPs transporting Traffic Trunks from different Class-Types to use different preemption priorities, and allow the LSP with higher setup priority to preempt the one with lower holding priority when they contend for resources.
DS-TE解决方案必须允许两个传输来自不同类别类型的业务中继的LSP使用不同的抢占优先级，并允许设置优先级较高的LSP在争夺资源时抢占持有优先级较低的LSP。
As an example, the DS-TE solution MUST allow the network administrator to define two Class-Types (CT0 and CT1) each comprising two TE-Classes where say:
例如，DS-TE解决方案必须允许网络管理员定义两种类别类型（CT0和CT1），每个类别包括两个TE类别，其中：
-one TE-Class groups CT0 and preemption 0 -one TE-Class groups CT0 and preemption 2 -one TE-Class groups CT1 and preemption 1 -one TE-Class groups CT1 and preemption 3
-一个TE类组CT0和抢占0-一个TE类组CT0和抢占2-一个TE类组CT1和抢占1-一个TE类组CT1和抢占3
The network administrator would then, in particular, be able to:
然后，网络管理员尤其能够：
- transport a CT0 Traffic Trunk over an LSP with setup priority=0 and holding priority=0 - transport a CT0 Traffic Trunk over an LSP with setup priority=2 and holding priority=0 - transport a CT1 Traffic Trunk over an LSP with setup priority=1 and holding priority=1 - transport a CT1 Traffic Trunk over an LSP with setup priority=3 and holding priority=1.
- 通过设置优先级为0且保持优先级为0的LSP传输CT0交通干线-通过设置优先级为2且保持优先级为0的LSP传输CT0交通干线-通过设置优先级为1且保持优先级为1的LSP传输CT1交通干线-通过设置优先级为3且保持优先级为1的LSP传输CT1交通干线优先级=1。
The network administrator would then, in particular, NOT be able to:
网络管理员尤其不能：
- transport a CT0 Traffic Trunk over an LSP with setup priority=1 and holding priority=1 - transport a CT1 Traffic Trunk over an LSP with setup priority=0 and holding priority=0
- 通过设置优先级为1且保持优先级为1的LSP传输CT0交通干线-通过设置优先级为0且保持优先级为0的LSP传输CT1交通干线
The DS-TE solution MUST allow two LSPs transporting Traffic Trunks from different Class-Types to use the same preemption priority. In other words, the DS-TE solution MUST allow TE-classes using different CTs to use the same preemption priority. This effectively allows the network administrator to ensure that no preemption happens across Class-Types, if so desired.
DS-TE解决方案必须允许两个传输来自不同类别类型的业务中继的LSP使用相同的抢占优先级。换句话说，DS-TE解决方案必须允许使用不同CT的TE类使用相同的抢占优先级。如果需要的话，这有效地允许网络管理员确保跨类类型不发生抢占。
As an example, the DS-TE solution MUST allow the network administrator to define three Class-Types (CT0, CT1 and CT2) each comprising one TE-Class which uses preemption 0. In that case, no preemption will ever occur.
例如，DS-TE解决方案必须允许网络管理员定义三种类类型（CT0、CT1和CT2），每种类型包含一个使用抢占0的TE类。在这种情况下，将永远不会发生抢占。
Since there are 8 preemption priorities and up to 8 Class-Types, there could theoretically be up to 64 TE-Classes in a network. This is felt to be beyond current practical requirements. The current practical requirement is that the DS-TE solution MUST allow support
Since there are 8 preemption priorities and up to 8 Class-Types, there could theoretically be up to 64 TE-Classes in a network. This is felt to be beyond current practical requirements. The current practical requirement is that the DS-TE solution MUST allow supporttranslate error, please retry
for up to 8 TE-classes. The DS-TE solution MUST allow these TE-classes to comprise any arbitrary subset of 8 (or less) from the (64) possible combinations of (8) Class-Types and (8) preemption priorities.
最多8节TE课程。DS-TE解决方案必须允许这些TE类包含（8）类类型和（8）抢占优先级的（64）个可能组合中的8个（或更少）的任意子集。
As with existing TE, an LSP which gets preempted is torn down at preemption time. The Head-end of the preempted LSP may then attempt to reestablish that LSP, which involves re-computing a path by Constraint Based Routing based on updated available bandwidth information and then signaling for LSP establishment along the new path. It is to be noted that there may be cases where the preempted LSP cannot be reestablished (e.g., no possible path satisfying LSP bandwidth constraints as well as other constraints). In such cases, the Head-end behavior is left to implementation. It may involve periodic attempts at reestablishing the LSP, relaxing of the LSP constraints, or other behaviors.
与现有TE一样，被抢占的LSP在抢占时被拆除。抢占LSP的前端随后可尝试重新建立该LSP，其涉及基于更新的可用带宽信息通过基于约束的路由重新计算路径，然后沿新路径发送LSP建立的信令。应注意，可能存在抢占LSP不能重新建立的情况（例如，没有满足LSP带宽约束以及其他约束的可能路径）。在这种情况下，前端行为留待实现。它可能涉及定期尝试重新建立LSP、放松LSP约束或其他行为。
The DS-TE solution MUST allow operation over E-LSPs onto which a single <FEC/{TA}PSC> is transported.
DS-TE解决方案必须允许在E-LSP上运行，在E-LSP上传输单个<FEC/{TA}PSC>。
The DS-TE solution MUST allow operation over L-LSPs.
DS-TE解决方案必须允许在L-LSP上运行。
The DS-TE solution MAY allow operation over E-LSPs onto which multiple <FEC/{TA}PSC> of a given FEC are transported, under the condition that those multiple <FEC/{TA}PSC> can effectively be treated by DS-TE as a single atomic traffic trunk (in particular this means that those multiple <FEC/{TA}PSC> are routed as a whole based on a single collective bandwidth requirement, a single affinity attribute, a single preemption level, a single Class-Type, etc.). In that case, it is also assumed that the multiple {TA}PSCs are grouped together in a consistent manner throughout the DS-TE domain (e.g., if <FECx/{TA}PSC1> and <FECx/{TA}PSC2> are transported together on an E-LSP, then there will not be any L-LSP transporting <FECy/{TA}PSC1> or <FECy/{TA}PSC2> on its own, and there will not be any E-LSP transporting <FECz/{TA}PSC1> and/or <FECz/{TA}PSC2> with <FECz/{TA}PSC3>).
DS-TE解决方案可以允许在E-LSP上操作，给定FEC的多个<FEC/{TA}PSC>被传输到E-LSP上，条件是这些多个<FEC/{TA}PSC>可以被DS-TE有效地视为单个原子业务中继（尤其是这意味着这些多个<FEC/{TA}PSC>）PSC>根据单个集体带宽需求、单个关联属性、单个抢占级别、单个类类型等作为一个整体进行路由）。在这种情况下，还假设在整个DS-TE域中以一致的方式将多个{TA}psc分组在一起（例如，如果<FECx/{TA}PSC1>和<FECx/{TA}PSC2>在e-LSP上一起传输，则将不存在任何L-LSP传输<FECy/{TA}PSC1>或<FECy/{TA}PSC2>本身，并且不会有任何E-LSP传输<FECz/{TA}PSC1>和/或<FECz/{TA}PSC2>和<FECz/{TA}PSC3>）。
As discussed in section 2.2, the DS-TE solution MAY support adjustment of Diff-Serv PHBs parameters (e.g., queue bandwidth) based on the amount of TE-LSPs established for each OA/Class-Type. Such dynamic adjustment is optional for DS-TE implementations.
如第2.2节所述，DS-TE解决方案可支持根据为每种OA/类别类型建立的TE LSP数量调整区分服务PHB参数（例如，队列带宽）。这种动态调整对于DS-TE实现是可选的。
Where this dynamic adjustment is supported, it MUST allow for disabling via configuration (thus reverting to PHB treatment with static scheduler configuration independent of DS-TE operations). It MAY involve a number of configurable parameters which are outside the scope of this specification. Those MAY include configurable parameters controlling how scheduling resources (e.g., service rates) need to be apportioned across multiple OAs when those belong to the same Class-Type and are transported together on the same E-LSP.
在支持此动态调整的情况下，它必须允许通过配置禁用（从而恢复到PHB处理，使用独立于DS-TE操作的静态调度程序配置）。它可能涉及本规范范围之外的许多可配置参数。这些可能包括可配置参数，控制当调度资源（例如，服务费率）属于同一类类型且在同一e-LSP上一起传输时，需要如何在多个oa之间分配调度资源。
Where supported, the dynamic adjustment MUST take account of the performance requirements of each PDB when computing required adjustments.
在支持的情况下，在计算所需调整时，动态调整必须考虑每个PDB的性能要求。
Existing TE mechanisms allow overbooking to be applied on LSPs for Constraint Based Routing and admission control. Historically, this has been achieved in TE deployment through factoring overbooking ratios at the time of sizing the LSP bandwidth and/or at the time of configuring the Maximum Reservable Bandwidth on links.
现有的TE机制允许在LSP上应用超售，以实现基于约束的路由和准入控制。从历史上看，这是在TE部署中通过在调整LSP带宽和/或在配置链路上的最大可保留带宽时考虑超售率实现的。
The DS-TE solution MUST also allow overbooking and MUST effectively allow different overbooking ratios to be enforced for different CTs.
DS-TE解决方案还必须允许超售，并且必须有效地允许针对不同CT实施不同的超售比率。
The DS-TE solution SHOULD optionally allow the effective overbooking ratio of a given CT to be tweaked differently in different parts of the network.
DS-TE解决方案应允许在网络的不同部分对给定CT的有效超售比率进行不同调整。
With existing TE, restoration policies use standard priority mechanisms such as, for example, the preemption priority to effectively control the order/importance of LSPs for restoration purposes.
对于现有TE，恢复策略使用标准优先级机制（例如，抢占优先级）来有效控制LSP的顺序/重要性，以便进行恢复。
The DS-TE solution MUST ensure that similar application of the use of standard priority mechanisms for implementation of restoration policy are not prevented since those are expected to be required for achieving the survivability requirements of DS-TE networks.
DS-TE解决方案必须确保不会阻止使用标准优先级机制来实施恢复策略的类似应用，因为实现DS-TE网络的生存性要求需要这些机制。
Further discussion of restoration requirements are presented in the output document of the TEWG Requirements Design Team [SURVIV-REQ].
TEWG需求设计团队的输出文件[SURVI-REQ]中介绍了恢复需求的进一步讨论。
A range of solutions is possible for the support of the DS-TE requirements discussed above. For example, some solutions may require that all current TE protocols syntax (IGP, RSVP-TE,) be
一系列解决方案可用于支持上述DS-TE要求。例如，一些解决方案可能要求所有当前的TE协议语法（IGP、RSVP-TE等）都是
extended in various ways. For instance, current TE protocols could be modified to support multiple bandwidth constraints rather than the existing single aggregate bandwidth constraint. Alternatively, other solutions may keep the existing TE protocols syntax unchanged but modify their semantics to allow for the multiple bandwidth constraints.
以各种方式扩展。例如，可以修改当前的TE协议以支持多个带宽约束，而不是现有的单个聚合带宽约束。或者，其他解决方案可以保持现有TE协议语法不变，但修改其语义以允许多个带宽约束。
This section identifies the evaluation criteria that MUST be used to assess potential DS-TE solutions for selection.
本节确定了必须用于评估潜在DS-TE解决方案以供选择的评估标准。
The solution MUST address all the scenarios described in section 2 and satisfy all the requirements listed in section 3.
解决方案必须解决第2节中描述的所有场景，并满足第3节中列出的所有要求。
- number of Class-Types that can be supported, compared to number identified in Requirements section - number of PDBs within a Class-Type
- 可支持的类类型的数量，与“需求”部分“类类型中的PDB数量”中确定的数量相比
- how far can the solution be extended in the future if requirements for more Class-Types are identified in the future.
- 如果将来确定了对更多类类型的需求，那么解决方案在将来可以扩展到什么程度。
- impact on network scalability in what is propagated, processed, stored and computed (IGP signaling, IGP processing, IGP database, TE-Tunnel signaling ,...). - how does scalability impact evolve with number of Class-Types/PDBs actually deployed in a network. In particular, is it possible to keep overhead small for a large networks which only use a small number of Class-Types/PDBs, while allowing higher number of Class-Types/PDBs in smaller networks which can bear higher overhead)
- 传播、处理、存储和计算内容对网络可扩展性的影响（IGP信令、IGP处理、IGP数据库、TE隧道信令等）可伸缩性如何影响实际部署在网络中的类类型/PDB的数量。特别是，对于仅使用少量类类型/PDB的大型网络，是否可以保持较小的开销，同时在可承受较高开销的小型网络中允许较高数量的类类型/PDB）
- backward compatibility/migration with/from existing TE mechanisms - backward compatibility/migration when increasing/decreasing the number of Class-Types actually deployed in a given network.
- 与现有TE机制的向后兼容性/迁移-增加/减少给定网络中实际部署的类类型数量时的向后兼容性/迁移。
Work is currently in progress to investigate the performance and trade-offs of different operational aspects of Bandwidth Constraints models (for example see [BC-MODEL], [BC-CONS] and [MAR]). In this investigation, at least the following criteria are expected to be considered:
目前正在开展工作，以调查带宽约束模型（例如，见[BC-MODEL]、[BC-CONS]和[MAR]）不同操作方面的性能和权衡。在本次调查中，至少应考虑以下标准：
(1) addresses the scenarios in Section 2 (2) works well under both normal and overload conditions (3) applies equally when preemption is either enabled or disabled (4) minimizes signaling load processing requirements (5) maximizes efficient use of the network (6) Minimizes implementation and deployment complexity.
(1) 解决第2（2）节中的场景在正常和过载条件下都能很好地工作（3）在启用或禁用抢占时同样适用（4）最小化信令负载处理要求（5）最大化网络的有效使用（6）最小化实现和部署复杂性。
In selection criteria (2), "normal condition" means that the network is attempting to establish a volume of DS-TE LSPs for which it is designed; "overload condition" means that the network is attempting to establish a volume of DS-TE LSPs beyond the one it is designed for; "works well" means that under these conditions, the network should be able to sustain the expected performance, e.g., under overload it is x times worse than its normal performance.
在选择标准（2）中，“正常条件”是指网络正试图建立其设计的DS-TE LSP卷；“过载条件”指网络试图建立超出其设计容量的DS-TE LSP容量；“运行良好”是指在这些条件下，网络应能够维持预期性能，例如，在过载情况下，其性能比正常性能差x倍。
The solution developed to address the DS-TE requirements defined in this document MUST address security aspects. DS-TE does not raise any specific additional security requirements beyond the existing security requirements of MPLS TE and Diff-Serv. The solution MUST ensure that the existing security mechanisms (including those protecting against DOS attacks) of MPLS TE and Diff-Serv are not compromised by the protocol/procedure extensions of the DS-TE solution or otherwise MUST provide security mechanisms to address this.
为满足本文件中定义的DS-TE要求而开发的解决方案必须满足安全方面的要求。除了MPLS TE和Diff Serv的现有安全要求外，DS-TE没有提出任何特定的额外安全要求。解决方案必须确保MPLS TE和Diff Serv的现有安全机制（包括防止DOS攻击的机制）不受DS-TE解决方案的协议/过程扩展的影响，或者必须提供安全机制来解决此问题。
We thank David Allen for his help in aligning with up-to-date Diff-Serv terminology.
我们感谢David Allen帮助我们使用最新的Diff-Serv术语。
[AF] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[AF]Heinanen，J.，Baker，F.，Weiss，W.和J.Wroclawski，“保证货运PHB集团”，RFC 25971999年6月。
[DIFF-ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[DIFF-ARCH]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[DIFF-FIELD] 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.
[DIFF-FIELD]Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6标头中区分服务字段（DS字段）的定义”，RFC 24741998年12月。
[MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS-ARCH]Rosen，E.，Viswanathan，A.和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[DIFF-MPLS] 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.
[DIFF-MPLS]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[DIFF-NEW] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[DIFF-NEW]Grossman，D.，“Diffserv的新术语和澄清”，RFC3260，2002年4月。
[EF] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J.Y., Davari, S., Courtney, W., Firioiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[EF]Davie，B.，Charny，A.，Bennet，J.C.R.，Benson，K.，Le Boudec，J.Y.，Davari，S.，Courtney，W.，Firioiu，V.和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[TEWG-FW] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I. and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.
[TEWG-FW]Awduche，D.，Chiu，A.，Elwalid，A.，Widjaja，I.和X.Xiao，“互联网流量工程概述和原则”，RFC 3272，2002年5月。
[TE-REQ] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, September 1999.
[TE-REQ]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[DIFF-PDB] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[DIFF-PDB]Nichols，K.和B.Carpenter，“每个域的区分服务行为定义及其规范规则”，RFC 3086，2001年4月。
[ISIS-TE] Smit, Li, "IS-IS extensions for Traffic Engineering", Work in Progress, December 2002.
[ISIS-TE]Smit，Li，“交通工程的IS-IS扩展”，正在进行的工作，2002年12月。
[OSPF-TE] Katz, et al., "Traffic Engineering Extensions to OSPF", Work in Progress, October 2002.
[OSPF-TE]Katz等人，“OSPF的交通工程扩展”，正在进行的工作，2002年10月。
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RSVP-TE]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[SURVIV-REQ] Lai, W. and D. McDysan, "Network Hierarchy and Multilayer Survivability", RFC 3386, November 2002.
[SURVIV-REQ]Lai，W.和D.McDysan，“网络层次结构和多层生存能力”，RFC 3386，2002年11月。
[BC-MODEL] Lai, W., "Bandwidth Constraints Models for Diffserv-aware MPLS Traffic Engineering: Performance Evaluation", Work in Progress, June 2002.
[BC-MODEL]Lai，W.“区分服务感知MPLS流量工程的带宽约束模型：性能评估”，正在进行的工作，2002年6月。
[BC-CONS] F. Le Faucheur, "Considerations on Bandwidth Constraints Models for DS-TE", Work in Progress, June 2002.
[BC-CONS]F.Le Faucheur，“DS-TE带宽约束模型的考虑”，正在进行的工作，2002年6月。
[MAR] Ash, J., "Max Allocation with Reservation Bandwidth Constraint Model for MPLS/DiffServ TE & Performance Comparisons", Work in Progress, May 2003.
[MAR]Ash，J.，“MPLS/DiffServ TE的最大带宽限制分配模型和性能比较”，正在进行的工作，2003年5月。
This document was the collective work of several people. The text and content of this document was contributed by the editors and the co-authors listed below. (The contact information for the editors appears below.)
这份文件是几个人的集体工作。本文件的文本和内容由以下列出的编辑和合著者提供。（编辑的联系信息如下所示。）
Martin Tatham Thomas Telkamp
BT Global Crossing
Adastral Park, Martlesham Heath, Oudkerkhof 51, 3512 GJ Utrecht
Ipswich IP5 3RE, UK The Netherlands
Phone: +44-1473-606349 Phone: +31 30 238 1250
EMail: martin.tatham@bt.com EMail: telkamp@gblx.net
Martin Tatham Thomas Telkamp
BT Global Crossing
Adastral Park, Martlesham Heath, Oudkerkhof 51, 3512 GJ Utrecht
Ipswich IP5 3RE, UK The Netherlands
Phone: +44-1473-606349 Phone: +31 30 238 1250
EMail: martin.tatham@bt.com EMail: telkamp@gblx.net
David Cooper Jim Boyle Global Crossing Protocol Driven Networks, Inc. 960 Hamlin Court 1381 Kildaire Farm Road #288 Sunnyvale, CA 94089, USA Cary, NC 27511, USA Phone: (916) 415-0437 Phone: (919) 852-5160 EMail: dcooper@gblx.net EMail: jboyle@pdnets.com
David Cooper Jim Boyle Global Crossing Protocol Driven Networks，Inc.960 Hamlin Court 1381 Kildaire Farm Road#288 Sunnyvale，CA 94089，美国加里，北卡罗来纳州27511电话：（916）415-0437电话：（919）852-5160电子邮件：dcooper@gblx.net电邮：jboyle@pdnets.com
Luyuan Fang Gerald R. Ash AT&T Labs AT&T Labs 200 Laurel Avenue 200 Laurel Avenue Middletown, New Jersey 07748, USA Middletown, New Jersey 07748,USA Phone: (732) 420-1921 Phone: (732) 420-4578 EMail: luyuanfang@att.com EMail: gash@att.com
美国新泽西州劳雷尔大道200号劳雷尔大道中城，美国新泽西州中城，美国电话：（732）420-1921电话：（732）420-4578电子邮件：luyuanfang@att.com电邮：gash@att.com
Pete Hicks Angela Chiu CoreExpress, Inc AT&T Labs-Research 12655 Olive Blvd, Suite 500 200 Laurel Ave. Rm A5-1F13 St. Louis, MO 63141, USA Middletown, NJ 07748, USA Phone: (314) 317-7504 Phone: (732) 420-9061 EMail: pete.hicks@coreexpress.net EMail: chiu@research.att.com
Pete Hicks Angela Chiu CoreExpress，Inc.AT&T实验室研究12655 Olive Blvd，500室，美国密苏里州圣路易斯劳雷尔大道200号A5-1F13室，邮编63141，美国新泽西州米德尔顿07748电话：（314）317-7504电话：（732）420-9061电子邮件：Pete。hicks@coreexpress.net电邮：chiu@research.att.com
William Townsend Thomas D. Nadeau
Tenor Networks Cisco Systems, Inc.
100 Nagog Park 300 Beaver Brook Road
Acton, MA 01720, USA Boxborough, MA 01719
Phone: +1 978-264-4900 Phone: +1-978-936-1470
EMail:btownsend@tenornetworks.com EMail: tnadeau@cisco.com
William Townsend Thomas D. Nadeau
Tenor Networks Cisco Systems, Inc.
100 Nagog Park 300 Beaver Brook Road
Acton, MA 01720, USA Boxborough, MA 01719
Phone: +1 978-264-4900 Phone: +1-978-936-1470
EMail:btownsend@tenornetworks.com EMail: tnadeau@cisco.com
Darek Skalecki Nortel Networks 3500 Carling Ave, Nepean K2H 8E9, Phone: (613) 765-2252 EMail: dareks@nortelnetworks.com
Darek Skalecki Nortel Networks尼泊尔卡林大道3500号K2H 8E9，电话：（613）765-2252电子邮件：dareks@nortelnetworks.com
Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis, France
Francois Le Faucheur Cisco Systems，Inc.绿边企业村-法国索菲亚安提波利斯大街T3400号巴蒂门特酒店
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Wai Sum Lai AT&T Labs 200 Laurel Avenue Middletown, New Jersey 07748, USA
美国新泽西州劳雷尔大道中城200号惠森丽AT&T实验室，邮编：07748
Phone: (732) 420-3712 EMail: wlai@att.com
电话：（732）420-3712电子邮件：wlai@att.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。