Network Working Group F. Le Faucheur
Request for Comments: 4125 Cisco Systems, Inc.
Category: Experimental W. Lai
AT&T Labs
June 2005
Network Working Group F. Le Faucheur
Request for Comments: 4125 Cisco Systems, Inc.
Category: Experimental W. Lai
AT&T Labs
June 2005
Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering
区分服务感知MPLS流量工程的最大分配带宽约束模型
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 Maximum Allocation Model.
本文档为区分服务感知MPLS流量工程的带宽约束模型提供了规范，称为最大分配模型。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. Definitions .....................................................2
3. Maximum Allocation Model Definition .............................3
4. Example Formulas for Computing "Unreserved TE-Class [i]" with
Maximum Allocation Model.........................................6
5. Security Considerations .........................................7
6. IANA Considerations .............................................7
7. Acknowledgements ................................................7
Appendix A: Addressing [DSTE-REQ] Scenarios.........................8
Normative References...............................................10
Informative References.............................................10
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. Definitions .....................................................2
3. Maximum Allocation Model Definition .............................3
4. Example Formulas for Computing "Unreserved TE-Class [i]" with
Maximum Allocation Model.........................................6
5. Security Considerations .........................................7
6. IANA Considerations .............................................7
7. Acknowledgements ................................................7
Appendix A: Addressing [DSTE-REQ] Scenarios.........................8
Normative References...............................................10
Informative References.............................................10
[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 Maximum Allocation Model (MAM).
本文件详细描述了DS-TE的一个特定带宽约束模型，该模型在[DSTE-REQ]中介绍，称为最大分配模型（MAM）。
[DSTE-PROTO] specifies the IGP and RSVP-TE signaling extensions for support of DS-TE. These extensions support MAM.
[DSTE-PROTO]指定支持DS-TE的IGP和RSVP-TE信令扩展。这些扩展支持MAM。
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]中所述进行解释。
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 set-up priority, as 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 Maximum Allocation 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。
MAM is defined in the following manner:
MAM的定义如下：
o Maximum Number of Bandwidth Constraints (MaxBC) = Maximum Number of Class-Types (MaxCT) = 8
o 带宽限制的最大数量（MaxBC）=类类型的最大数量（MaxCT）=8
o for each value of c in the range 0 <= c <= (MaxCT - 1): Reserved (CTc) <= BCc <= Max-Reservable-Bandwidth,
o 对于0<=c<=（MaxCT-1）范围内的每个c值：保留（CTc）<=BCc<=最大可保留带宽，
o SUM (Reserved(CTc)) <= Max-Reservable-Bandwidth where the SUM is across all values of c in the range 0 <= c <= (MaxCT - 1)
o 总和（保留（CTc））<=最大可保留带宽，其中总和跨越范围0<=c<=（MaxCT-1）内的所有c值
A DS-TE LSR implementing MAM MUST support enforcement of Bandwidth Constraints in compliance with this definition.
实现MAM的DS-TE LSR必须支持按照此定义实施带宽约束。
To increase the degree of bandwidth sharing among the different CTs, the sum of Bandwidth Constraints may exceed the Maximum Reservable Bandwidth, so that the following relationship may hold true:
为了增加不同ct之间的带宽共享程度，带宽约束的总和可能超过最大可保留带宽，因此以下关系可能成立：
o SUM (BCc) > Max-Reservable-Bandwidth, where the SUM is across all values of c in the range 0 <= c <= (MaxCT - 1)
o 求和（BCc）>最大可保留带宽，其中求和跨越范围0<=c<=（MaxCT-1）内的所有c值
The sum of Bandwidth Constraints may also be equal to (or below) the Maximum Reservable Bandwidth. In that case, the Maximum Reservable Bandwidth does not actually constrain CT bandwidth reservations (in other words, the 3rd bullet item of the MAM definition above will never effectively come into play). This is because the 2nd bullet item of the MAM definition above implies that:
带宽约束的总和也可以等于（或低于）最大可保留带宽。在这种情况下，最大可保留带宽实际上并不限制CT带宽保留（换句话说，上述MAM定义的第三个项目符号将永远不会有效发挥作用）。这是因为上述MAM定义的第二个项目符号表示：
SUM (reserved(CTc)) <= SUM (BCc)
SUM (reserved(CTc)) <= SUM (BCc)
and we assume here that
我们在这里假设
SUM (BCc) <= Maximum Reservable Bandwidth.
总和（BCc）<=最大可保留带宽。
Therefore, it will always be true that:
因此，以下情况始终是正确的：
SUM (Reserved(CTc)) <= Max-Reservable-Bandwidth.
总和（保留（CTc））<=最大可保留带宽。
Both preemption within a CT and across CTs is allowed.
允许在CT内和跨CT抢占。
Where 8 CTs are active, the MAM Bandwidth Constraints can also be expressed in the following way:
当8个CT处于活动状态时，MAM带宽约束也可以用以下方式表示：
- All LSPs from CT7 use no more than BC7
- CT7的所有LSP使用不超过BC7
- All LSPs from CT6 use no more than BC6
- CT6的所有LSP使用不超过BC6
- All LSPs from CT5 use no more than BC5
- CT5的所有LSP使用不超过BC5
- etc.
- 等
- All LSPs from CT0 use no more than BC0
- CT0中的所有LSP使用不超过BC0
- All LSPs from all CTs collectively use no more than the Maximum Reservable Bandwidth
- 所有CT的所有LSP共同使用的带宽不超过最大可保留带宽
Purely for illustration purposes, the diagram below represents MAM in a pictorial manner when 3 CTs are active:
仅出于说明目的，下图以图形方式表示3个CT激活时的MAM：
I----------------------------I
<---BC0---> I
I---------I I
I I I
I CT0 I I
I I I
I---------I I
I I
I I
<-------BC1-------> I
I-----------------I I
I I I
I CT1 I I
I I I
I-----------------I I
I I
I I
<-----BC2-----> I
I-------------I I
I I I
I CT2 I I
I I I
I-------------I I
I I
I CT0+CT1+CT2 I
I I
I----------------------------I
I----------------------------I
<---BC0---> I
I---------I I
I I I
I CT0 I I
I I I
I---------I I
I I
I I
<-------BC1-------> I
I-----------------I I
I I I
I CT1 I I
I I I
I-----------------I I
I I
I I
<-----BC2-----> I
I-------------I I
I I I
I CT2 I I
I I I
I-------------I I
I I
I CT0+CT1+CT2 I
I I
I----------------------------I
<--Max Reservable Bandwidth-->
<--最大可保留带宽-->
(Note that, in this illustration, the sum BC0 + BC1 + BC2 exceeds the Max Reservable Bandwidth.)
（注意，在本图中，BC0+BC1+BC2之和超过了最大可保留带宽。）
While more flexible/sophisticated Bandwidth Constraints Models can be defined (and are indeed defined; see [DSTE-RDM]), the Maximum Allocation Model is attractive in some DS-TE environments for the following reasons:
虽然可以定义更灵活/复杂的带宽约束模型（并且确实已经定义；请参见[DSTE-RDM]），但最大分配模型在某些DS-TE环境中很有吸引力，原因如下：
- Network administrators generally find MAM simple and intuitive
- 网络管理员通常认为MAM简单直观
- MAM matches simple bandwidth control policies that Network Administrators may want to enforce, such as setting an individual Bandwidth Constraint for a given type of traffic (a.k.a. Class-Type) and simultaneously limit the aggregate of reserved bandwidth across all types of traffic.
- MAM匹配网络管理员可能希望强制执行的简单带宽控制策略，例如为给定类型的流量（也称为类类型）设置单个带宽约束，同时限制所有类型流量中保留带宽的聚合。
- MAM can be used in a way which ensures isolation across Class-Types, whether preemption is used or not.
- MAM的使用方式可以确保跨类类型的隔离，无论是否使用抢占。
- MAM can simultaneously achieve isolation, bandwidth efficiency, and protection against QoS degradation of the premium CT.
- MAM可以同时实现隔离、带宽效率和防止高级CT的QoS下降。
- MAM only requires limited protocol extensions such as the ones defined in [DSTE-PROTO].
- MAM只需要有限的协议扩展，如[DSTE-PROTO]中定义的扩展。
MAM may not be attractive in some DS-TE environments because:
MAM在某些DS-TE环境中可能没有吸引力，因为：
- MAM cannot simultaneously achieve isolation, bandwidth efficiency, and protection against QoS degradation of CTs other than the Premium CT.
- MAM不能同时实现隔离、带宽效率和对除高级CT以外的CT的QoS降级的保护。
Additional considerations on the properties of MAM, and its comparison with RDM, can be found in [BC-CONS] and [BC-MODEL].
有关MAM特性的其他注意事项及其与RDM的比较，请参见[BC-CONS]和[BC-MODEL]。
As a very simple example of usage of MAM, a network administrator using one CT for Voice (CT1) and one CT for Data (CT0) might configure on a given 2.5 Gb/s link:
作为使用MAM的一个非常简单的示例，网络管理员使用一个CT进行语音（CT1）和一个CT进行数据（CT0）时，可能会在给定的2.5 Gb/s链路上配置：
- BC0 = 2 Gb/s (i.e., Data is limited to 2 Gb/s)
- BC0=2 Gb/s（即数据限制为2 Gb/s）
- BC1 = 1 Gb/s (i.e., Voice is limited to 1 Gb/s)
- BC1=1 Gb/s（即语音限制为1 Gb/s）
- Maximum Reservable Bandwidth = 2.5 Gb/s (i.e., aggregate Data + Voice is limited to 2.5 Gb/s)
- 最大可保留带宽=2.5 Gb/s（即聚合数据+语音限制为2.5 Gb/s）
4. Example Formulas for Computing "Unreserved TE-Class [i]" with Maximum Allocation Model
4. 使用最大分配模型计算“无保留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 MAM MUST reflect the MAM Bandwidth Constraints defined in Section 3 when computing "Unreserved TE-Class [i]".
如[DSTE-PROTO]中所述，计算“无保留TE类[i]”的公式必须反映与TE类[i]相关的CT相关的所有带宽约束，因此取决于带宽约束模型。因此，在计算“无保留TE类[i]”时，实现MAM的DS-TE LSR必须反映第3节中定义的MAM带宽约束。
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,
如[DSTE-PROTO]所述，准入控制算法的细节以及计算“无保留TE类[i]”的公式不在IETF工作范围内。记住这一点，
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 MAM. In the example, we assume the use of 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.
为了便于说明，我们在本节中提供了一个示例，说明如何使用MAM计算TE类[i]的无保留带宽值。在该示例中，我们假设使用基本接纳控制算法，该算法简单地从与该LSP相关联的CT的所有带宽约束中推断任何已建立LSP的确切带宽。
Then:
然后：
"Unreserved TE-Class [i]" =
“未保留的TE类[i]”=
MIN [
[ BCc - SUM ( Reserved(CTc,q) ) ] for q <= p ,
[ Max-Res-Bw - SUM (Reserved(CTb,q)) ] for q <= p and 0 <= b <= 7,
]
MIN [
[ BCc - SUM ( Reserved(CTc,q) ) ] for q <= p ,
[ Max-Res-Bw - 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>。
Security considerations related to the use of DS-TE are discussed in [DSTE-PROTO]. Those apply independently of the Bandwidth Constraints Model, including MAM specified in this document.
[DSTE-PROTO]中讨论了与使用DS-TE相关的安全注意事项。这些应用独立于带宽约束模型，包括本文档中指定的MAM。
[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 with these guidelines, IANA has assigned a Bandwidth Constraints Model Id for MAM from the range 0-239 (which is to be managed as per the "Specification Required" policy defined in [IANA-CONS]).
[DSTE-PROTO]为“带宽约束模型Id”定义了一个新的名称空间。[DSTE-PROTO]第13.1节详细介绍了该名称空间中的值分配指南。根据这些指南，IANA为MAM分配了一个范围为0-239的带宽约束模型Id（将根据[IANA-CONS]中定义的“所需规范”策略进行管理）。
Bandwidth Constraints Model Id 1 was allocated by IANA to MAM.
带宽限制模型Id 1由IANA分配给MAM。
A lot of the material in this document has been derived from ongoing discussions within the TEWG work. This involved many people including Jerry Ash and Dimitry Haskin.
本文件中的许多材料来源于TEWG工作中正在进行的讨论。这涉及许多人，包括杰里·阿什和迪米特里·哈斯金。
Appendix A: Addressing [DSTE-REQ] Scenarios
附录A：寻址[DSTE-REQ]方案
This Appendix provides examples of how the Maximum Allocation 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=语音）=链路容量的“特定百分比”
- Bandwidth Constraint 0 (for CT0 = Data) = link capacity (or a constraint specific to data traffic)
- 带宽约束0（对于CT0=数据）=链路容量（或特定于数据流量的约束）
- Max Reservable Bandwidth = link capacity
- 最大可保留带宽=链路容量
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 Maximum Allocation 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 (or up to its own specific constraint)
- 能够使用所有剩余链路容量（或达到其自身特定限制）的数据流量
- voice traffic capable of preempting other traffic
- 能够抢占其他流量的语音流量
By configuring on every link:
通过在每个链接上配置：
- BC2 (for CT2) = e.g., 45% of link capacity
- BC2（对于CT2）=例如，链路容量的45%
- BC1 (for CT1) = e.g., 35% of link capacity
- BC1（对于CT1）=例如，链路容量的35%
- BC0 (for CT0) = e.g., 100% of link capacity
- BC0（对于CT0）=例如，链路容量的100%
- Max Reservable Bandwidth = link capacity
- 最大可保留带宽=链路容量
DS-TE with the Maximum Allocation Model 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.
具有最大分配模型的DS-TE将确保与分配给相应的区分服务每跳行为（PHB）的资源相比，在链路上建立的每个CT的流量在可接受的水平内，无论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 Maximum Allocation 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 CT and corresponding Diffserv resources.
Diffserv调度配置的可选自动调整可用于在每个CT的已建立通信量和相应Diffserv资源之间保持非常严格的关系。
By configuring on every link:
通过在每个链接上配置：
- BC1 (for CT1) = "given" percentage of link bandwidth (appropriate to achieve the QoS objectives of the Guaranteed Bandwidth service)
- BC1（对于CT1）=“给定”链路带宽百分比（适用于实现保证带宽服务的QoS目标）
- BC0 (for CT0 = Data) = link capacity (or a constraint specific to data traffic)
- BC0（对于CT0=数据）=链路容量（或特定于数据流量的约束）
- Max Reservable Bandwidth = link capacity
- 最大可保留带宽=链路容量
DS-TE with the Maximum Allocation 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
具有最大分配模型的DS-TE将确保在每个链路上建立的保证带宽流量量保持在给定百分比以下，以便始终满足其QoS目标。同时，它将允许交通工程
the rest of the traffic such that links can be filled up (or limited to the specific constraint for such traffic).
剩余的通信量使得链路可以被填满（或限制为此类通信量的特定约束）。
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-RDM] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005.
[DSTE-RDM]Le Faucheur，F.，编辑，“区分服务感知MPLS流量工程的俄罗斯玩偶带宽约束模型”，RFC 4127，2005年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流量工程快速重路由：用于带宽保护的旁路隧道路径计算”，正在进行中。
Authors' Addresses
作者地址
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
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编辑功能的资金目前由互联网协会提供。