Network Working Group F. Le Faucheur, Ed.
Request for Comments: 4124 Cisco Systems, Inc.
Category: Standards Track June 2005
Network Working Group F. Le Faucheur, Ed.
Request for Comments: 4124 Cisco Systems, Inc.
Category: Standards Track June 2005
Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering
支持区分服务的MPLS流量工程的协议扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document specifies the protocol extensions for support of Diffserv-aware MPLS Traffic Engineering (DS-TE). This includes generalization of the semantics of a number of Interior Gateway Protocol (IGP) extensions already defined for existing MPLS Traffic Engineering in RFC 3630, RFC 3784, and additional IGP extensions beyond those. This also includes extensions to RSVP-TE signaling beyond those already specified in RFC 3209 for existing MPLS Traffic Engineering. These extensions address the requirements for DS-TE spelled out in RFC 3564.
本文档规定了支持区分服务的MPLS流量工程（DS-TE）的协议扩展。这包括对RFC 3630、RFC 3784中已为现有MPLS流量工程定义的许多内部网关协议（IGP）扩展的语义的概括，以及除此之外的其他IGP扩展。这还包括对RSVP-TE信令的扩展，超出了RFC 3209中为现有MPLS流量工程指定的扩展。这些扩展满足RFC3564中规定的DS-TE要求。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Specification of Requirements ..............................3
2. Contributing Authors ............................................4
3. Definitions .....................................................5
4. Configurable Parameters .........................................5
4.1. Link Parameters ............................................5
4.1.1. Bandwidth Constraints (BCs) .........................5
4.1.2. Overbooking .........................................6
4.2. LSR Parameters .............................................7
4.2.1. TE-Class Mapping ....................................7
4.3. LSP Parameters .............................................8
4.3.1. Class-Type ..........................................8
4.3.2. Setup and Holding Preemption Priorities .............8
4.3.3. Class-Type/Preemption Relationship ..................8
1. Introduction ....................................................3
1.1. Specification of Requirements ..............................3
2. Contributing Authors ............................................4
3. Definitions .....................................................5
4. Configurable Parameters .........................................5
4.1. Link Parameters ............................................5
4.1.1. Bandwidth Constraints (BCs) .........................5
4.1.2. Overbooking .........................................6
4.2. LSR Parameters .............................................7
4.2.1. TE-Class Mapping ....................................7
4.3. LSP Parameters .............................................8
4.3.1. Class-Type ..........................................8
4.3.2. Setup and Holding Preemption Priorities .............8
4.3.3. Class-Type/Preemption Relationship ..................8
4.4. Examples of Parameters Configuration .......................9
4.4.1. Example 1 ...........................................9
4.4.2. Example 2 ...........................................9
4.4.3. Example 3 ..........................................10
4.4.4. Example 4 ..........................................11
4.4.5. Example 5 ..........................................11
5. IGP Extensions for DS-TE .......................................12
5.1. Bandwidth Constraints .....................................12
5.2. Unreserved Bandwidth ......................................14
6. RSVP-TE Extensions for DS-TE ...................................15
6.1. DS-TE-Related RSVP Messages Format ........................15
6.1.1. Path Message Format ................................16
6.2. CLASSTYPE Object ..........................................16
6.2.1. CLASSTYPE object ...................................16
6.3. Handling CLASSTYPE Object .................................17
6.4. Non-support of the CLASSTYPE Object .......................20
6.5. Error Codes for Diffserv-aware TE .........................20
7. DS-TE Support with MPLS Extensions .............................21
7.1. DS-TE Support and References to Preemption Priority .......22
7.2. DS-TE Support and References to Maximum Reservable
Bandwidth .................................................22
8. Constraint-Based Routing .......................................22
9. Diffserv Scheduling ............................................23
10. Existing TE as a Particular Case of DS-TE .....................23
11. Computing "Unreserved TE-Class [i]" and Admission
Control Rules .................................................23
11.1. Computing "Unreserved TE-Class [i]" .....................23
11.2. Admission Control Rules .................................24
12. Security Considerations .......................................24
13. IANA Considerations ...........................................25
13.1. A New Name Space for Bandwidth Constraints Model
Identifiers .............................................25
13.2. A New Name Space for Error Values under the
"Diffserv-aware TE ......................................25
13.3. Assignments Made in This Document .......................26
13.3.1. Bandwidth Constraints sub-TLV for
OSPF Version 2 ..................................26
13.3.2. Bandwidth Constraints sub-TLV for ISIS ..........26
13.3.3. CLASSTYPE Object for RSVP .......................26
13.3.4. "Diffserv-aware TE Error" Error Code ............27
13.3.5. Error Values for "Diffserv-aware TE Error" ......27
14. Acknowledgements ..............................................28
Appendix A: Prediction for Multiple Path Computation ..............29
Appendix B: Solution Evaluation ...................................29
Appendix C: Interoperability with non DS-TE capable LSRs ..........31
Normative References ..............................................34
Informative References ............................................35
4.4. Examples of Parameters Configuration .......................9
4.4.1. Example 1 ...........................................9
4.4.2. Example 2 ...........................................9
4.4.3. Example 3 ..........................................10
4.4.4. Example 4 ..........................................11
4.4.5. Example 5 ..........................................11
5. IGP Extensions for DS-TE .......................................12
5.1. Bandwidth Constraints .....................................12
5.2. Unreserved Bandwidth ......................................14
6. RSVP-TE Extensions for DS-TE ...................................15
6.1. DS-TE-Related RSVP Messages Format ........................15
6.1.1. Path Message Format ................................16
6.2. CLASSTYPE Object ..........................................16
6.2.1. CLASSTYPE object ...................................16
6.3. Handling CLASSTYPE Object .................................17
6.4. Non-support of the CLASSTYPE Object .......................20
6.5. Error Codes for Diffserv-aware TE .........................20
7. DS-TE Support with MPLS Extensions .............................21
7.1. DS-TE Support and References to Preemption Priority .......22
7.2. DS-TE Support and References to Maximum Reservable
Bandwidth .................................................22
8. Constraint-Based Routing .......................................22
9. Diffserv Scheduling ............................................23
10. Existing TE as a Particular Case of DS-TE .....................23
11. Computing "Unreserved TE-Class [i]" and Admission
Control Rules .................................................23
11.1. Computing "Unreserved TE-Class [i]" .....................23
11.2. Admission Control Rules .................................24
12. Security Considerations .......................................24
13. IANA Considerations ...........................................25
13.1. A New Name Space for Bandwidth Constraints Model
Identifiers .............................................25
13.2. A New Name Space for Error Values under the
"Diffserv-aware TE ......................................25
13.3. Assignments Made in This Document .......................26
13.3.1. Bandwidth Constraints sub-TLV for
OSPF Version 2 ..................................26
13.3.2. Bandwidth Constraints sub-TLV for ISIS ..........26
13.3.3. CLASSTYPE Object for RSVP .......................26
13.3.4. "Diffserv-aware TE Error" Error Code ............27
13.3.5. Error Values for "Diffserv-aware TE Error" ......27
14. Acknowledgements ..............................................28
Appendix A: Prediction for Multiple Path Computation ..............29
Appendix B: Solution Evaluation ...................................29
Appendix C: Interoperability with non DS-TE capable LSRs ..........31
Normative References ..............................................34
Informative References ............................................35
[DSTE-REQ] presents the Service Provider requirements for support of Differentiated-Service (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]提出了服务提供商对支持区分服务（Diffserv）感知MPLS流量工程（DS-TE）的要求。这包括能够针对不同类别的流量实施不同带宽约束的基本要求。
This document specifies the IGP and RSVP-TE signaling extensions (beyond those already specified for existing MPLS Traffic Engineering [OSPF-TE][ISIS-TE][RSVP-TE]) for support of the DS-TE requirements spelled out in [DSTE-REQ] including environments relying on distributed Constraint-Based Routing (e.g., path computation involving head-end Label Switching Routers).
本文件规定了IGP和RSVP-TE信令扩展（现有MPLS流量工程[OSPF-TE][ISIS-TE][RSVP-TE]已经指定的扩展除外），以支持[DSTE-REQ]中规定的DS-TE要求，包括依赖分布式约束路由的环境（例如，涉及前端标签交换路由器的路径计算）。
[DSTE-REQ] provides a definition and examples of Bandwidth
Constraints models. The present document does not specify nor assume
a particular Bandwidth Constraints model. Specific Bandwidth
Constraints models are outside the scope of this document. Although
the extensions for DS-TE specified in this document may not be
sufficient to support all the conceivable Bandwidth Constraints
models, they do support the Russian Dolls Model specified in
[DSTE-RDM], the Maximum Allocation Model specified in [DSTE-MAM], and
the Maximum Allocation with Reservation Model specified in
[DSTE-MAR].
[DSTE-REQ] provides a definition and examples of Bandwidth
Constraints models. The present document does not specify nor assume
a particular Bandwidth Constraints model. Specific Bandwidth
Constraints models are outside the scope of this document. Although
the extensions for DS-TE specified in this document may not be
sufficient to support all the conceivable Bandwidth Constraints
models, they do support the Russian Dolls Model specified in
[DSTE-RDM], the Maximum Allocation Model specified in [DSTE-MAM], and
the Maximum Allocation with Reservation Model specified in
[DSTE-MAR].
There may be differences between the quality of service expressed and obtained with Diffserv without DS-TE and with DS-TE. Because DS-TE uses Constraint-Based Routing, and because of the type of admission control capabilities it adds to Diffserv, DS-TE has capabilities for traffic that Diffserv does not: Diffserv does not indicate preemption, by intent, whereas DS-TE describes multiple levels of preemption for its Class-Types. Also, Diffserv does not support any means of explicitly controlling overbooking, while DS-TE allows this. When considering a complete quality of service environment, with Diffserv routers and DS-TE, it is important to consider these differences carefully.
在使用不带DS-TE的Diffserv和使用DS-TE的Diffserv表示和获得的服务质量之间可能存在差异。由于DS-TE使用基于约束的路由，并且由于它添加到Diffserv的准入控制功能的类型，DS-TE具有Diffserv没有的流量功能：Diffserv无意表示抢占，而DS-TE描述了其类类型的多个抢占级别。此外，Diffserv不支持任何显式控制超售的方法，而DS-TE允许这样做。当考虑到一个完整的服务质量环境时，使用DiffServ路由器和DS-TE，仔细考虑这些差异是很重要的。
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]中的许多定义：
Traffic Trunk: an aggregation of traffic flows of the same class (i.e., treated equivalently from the DS-TE perspective), which is placed inside a Label Switched Path (LSP).
交通干线：位于标签交换路径（LSP）内的同一类交通流的集合（即，从DS-TE角度等效处理）。
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: 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 setup priority, the holding priority, or both.
TE类：一对：i。第二类。该类类型允许的抢占优先级。这意味着从该类类型传输业务中继的LSP可以使用该抢占优先级作为设置优先级、保持优先级或两者。
Definitions for a number of MPLS terms are not repeated here. They can be found in [MPLS-ARCH].
许多MPLS术语的定义在此不再重复。它们可以在[MPLS-ARCH]中找到。
This section only discusses the differences with the configurable parameters supported for MPLS Traffic Engineering as per [TE-REQ], [ISIS-TE], [OSPF-TE], and [RSVP-TE]. All other parameters are unchanged.
本节仅讨论与根据[TE-REQ]、[ISIS-TE]、[OSPF-TE]和[RSVP-TE]的MPLS流量工程支持的可配置参数之间的差异。所有其他参数不变。
[DSTE-REQ] states that "Regardless of the Bandwidth Constraints Model, the DS-TE solution MUST allow support for up to 8 BCs."
[DSTE-REQ]声明“无论带宽限制模型如何，DS-TE解决方案必须允许支持多达8个BCs。”
For DS-TE, the existing "Maximum Reservable link bandwidth" parameter is retained, but its semantics is generalized and interpreted as the aggregate bandwidth constraint across all Class-Types, so that, independently of the Bandwidth Constraints Model in use:
对于DS-TE，保留现有的“最大可保留链路带宽”参数，但其语义被概括并解释为所有类类型的聚合带宽约束，因此，与使用的带宽约束模型无关：
SUM (Reserved (CTc)) <= Max Reservable Bandwidth,
总和（保留（CTc））<=最大可保留带宽，
where the SUM is across all values of "c" in the range 0 <= c <= 7.
其中，总和是0<=c<=7范围内所有“c”值的总和。
Additionally, on every link, a DS-TE implementation MUST provide for configuration of up to 8 additional link parameters which are the eight potential BCs, i.e., BC0, BC1, ... BC7. The LSR MUST interpret these BCs in accordance with the supported Bandwidth Constraints Model (i.e., what BC applies to what Class-Type, and how).
此外，在每个链路上，DS-TE实现必须提供多达8个额外链路参数的配置，这些参数是8个潜在的BCs，即BC0、BC1、。。。BC7。LSR必须根据支持的带宽约束模型解释这些BC（即，什么BC适用于什么类类型，以及如何应用）。
Where the Bandwidth Constraints Model imposes some relationship among the values to be configured for these BCs, the LSR MUST enforce those at configuration time. For example, when the Russian Dolls Bandwidth Constraints Model ([DSTE-RDM]) is used, the LSR MUST ensure that BCi is configured smaller than or equal to BCj, where i is greater than j, and ensure that BC0 is equal to the Maximum Reservable Bandwidth. As another example, when the Maximum Allocation Model ([DSTE-MAM]) is used, the LSR MUST ensure that all BCi are configured smaller or equal to the Maximum Reservable Bandwidth.
如果带宽约束模型在要为这些BC配置的值之间施加了某种关系，则LSR必须在配置时强制执行这些关系。例如，当使用俄罗斯玩偶带宽约束模型（[DSTE-RDM]）时，LSR必须确保BCi配置为小于或等于BCj，其中i大于j，并确保BC0等于最大可保留带宽。作为另一个示例，当使用最大分配模型（[DSTE-MAM]）时，LSR必须确保所有BCi的配置小于或等于最大可保留带宽。
DS-TE enables a network administrator to apply different overbooking (or underbooking) ratios for different CTs.
DS-TE使网络管理员能够为不同的CT应用不同的超售（或欠售）比率。
The principal methods to achieve this are the same as those historically used in existing TE deployment:
实现这一点的主要方法与现有TE部署中历史上使用的方法相同：
(i) To take into account the overbooking/underbooking ratio appropriate for the Ordered Aggregate (OA) or CT associated with the considered LSP at the time of establishing the bandwidth size of a given LSP. We refer to this method as the "LSP Size Overbooking" method. AND/OR (ii) To take into account the overbooking/underbooking ratio at the time of configuring the Maximum Reservable Bandwidth/BCs and use values that are larger (overbooking) or smaller (underbooking) than those actually supported by the link. We refer to this method as the "Link Size Overbooking" method.
(i) 在确定给定LSP的带宽大小时，考虑与所考虑LSP相关的有序聚合（OA）或CT的适当超售/欠售比率。我们将此方法称为“LSP尺寸超售”方法。和/或（ii）在配置最大可预约带宽/BCs时考虑超售/欠售比率，并使用大于（超售）或小于（欠售）链路实际支持的值。我们将此方法称为“链接大小超售”方法。
The "LSP Size Overbooking" and "Link Size Overbooking" methods are expected to be sufficient in many DS-TE environments and require no additional configurable parameters. Other overbooking methods may involve such additional configurable parameters, but are beyond the scope of this document.
“LSP大小超售”和“链路大小超售”方法预计在许多DS-TE环境中已经足够，并且不需要额外的可配置参数。其他超售方法可能涉及此类额外的可配置参数，但不在本文件范围内。
In line with [DSTE-REQ], the preemption attributes defined in [TE-REQ] are retained with DS-TE and applicable within, and across, all CTs. The preemption attributes of setup priority and holding priority retain existing semantics, and in particular these semantics are not affected by the LSP CT. This means that if LSP1 contends with LSP2 for resources, LSP1 may preempt LSP2 if LSP1 has a higher setup preemption priority (i.e., lower numerical priority value) than LSP2 holding preemption priority, regardless of LSP1 CT and LSP2 CT.
与[DSTE-REQ]一致，[TE-REQ]中定义的抢占属性保留在DS-TE中，并适用于所有CT内和跨CT。setup priority和holding priority的抢占属性保留现有语义，特别是这些语义不受LSP CT的影响。这意味着，如果LSP1与LSP2争夺资源，则无论LSP1 CT和LSP2 CT如何，如果LSP1的设置抢占优先级高于持有抢占优先级的LSP2，则LSP1可能抢占LSP2。
DS-TE LSRs MUST allow configuration of a TE-Class mapping whereby the Class-Type and preemption level are configured for each of (up to) 8 TE-Classes.
DS-TE LSR必须允许配置TE类映射，从而为每个（最多）8个TE类配置类类型和抢占级别。
This mapping is referred to as :
此映射称为：
TE-Class[i] <--> < CTc , preemption p >
TE-Class[i] <--> < CTc , preemption p >
where 0 <= i <= 7, 0 <= c <= 7, 0 <= p <= 7
where 0 <= i <= 7, 0 <= c <= 7, 0 <= p <= 7
Two TE-Classes MUST NOT be identical (i.e., have both the same Class-Type and the same preemption priority).
两个TE类不得相同（即，具有相同的类类型和相同的抢占优先级）。
There are no other restrictions on how any of the 8 Class-Types can be paired up with any of the 8 preemption priorities to form a TE-Class. In particular, one given preemption priority can be paired up with two (or more) different Class-Types to form two (or more) TE-Classes. Similarly, one Class-Type can be paired up with two (or more) different preemption priorities to form two (or more) TE-Classes. Also, there is no mandatory ordering relationship between the TE-Class index (i.e., "i" above) and the Class-Type (i.e., "c" above) or the preemption priority (i.e., "p" above) of the TE-Class.
对于如何将8个类类型中的任何一个与8个抢占优先级中的任何一个配对以形成TE类，没有其他限制。特别是，一个给定的抢占优先级可以与两个（或更多）不同的类类型配对，以形成两个（或更多）TE类。类似地，一个类类型可以与两个（或更多）不同的抢占优先级配对，以形成两个（或更多）TE类。此外，TE类索引（即上面的“i”）和TE类的类类型（即上面的“c”）或抢占优先级（即上面的“p”）之间没有强制排序关系。
Where the network administrator uses less than 8 TE-Classes, the DS-TE LSR MUST allow remaining ones to be configured as "Unused". Note that configuring all the 8 TE-Classes as "Unused" effectively results in disabling TE/DS-TE since no TE/DS-TE LSP can be established (nor even configured, since as described in Section 4.3.3 below, the CT and preemption priorities configured for an LSP MUST form one of the configured TE-Classes).
如果网络管理员使用的TE类少于8个，则DS-TE LSR必须允许将剩余的TE类配置为“未使用”。请注意，将所有8个TE类配置为“未使用”会有效地导致禁用TE/DS-TE，因为无法建立TE/DS-TE LSP（甚至也无法配置，因为如下文第4.3.3节所述，为LSP配置的CT和抢占优先级必须构成配置的TE类之一）。
To ensure coherent DS-TE operation, the network administrator MUST configure exactly the same TE-Class mapping on all LSRs of the DS-TE domain.
为了确保一致的DS-TE操作，网络管理员必须在DS-TE域的所有LSR上配置完全相同的TE类映射。
When the TE-Class mapping needs to be modified in the DS-TE domain, care ought to be exercised during the transient period of reconfiguration during which some DS-TE LSRs may be configured with the new TE-Class mapping while others are still configured with the old TE-Class mapping. It is recommended that active tunnels do not use any of the TE-Classes that are being modified during such a transient reconfiguration period.
当需要在DS-TE域中修改TE类映射时，应注意在重新配置的过渡期间，在此期间，一些DS-TE LSR可能配置有新的TE类映射，而其他DS-TE LSR仍配置有旧的TE类映射。建议主动隧道不要使用在这种瞬态重新配置期间被修改的任何TE类。
With DS-TE, LSRs MUST support, for every LSP, an additional configurable parameter that indicates the Class-Type of the Traffic Trunk transported by the LSP.
对于DS-TE，LSR必须为每个LSP支持一个额外的可配置参数，该参数指示LSP传输的业务主干的类别类型。
There is one and only one Class-Type configured per LSP.
每个LSP配置一个且只有一个类类型。
The configured Class-Type indicates, in accordance with the supported Bandwidth Constraints Model, the BCs that MUST be enforced for that LSP.
根据支持的带宽约束模型，配置的类类型指示必须为该LSP强制的BCs。
As per existing TE, DS-TE LSRs MUST allow every DS-TE LSP to be configured with a setup and holding priority, each with a value between 0 and 7.
根据现有TE，DS-TE LSR必须允许每个DS-TE LSP配置一个设置和保持优先级，每个优先级的值在0和7之间。
With DS-TE, the preemption priority configured for the setup priority of a given LSP and the Class-Type configured for that LSP MUST be such that, together, they form one of the (up to) 8 TE-Classes configured in the TE-Class mapping specified in Section 4.2.1 above.
对于DS-TE，为给定LSP的设置优先级配置的抢占优先级和为该LSP配置的类类型必须确保，它们一起构成在上述第4.2.1节规定的TE类映射中配置的（最多）8个TE类之一。
The preemption priority configured for the holding priority of a given LSP and the Class-Type configured for that LSP MUST also be such that, together, they form one of the (up to) 8 TE-Classes configured in the TE-Class mapping specified in Section 4.2.1 above.
为给定LSP的保持优先级配置的抢占优先级和为该LSP配置的类类型也必须是这样的，即它们一起构成在上文第4.2.1节规定的TE类映射中配置的（最多）8个TE类之一。
The LSR MUST enforce these two rules at configuration time.
LSR必须在配置时强制执行这两个规则。
For illustration purposes, we now present a few examples of how these configurable parameters may be used. All these examples assume that different BCs need to be enforced for different sets of Traffic Trunks (e.g., for Voice and for Data) so that two or more Class-Types need to be used.
为了便于说明，我们现在提供了一些如何使用这些可配置参数的示例。所有这些示例都假设需要为不同的业务中继集（例如，语音和数据）实施不同的BCs，因此需要使用两种或更多的类类型。
The network administrator of a first network using two CTs (CT1 for Voice and CT0 for Data) may elect to configure the following TE-Class mapping to ensure that Voice LSPs are never driven away from their shortest path because of Data LSPs:
使用两个CT（CT1用于语音，CT0用于数据）的第一个网络的网络管理员可以选择配置以下TE类映射，以确保语音LSP不会因为数据LSP而偏离其最短路径：
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 1 >
TE-Class[i] <--> unused, for 2 <= i <= 7
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 1 >
TE-Class[i] <--> unused, for 2 <= i <= 7
Voice LSPs would then be configured with:
CT = CT1, setup priority = 0, holding priority = 0
Voice LSPs would then be configured with:
CT = CT1, setup priority = 0, holding priority = 0
Data LSPs would then be configured with:
CT = CT0, setup priority = 1, holding priority = 1
Data LSPs would then be configured with:
CT = CT0, setup priority = 1, holding priority = 1
A new Voice LSP would then be able to preempt an existing Data LSP in case they contend for resources. A Data LSP would never preempt a Voice LSP. A Voice LSP would never preempt another Voice LSP. A Data LSP would never preempt another Data LSP.
新的语音LSP将能够抢占现有的数据LSP，以防它们争夺资源。数据LSP永远不会抢占语音LSP。一个语音LSP永远不会抢占另一个语音LSP。一个数据LSP永远不会抢占另一个数据LSP。
The network administrator of another network may elect to configure the following TE-Class mapping in order to optimize global network resource utilization by favoring placement of large LSPs closer to their shortest path:
另一个网络的网络管理员可以选择配置以下TE类映射，以便通过将大型LSP放置在更接近其最短路径的位置来优化全局网络资源利用率：
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 1 >
TE-Class[2] <--> < CT1 , preemption 2 >
TE-Class[3] <--> < CT0 , preemption 3 >
TE-Class[i] <--> unused, for 4 <= i <= 7
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 1 >
TE-Class[2] <--> < CT1 , preemption 2 >
TE-Class[3] <--> < CT0 , preemption 3 >
TE-Class[i] <--> unused, for 4 <= i <= 7
Large-size Voice LSPs could be configured with:
CT = CT1, setup priority = 0, holding priority = 0
Large-size Voice LSPs could be configured with:
CT = CT1, setup priority = 0, holding priority = 0
Large-size Data LSPs could be configured with:
CT = CT0, setup priority = 1, holding priority = 1
Large-size Data LSPs could be configured with:
CT = CT0, setup priority = 1, holding priority = 1
Small-size Voice LSPs could be configured with:
CT = CT1, setup priority = 2, holding priority = 2
Small-size Voice LSPs could be configured with:
CT = CT1, setup priority = 2, holding priority = 2
Small-size Data LSPs could be configured with:
CT = CT0, setup priority = 3, holding priority = 3
Small-size Data LSPs could be configured with:
CT = CT0, setup priority = 3, holding priority = 3
A new large-size Voice LSP would then be able to preempt a small-size Voice LSP or any Data LSP in case they contend for resources. A new large-size Data LSP would then be able to preempt a small-size Data LSP or a small-size Voice LSP in case they contend for resources, but it would not be able to preempt a large-size Voice LSP.
新的大型语音LSP将能够抢占小型语音LSP或任何数据LSP，以防它们争夺资源。新的大数据LSP将能够抢占小数据LSP或小语音LSP，以防它们争夺资源，但它将无法抢占大语音LSP。
The network administrator of another network may elect to configure the following TE-Class mapping in order to ensure that Voice LSPs are never driven away from their shortest path because of Data LSPs. This also achieves some optimization of global network resource utilization by favoring placement of large LSPs closer to their shortest path:
另一个网络的网络管理员可以选择配置以下TE类映射，以确保语音LSP不会因为数据LSP而偏离其最短路径。通过有利于将大型LSP放置在更接近其最短路径的位置，这也实现了全球网络资源利用率的一些优化：
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT1 , preemption 1 >
TE-Class[2] <--> < CT0 , preemption 2 >
TE-Class[3] <--> < CT0 , preemption 3 >
TE-Class[i] <--> unused, for 4 <= i <= 7
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT1 , preemption 1 >
TE-Class[2] <--> < CT0 , preemption 2 >
TE-Class[3] <--> < CT0 , preemption 3 >
TE-Class[i] <--> unused, for 4 <= i <= 7
Large-size Voice LSPs could be configured with: CT = CT1, setup priority = 0, holding priority = 0.
大尺寸语音LSP可配置为：CT=CT1，设置优先级=0，保持优先级=0。
Small-size Voice LSPs could be configured with: CT = CT1, setup priority = 1, holding priority = 1.
小尺寸语音LSP可配置为：CT=CT1，设置优先级=1，保持优先级=1。
Large-size Data LSPs could be configured with: CT = CT0, setup priority = 2, holding priority = 2.
大数据LSP可以配置为：CT=CT0，设置优先级=2，保持优先级=2。
Small-size Data LSPs could be configured with: CT=CT0, setup priority = 3, holding priority = 3.
小尺寸数据LSP可配置为：CT=CT0，设置优先级=3，保持优先级=3。
A Voice LSP could preempt a Data LSP if they contend for resources. A Data LSP would never preempt a Voice LSP. A large-size Voice LSP could preempt a small-size Voice LSP if they contend for resources. A large-size Data LSP could preempt a small-size Data LSP if they contend for resources.
如果语音LSP争夺资源，则它们可以抢占数据LSP。数据LSP永远不会抢占语音LSP。如果大型语音LSP争夺资源，则它们可以抢占小型语音LSP。如果大型数据LSP争夺资源，则它们可以抢占小型数据LSP。
The network administrator of another network may elect to configure the following TE-Class mapping in order to ensure that no preemption occurs in the DS-TE domain:
另一个网络的网络管理员可以选择配置以下TE类映射，以确保DS-TE域中不会发生抢占：
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 0 >
TE-Class[i] <--> unused, for 2 <= i <= 7
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 0 >
TE-Class[i] <--> unused, for 2 <= i <= 7
Voice LSPs would then be configured with:
CT = CT1, setup priority =0, holding priority = 0
Voice LSPs would then be configured with:
CT = CT1, setup priority =0, holding priority = 0
Data LSPs would then be configured with:
CT = CT0, setup priority = 0, holding priority = 0
Data LSPs would then be configured with:
CT = CT0, setup priority = 0, holding priority = 0
No LSP would then be able to preempt any other LSP.
然后，任何LSP都无法抢占任何其他LSP。
The network administrator of another network may elect to configure the following TE-Class mapping in view of increased network stability through a more limited use of preemption:
另一个网络的网络管理员可以选择配置以下TE类映射，以通过更有限的抢占使用提高网络稳定性：
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT1 , preemption 1 >
TE-Class[2] <--> < CT0 , preemption 1 >
TE-Class[3] <--> < CT0 , preemption 2 >
TE-Class[i] <--> unused, for 4 <= i <= 7
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT1 , preemption 1 >
TE-Class[2] <--> < CT0 , preemption 1 >
TE-Class[3] <--> < CT0 , preemption 2 >
TE-Class[i] <--> unused, for 4 <= i <= 7
Large-size Voice LSPs could be configured with: CT = CT1, setup priority = 0, holding priority = 0.
大尺寸语音LSP可配置为：CT=CT1，设置优先级=0，保持优先级=0。
Small-size Voice LSPs could be configured with: CT = CT1, setup priority = 1, holding priority = 0.
小尺寸语音LSP可配置为：CT=CT1，设置优先级=1，保持优先级=0。
Large-size Data LSPs could be configured with: CT = CT0, setup priority = 2, holding priority = 1.
大数据LSP可以配置为：CT=CT0，设置优先级=2，保持优先级=1。
Small-size Data LSPs could be configured with: CT = CT0, setup priority = 2, holding priority = 2.
小尺寸数据LSP可配置为：CT=CT0，设置优先级=2，保持优先级=2。
A new large-size Voice LSP would be able to preempt a Data LSP in case they contend for resources, but it would not be able to preempt any Voice LSP even a small-size Voice LSP.
新的大型语音LSP将能够抢占数据LSP，以防它们争夺资源，但它将无法抢占任何语音LSP，即使是小型语音LSP。
A new small-size Voice LSP would be able to preempt a small-size Data LSP in case they contend for resources, but it would not be able to preempt a large-size Data LSP or any Voice LSP.
新的小型语音LSP将能够抢占小型数据LSP，以防它们争夺资源，但它将无法抢占大型数据LSP或任何语音LSP。
A Data LSP would not be able to preempt any other LSP.
数据LSP将无法抢占任何其他LSP。
This section only discusses the differences with the IGP advertisement supported for (aggregate) MPLS Traffic Engineering as per [OSPF-TE] and [ISIS-TE]. The rest of the IGP advertisement is unchanged.
本节仅讨论与[OSPF-TE]和[ISIS-TE]规定的（聚合）MPLS流量工程支持的IGP广告的区别。IGP广告的其余部分不变。
As detailed above in Section 4.1.1, up to 8 BCs (BCb, 0 <= b <= 7) are configurable on any given link.
如上文第4.1.1节所述，在任何给定链路上最多可配置8个BC（BCb，0<=b<=7）。
With DS-TE, the existing "Maximum Reservable Bandwidth" sub-TLV ([OSPF-TE], [ISIS-TE]) is retained with a generalized semantics so that it MUST now be interpreted as the aggregate bandwidth constraint across all Class-Types; i.e., SUM (Reserved (CTc)) <= Max Reservable Bandwidth, independently of the Bandwidth Constraints Model.
对于DS-TE，现有的“最大可保留带宽”子TLV（[OSPF-TE]、[ISIS-TE]）以广义语义保留，因此现在必须将其解释为所有类类型的聚合带宽约束；i、 例如，总和（保留（CTc））<=最大可保留带宽，与带宽约束模型无关。
This document also defines the following new optional sub-TLV to advertise the eight potential BCs (BC0 to BC7):
本文件还定义了以下新的可选子TLV，以公布八个潜在的BC（BC0至BC7）：
"Bandwidth Constraints" sub-TLV:
“带宽限制”子TLV：
- Bandwidth Constraints Model Id (1 octet) - Reserved (3 octets) - Bandwidth Constraints (N x 4 octets)
- 带宽限制模型Id（1个八位字节）-保留（3个八位字节）-带宽限制（N x 4个八位字节）
Where: - With OSPF, the sub-TLV is a sub-TLV of the "Link TLV" and its sub-TLV type is 17.
其中：-对于OSPF，子TLV是“链路TLV”的子TLV，其子TLV类型为17。
- With ISIS, the sub-TLV is a sub-TLV of the "extended IS reachability TLV" and its sub-TLV type is 22.
- 对于ISIS，子TLV是“扩展is可达性TLV”的子TLV，其子TLV类型为22。
- Bandwidth Constraints Model Id: a 1-octet identifier for the Bandwidth Constraints Model currently in use by the LSR initiating the IGP advertisement. See the IANA Considerations section for assignment of values in this name space.
- 带宽约束模型Id：启动IGP播发的LSR当前使用的带宽约束模型的1个八位组标识符。有关此名称空间中值的分配，请参见IANA注意事项部分。
- Reserved: a 3-octet field. This field should be set to zero by the LSR generating the sub-TLV and should be ignored by the LSR receiving the sub-TLV.
- 保留：3个八位字节字段。生成子TLV的LSR应将该字段设置为零，接收子TLV的LSR应忽略该字段。
- Bandwidth Constraints: contains BC0, BC1,... BC(N-1). Each BC is encoded on 32 bits in IEEE floating point format. The units are bytes (not bits!) per second. Where the configured TE-Class mapping and the Bandwidth Constraints model in use are such that BCh+1, BCh+2, ...and BC7 are not relevant to any of the Class-Types associated with a configured TE-Class, it is RECOMMENDED that only the Bandwidth Constraints from BC0 to BCh be advertised, in order to minimize the impact on IGP scalability.
- 带宽限制：包含BC0、BC1、，。。。BC（N-1）。每个BC以IEEE浮点格式在32位上编码。单位为每秒字节（不是位！）。如果所配置的TE类映射和所使用的带宽约束模型使得BCh+1、BCh+2……和BC7与与所配置的TE类关联的任何类类型都不相关，则建议仅公布从BC0到BCh的带宽约束，以最小化对IGP可伸缩性的影响。
All relevant generic TLV encoding rules (including TLV format, padding and alignment, as well as IEEE floating point format encoding) defined in [OSPF-TE] and [ISIS-TE] are applicable to this new sub-TLV.
[OSPF-TE]和[ISIS-TE]中定义的所有相关通用TLV编码规则（包括TLV格式、填充和对齐以及IEEE浮点格式编码）均适用于该新子TLV。
The "Bandwidth Constraints" sub-TLV format is illustrated below:
“带宽约束”子TLV格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BC Model Id | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BC0 value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BCh value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BC Model Id | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BC0 value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BCh value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A DS-TE LSR MAY optionally advertise BCs.
DS-TE LSR可以可选地通告bc。
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. For example, in the case where a service provider deploys DS-TE with TE-Classes associated with CT0 and CT1 only, and where the Bandwidth Constraints Model is such that only BC0 and BC1 are relevant to CT0 and CT1, a DS-TE LSR which does advertise BCs would include in the IGP advertisement the Maximum Reservable Bandwidth sub-TLV, as well as the "Bandwidth Constraints" sub-TLV. The former should contain the aggregate bandwidth constraint across all CTs, and the latter should contain BC0 and BC1.
不播发BCs的DS-TE LSR必须使用新的“带宽约束”子TLV（除了现有的最大可保留带宽子TLV）来执行此操作。例如，在服务提供商使用仅与CT0和CT1相关联的TE类部署DS-TE的情况下，并且在带宽约束模型使得只有BC0和BC1与CT0和CT1相关的情况下，广告BCs的DS-TE LSR将在IGP广告中包括最大可保留带宽子TLV以及“带宽约束”子TLV。前者应包含所有CT的聚合带宽约束，后者应包含BC0和BC1。
A DS-TE LSR receiving the "Bandwidth Constraints" sub-TLV with a Bandwidth Constraints Model Id that does not match the Bandwidth Constraints Model it currently uses SHOULD generate a warning to the operator/management system, reporting the inconsistency between Bandwidth Constraints Models used on different links. Also, in that case, if the DS-TE LSR does not support the Bandwidth Constraints
接收“带宽约束”子TLV的DS-TE LSR的带宽约束模型Id与其当前使用的带宽约束模型不匹配，应向运营商/管理系统发出警告，报告不同链路上使用的带宽约束模型之间的不一致性。此外，在这种情况下，如果DS-TE LSR不支持带宽约束
Model designated by the Bandwidth Constraints Model Id, or if the DS-TE LSR does not support operations with multiple simultaneous Bandwidth Constraints Models, the DS-TE LSR MAY discard the corresponding TLV. If the DS-TE LSR does support the Bandwidth Constraints Model designated by the Bandwidth Constraints Model Id, and if the DS-TE LSR does support operations with multiple simultaneous Bandwidth Constraints Models, the DS-TE LSR MAY accept the corresponding TLV and allow operations with different Bandwidth Constraints Models used in different parts of the DS-TE domain.
由带宽约束模型Id指定的模型，或者如果DS-TE LSR不支持具有多个同时带宽约束模型的操作，则DS-TE LSR可以丢弃相应的TLV。如果DS-TE LSR确实支持由带宽约束模型Id指定的带宽约束模型，并且如果DS-TE LSR确实支持具有多个同时带宽约束模型的操作，DS-TE LSR可以接受相应的TLV，并允许在DS-TE域的不同部分中使用不同带宽约束模型的操作。
With DS-TE, the existing "Unreserved Bandwidth" sub-TLV is retained as the only vehicle to advertise dynamic bandwidth information necessary for Constraint-Based Routing on head-ends, except that it is used with a generalized semantics. The Unreserved Bandwidth sub-TLV still carries eight bandwidth values, but they now correspond to the unreserved bandwidth for each of the TE-Classes (instead of for each preemption priority, as per existing TE).
在DS-TE中，现有的“无保留带宽”子TLV被保留为在前端发布基于约束的路由所需的动态带宽信息的唯一工具，但它与广义语义一起使用。无保留带宽子TLV仍然携带八个带宽值，但它们现在对应于每个TE类的无保留带宽（而不是根据现有TE针对每个抢占优先级）。
More precisely, a DS-TE LSR MUST support the Unreserved Bandwidth sub-TLV with a definition that is generalized into the following:
更准确地说，DS-TE LSR必须支持无保留带宽子TLV，其定义概括如下：
The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved for each of the eight TE-Classes, in IEEE floating point format arranged in increasing order of TE-Class index. Unreserved bandwidth for TE-Class [0] occurs at the start of the sub-TLV, and unreserved bandwidth for TE-Class [7] at the end of the sub-TLV. The unreserved bandwidth value for TE-Class [i] ( 0 <= i <= 7) is referred to as "Unreserved TE-Class [i]". It indicates the bandwidth that is available, for reservation, to an LSP that:
无保留带宽子TLV指定八个TE类中每个类尚未保留的带宽量，采用IEEE浮点格式，按TE类索引的递增顺序排列。TE类[0]的未保留带宽出现在子TLV的开始处，TE类[7]的未保留带宽出现在子TLV的结束处。TE类[i]（0<=i<=7）的未保留带宽值称为“未保留TE类[i]”。它表示LSP可用于预订的带宽，该LSP：
- transports a Traffic Trunk from the Class-Type of TE-Class[i], and
- 从TE类[i]的类类型传输通信干线，以及
- has a setup priority corresponding to the preemption priority of TE-Class[i].
- 具有与TE类[i]的抢占优先级相对应的设置优先级。
The units are bytes per second.
单位为每秒字节数。
Because the bandwidth values are now ordered by TE-class index and thus can relate to different CTs with different BCs and to any arbitrary preemption priority, a DS-TE LSR MUST NOT assume any ordered relationship among these bandwidth values.
由于带宽值现在按TE类索引排序，因此可以与具有不同BCs的不同CT以及任何任意抢占优先级相关，因此DS-TE LSR不得假定这些带宽值之间存在任何有序关系。
With existing TE, because all preemption priorities reflect the same (and only) BCs and bandwidth values are advertised in preemption priority order, the following relationship is always true, and is often assumed by TE implementations:
对于现有TE，由于所有抢占优先级反映相同（且仅）BCs，并且带宽值以抢占优先级顺序公布，因此以下关系始终为真，TE实现通常假定：
If i < j, then "Unreserved Bw [i]" >= "Unreserved Bw [j]"
If i < j, then "Unreserved Bw [i]" >= "Unreserved Bw [j]"
With DS-TE, no relationship is to be assumed such that:
对于DS-TE，不应假设存在以下关系：
If i < j, then any of the following relationships may be true: "Unreserved TE-Class [i]" = "Unreserved TE-Class [j]" OR "Unreserved TE-Class [i]" > "Unreserved TE-Class [j]" OR "Unreserved TE-Class [i]" < "Unreserved TE-Class [j]".
如果i<j，则以下任何关系可能为真：“未保留的TE类[i]”=“未保留的TE类[j]”或“未保留的TE类[i]”>“未保留的TE类[j]”或“未保留的TE类[i]”<“未保留的TE类[j]”。
Rules for computing "Unreserved TE-Class [i]" are specified in Section 11.
第11节规定了计算“无保留TE类[i]”的规则。
If TE-Class[i] is unused, the value advertised by the IGP in "Unreserved TE-Class [i]" MUST be set to zero by the LSR generating the IGP advertisement, and MUST be ignored by the LSR receiving the IGP advertisement.
如果TE类[i]未使用，则生成IGP播发的LSR必须将IGP在“未保留的TE类[i]”中播发的值设置为零，并且接收IGP播发的LSR必须忽略该值。
In this section, we describe extensions to RSVP-TE for support of Diffserv-aware MPLS Traffic Engineering. These extensions are in addition to the extensions to RSVP defined in [RSVP-TE] for support of (aggregate) MPLS Traffic Engineering and to the extensions to RSVP defined in [DIFF-MPLS] for support of Diffserv over MPLS.
在本节中，我们将介绍RSVP-TE的扩展，以支持区分服务感知MPLS流量工程。这些扩展是对[RSVP-TE]中定义的用于支持（聚合）MPLS流量工程的RSVP扩展和[DIFF-MPLS]中定义的用于支持MPLS上的区分服务的RSVP扩展的补充。
One new RSVP object is defined in this document: the CLASSTYPE object. Detailed description of this object is provided below. This new object is applicable to Path messages. This specification only defines the use of the CLASSTYPE object in Path messages used to establish LSP Tunnels in accordance with [RSVP-TE] and thus containing a session object with a CT equal to LSP_TUNNEL_IPv4 and containing a LABEL_REQUEST object.
本文档中定义了一个新的RSVP对象：CLASSTYPE对象。下文提供了该对象的详细说明。此新对象适用于路径消息。本规范仅定义在用于根据[RSVP-TE]建立LSP隧道的路径消息中使用CLASSTYPE对象，从而包含一个会话对象，其CT等于LSP_TUNNEL_IPv4，并包含一个LABEL_请求对象。
Restrictions defined in [RSVP-TE] for support of establishment of LSP Tunnels via RSVP-TE are also applicable to the establishment of LSP Tunnels supporting DS-TE. For instance, only unicast LSPs are supported, and multicast LSPs are for further study.
[RSVP-TE]中定义的通过RSVP-TE支持建立LSP隧道的限制也适用于建立支持DS-TE的LSP隧道。例如，只支持单播LSP，多播LSP有待进一步研究。
This new CLASSTYPE object is optional with respect to RSVP so that general RSVP implementations not concerned with MPLS LSP setup do not have to support this object.
这个新的类类型对象对于RSVP是可选的，因此与MPLS LSP设置无关的一般RSVP实现不必支持这个对象。
An LSR supporting DS-TE MUST support the CLASSTYPE object.
支持DS-TE的LSR必须支持CLASSTYPE对象。
The format of the Path message is as follows:
Path消息的格式如下所示：
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <DIFFSERV> ]
[ <CLASSTYPE> ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <DIFFSERV> ]
[ <CLASSTYPE> ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
The CLASSTYPE object Class Name is CLASSTYPE. Its Class Number is 66. Currently, there is only one defined C-Type which is C-Type 1. The CLASSTYPE object format is shown below.
CLASSTYPE对象类名为CLASSTYPE。它的班号是66。目前，只有一个已定义的C-Type，即C-Type 1。CLASSTYPE对象格式如下所示。
Class Number = 66 Class-Type = 1
类别编号=66类别类型=1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | CT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | CT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 29 bits This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt.
保留：29位此字段保留。传输时必须将其设置为零，接收时必须忽略。
CT: 3 bits Indicates the Class-Type. Values currently allowed are 1, 2, ... , 7. Value of 0 is Reserved.
CT:3位表示类别类型。当前允许的值为1，2，7.保留0的值。
To establish an LSP tunnel with RSVP, the sender LSR creates a Path message with a session type of LSP_Tunnel_IPv4 and with a
要使用RSVP建立LSP隧道，发送方LSR将创建一个会话类型为LSP_tunnel_IPv4且具有
LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also include the DIFFSERV object as per [DIFF-MPLS].
根据[RSVP-TE]标记请求对象。发送方LSR还可以包括根据[DIFF-MPLS]的DIFFSERV对象。
If the LSP is associated with Class-Type 0, the sender LSR MUST NOT include the CLASSTYPE object in the Path message. This allows backward compatibility with non-DSTE-configured or non-DSTE-capable LSRs as discussed below in Section 10 and Appendix C.
如果LSP与类类型0关联，则发送方LSR不得在路径消息中包含该类类型对象。这允许向后兼容非DSTE配置或非DSTE能力的LSR，如下文第10节和附录C所述。
If the LSP is associated with Class-Type N (1 <= N <=7), the sender LSR MUST include the CLASSTYPE object in the Path message with the Class-Type (CT) field set to N.
如果LSP与类别类型N（1<=N<=7）关联，则发送方LSR必须在路径消息中包含类别类型对象，类别类型（CT）字段设置为N。
If a Path message contains multiple CLASSTYPE objects, only the first one is meaningful; subsequent CLASSTYPE object(s) MUST be ignored and MUST NOT be forwarded.
如果路径消息包含多个类类型对象，则只有第一个有意义；必须忽略后续类类型对象，并且不得转发。
Each LSR along the path MUST record the CLASSTYPE object, when it is present, in its path state block.
路径上的每个LSR必须在其路径状态块中记录存在的类类型对象。
If the CLASSTYPE object is not present in the Path message, the LSR MUST associate the Class-Type 0 to the LSP.
如果Path消息中不存在CLASSTYPE对象，则LSR必须将类类型0与LSP关联。
The destination LSR responding to the Path message by sending a Resv message MUST NOT include a CLASSTYPE object in the Resv message (whether or not the Path message contained a CLASSTYPE object).
通过发送Resv消息响应Path消息的目标LSR不得在Resv消息中包含CLASSTYPE对象（无论Path消息是否包含CLASSTYPE对象）。
During establishment of an LSP corresponding to the Class-Type N, the LSR MUST perform admission control over the bandwidth available for that particular Class-Type.
在建立与类类型N对应的LSP期间，LSR必须对该特定类类型的可用带宽执行接纳控制。
An LSR that recognizes the CLASSTYPE object and that receives a Path message that:
识别CLASSTYPE对象并接收以下路径消息的LSR：
- contains the CLASSTYPE object, but
- 包含类类型对象，但
- does not contain a LABEL_REQUEST object or does not have a session type of LSP_Tunnel_IPv4,
- 不包含LABEL_请求对象或会话类型为LSP_Tunnel_IPv4，
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "Unexpected CLASSTYPE object". These codes are defined in Section 6.5.
必须向发送方发送路径错误，错误代码为“Diffserv aware TE error”，错误值为“意外的类类型对象”。这些代码在第6.5节中定义。
An LSR receiving a Path message with the CLASSTYPE object that:
LSR接收带有CLASSTYPE对象的路径消息，该对象：
- recognizes the CLASSTYPE object, but
- 识别CLASSTYPE对象，但
- does not support the particular Class-Type,
- 不支持特定的类类型，
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "Unsupported Class-Type". These codes are defined in Section 6.5.
必须向发件人发送路径错误，错误代码为“Diffserv aware TE error”，错误值为“Unsupported Class Type”。这些代码在第6.5节中定义。
An LSR receiving a Path message with the CLASSTYPE object that:
LSR接收带有CLASSTYPE对象的路径消息，该对象：
- recognizes the CLASSTYPE object, but
- 识别CLASSTYPE对象，但
- determines that the Class-Type value is not valid (i.e., Class-Type value 0),
- 确定类类型值无效（即类类型值0），
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "Invalid Class-Type value". These codes are defined in Section 6.5.
必须向发件人发送路径错误，错误代码为“Diffserv aware TE error”，错误值为“无效类类型值”。这些代码在第6.5节中定义。
An LSR receiving a Path message with the CLASSTYPE object, which:
接收带有CLASSTYPE对象的路径消息的LSR，其：
- recognizes the CLASSTYPE object and
- 识别类类型对象和
- supports the particular Class-Type, but
- 支持特定的类类型，但
- determines that the tuple formed by (i) this Class-Type and (ii) the setup priority signaled in the same Path message, is not one of the eight TE-Classes configured in the TE-class mapping,
- 确定由（i）该类类型和（ii）在同一路径消息中用信号表示的设置优先级形成的元组不是在TE类映射中配置的八个TE类之一，
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "CT and setup priority do not form a configured TE-Class". These codes are defined in Section 6.5.
必须向发送方发送路径错误，错误代码为“Diffserv aware TE error”，错误值为“CT和设置优先级不构成配置的TE类”。这些代码在第6.5节中定义。
An LSR receiving a Path message with the CLASSTYPE object that:
LSR接收带有CLASSTYPE对象的路径消息，该对象：
- recognizes the CLASSTYPE object and
- 识别类类型对象和
- supports the particular Class-Type, but
- 支持特定的类类型，但
- determines that the tuple formed by (i) this Class-Type and (ii) the holding priority signaled in the same Path message, is not one of the eight TE-Classes configured in the TE-class mapping,
- 确定由（i）该类类型和（ii）在同一路径消息中用信号表示的保持优先级形成的元组不是在TE类映射中配置的八个TE类之一，
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "CT and holding priority do not form a configured TE-Class". These codes are defined in Section 6.5.
必须向发送方发送路径错误，错误代码为“Diffserv aware TE error”，错误值为“CT和保持优先级不构成配置的TE类”。这些代码在第6.5节中定义。
An LSR receiving a Path message with the CLASSTYPE object that:
LSR接收带有CLASSTYPE对象的路径消息，该对象：
- recognizes the CLASSTYPE object and
- 识别类类型对象和
- supports the particular Class-Type, but
- 支持特定的类类型，但
- determines that the tuple formed by (i) this Class-Type and (ii) the setup priority signaled in the same Path message, is not one of the eight TE-Classes configured in the TE-class mapping, AND
- 确定由（i）该类类型和（ii）在同一路径消息中发出信号的设置优先级形成的元组不是在TE类映射中配置的八个TE类之一，以及
- determines that the tuple formed by (i) this Class-Type and (ii) the holding priority signaled in the same Path message, is not one of the eight TE-Classes configured in the TE-class mapping
- 确定由（i）该类类型和（ii）在同一路径消息中用信号表示的保持优先级形成的元组不是在TE类映射中配置的八个TE类之一
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "CT and setup priority do not form a configured TE-Class AND CT and holding priority do not form a configured TE-Class". These codes are defined in Section 6.5.
必须向发送方发送路径错误，错误代码为“Diffserv aware TE error”，错误值为“CT和设置优先级不构成配置的TE类，CT和保持优先级不构成配置的TE类”。这些代码在第6.5节中定义。
An LSR receiving a Path message with the CLASSTYPE object and with the DIFFSERV object for an L-LSP that:
对于L-LSP，接收带有CLASSTYPE对象和DIFFSERV对象的Path消息的LSR：
- recognizes the CLASSTYPE object,
- 识别类类型对象，
- has local knowledge of the relationship between Class-Types and Per Hop Behavior (PHB) Scheduling Class, e.g., via configuration, and
- 了解类类型和每跳行为（PHB）调度类之间的关系，例如，通过配置，以及
- determines, based on this local knowledge, that the PHB Scheduling Class (PSC) signaled in the DIFFSERV object is inconsistent with the Class-Type signaled in the CLASSTYPE object,
- 基于此局部知识，确定DIFFSERV对象中发出信号的PHB调度类（PSC）与CLASSTYPE对象中发出信号的类类型不一致，
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "Inconsistency between signaled PSC and signaled CT". These codes are defined below in Section 6.5.
必须向发送方发送路径错误，错误代码为“Diffserv aware TE error”，错误值为“信号PSC和信号CT之间不一致”。这些代码定义见下文第6.5节。
An LSR receiving a Path message with the CLASSTYPE object and with the DIFFSERV object for an E-LSP that:
对于E-LSP，接收带有CLASSTYPE对象和DIFFSERV对象的路径消息的LSR，其：
- recognizes the CLASSTYPE object,
- 识别类类型对象，
- has local knowledge of the relationship between Class-Types and PHBs (e.g., via configuration)
- 了解类类型和PHB之间的关系（例如，通过配置）
- determines, based on this local knowledge, that the PHBs signaled in the MAP entries of the DIFFSERV object are inconsistent with the Class-Type signaled in the CLASSTYPE object,
- 基于此局部知识，确定DIFFSERV对象的映射项中发出信号的PHB与CLASSTYPE对象中发出信号的类类型不一致，
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "Inconsistency between signaled PHBs and signaled CT". These codes are defined in Section 6.5.
必须向发送方发送路径错误，错误代码为“Diffserv aware TE error”，错误值为“发信号的PHB和发信号的CT之间不一致”。这些代码在第6.5节中定义。
An LSR MUST handle situations in which the LSP cannot be accepted for reasons other than those already discussed in this section, in accordance with [RSVP-TE] and [DIFF-MPLS] (e.g., a reservation is rejected by admission control, and a label cannot be associated).
LSR必须根据[RSVP-TE]和[DIFF-MPLS]处理由于本节中已讨论的原因以外的原因而无法接受LSP的情况（例如，允许控制拒绝保留，并且无法关联标签）。
An LSR that does not recognize the CLASSTYPE object Class-Num MUST behave in accordance with the procedures specified in [RSVP] for an unknown Class-Num whose format is 0bbbbbbb (i.e., it MUST send a PathErr with the error code "Unknown object class" toward the sender).
不识别CLASSTYPE object Class Num的LSR必须按照[RSVP]中为格式为0BBB的未知Class Num指定的过程进行操作（即，它必须向发送方发送错误代码为“unknown object Class”的PathErr）。
An LSR that recognizes the CLASSTYPE object Class-Num but that does not recognize the CLASSTYPE object C-Type, MUST behave in accordance with the procedures specified in [RSVP] for an unknown C-type (i.e., it MUST send a PathErr with the error code "Unknown object C-Type" toward the sender).
识别CLASSTYPE object Class Num但不识别CLASSTYPE object C-Type的LSR必须按照[RSVP]中为未知C-Type指定的过程进行操作（即，它必须向发送方发送错误代码为“unknown object C-Type”的PathErr）。
Both of the above situations cause the path setup to fail. The sender SHOULD notify the operator/management system that an LSP cannot be established and might take action to retry reservation establishment without the CLASSTYPE object.
上述两种情况都会导致路径设置失败。发送方应通知操作员/管理系统无法建立LSP，并可能采取措施在没有CLASSTYPE对象的情况下重试建立预约。
In the procedures described above, certain errors are reported as a "Diffserv-aware TE Error". The value of the "Diffserv-aware TE Error" error code is 28.
在上述过程中，某些错误被报告为“区分服务感知TE错误”。“区分服务感知TE错误”错误代码的值为28。
The following table defines error values for the Diffserv-aware TE Error:
下表定义了区分服务感知TE错误的错误值：
Value Error
值错误
1 Unexpected CLASSTYPE object 2 Unsupported Class-Type 3 Invalid Class-Type value 4 Class-Type and setup priority do not form a configured TE-Class 5 Class-Type and holding priority do not form a configured TE-Class 6 Class-Type and setup priority do not form a configured TE-Class AND Class-Type and holding priority do not form a configured TE-Class 7 Inconsistency between signaled PSC and signaled Class-Type 8 Inconsistency between signaled PHBs and signaled Class-Type
1意外的类别类型对象2不支持的类别类型3无效的类别类型值4类别类型和设置优先级不构成已配置的TE类别5类别类型和保留优先级不构成已配置的TE类别6类别类型和设置优先级不构成已配置的TE类别和类别类型，保留优先级不构成已配置的TE类别TE 7类信号PSC和8类信号PHB之间的不一致性
See the IANA Considerations section for allocation of additional values.
有关附加值的分配，请参见IANA注意事项部分。
There are a number of extensions to the initial base specification for signaling [RSVP-TE] and IGP support for TE [OSPF-TE][ISIS-TE]. Those include enhancements for generalization ([GMPLS-SIG] and [GMPLS-ROUTE]), as well as for additional functionality, such as LSP hierarchy [HIERARCHY], link bundling [BUNDLE], and fast restoration [REROUTE]. These specifications may reference how to encode information associated with certain preemption priorities, how to treat LSPs at different preemption priorities, or they may otherwise specify encodings or behavior that have a different meaning for a DS-TE router.
信令[RSVP-TE]的初始基本规范和TE[OSPF-TE][ISIS-TE]的IGP支持有许多扩展。这些包括对泛化（[GMPLS-SIG]和[GMPLS-ROUTE]）的增强，以及对附加功能的增强，如LSP层次结构[hierarchy]、链路捆绑[BUNDLE]和快速恢复[REROUTE]。这些规范可以参考如何编码与某些抢占优先级相关联的信息，如何以不同的抢占优先级处理lsp，或者它们可以以其他方式指定对DS-TE路由器具有不同含义的编码或行为。
In order for an implementation to support both this specification for Diffserv-aware TE and a given MPLS enhancement, such as those listed above (but not limited to those), it MUST treat references to "preemption priority" and to "Maximum Reservable Bandwidth" in a generalized manner, i.e., the manner in which this specification uses those terms.
为了实现支持区分服务感知TE的本规范和给定MPLS增强，例如上面列出的那些（但不限于这些），它必须以广义的方式处理对“抢占优先级”和“最大可保留带宽”的引用，即本规范使用这些术语的方式。
Additionally, current and future MPLS enhancements may include more precise specification for how they interact with Diffserv-aware TE.
此外，当前和未来的MPLS增强可能包括关于它们如何与区分服务感知TE交互的更精确规范。
When a router supports both Diffserv-aware TE and one of the MPLS protocol extensions such as those mentioned above, encoding of values of preemption priority in signaling or encoding of information associated with preemption priorities in IGP defined for the MPLS extension, MUST be considered an encoding of the same information for the corresponding TE-Class. For instance, if an MPLS enhancement specifies advertisement in IGP of a parameter for routing information at preemption priority N, in a DS-TE environment it MUST actually be interpreted as specifying advertisement of the same routing information but for TE-Class [N]. On receipt, DS-TE routers MUST also interpret it as such.
当路由器支持区分服务感知TE和如上所述的MPLS协议扩展之一时，信令中抢占优先级值的编码或为MPLS扩展定义的IGP中与抢占优先级相关联的信息的编码，必须将其视为对应TE类的相同信息的编码。例如，如果MPLS增强在IGP中指定抢占优先级为N的路由信息参数的播发，则在DS-TE环境中，它实际上必须被解释为指定相同路由信息的播发，但对于TE类[N]。在收到时，DS-TE路由器也必须这样解释。
When there is discussion on how to comparatively treat LSPs of different preemption priority, a DS-TE LSR MUST treat the preemption priorities in this context as those associated with the TE-Classes of the LSPs in question.
当讨论如何比较处理不同抢占优先级的LSP时，DS-TE LSR必须将此上下文中的抢占优先级视为与所述LSP的TE类相关联的优先级。
When a router supports both Diffserv-aware TE and MPLS protocol extensions such as those mentioned above, advertisements of Maximum Reservable Bandwidth MUST be done with the generalized interpretation defined in Section 4.1.1 as the aggregate bandwidth constraint across all Class-Types. It MAY also allow the optional advertisement of all BCs.
当路由器同时支持区分服务感知TE和MPLS协议扩展（如上文所述）时，必须使用第4.1.1节中定义为所有类别类型的聚合带宽约束的通用解释来发布最大可保留带宽。它还允许所有BC的可选广告。
Let us consider the case where a path needs to be computed for an LSP whose Class-Type is configured to CTc and whose setup preemption priority is configured to p.
让我们考虑对于类类型配置为CTC并将其设置优先权优先级配置为P的LSP需要计算路径的情况。
Then the pair of CTc and p will map to one of the TE-Classes defined in the TE-Class mapping. Let us refer to this TE-Class as TE-Class[i].
然后，CTc和p对将映射到TE类映射中定义的其中一个TE类。让我们把这个TE类称为TE类[i]。
The Constraint-Based Routing algorithm of a DS-TE LSR is still only required to perform path computation satisfying a single BC which is to fit in "Unreserved TE-Class [i]" as advertised by the IGP for every link. Thus, no changes to the existing TE Constraint-Based Routing algorithm itself are required.
DS-TE LSR的基于约束的路由算法仍然只需要执行满足单个BC的路径计算，该BC适合IGP为每个链路宣传的“无保留TE类[i]”。因此，不需要更改现有的基于TE约束的路由算法本身。
The Constraint-Based Routing algorithm MAY also take into account, when used, the optional additional information advertised in IGP such as the BCs and the Maximum Reservable Bandwidth. For example, the
当使用时，基于约束的路由算法还可以考虑IGP中公布的可选附加信息，例如BCs和最大可保留带宽。例如
BCs MIGHT be used as tie-breaker criteria in situations where multiple paths, otherwise equally attractive, are possible.
在可能存在多条路径的情况下，BCs可用作平局打破标准，否则同样具有吸引力。
The Class-Type signaled at LSP establishment MAY optionally be used by DS-TE LSRs to dynamically adjust the resources allocated to the Class-Type by the Diffserv scheduler. In addition, the Diffserv information (i.e., the PSC) signaled by the TE-LSP signaling protocols as specified in [DIFF-MPLS], if used, MAY optionally be used by DS-TE LSRs to dynamically adjust the resources allocated by the Diffserv scheduler to a PSC/OA within a CT.
在LSP建立时发信号的类类型可任选地由DS-TE lsr用于动态调整由Diffserv调度器分配给该类类型的资源。此外，如在[DIFF-MPLS]中指定的由TE-LSP信令协议发信号的Diffserv信息（即，PSC）如果被使用，则DS-TE lsr可以可选地使用该Diffserv信息来动态地调整由Diffserv调度器分配给CT内的PSC/OA的资源。
We observe that existing TE can be viewed as a particular case of DS-TE where:
我们观察到，现有TE可被视为DS-TE的一种特殊情况，其中：
(i) a single Class-Type is used, (ii) all 8 preemption priorities are allowed for that Class-Type, and (iii) the following TE-Class mapping is used: TE-Class[i] <--> < CT0 , preemption i > Where 0 <= i <= 7.
(i) 使用单个类类型，（ii）该类类型允许所有8个抢占优先级，以及（iii）使用以下TE类映射：TE类[i]<--><CT0，抢占i>，其中0<=i<=7。
In that case, DS-TE behaves as existing TE.
在这种情况下，DS-TE的行为与现有TE相同。
As with existing TE, the IGP advertises: - Unreserved Bandwidth for each of the 8 preemption priorities.
与现有TE一样，IGP宣传：-8个抢占优先级中的每一个的无保留带宽。
As with existing TE, the IGP may advertise: - Maximum Reservable Bandwidth containing a BC applying across all LSPs .
与现有TE一样，IGP可以通告：-包含应用于所有lsp的BC的最大可保留带宽。
Because all LSPs transport traffic from CT0, RSVP-TE signaling is done without explicit signaling of the Class-Type (which is only used for Class-Types other than CT0, as explained in Section 6) as with existing TE.
由于所有LSP传输来自CT0的流量，RSVP-TE信令在没有类类型明确信令的情况下完成（仅用于除CT0以外的类类型，如第6节所述），与现有TE相同。
We first observe that, for existing TE, details on admission control algorithms for TE LSPs, and consequently details on formulas for computing the unreserved bandwidth, are outside the scope of the current IETF work. This is left for vendor differentiation. Note that this does not compromise interoperability across various
我们首先观察到，对于现有TE，TE LSP的准入控制算法的细节，以及计算无保留带宽公式的细节，不在当前IETF工作的范围之内。这是留给供应商区分的。请注意，这不会影响跨多个应用程序的互操作性
implementations because the TE schemes rely on LSRs to advertise their local view of the world in terms of Unreserved Bw to other LSRs. This way, regardless of the actual local admission control algorithm used on one given LSR, Constraint-Based Routing on other LSRs can rely on advertised information to determine whether an additional LSP will be accepted or rejected by the given LSR. The only requirement is that an LSR advertises unreserved bandwidth values that are consistent with its specific local admission control algorithm and take into account the holding preemption priority of established LSPs.
因为TE方案依赖于LSR，以无保留的Bw向其他LSR宣传其本地世界视图。这样，不管在一个给定LSR上使用的实际本地接纳控制算法如何，在其他LSR上基于约束的路由可以依赖广告信息来确定附加LSP是否将被给定LSR接受或拒绝。唯一的要求是，LSR播发与其特定的本地接纳控制算法一致的无保留带宽值，并考虑已建立LSP的持有抢占优先级。
In the context of DS-TE, again, details on admission control algorithms are left for vendor differentiation, and formulas for computing the unreserved bandwidth for TE-Class[i] are outside the scope of this specification. However, DS-TE places the additional requirement on the LSR that the unreserved bandwidth values advertised MUST reflect all the BCs relevant to the CT associated with TE-Class[i] in accordance with the Bandwidth Constraints Model. Thus, formulas for computing "Unreserved TE-Class [i]" depend on the Bandwidth Constraints Model in use and MUST reflect how BCs apply to CTs. Example formulas for computing "Unreserved TE-Class [i]" Model are provided for the Russian Dolls Model and Maximum Allocation Model respectively in [DSTE-RDM] and [DSTE-MAM].
在DS-TE的上下文中，关于准入控制算法的详细信息仍然留给供应商进行区分，用于计算TE类[i]的无保留带宽的公式不在本规范的范围内。然而，DS-TE对LSR提出了附加要求，即根据带宽约束模型，公布的无保留带宽值必须反映与TE类[i]相关的CT相关的所有BC。因此，计算“无保留TE类[i]”的公式取决于使用的带宽约束模型，并且必须反映BCs如何应用于CT。[DSTE-RDM]和[DSTE-MAM]中分别为俄罗斯玩偶模型和最大分配模型提供了计算“无保留TE类[i]”模型的示例公式。
As with existing TE, DS-TE LSRs MUST consider the holding preemption priority of established LSPs (as opposed to their setup preemption priority) for the purpose of computing the unreserved bandwidth for TE-Class [i].
与现有的TE一样，DS-TE LSR必须考虑建立的LSPs的优先抢占优先级（相对于它们的设置抢占优先级），以便计算TE类[I]的未保留带宽。
A DS-TE LSR MUST support the following admission control rule:
DS-TE LSR必须支持以下准入控制规则：
Regardless of how the admission control algorithm actually computes the unreserved bandwidth for TE-Class[i] for one of its local links, an LSP of bandwidth B, of setup preemption priority p and of Class-Type CTc is admissible on that link if, and only if,:
无论许可控制算法如何实际计算TE类[i]的一个本地链路的无保留带宽，带宽B、设置抢占优先级p和类别类型CTc的LSP在该链路上是可接受的，当且仅当：
B <= Unreserved Bandwidth for TE-Class[i]
B<=TE类的未保留带宽[i]
where TE-Class [i] maps to < CTc , p > in the TE-Class mapping configured on the LSR.
其中，TE类[i]映射到LSR上配置的TE类映射中的<CTc，p>。
This document does not introduce additional security threats beyond those described for Diffserv ([DIFF-ARCH]) and MPLS Traffic Engineering ([TE-REQ], [RSVP-TE], [OSPF-TE], [ISIS-TE]) and the same
除了针对Diffserv（[DIFF-ARCH]）和MPLS流量工程（[TE-REQ]、[RSVP-TE]、[OSPF-TE]、[ISIS-TE]）所述的安全威胁外，本文件不会引入其他安全威胁，以及相同的安全威胁
security measures and procedures described in these documents apply here. For example, the approach for defense against theft- and denial-of-service attacks discussed in [DIFF-ARCH], which consists of the combination of traffic conditioning at DS boundary nodes along with security and integrity of the network infrastructure within a Diffserv domain, may be followed when DS-TE is in use. Also, as stated in [TE-REQ], it is specifically important that manipulation of administratively configurable parameters (such as those related to DS-TE LSPs) be executed in a secure manner by authorized entities.
这些文件中描述的安全措施和程序适用于此处。例如，在使用DS-TE时，可采用[DIFF-ARCH]中讨论的防盗和拒绝服务攻击防御方法，该方法包括DS边界节点处的流量调节以及Diffserv域内网络基础设施的安全性和完整性。此外，如[TE-REQ]中所述，授权实体以安全的方式执行管理可配置参数（如与DS-TE LSP相关的参数）的操作尤为重要。
This document creates two new name spaces that are to be managed by IANA. Also, a number of assignments from existing name spaces have been made by IANA in this document. They are discussed below.
本文档创建了两个新的名称空间，由IANA管理。此外，IANA在本文件中还对现有名称空间进行了大量分配。下文将讨论这些问题。
This document defines in Section 5.1 a "Bandwidth Constraints Model Id" field (name space) within the "Bandwidth Constraints" sub-TLV, both for OSPF and ISIS. The new name space has been created by the IANA and they will maintain this new name space. The field for this namespace is 1 octet, and IANA guidelines for assignments for this field are as follows:
本文件在第5.1节中为OSPF和ISIS定义了“带宽约束”子TLV中的“带宽约束模型Id”字段（名称空间）。IANA已经创建了新的名称空间，他们将维护这个新的名称空间。此名称空间的字段为1个八位字节，IANA对此字段的分配准则如下：
o values in the range 0-239 are to be assigned according to the "Specification Required" policy defined in [IANA-CONS].
o 应根据[IANA-CONS]中定义的“所需规范”政策分配0-239范围内的值。
o values in the range 240-255 are reserved for "Private Use" as defined in [IANA-CONS].
o 240-255范围内的值保留为[IANA-CONS]中定义的“专用”。
13.2. A New Name Space for Error Values under the "Diffserv-aware TE Error"
13.2. “Diffserv aware TE Error”下错误值的新名称空间
An Error Code is an 8-bit quantity defined in [RSVP] that appears in an ERROR_SPEC object to define an error condition broadly. With each Error Code there may be a 16-bit Error Value (which depends on the Error Code) that further specifies the cause of the error.
错误代码是在[RSVP]中定义的8位数量，出现在错误规范对象中，用于广泛定义错误条件。对于每个错误代码，可能有一个16位错误值（取决于错误代码），该值进一步指定了错误的原因。
This document defines in Section 6.5 a new RSVP error code, the "Diffserv-aware TE Error" (see Section 13.3.4). The Error Values for the "Diffserv-aware TE Error" constitute a new name space to be managed by IANA.
本文件在第6.5节中定义了一个新的RSVP错误代码，“区分服务感知TE错误”（见第13.3.4节）。“区分服务感知TE错误”的错误值构成一个新的名称空间，由IANA管理。
This document defines, in Section 6.5, values 1 through 7 in that name space (see Section 13.3.5).
本文件在第6.5节中定义了该名称空间中的值1至7（见第13.3.5节）。
Future allocations of values in this name space are to be assigned by IANA using the "Specification Required" policy defined in [IANA-CONS].
IANA将使用[IANA-CONS]中定义的“所需规范”策略分配此名称空间中的未来值分配。
[OSPF-TE] creates a name space for the sub-TLV types within the "Link TLV" of the Traffic Engineering Link State Advertisement (LSA) and rules for management of this name space by IANA.
[OSPF-TE]为流量工程链路状态公告（LSA）的“链路TLV”内的子TLV类型创建名称空间，并制定IANA管理该名称空间的规则。
This document defines in Section 5.1 a new sub-TLV, the "Bandwidth Constraints" sub-TLV, for the OSPF "Link" TLV. In accordance with the IANA considerations provided in [OSPF-TE], a sub-TLV type in the range 10 to 32767 was requested, and the value 17 has been assigned by IANA for the "Bandwidth Constraints" sub-TLV.
本文件在第5.1节中为OSPF“链路”TLV定义了一个新的子TLV，即“带宽约束”子TLV。根据[OSPF-TE]中提供的IANA注意事项，请求范围为10到32767的子TLV类型，IANA已为“带宽约束”子TLV分配了值17。
[ISIS-TE] creates a name space for the sub-TLV types within the ISIS "Extended IS Reachability" TLV and rules for management of this name space by IANA.
[ISIS-TE]为ISIS“扩展IS可达性”TLV中的子TLV类型创建名称空间，并制定IANA管理该名称空间的规则。
This document defines in Section 5.1 a new sub-TLV, the "Bandwidth Constraints" sub-TLV, for the ISIS "Extended IS Reachability" TLV. In accordance with the IANA considerations provided in [ISIS-TE], a sub-TLV type was requested, and the value 22 has been assigned by IANA for the "Bandwidth Constraints" sub-TLV.
本文件在第5.1节中为ISIS“扩展IS可达性”TLV定义了一个新的子TLV，“带宽约束”子TLV。根据[ISIS-TE]中提供的IANA注意事项，请求了子TLV类型，IANA为“带宽约束”子TLV分配了值22。
[RSVP] defines the Class Number name space for RSVP object, which is managed by IANA. Currently allocated Class Numbers are listed at http://www.iana.org/assignments/rsvp-parameters.
[RSVP]定义由IANA管理的RSVP对象的类号名称空间。当前分配的班级编号列在http://www.iana.org/assignments/rsvp-parameters.
This document defines in Section 6.2.1 a new RSVP object, the CLASSTYPE object. IANA has assigned a Class Number for this RSVP object from the range defined in Section 3.10 of [RSVP] for objects that, if not understood, cause the entire RSVP message to be rejected with an error code of "Unknown Object Class". Such objects are identified by a zero in the most significant bit of the class number (i.e., Class-Num = 0bbbbbbb).
本文档在第6.2.1节中定义了一个新的RSVP对象，即CLASSTYPE对象。IANA已从[RSVP]第3.10节中定义的范围为该RSVP对象分配了一个类别号，如果不理解，将导致整个RSVP消息被拒绝，错误代码为“未知对象类别”。此类对象由类编号（即，类Num=0bbb）的最高有效位中的零标识。
IANA assigned Class-Number 66 to the CLASSTYPE object. C_Type 1 is defined in this document for the CLASSTYPE object.
IANA将类号66分配给CLASSTYPE对象。C_类型1在本文档中为CLASSTYPE对象定义。
[RSVP] defines the Error Code name space and rules for management of this name space by IANA. Currently allocated Error Codes are listed at http://www.iana.org/assignments/rsvp-parameters.
[RSVP]定义错误代码名称空间和IANA管理该名称空间的规则。当前分配的错误代码列在http://www.iana.org/assignments/rsvp-parameters.
This document defines in Section 6.5 a new RSVP Error Code, the "Diffserv-aware TE Error". In accordance with the IANA considerations provided in [RSVP], Error Code 28 was assigned by IANA to the "Diffserv-aware TE Error".
本文件在第6.5节中定义了一个新的RSVP错误代码，“区分服务感知TE错误”。根据[RSVP]中提供的IANA注意事项，IANA将错误代码28分配给“区分服务感知TE错误”。
An Error Code is an 8-bit quantity defined in [RSVP] that appears in an ERROR_SPEC object to define an error condition broadly. With each Error Code there may be a 16-bit Error Value (which depends on the Error Code) that further specifies the cause of the error.
错误代码是在[RSVP]中定义的8位数量，出现在错误规范对象中，用于广泛定义错误条件。对于每个错误代码，可能有一个16位错误值（取决于错误代码），该值进一步指定了错误的原因。
This document defines in Section 6.5 a new RSVP error code, the "Diffserv-aware TE Error" (see Section 13.3.4). The Error Values for the "Diffserv-aware TE Error" constitute a new name space to be managed by IANA.
本文件在第6.5节中定义了一个新的RSVP错误代码，“区分服务感知TE错误”（见第13.3.4节）。“区分服务感知TE错误”的错误值构成一个新的名称空间，由IANA管理。
This document defines, in Section 6.5, the following Error Values for the "Diffserv-aware TE Error":
本文件在第6.5节中定义了“区分服务感知TE错误”的以下错误值：
Value Error
值错误
1 Unexpected CLASSTYPE object 2 Unsupported Class-Type 3 Invalid Class-Type value 4 Class-Type and setup priority do not form a configured TE-Class 5 Class-Type and holding priority do not form a configured TE-Class 6 Class-Type and setup priority do not form a configured TE-Class AND Class-Type and holding priority do not form a configured TE-Class 7 Inconsistency between signaled PSC and signaled Class-Type 8 Inconsistency between signaled PHBs and signaled Class-Type
1意外的类别类型对象2不支持的类别类型3无效的类别类型值4类别类型和设置优先级不构成已配置的TE类别5类别类型和保留优先级不构成已配置的TE类别6类别类型和设置优先级不构成已配置的TE类别和类别类型，保留优先级不构成已配置的TE类别TE 7类信号PSC和8类信号PHB之间的不一致性
See Section 13.2 for allocation of other values in that name space.
有关该名称空间中其他值的分配，请参见第13.2节。
We thank Martin Tatham, Angela Chiu, and Pete Hicks for their earlier contribution in this work. We also thank Sanjaya Choudhury for his thorough review and suggestions.
我们感谢Martin Tatham、Angela Chiu和Pete Hicks在这项工作中的早期贡献。我们还感谢Sanjaya Choudhury的全面审查和建议。
Appendix A: Prediction for Multiple Path Computation
附录A：多路径计算的预测
There are situations where a head-end needs to compute paths for multiple LSPs over a short period of time. There are potential advantages for the head-end in trying to predict the impact of the n-th LSP on the unreserved bandwidth when computing the path for the (n+1)-th LSP, before receiving updated IGP information. For example, better load-distribution of the multiple LSPs would be performed across multiple paths. Also, when the (n+1)-th LSP would no longer fit on a link after establishment of the n-th LSP, the head-end would avoid Connection Admission Control (CAC) rejection. Although there are a number of conceivable scenarios where worse situations might result, doing such predictions is more likely to improve situations. As a matter of fact, a number of network administrators have elected to use such predictions when deploying existing TE.
有些情况下，前端需要在短时间内计算多个LSP的路径。在接收更新的IGP信息之前，当计算第（n+1）个LSP的路径时，在尝试预测第n个LSP对无保留带宽的影响方面，对于前端来说有潜在的优势。例如，可以跨多条路径执行多个LSP的更好负载分配。此外，当在建立第n个LSP之后第（n+1）个LSP将不再适合于链路时，前端将避免连接允许控制（CAC）拒绝。尽管有许多可能导致更糟糕情况的场景，但进行此类预测更有可能改善情况。事实上，许多网络管理员已经选择在部署现有TE时使用这些预测。
Such predictions are local matters, are optional, and are outside the scope of this specification.
此类预测是局部事件，是可选的，不在本规范的范围内。
Where such predictions are not used, the optional BC sub-TLV and the optional Maximum Reservable Bandwidth sub-TLV need not be advertised in IGP for the purpose of path computation, since the information contained in the Unreserved Bw sub-TLV is all that is required by Head-Ends to perform Constraint-Based Routing.
在不使用此类预测的情况下，出于路径计算的目的，不需要在IGP中公布可选BC子TLV和可选最大可保留带宽子TLV，因为包含在无保留Bw子TLV中的信息是头端执行基于约束的路由所需的全部信息。
Where such predictions are used on head-ends, the optional BCs sub-TLV and the optional Maximum Reservable Bandwidth sub-TLV MAY be advertised in IGP. This is in order for the head-ends to predict as accurately as possible how an LSP affects unreserved bandwidth values for subsequent LSPs.
在头端上使用这种预测的情况下，可选的BCs子TLV和可选的最大可保留带宽子TLV可以在IGP中公布。这是为了使前端尽可能准确地预测LSP如何影响后续LSP的未保留带宽值。
Remembering that actual admission control algorithms are left for vendor differentiation, we observe that predictions can only be performed effectively when the head-end LSR predictions are based on the same (or a very close) admission control algorithm as that used by other LSRs.
记住，实际的准入控制算法留给供应商区分，我们观察到，只有当前端LSR预测基于与其他LSR相同（或非常接近）的准入控制算法时，预测才能有效执行。
Appendix B: Solution Evaluation
附录B：解决方案评估
This DS-TE Solution addresses all the scenarios presented in [DSTE-REQ].
此DS-TE解决方案解决了[DSTE-REQ]中提出的所有方案。
It also satisfies all the detailed requirements presented in [DSTE-REQ].
它还满足[DSTE-REQ]中提出的所有详细要求。
The objective set out in the last paragraph of Section 4.7 of [DSTE-REQ], "Overbooking", is only partially addressed by this DS-TE solution. Through support of the "LSP size Overbooking" and "Link Size Overbooking" methods, this DS-TE solution effectively allows CTs to have different overbooking ratios and simultaneously allows overbooking to be tweaked differently (collectively across all CTs) on different links. But, in a general sense, it does not allow the effective overbooking ratio of every CT to be tweaked differently in different parts of the network independently of other CTs, while maintaining accurate bandwidth accounting of how different CTs mutually affect each other through shared BCs (such as the Maximum Reservable Bandwidth).
[DSTE-REQ]第4.7节最后一段中规定的目标“超售”仅部分由DS-TE解决方案解决。通过支持“LSP大小超售”和“链路大小超售”方法，此DS-TE解决方案有效地允许CT具有不同的超售比率，同时允许在不同链路上以不同方式调整超售（在所有CT之间）。但是，在一般意义上，它不允许独立于其他CT在网络的不同部分对每个CT的有效超售比率进行不同的调整，同时保持不同CT如何通过共享BCs相互影响的准确带宽核算（例如最大可保留带宽）。
This DS-TE solution supports 8 CTs. It is entirely flexible as to how Traffic Trunks are grouped together into a CT.
此DS-TE解决方案支持8个CT。对于如何将交通干线组合成CT，它是完全灵活的。
A maximum of 8 CTs is considered more than comfortable by the authors of this document. A maximum of 8 TE-Classes is considered sufficient by the authors of this document. However, this solution could be extended to support more CTs or more TE-Classes if deemed necessary in the future; this would necessitate additional IGP extensions beyond those specified in this document.
本文件的作者认为最多8个CT是非常舒适的。本文件的作者认为最多8个TE类就足够了。但是，如果将来认为有必要，该解决方案可以扩展到支持更多CT或更多TE类；这将需要额外的IGP扩展，超出本文件规定的范围。
Although the prime objective of this solution is support of Diffserv-aware Traffic Engineering, its mechanisms are not tightly coupled with Diffserv. This makes the solution amenable, or more easily extendable, for support of potential other future Traffic Engineering applications.
尽管该解决方案的主要目标是支持区分服务感知流量工程，但其机制与区分服务之间并没有紧密耦合。这使得解决方案易于修改，或更易于扩展，以支持潜在的其他未来交通工程应用。
This DS-TE solution is expected to have a very small scalability impact compared to that of existing TE.
与现有的DS-TE解决方案相比，该DS-TE解决方案预计对可伸缩性的影响非常小。
From an IGP viewpoint, the amount of mandatory information to be advertised is identical to that of existing TE. One additional sub-TLV has been specified, but its use is optional, and it only contains a limited amount of static information (at most 8 BCs).
从IGP的角度来看，要公布的强制性信息量与现有TE的相同。已经指定了一个子TLV，但它的使用是可选的，并且它只包含有限的静态信息（最多8个BC）。
We expect no noticeable impact on LSP Path computation because, as with existing TE, this solution only requires Constrained Shortest Path First (CSPF) to consider a single unreserved bandwidth value for any given LSP.
我们期望对LSP路径计算没有明显的影响，因为与现有的TE一样，该解决方案只需要约束的最短路径优先（CSPF）考虑任何给定的LSP的单个未保留带宽值。
From a signaling viewpoint, we expect no significant impact due to this solution because it only requires processing of one additional item of information (the Class-Type) and does not significantly increase the likelihood of CAC rejection. Note that DS-TE has some inherent impact on LSP signaling in that it assumes that different classes of traffic are split over different LSPs so that more LSPs need to be signaled. However, this is due to the DS-TE concept itself and not to the actual DS-TE solution discussed here.
从信令的角度来看，我们预计该解决方案不会产生重大影响，因为它只需要处理一个额外的信息项（类类型），并且不会显著增加CAC拒绝的可能性。注意，DS-TE对LSP信令有一些固有的影响，因为它假设不同类别的业务在不同的LSP上被分割，因此需要发送更多的LSP信令。然而，这是由于DS-TE概念本身，而不是此处讨论的实际DS-TE解决方案。
This solution is expected to allow smooth migration from existing TE to DS-TE. This is because existing TE can be supported as a particular configuration of DS-TE. This means that an "upgraded" LSR with a DS-TE implementation can directly interwork with an "old" LSR supporting existing TE only.
该解决方案有望实现从现有TE到DS-TE的平滑迁移。这是因为现有TE可以作为DS-TE的特定配置来支持。这意味着具有DS-TE实现的“升级”LSR可以直接与仅支持现有TE的“旧”LSR交互。
This solution is expected to allow smooth migration when the number of CTs actually deployed is increased, as it only requires configuration changes. However, these changes need to be performed in a coordinated manner across the DS-TE domain.
当实际部署的CT数量增加时，此解决方案有望实现平滑迁移，因为它只需要更改配置。但是，这些更改需要在DS-TE域中以协调的方式执行。
Appendix C: Interoperability with Non-DS-TE Capable LSRs
附录C：与不支持DS TE的LSR的互操作性
This DSTE solution allows operations in a hybrid network where some LSRs are DS-TE capable and some are not, as may occur during migration phases. This appendix discusses the constraints and operations in such hybrid networks.
此DSTE解决方案允许在混合网络中进行操作，其中某些LSR支持DS-TE，而某些LSR不支持DS-TE，这可能在迁移阶段发生。本附录讨论了此类混合网络中的约束和操作。
We refer to the set of DS-TE-capable LSRs as the DS-TE domain. We refer to the set of non-DS-TE-capable (but TE-capable) LSRs as the TE-domain.
我们将支持DS-TE的LSR集称为DS-TE域。我们将不支持DS TE（但支持TE）的LSR集称为TE域。
Hybrid operations require that the TE-Class mapping in the DS-TE domain be configured so that:
混合操作要求配置DS-TE域中的TE类映射，以便：
- a TE-Class exists for CT0 for every preemption priority actually used in the TE domain, and
- 对于TE域中实际使用的每个抢占优先级，CT0都存在一个TE类，并且
- the index in the TE-class mapping for each of these TE-Classes is equal to the preemption priority.
- TE类映射中每个TE类的索引都等于抢占优先级。
For example, imagine the TE domain uses preemption 2 and 3. Then, DS-TE can be deployed in the same network by including the following TE-Classes in the TE-Class mapping:
例如，假设TE域使用抢占2和3。然后，通过在TE类映射中包含以下TE类，DS-TE可以部署在同一网络中：
i <---> CT preemption
====================================
2 CT0 2
3 CT0 3
i <---> CT preemption
====================================
2 CT0 2
3 CT0 3
Another way to look at this is to say that although the whole TE-class mapping does not have to be consistent with the TE domain, the subset of this TE-Class mapping applicable to CT0 effectively has to be consistent with the TE domain.
看待这一点的另一种方式是，尽管整个TE类映射不必与TE域一致，但适用于CT0的该TE类映射的子集实际上必须与TE域一致。
Hybrid operations also require that:
混合运行还要求：
- non-DS-TE-capable LSRs be configured to advertise the Maximum Reservable Bandwidth, and
- 不支持DS TE的LSR应配置为公布最大可保留带宽，以及
- DS-TE-capable LSRs be configured to advertise BCs (using the Max Reservable Bandwidth sub-TLV as well as the BCs sub-TLV, as specified in Section 5.1).
- 支持DS TE的LSR应配置为播发BCs（使用最大可保留带宽子TLV以及BCs子TLV，如第5.1节所述）。
This allows DS-TE-capable LSRs to identify non-DS-TE-capable LSRs unambiguously.
这允许支持DS TE的LSR明确标识不支持DS TE的LSR。
Finally, hybrid operations require that non-DS-TE-capable LSRs be able to accept Unreserved Bw sub-TLVs containing non decreasing bandwidth values (i.e., with Unreserved [p] < Unreserved [q] with p < q).
最后，混合操作要求不支持DS TE的LSR能够接受包含非递减带宽值的无保留Bw子TLV（即，无保留的[p]<无保留的[q]和p<q）。
In such hybrid networks, the following apply:
在此类混合网络中，以下各项适用：
- CT0 LSPs can be established by both DS-TE-capable LSRs and non-DS-TE-capable LSRs.
- CT0 LSP可以由支持DS TE的LSR和不支持DS TE的LSR建立。
- CT0 LSPs can transit via (or terminate at) both DS-TE-capable LSRs and non-DS-TE-capable LSRs.
- CT0 LSP可以通过（或终止于）支持DS TE的LSR和不支持DS TE的LSR进行传输。
- LSPs from other CTs can only be established by DS-TE-capable LSRs.
- 来自其他CT的LSP只能由支持DS TE的LSR建立。
- LSPs from other CTs can only transit via (or terminate at) DS-TE-capable LSRs.
- 来自其他CT的LSP只能通过（或终止于）支持DS TE的LSR传输。
Let us consider the following example to illustrate operations:
让我们考虑下面的例子来说明操作：
LSR0--------LSR1----------LSR2
Link01 Link12
LSR0--------LSR1----------LSR2
Link01 Link12
where: LSR0 is a non-DS-TE-capable LSR LSR1 and LSR2 are DS-TE-capable LSRs
其中：LSR0是不支持DS TE的LSR LSR1和LSR2是支持DS TE的LSR
Let's assume again that preemptions 2 and 3 are used in the TE-domain
and that the following TE-Class mapping is configured on LSR1 and
LSR2:
i <---> CT preemption
====================================
0 CT1 0
1 CT1 1
2 CT0 2
3 CT0 3
rest unused
Let's assume again that preemptions 2 and 3 are used in the TE-domain
and that the following TE-Class mapping is configured on LSR1 and
LSR2:
i <---> CT preemption
====================================
0 CT1 0
1 CT1 1
2 CT0 2
3 CT0 3
rest unused
LSR0 is configured with a Max Reservable Bandwidth = m01 for Link01. LSR1 is configured with a BC0 = x0, a BC1 = x1 (possibly = 0), and a Max Reservable Bandwidth = m10 (possibly = m01) for Link01.
对于Link01，LSR0配置了最大可保留带宽=m01。对于Link01，LSR1配置了BC0=x0、BC1=x1（可能=0）和最大可保留带宽=m10（可能=m01）。
In IGP for Link01, LSR0 will advertise:
在Link01的IGP中，LSR0将公布：
- Max Reservable Bw sub-TLV = <m01>
- 最大可保留Bw子TLV=<m01>
- Unreserved Bw sub-TLV = <CT0/0, CT0/1, CT0/2, CT0/3, CT0/4, CT0/5, CT0/6, CT0/7>
- 无保留Bw子TLV=<CT0/0、CT0/1、CT0/2、CT0/3、CT0/4、CT0/5、CT0/6、CT0/7>
On receipt of such advertisement, LSR1 will:
收到此类广告后，LSR1将：
- understand that LSR0 is not DS-TE-capable because it advertised a Max Reservable Bw sub-TLV and no Bandwidth Constraints sub-TLV, and
- 了解LSR0不支持DS TE，因为它公布了最大可保留Bw子TLV和无带宽约束子TLV，以及
- conclude that only CT0 LSPs can transit via LSR0 and that only the values CT0/2 and CT0/3 are meaningful in the Unreserved Bw sub-TLV. LSR1 may effectively behave as if the six other values contained in the Unreserved Bw sub-TLV were set to zero.
- 得出结论，只有CT0 LSP可以通过LSR0传输，并且只有值CT0/2和CT0/3在无保留Bw子TLV中有意义。LSR1可以有效地表现为将无保留Bw子TLV中包含的其他六个值设置为零。
In IGP for Link01, LSR1 will advertise:
在Link01的IGP中，LSR1将公布：
- Max Reservable Bw sub-TLV = <m10>
- 最大可保留Bw子TLV=<m10>
- Bandwidth Constraints sub-TLV = <BC Model ID, x0, x1>
- 带宽约束子TLV=<BC型号ID，x0，x1>
- Unreserved Bw sub-TLV = <CT1/0, CT1/1, CT0/2, CT0/3, 0, 0, 0, 0>
- 无保留Bw子TLV=<CT1/0、CT1/1、CT0/2、CT0/3、0、0、0、0>
On receipt of such advertisement, LSR0 will:
收到此类广告后，LSR0将：
- ignore the Bandwidth Constraints sub-TLV (unrecognized)
- 忽略子TLV的带宽约束（无法识别）
- correctly process CT0/2 and CT0/3 in the Unreserved Bw sub-TLV and use these values for CTO LSP establishment
- 正确处理无保留Bw子TLV中的CT0/2和CT0/3，并使用这些值建立CTO LSP
- incorrectly believe that the other values contained in the Unreserved Bw sub-TLV relate to other preemption priorities for CT0; but it will actually never use those since we assume that only preemptions 2 and 3 are used in the TE domain.
- 错误地认为无保留Bw子TLV中包含的其他值与CT0的其他抢占优先级有关；但它实际上永远不会使用这些，因为我们假设在TE域中只使用抢占2和3。
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月。
[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月。
[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月。
[OSPF-TE] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[OSPF-TE]Katz，D.，Kompella，K.和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[ISIS-TE]Smit，H.和T.Li，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 37842004年6月。
[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月。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[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月。
[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
资料性引用
[DIFF-ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[DIFF-ARCH]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[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月。
[DSTE-MAM] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware Traffice Engineering", RFC 4125, June 2005.
[DSTE-MAM]Le Faucheur，F.和W.Lai，“区分服务感知流量工程的最大分配带宽约束模型”，RFC 41252005年6月。
[DSTE-MAR] Ash, J., "Max Allocation with Reservation Bandwidth Constraints Model for DiffServ-aware MPLS Traffic Engineering & Performance Comparisons", RFC 4126, June 2005.
[DSTE-MAR]Ash，J.“区分服务感知MPLS流量工程和性能比较的保留带宽约束最大分配模型”，RFC 4126，2005年6月。
[GMPLS-SIG] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[GMPLS-SIG]Berger，L.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[GMPLS-ROUTE] Kompella, et al., "Routing Extensions in Support of Generalized MPLS", Work in Progress.
[GMPLS-ROUTE]Kompella等人，“支持通用MPLS的路由扩展”，正在进行中。
[BUNDLE] Kompella, Rekhter, Berger, "Link Bundling in MPLS Traffic Engineering", Work in Progress.
[BUNDLE]Kompella，Rekhter，Berger，“MPLS流量工程中的链路捆绑”，正在进行中。
[HIERARCHY] Kompella, Rekhter, "LSP Hierarchy with Generalized MPLS TE", Work in Progress.
[HIERARCHY]Kompella，Rekhter，“具有通用MPLS TE的LSP层次结构”，正在进行中。
[REROUTE] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[REROUTE]Pan，P.，Swallow，G.，和A.Atlas，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
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编辑功能的资金目前由互联网协会提供。