Network Working Group F. Le Faucheur, Ed.
Request for Comments: 4127 Cisco Systems, Inc.
Category: Experimental June 2005
Network Working Group F. Le Faucheur, Ed.
Request for Comments: 4127 Cisco Systems, Inc.
Category: Experimental June 2005
Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering
区分服务感知MPLS流量工程的俄罗斯Dolls带宽约束模型
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model.
本文档提供了区分服务感知MPLS流量工程的一种带宽约束模型的规范，称为俄罗斯Dolls模型。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. Contributing Authors ............................................3
3. Definitions .....................................................4
4. Russian Dolls Model Definition ..................................5
5. Example Formulas for Computing "Unreserved TE-Class [i]" with
Russian Dolls Model .............................................7
6. Receiving Both Maximum Reservable Bandwidth and Bandwidth
Constraints sub-TLVs ............................................8
7. Security Considerations .........................................8
8. IANA Considerations .............................................8
9. Acknowledgements ................................................9
Appendix A: Addressing [DSTE-REQ] Scenarios .......................10
Normative References ..............................................11
Informative References ............................................12
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. Contributing Authors ............................................3
3. Definitions .....................................................4
4. Russian Dolls Model Definition ..................................5
5. Example Formulas for Computing "Unreserved TE-Class [i]" with
Russian Dolls Model .............................................7
6. Receiving Both Maximum Reservable Bandwidth and Bandwidth
Constraints sub-TLVs ............................................8
7. Security Considerations .........................................8
8. IANA Considerations .............................................8
9. Acknowledgements ................................................9
Appendix A: Addressing [DSTE-REQ] Scenarios .......................10
Normative References ..............................................11
Informative References ............................................12
[DSTE-REQ] presents the Service Providers requirements for support of Diffserv-aware MPLS Traffic Engineering (DS-TE). This includes the fundamental requirement to be able to enforce different Bandwidth Constraints for different classes of traffic.
[DSTE-REQ]介绍了服务提供商对支持区分服务的MPLS流量工程（DS-TE）的要求。这包括能够针对不同类别的流量实施不同带宽约束的基本要求。
[DSTE-REQ] also defines the concept of Bandwidth Constraints Model for DS-TE and states that "The DS-TE technical solution MUST specify at least one Bandwidth Constraints Model and MAY specify multiple Bandwidth Constraints Models".
[DSTE-REQ]还定义了DS-TE带宽约束模型的概念，并指出“DS-TE技术解决方案必须指定至少一个带宽约束模型，并且可以指定多个带宽约束模型”。
This document provides a detailed description of one particular Bandwidth Constraints Model for DS-TE which is introduced in [DSTE-REQ] and called the Russian Dolls Model (RDM).
本文件详细描述了[DSTE-REQ]中介绍的DS-TE的一种特定带宽约束模型，称为俄罗斯玩偶模型（RDM）。
[DSTE-PROTO] specifies the Interior Gateway Protocol (IGP) and RSVP-TE signaling extensions for support of DS-TE. These extensions support RDM.
[DSTE-PROTO]指定内部网关协议（IGP）和RSVP-TE信令扩展以支持DS-TE。这些扩展支持RDM。
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]中所述进行解释。
This document was the collective work of several authors. The text and content were contributed by the editor and the co-authors listed below. (The contact information for the editor appears in the Editor's Address section.)
这份文件是几位作者的集体作品。文本和内容由编辑和下面列出的合著者提供。（编辑的联系信息显示在编辑地址部分。）
Jim Boyle Kireeti Kompella Protocol Driven Networks, Inc. Juniper Networks, Inc. 1381 Kildaire Farm Road #288 1194 N. Mathilda Ave. Cary, NC 27511, USA Sunnyvale, CA 94099
Jim Boyle Kireeti Kompella Protocol Driven Networks，Inc.Juniper Networks，Inc.基尔代尔农场路1381号#288 1194 N.马蒂尔达大道卡里，北卡罗来纳州27511号，美国加利福尼亚州桑尼维尔94099
Phone: (919) 852-5160 EMail: kireeti@juniper.net
EMail: jboyle@pdnets.com
Phone: (919) 852-5160 EMail: kireeti@juniper.net
EMail: jboyle@pdnets.com
William Townsend Thomas D. Nadeau Tenor Networks Cisco Systems, Inc. 100 Nagog Park 250 Apollo Drive Acton, MA 01720 Chelmsford, MA 01824
William Townsend Thomas D.Nadeau Tenor Networks Cisco Systems，Inc.马萨诸塞州切尔姆斯福德阿波罗大道阿克顿100号Nagog公园邮编01720邮编01824
Phone: +1-978-264-4900 Phone: +1-978-244-3051
EMail: btownsend@tenornetworks.com EMail: tnadeau@cisco.com
Phone: +1-978-264-4900 Phone: +1-978-244-3051
EMail: btownsend@tenornetworks.com EMail: tnadeau@cisco.com
Darek Skalecki Nortel Networks 3500 Carling Ave, Nepean K2H 8E9
尼泊尔卡林大道3500号Darek Skalecki Nortel Networks K2H 8E9
Phone: +1-613-765-2252
EMail: dareks@nortelnetworks.com
Phone: +1-613-765-2252
EMail: dareks@nortelnetworks.com
For readability a number of definitions from [DSTE-REQ] are repeated here:
为便于阅读，此处重复[DSTE-REQ]中的许多定义：
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。
TE-Class: A pair of:
TE类：一对：
i. a Class-Type
i. 班级类型
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 setup priority, the holding priority, or both.
二、该类类型允许的抢占优先级。这意味着从该类类型传输业务中继的LSP可以使用该抢占优先级作为设置优先级、保持优先级或两者。
A number of recovery mechanisms under investigation or specification in the IETF take advantage of the concept of bandwidth sharing across particular sets of LSPs. "Shared Mesh Restoration" in [GMPLS-RECOV] and "Facility-based Computation Model" in [MPLS-BACKUP] are example mechanisms that increase bandwidth efficiency by sharing bandwidth across backup LSPs protecting against independent failures. To ensure that the notion of "Reserved (CTc)" introduced in [DSTE-REQ] is compatible with such a concept of bandwidth sharing across multiple LSPs, the wording of the "Reserved (CTc)" definition provided in [DSTE-REQ] is generalized into the following:
IETF中正在研究或规范的许多恢复机制利用了跨特定LSP组共享带宽的概念。[GMPLS-RECOV]中的“共享网格恢复”和[MPLS-BACKUP]中的“基于设施的计算模型”是通过在备份LSP之间共享带宽以防止独立故障而提高带宽效率的示例机制。为确保[DSTE-REQ]中引入的“保留（CTc）”概念与跨多个LSP共享带宽的概念兼容，[DSTE-REQ]中提供的“保留（CTc）”定义的措辞概括如下：
Reserved (CTc): For a given Class-Type CTc ( 0 <= c <= MaxCT ), let us define "Reserved(CTc)" as the total amount of the bandwidth reserved by all the established LSPs which belong to CTc.
保留（CTc）：对于给定的类类型CTc（0<=c<=MaxCT），让我们将“保留（CTc）”定义为属于CTc的所有已建立LSP保留的带宽总量。
With this generalization, the Russian Dolls Model definition provided in this document is compatible with Shared Mesh Restoration defined in [GMPLS-RECOV], so that DS-TE and Shared Mesh Protection can operate simultaneously. This assumes that Shared Mesh Restoration operates independently within each DS-TE Class-Type and does not operate across Class-Types (for example, backup LSPs protecting Primary LSPs of CTx also need to belong to CTx; Excess Traffic LSPs sharing bandwidth with Backup LSPs of CTx also need to belong to CTx).
通过这种推广，本文中提供的俄罗斯玩偶模型定义与[GMPLS-RECOV]中定义的共享网格恢复兼容，因此DS-TE和共享网格保护可以同时运行。这假设共享网格恢复在每个DS-TE类类型内独立运行，并且不跨类类型运行（例如，保护CTx主LSP的备份LSP也需要属于CTx；与CTx备份LSP共享带宽的多余流量LSP也需要属于CTx）。
We also introduce the following definition:
我们还介绍了以下定义：
Reserved(CTb,q): Let us define "Reserved(CTb,q)" as the total amount of the bandwidth reserved by all the established LSPs that belong to CTb and have a holding priority of q. Note that if q and CTb do not form one of the 8 possible configured TE-Classes, then there cannot be any established LSPs that belongs to CTb and has a holding priority of q; therefore, in this case, Reserved(CTb,q) = 0.
Reserved（CTb，q）：让我们定义“Reserved（CTb，q）”为属于CTb且保持优先级为q的所有已建立lsp保留的带宽总量。注意，如果q和CTb不构成8个可能配置的TE类中的一个，则不存在属于CTb且持有优先级为q的任何已建立LSP；因此，在这种情况下，保留（CTb，q）=0。
RDM is defined in the following manner:
RDM的定义方式如下：
o Maximum Number of Bandwidth Constraints (MaxBC)= Maximum Number of Class-Types (MaxCT) = 8
o 带宽限制的最大数量（MaxBC）=类类型的最大数量（MaxCT）=8
o for each value of b in the range 0 <= b <= (MaxCT - 1): SUM (Reserved (CTc)) <= BCb, where the SUM is across all values of c in the range b <= c <= (MaxCT - 1)
o 对于范围0<=b<=（MaxCT-1）中的每一个b值：SUM（Reserved（CTc））<=BCb，其中该和跨越范围b<=c<=（MaxCT-1）中的所有c值
o BC0= Maximum Reservable Bandwidth, so that SUM (Reserved(CTc)) <= Max-Reservable-Bw, where the SUM is across all values of c in the range 0 <= c <= (MaxCT - 1)
o BC0=最大可保留带宽，因此SUM（Reserved（CTc））<=最大可保留带宽，其中SUM跨越范围0<=c<=（MaxCT-1）内的所有c值
A DS-TE LSR implementing RDM MUST support enforcement of Bandwidth Constraints in compliance with this definition.
实现RDM的DS-TE LSR必须支持按照此定义实施带宽约束。
Both preemption within a CT and across CTs is allowed.
允许在CT内和跨CT抢占。
Where 8 CTs are active, the RDM Bandwidth Constraints can also be expressed in the following way:
当8个CT处于活动状态时，RDM带宽约束也可以用以下方式表示：
- All LSPs from CT7 use no more than BC7
- CT7的所有LSP使用不超过BC7
- All LSPs from CT6 and CT7 use no more than BC6
- 来自CT6和CT7的所有LSP使用不超过BC6
- All LSPs from CT5, CT6 and CT7 use no more than BC5
- CT5、CT6和CT7的所有LSP使用不超过BC5
- etc.
- 等
- All LSPs from CT0, CT1, ..., CT7 use no more than BC0 = "Maximum Reservable Bandwidth"
- 来自CT0、CT1、…、CT7的所有LSP使用的带宽不超过BC0=“最大可保留带宽”
Purely for illustration purposes, the diagram below represents the Russian Dolls Bandwidth Constraints Model in a pictorial manner when 3 Class-Types are active:
纯粹出于说明目的，下图以图形方式表示俄罗斯玩偶带宽约束模型，其中有3种类别处于活动状态：
I------------------------------------------------------I
I-------------------------------I I
I--------------I I I
I CT2 I CT2+CT1 I CT2+CT1+CT0 I
I--------------I I I
I-------------------------------I I
I------------------------------------------------------I
I------------------------------------------------------I
I-------------------------------I I
I--------------I I I
I CT2 I CT2+CT1 I CT2+CT1+CT0 I
I--------------I I I
I-------------------------------I I
I------------------------------------------------------I
I-----BC2------>
I----------------------BC1------>
I------------------------------BC0=Max Reservable Bw--->
I-----BC2------>
I----------------------BC1------>
I------------------------------BC0=Max Reservable Bw--->
While simpler Bandwidth Constraints models or, conversely, more flexible/sophisticated Bandwidth Constraints models can be defined, the Russian Dolls Model is attractive in some DS-TE environments for the following reasons:
虽然可以定义更简单的带宽约束模型，或者相反，可以定义更灵活/复杂的带宽约束模型，但俄罗斯娃娃模型在某些DS-TE环境中具有吸引力，原因如下：
- Although it is a little less intuitive than the Maximum Allocation Model (see [DSTE-MAM]), RDM is still a simple model to conceptualize.
- 尽管RDM比最大分配模型（见[DSTE-MAM]）直观一些，但它仍然是一个简单的概念化模型。
- RDM can be used simultaneously to ensure bandwidth efficiency and to protect against QoS degradation of all CTs, whether preemption is used or not.
- 无论是否使用抢占，RDM都可以同时用于确保带宽效率和防止所有CT的QoS降低。
- RDM can be used in conjunction with preemption to simultaneously achieve (i) isolation across CTs (so that each CT is guaranteed its share of bandwidth no matter the level of contention by other classes), (ii) bandwidth efficiency, and (iii) protection against QoS degradation of all CTs.
- RDM可与抢占结合使用，以同时实现（i）跨CT的隔离（从而保证每个CT的带宽份额，无论其他类别的争用程度如何），（ii）带宽效率，以及（iii）防止所有CT的QoS降级。
- RDM only requires limited protocol extensions such as the ones defined in [DSTE-PROTO].
- RDM只需要有限的协议扩展，如[DSTE-PROTO]中定义的扩展。
RDM may not be attractive in some DS-TE environments for the following reasons:
RDM在某些DS-TE环境中可能没有吸引力，原因如下：
- if the usage of preemption is precluded for some administrative reason, while RDM can still ensure bandwidth efficiency and protection against QoS degradation of all CTs, RDM cannot guarantee isolation across Class-Types.
- 如果由于某些管理原因禁止使用抢占，而RDM仍然可以确保带宽效率并防止所有CT的QoS降级，RDM无法保证跨类类型的隔离。
Additional considerations on the properties of RDM can be found in [BC-CONS] and [BC-MODEL].
关于RDM属性的其他注意事项可在[BC-CONS]和[BC-MODEL]中找到。
As a simple example usage of the "Russian Dolls" Bandwidth Constraints Model, a network administrator, using one CT for Voice (CT1) and one CT for data (CT0), might configure on a given link:
作为“俄罗斯玩偶”带宽限制模型的一个简单示例，网络管理员使用一个CT代表语音（CT1）和一个CT代表数据（CT0），可以在给定的链路上配置：
- BC0 = Max-Reservable - Bw = 2.5 Gb/s (i.e., Voice + Data is limited to 2.5 Gb/s)
- BC0=最大可预约-Bw=2.5 Gb/s（即语音+数据限制为2.5 Gb/s）
- BC1 = 1.5 Gb/s (i.e., Voice is limited to 1.5 Gb/s).
- BC1=1.5 Gb/s（即，语音限制为1.5 Gb/s）。
5. Example Formulas for Computing "Unreserved TE-Class [i]" with Russian Dolls Model
5. 使用俄罗斯玩偶模型计算“无保留TE类[i]”的示例公式
As specified in [DSTE-PROTO], formulas for computing "Unreserved TE-Class [i]" MUST reflect all of the Bandwidth Constraints relevant to the CT associated with TE-Class[i], and thus, depend on the Bandwidth Constraints Model. Thus, a DS-TE LSR implementing RDM MUST reflect the RDM Bandwidth Constraints defined in section 4 above when computing "Unreserved TE-Class [i]".
如[DSTE-PROTO]中所述，计算“无保留TE类[i]”的公式必须反映与TE类[i]相关的CT相关的所有带宽约束，因此取决于带宽约束模型。因此，在计算“无保留TE类[i]”时，实现RDM的DS-TE LSR必须反映上文第4节中定义的RDM带宽约束。
As explained in [DSTE-PROTO], the details of admission control algorithms, as well as formulas for computing "Unreserved TE-Class [i]", are outside the scope of the IETF work. Keeping that in mind, we provide in this section an example for illustration purposes, of how values for the unreserved bandwidth for TE-Class[i] might be computed with RDM. In the example, we assume the basic admission control algorithm, which simply deducts the exact bandwidth of any established LSP from all of the Bandwidth Constraints relevant to the CT associated with that LSP.
如[DSTE-PROTO]所述，准入控制算法的细节以及计算“无保留TE类[i]”的公式不在IETF工作范围内。记住这一点，我们在本节中提供了一个示例，用于说明如何使用RDM计算TE类[i]的无保留带宽值。在该示例中，我们假设基本接纳控制算法，该算法简单地从与该LSP相关联的CT的所有带宽约束中推导出任何已建立LSP的确切带宽。
We assume that:
我们假设：
TE-Class [i] <--> < CTc , preemption p>
TE-Class [i] <--> < CTc , preemption p>
in the configured TE-Class mapping.
在配置的TE类映射中。
For readability, formulas are first shown assuming only 3 CTs are active. The formulas are then extended to cover the cases where more CTs are used.
为了便于阅读，首先显示公式时假设只有3个CT处于活动状态。然后对公式进行扩展，以涵盖使用更多CT的情况。
If CTc = CT0, then "Unreserved TE-Class [i]" =
[ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2
If CTc = CT0, then "Unreserved TE-Class [i]" =
[ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2
If CTc = CT1, then "Unreserved TE-Class [i]" =
MIN [
[ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 2,
[ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2
]
If CTc = CT1, then "Unreserved TE-Class [i]" =
MIN [
[ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 2,
[ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2
]
If CTc = CT2, then "Unreserved TE-Class [i]" =
MIN [
[ BC2 - SUM ( Reserved(CTb,q) ) ] for q <= p and 2 <= b <= 2,
[ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 2,
[ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2
]
If CTc = CT2, then "Unreserved TE-Class [i]" =
MIN [
[ BC2 - SUM ( Reserved(CTb,q) ) ] for q <= p and 2 <= b <= 2,
[ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 2,
[ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2
]
The formula can be generalized to 8 active CTs and expressed in a more compact way in the following:
该公式可推广到8个有源CT，并以更紧凑的方式表示如下：
"Unreserved TE-Class [i]" =
MIN [
[ BCc - SUM ( Reserved(CTb,q) ) ] for q <= p and c <= b <= 7,
[ BC(c-1) - SUM ( Reserved(CTb,q) ) ] for q <= p and (c-1)<= b <= 7,
. . .
[ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 7,
]
"Unreserved TE-Class [i]" =
MIN [
[ BCc - SUM ( Reserved(CTb,q) ) ] for q <= p and c <= b <= 7,
[ BC(c-1) - SUM ( Reserved(CTb,q) ) ] for q <= p and (c-1)<= b <= 7,
. . .
[ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 7,
]
where:
哪里：
TE-Class [i] <--> < CTc , preemption p> in the configured TE-Class mapping.
配置的TE类映射中的TE类[i]<--><CTc，抢占p>。
6. Receiving Both Maximum Reservable Bandwidth and Bandwidth Constraints sub-TLVs
6. 接收最大可保留带宽和带宽约束子TLV
[DSTE-PROTO] states that "A DS-TE LSR, which does advertise BCs, MUST use the new "Bandwidth Constraints" sub-TLV (in addition to the existing Maximum Reservable Bandwidth sub-TLV) to do so."
[DSTE-PROTO]声明“不播发BCs的DS-TE LSR必须使用新的“带宽约束”子TLV（除了现有的最大可保留带宽子TLV）来执行此操作。”
With RDM, BC0 is equal to the Maximum Reservable Bandwidth because they both represent the aggregate constraint across all CTs. Thus, a DS-TE LSR, receiving both the "Maximum Reservable Bw" sub-TLV and the new "Bandwidth Constraints" sub-TLV (which contains BC0) for a given link where the RDM model is used, MAY ignore the "Maximum Reservable Bw" sub-TLV.
对于RDM，BC0等于最大可保留带宽，因为它们都表示所有CT的聚合约束。因此，对于使用RDM模型的给定链路，接收“最大可保留Bw”子TLV和新的“带宽约束”子TLV（包含BC0）的DS-TE LSR可以忽略“最大可保留Bw”子TLV。
Security considerations related to the use of DS-TE are discussed in [DSTE-PROTO]. Those apply independently of the Bandwidth Constraints Model, including RDM specified in this document.
[DSTE-PROTO]中讨论了与使用DS-TE相关的安全注意事项。这些应用独立于带宽约束模型，包括本文档中指定的RDM。
[DSTE-PROTO] defines a new name space for "Bandwidth Constraints Model Id". The guidelines for allocation of values in that name space are detailed in section 13.1 of [DSTE-PROTO]. In accordance
[DSTE-PROTO]为“带宽约束模型Id”定义了一个新的名称空间。[DSTE-PROTO]第13.1节详细介绍了该名称空间中的值分配指南。依照
with these guidelines, the IANA has assigned a Bandwidth Constraints Model Id for RDM from the range 0-239 (which is to be managed as per the "Specification Required" policy defined in [IANA-CONS]).
根据这些指南，IANA为RDM分配了一个范围为0-239的带宽约束模型Id（将根据[IANA-CONS]中定义的“所需规范”策略进行管理）。
Bandwidth Constraints Model Id 0 was allocated by IANA to RDM.
带宽限制模型Id 0由IANA分配给RDM。
We thank Martin Tatham for his key contribution in this work. Tatiana Renko is also warmly thanked for her instantiation of the Russian Doll.
我们感谢马丁·塔瑟姆在这项工作中作出的重要贡献。塔蒂亚娜·伦科（Tatiana Renko）还对她制作的俄罗斯玩偶表示热烈感谢。
Appendix A: Addressing [DSTE-REQ] Scenarios
附录A：寻址[DSTE-REQ]方案
This appendix provides examples of how the Russian Dolls Bandwidth Constraints Model can be used to support each of the scenarios described in [DSTE-REQ].
本附录提供了俄罗斯玩偶带宽约束模型如何用于支持[DSTE-REQ]中描述的每个场景的示例。
By configuring on every link:
通过在每个链接上配置：
- Bandwidth Constraint 1 (for CT1 = Voice) = "certain percentage" of link capacity
- 带宽限制1（对于CT1=语音）=链路容量的“特定百分比”
- BC0 (for CT1=Voice + CT0=Data) = link capacity
- BC0（对于CT1=语音+CT0=数据）=链路容量
By configuring:
通过配置：
- every CT1/Voice TE-LSP with preemption = 0
- 每个CT1/语音TE-LSP，抢占=0
- every CT0/Data TE-LSP with preemption = 1
- 每个CT0/数据TE-LSP，抢占=1
DS-TE with the Russian Dolls Model will address all the requirements:
带有俄罗斯玩偶模型的DS-TE将满足所有要求：
- amount of Voice traffic limited to desired percentage on every link
- 每个链路上限制在所需百分比的语音通信量
- data traffic capable of using all remaining link capacity
- 能够使用所有剩余链路容量的数据流量
- voice traffic capable of preempting other traffic
- 能够抢占其他流量的语音流量
By configuring on every link:
通过在每个链接上配置：
- BC2 (for CT2) = e.g., 45%
- BC2（对于CT2）=例如，45%
- BC1 (for CT1+CT2) = e.g., 80%
- BC1（对于CT1+CT2）=例如，80%
- BC0 (for CT0+CT1+CT2) = e.g., 100%
- BC0（对于CT0+CT1+CT2）=例如，100%
DS-TE with the RDM will ensure that the amount of traffic of each CT established on a link is within acceptable levels as compared to the resources allocated to the corresponding Diffserv Per Hop Behaviors (PHBs) regardless of which order the LSPs are routed in, regardless of which preemption priorities are used by which LSPs and regardless of failure situations.
具有RDM的DS-TE将确保在链路上建立的每个CT的通信量与分配给相应的区分服务每跳行为（PHB）的资源相比在可接受的水平内，无论LSP以何种顺序路由，无论哪个LSP使用哪个抢占优先级，也不管故障情况。
By also configuring:
通过配置：
- every CT2/Voice TE-LSP with preemption = 0
- 每个CT2/语音TE-LSP，抢占=0
- every CT1/Premium Data TE-LSP with preemption = 1
- 每个CT1/高级数据TE-LSP，抢占=1
- every CT0/Best-Effort TE-LSP with preemption = 2
- 每个CT0/最大努力TE-LSP，抢占=2
DS-TE with the Russian Dolls Model will also ensure that:
带有俄罗斯玩偶模型的DS-TE还将确保：
- CT2 Voice LSPs always have first preemption priority in order to use the CT2 capacity
- CT2语音LSP始终具有第一抢占优先级，以便使用CT2容量
- CT1 Premium Data LSPs always have second preemption priority in order to use the CT1 capacity
- CT1高级数据LSP始终具有第二抢占优先级，以便使用CT1容量
- Best-Effort can use up to link capacity of what is left by CT2 and CT1.
- 尽最大努力可使用CT2和CT1剩余的链路容量。
Optional automatic adjustment of Diffserv scheduling configuration could be used for maintaining very strict relationships between the amounts of established traffic of each Class Type and corresponding Diffserv resources.
Diffserv调度配置的可选自动调整可用于维护每种类别类型的已建立通信量与相应Diffserv资源之间的非常严格的关系。
By configuring on every link:
通过在每个链接上配置：
- BC1 (for CT1) = "given" percentage of link bandwidth (appropriate to achieve the Guaranteed Bandwidth service's QoS objectives)
- BC1（对于CT1）=“给定”链路带宽百分比（适用于实现保证带宽服务的QoS目标）
- BC0 (for CT0+CT1) = 100% of link bandwidth
- BC0（对于CT0+CT1）=链路带宽的100%
DS-TE with the Russian Dolls Model will ensure that the amount of Guaranteed Bandwidth Traffic established on every link remains below the given percentage so that it will always meet its QoS objectives. At the same time, it will allow traffic engineering of the rest of the traffic such that links can be filled up.
采用俄罗斯Dolls模型的DS-TE将确保每条链路上建立的保证带宽流量保持在给定百分比以下，以便始终满足其QoS目标。同时，它将允许对其余的流量进行流量工程，这样链接就可以被填满。
Normative References
规范性引用文件
[DSTE-REQ] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[DSTE-REQ]Le Faucheur，F.和W.Lai，“支持区分服务感知MPLS流量工程的要求”，RFC 3564，2003年7月。
[DSTE-PROTO] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[DSTE-PROTO]Le Faucheur，F.，编辑，“支持区分服务感知MPLS流量工程的协议扩展”，RFC 41242005年6月。
[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月。
[IANA-CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA-CONS]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
Informative References
资料性引用
[BC-CONS] Le Faucheur, F., "Considerations on Bandwidth Constraints Model for DS-TE", Work in Progress, June 2002.
[BC-CONS]Le Faucheur，F.，“DS-TE带宽约束模型的考虑”，正在进行的工作，2002年6月。
[BC-MODEL] Lai, W., "Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation", RFC 4128, June 2005.
[BC-MODEL]Lai，W.“区分服务（Diffserv）感知MPLS流量工程的带宽约束模型：性能评估”，RFC 41282005年6月。
[DSTE-MAM] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, June 2005.
[DSTE-MAM]Le Faucheur，F.和W.Lai，“区分服务感知MPLS流量工程的最大分配带宽约束模型”，RFC 41252005年6月。
[GMPLS-RECOV] Lang, et al., "Generalized MPLS Recovery Functional Specification", Work in Progress.
[GMPLS-RECOV]Lang等人，“通用MPLS恢复功能规范”，正在进行的工作。
[MPLS-BACKUP] Vasseur, et al., "MPLS Traffic Engineering Fast Reroute: Bypass Tunnel Path Computation for Bandwidth Protection", Work in Progress.
[MPLS-BACKUP]Vasseur等人，“MPLS流量工程快速重路由：用于带宽保护的旁路隧道路径计算”，正在进行中。
Editor's Address
编辑地址
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
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。