Network Working Group K. Kompella
Request for Comments: 4201 Y. Rekhter
Updates: 3471, 3472, 3473 Juniper Networks
Category: Standards Track L. Berger
Movaz Networks
October 2005
Network Working Group K. Kompella
Request for Comments: 4201 Y. Rekhter
Updates: 3471, 3472, 3473 Juniper Networks
Category: Standards Track L. Berger
Movaz Networks
October 2005
Link Bundling in MPLS Traffic Engineering (TE)
MPLS流量工程（TE）中的链路捆绑
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
摘要
For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling, in certain cases a combination of <link identifier, label> is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP). Such cases are handled by using the link bundling construct, which is described in this document. This document updates the interface identification TLVs, which are defined in the GMPLS Signaling Functional Description.
对于通用多协议标签交换（GMPLS）信令，在某些情况下，<link identifier，Label>的组合不足以明确标识标签交换路径（LSP）使用的适当资源。这种情况是通过使用链接绑定构造来处理的，本文对此进行了描述。本文件更新了GMPLS信令功能描述中定义的接口标识TLV。
Table of Contents
目录
1. Introduction ................................................. 2
1.1. Specification of Requirements .......................... 2
2. Link Bundling ................................................ 3
2.1. Restrictions on Bundling ............................... 4
2.2. Routing Considerations ................................. 4
2.3. Signaling Considerations ............................... 5
2.3.1. Interface Identification TLV Format ............ 6
2.3.2. Errored Component Identification ............... 7
3. Traffic Engineering Parameters for Bundled Links ............. 7
3.1. OSPF Link Type ......................................... 7
3.2. OSPF Link ID ........................................... 7
3.3. Local and Remote Interface IP Address .................. 7
3.4. Local and Remote Identifiers ........................... 8
3.5. Traffic Engineering Metric ............................. 8
3.6. Maximum Bandwidth ...................................... 8
3.7. Maximum Reservable Bandwidth ........................... 8
3.8. Unreserved Bandwidth ................................... 8
3.9. Resource Classes (Administrative Groups) ............... 8
3.10. Maximum LSP Bandwidth ................................. 8
4. Bandwidth Accounting ......................................... 9
5. Security Considerations ...................................... 9
6. IANA Considerations .......................................... 9
7. References ................................................... 10
7.1. Normative References ................................... 10
7.2. Informative References ................................. 11
1. Introduction ................................................. 2
1.1. Specification of Requirements .......................... 2
2. Link Bundling ................................................ 3
2.1. Restrictions on Bundling ............................... 4
2.2. Routing Considerations ................................. 4
2.3. Signaling Considerations ............................... 5
2.3.1. Interface Identification TLV Format ............ 6
2.3.2. Errored Component Identification ............... 7
3. Traffic Engineering Parameters for Bundled Links ............. 7
3.1. OSPF Link Type ......................................... 7
3.2. OSPF Link ID ........................................... 7
3.3. Local and Remote Interface IP Address .................. 7
3.4. Local and Remote Identifiers ........................... 8
3.5. Traffic Engineering Metric ............................. 8
3.6. Maximum Bandwidth ...................................... 8
3.7. Maximum Reservable Bandwidth ........................... 8
3.8. Unreserved Bandwidth ................................... 8
3.9. Resource Classes (Administrative Groups) ............... 8
3.10. Maximum LSP Bandwidth ................................. 8
4. Bandwidth Accounting ......................................... 9
5. Security Considerations ...................................... 9
6. IANA Considerations .......................................... 9
7. References ................................................... 10
7.1. Normative References ................................... 10
7.2. Informative References ................................. 11
For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling, in certain cases a combination of <link identifier, label> is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP). Such cases are handled by using the link bundling construct, which is described in this document. This document updates the interface identification TLVs, which are defined in the GMPLS Signaling Functional Description.
对于通用多协议标签交换（GMPLS）信令，在某些情况下，<link identifier，Label>的组合不足以明确标识标签交换路径（LSP）使用的适当资源。这种情况是通过使用链接绑定构造来处理的，本文对此进行了描述。本文件更新了GMPLS信令功能描述中定义的接口标识TLV。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
As defined in [GMPLS-ROUTING], a traffic engineering (TE) link is a logical construct that represents a way to group/map information about certain physical resources (and their properties) that interconnect LSRs with information that is used by Constrained SPF (for the purpose of path computation) and by GMPLS signaling.
如[GMPLS-ROUTING]中所定义，流量工程（TE）链路是一种逻辑结构，表示将LSR与受约束SPF（用于路径计算）和GMPLS信令使用的信息互连的特定物理资源（及其属性）的信息分组/映射的方法。
As stated in [GMPLS-ROUTING], depending on the nature of resources that form a particular TE link for the purpose of GMPLS signaling, in some cases a combination of <TE link identifier, label> is sufficient to unambiguously identify the appropriate resource used by an LSP. In other cases, a combination of <TE link identifier, label> is not sufficient. Consider, for example, a TE link between a pair of SONET/SDH cross-connects, where this TE link is composed of several fibers. In this case the label is a TDM time slot, and moreover, this time slot is significant only within a particular fiber. Thus, when signaling an LSP over such a TE link, one needs to specify not just the identity of the link, but also the identity of a particular fiber within that TE link, as well as a particular label (time slot) within that fiber. Such cases are handled by using the link bundling construct, which is described in this document.
如[GMPLS-ROUTING]中所述，根据形成用于GMPLS信令的特定TE链路的资源的性质，在某些情况下，<TE链路标识符，标签>的组合足以明确标识LSP使用的适当资源。在其他情况下，<TE link identifier，label>的组合是不够的。例如，考虑一对SONET／SDH交叉连接之间的TE链路，其中TE链路由多个光纤组成。在这种情况下，标签是TDM时隙，而且，该时隙仅在特定光纤中有效。因此，当通过这样的TE链路发送LSP信号时，不仅需要指定链路的标识，还需要指定该TE链路内的特定光纤的标识，以及该光纤内的特定标签（时隙）。这种情况是通过使用链接绑定构造来处理的，本文对此进行了描述。
Consider a TE link such that, for the purpose of GMPLS signaling, a combination of <TE link identifier, label> is not sufficient to unambiguously identify the appropriate resources used by an LSP. In this situation, the link bundling construct assumes that the set of resources that form the TE link could be partitioned into disjoint subsets, such that (a) the partition is minimal, and (b) within each subset, a label is sufficient to unambiguously identify the appropriate resources used by an LSP. We refer to such subsets as "component links", and to the whole TE link as a "bundled link". Furthermore, we restrict the identifiers that can be used to identify component links such that they are unique for a given node. On a bundled link, a combination of <component link identifier, label> is sufficient to unambiguously identify the appropriate resources used by an LSP.
考虑一个TE链接，这样，对于GMPLS信令来说，<TE链路标识符、标签>的组合不足以明确地识别LSP所使用的适当资源。在这种情况下，链路捆绑构造假设形成TE链路的资源集可以被划分为不相交的子集，这样（a）分区是最小的，并且（b）在每个子集内，标签足以明确标识LSP使用的适当资源。我们将此类子集称为“组件链接”，将整个TE链接称为“捆绑链接”。此外，我们还限制了可用于标识组件链接的标识符，以便它们对于给定节点是唯一的。在捆绑链接上，<component link identifier，label>的组合足以明确标识LSP使用的适当资源。
The partition of resources that form a bundled link into component links has to be done consistently at both ends of the bundled link. Both ends of the bundled link also have to understand the other end's component link identifiers.
将形成捆绑链接的资源划分为组件链接必须在捆绑链接的两端一致地完成。捆绑链接的两端还必须了解另一端的组件链接标识符。
The purpose of link bundling is to improve routing scalability by reducing the amount of information that has to be handled by OSPF and/or IS-IS. This reduction is accomplished by performing information aggregation/abstraction. As with any other information aggregation/abstraction, this results in losing some of the
链路绑定的目的是通过减少OSPF和/或is-is必须处理的信息量来提高路由可伸缩性。这种简化是通过执行信息聚合/抽象来实现的。与任何其他信息聚合/抽象一样，这会导致丢失一些
information. To limit the amount of losses, one needs to restrict the type of information that can be aggregated/abstracted.
信息为了限制损失的数量，需要限制可聚合/抽象的信息类型。
All component links in a bundle have the same Link Type (i.e., point-to-point or multi-access), the same Traffic Engineering metric, the same set of resource classes at each end of the links, and must begin and end on the same pair of LSRs.
捆绑包中的所有组件链路都具有相同的链路类型（即点对点或多址）、相同的流量工程度量、链路两端的相同资源类集，并且必须在同一对LSR上开始和结束。
A Forwarding Adjacency may be a component link; in fact, a bundle can consist of a mix of point-to-point links and FAs.
转发邻接可以是组件链路；事实上，捆绑包可以由点到点链接和FAs组成。
If the component links are all multi-access links, the set of IS-IS or OSPF routers that are connected to each component link must be the same, and the Designated Router for each component link must be the same. If these conditions cannot be enforced, multi-access links must not be bundled.
如果组件链路都是多址链路，则连接到每个组件链路的IS-IS或OSPF路由器集必须相同，并且每个组件链路的指定路由器必须相同。如果无法强制执行这些条件，则不得捆绑多址链路。
Component link identifiers MUST be unique across both TE and component link identifiers on a particular node. This means that unnumbered identifiers have a node-wide scope, and that numbered identifiers have the same scope as IP addresses.
组件链接标识符在特定节点上的TE和组件链接标识符之间必须是唯一的。这意味着未编号的标识符具有节点范围，且编号的标识符具有与IP地址相同的范围。
A component link may be either numbered or unnumbered. A bundled link may itself be numbered or unnumbered, independent of whether the component links of that bundled link are numbered.
组件链接可以编号，也可以不编号。捆绑链路本身可以编号或不编号，这与该捆绑链路的组件链路是否编号无关。
Handling identifiers for unnumbered component links, including the case in which a link is formed by a Forwarding Adjacency, follows the same rules as those for an unnumbered TE link (see Section "Link Identifiers" of [RFC3477]/[RFC3480]). Furthermore, link local identifiers for all unnumbered links of a given LSR (whether component links, Forwarding Adjacencies, or bundled links) MUST be unique in the context of that LSR.
处理未编号组件链接的标识符，包括由转发邻接形成链接的情况，遵循与未编号TE链接相同的规则（请参见[RFC3477]/[RFC3480]的“链接标识符”一节）。此外，给定LSR的所有未编号链接（组件链接、转发邻接或捆绑链接）的链接本地标识符在该LSR的上下文中必须是唯一的。
The "liveness" of the bundled link is determined by the liveness of each of the component links within the bundled link; a bundled link is alive when at least one of its component links is determined to be alive. The liveness of a component link can be determined by any of several means: IS-IS or OSPF hellos over the component link, RSVP Hello, LMP hellos (see [LMP]), or from layer 1 or layer 2 indications.
捆绑链接的“活跃度”由捆绑链接内每个组件链接的活跃度确定；当至少一个捆绑链接的组件链接被确定为活动链接时，捆绑链接处于活动状态。组件链路的活跃度可以通过以下几种方式中的任何一种来确定：组件链路上的IS-IS或OSPF hellos、RSVP Hello、LMP hellos（参见[LMP]）或第1层或第2层指示。
Once a bundled link is determined to be alive, it can be advertised as a TE link and the TE information can be flooded. If IS-IS/OSPF hellos are run over the component links, IS-IS/OSPF flooding can be restricted to just one of the component links. Procedures for doing this are outside the scope of this document.
一旦捆绑链接被确定为活动链接，它就可以作为TE链接进行广告，并且TE信息可以被淹没。如果IS-IS/OSPF HELLO在组件链路上运行，则IS-IS/OSPF洪泛可以仅限于其中一个组件链路。执行此操作的程序不在本文件的范围内。
In the future, as new Traffic Engineering parameters are added to IS-IS and OSPF, they should be accompanied by descriptions as to how they can be bundled, and possible restrictions on bundling.
将来，随着IS-IS和OSPF中添加新的流量工程参数，这些参数应附有关于如何捆绑的说明，以及捆绑的可能限制。
Because information about the bundled link is flooded, but information about the component links is not, typically, an LSP's ERO will identify the bundled link to be used for the LSP, but not the component link. While Discovery of component link identities to be used in an ERO is outside the scope of the document, it is envisioned that such information may be provided via configuration or via future RRO extensions. When the bundled link is identified in an ERO or is dynamically identified, the choice of the component link for the LSP is a local matter between the two LSRs at each end of the bundled link.
由于有关捆绑链路的信息被淹没，但有关组件链路的信息不被淹没，因此LSP的ERO通常会识别将用于LSP的捆绑链路，而不是组件链路。虽然要在ERO中使用的组件链接标识的发现不在本文件的范围内，但可以通过配置或未来的RRO扩展提供此类信息。当捆绑链路在ERO中被标识或被动态标识时，LSP的组件链路的选择是捆绑链路每一端的两个LSR之间的局部问题。
Signaling must identify both the component link and label to use. The choice of the component link to use is always made by the sender of the Path/REQUEST message. If an LSP is bidirectional [RFC3471], the sender chooses a component link in each direction. The handling of labels is not modified by this document.
信令必须标识要使用的组件链路和标签。要使用的组件链接的选择始终由路径/请求消息的发送者进行。如果LSP是双向的[RFC3471]，发送方在每个方向上选择一个组件链路。本文件不修改标签的处理。
Component link identifiers are carried in RSVP messages, as described in section 8 of [RFC3473]. Component link identifiers are carried in CR-LDP messages, as described in section 8 of [RFC3473]. Additional processing related to unnumbered links is described in the "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV", and "Unnumbered Forwarding Adjacencies" sections of [RFC3477]/[RFC3480].
如[RFC3473]第8节所述，RSVP消息中包含组件链路标识符。组件链路标识符载于CR-LDP消息中，如[RFC3473]第8节所述。[RFC3477]/[RFC3480]的“处理IF_ID RSVP_HOP对象”/“处理IF_ID TLV”和“未编号转发邻接”部分中描述了与未编号链路相关的附加处理。
[RFC3471] defines the Interface Identification type-length-value (TLV) types. This document specifies that the TLV types 1, 2, and 3 SHOULD be used to indicate component links in IF_ID RSVP_HOP objects and IF_ID TLVs.
[RFC3471]定义接口标识类型长度值（TLV）类型。本文档规定TLV类型1、2和3应用于指示IF_ID RSVP_HOP对象和IF_ID TLV中的组件链接。
Type 1 TLVs are used for IPv4 numbered component link identifiers.
类型1 TLV用于IPv4编号的组件链路标识符。
Type 2 TLVs are used for IPv6 numbered component link identifiers.
类型2 TLV用于IPv6编号的组件链路标识符。
Type 3 TLVs are used for unnumbered component link identifiers.
类型3 TLV用于未编号的组件链接标识符。
The Component Interface TLVs, TLV types 4 and 5, SHOULD NOT be used. Note, in Path and REQUEST messages, link identifiers MUST be specified from the sender's perspective.
不应使用组件接口TLV，TLV类型4和5。注意，在路径和请求消息中，必须从发送者的角度指定链接标识符。
Except in the special case noted below, for a unidirectional LSP, only a single TLV SHOULD be used in an IF_ID RSVP_HOP object or IF_ID TLV. This TLV indicates the component link identifier of the downstream data channel on which label allocation must be done.
除了下面提到的特殊情况外，对于单向LSP，在IF_ID RSVP_HOP对象或IF_ID TLV中只能使用单个TLV。此TLV表示下游数据通道的组件链路标识符，必须在其上进行标签分配。
Except in the special case noted below, for a bidirectional LSP, only one or two TLVs SHOULD be used in an IF_ID RSVP_HOP object or IF_ID TLV. The first TLV always indicates the component link identifier of the downstream data channel on which label allocation must be done. When present, the second TLV always indicates the component link identifier of the upstream data channel on which label allocation must be done. When only one TLV is present, it indicates the component link identifier for both downstream and upstream data channels.
除了下面提到的特殊情况外，对于双向LSP，在IF_ID RSVP_HOP对象或IF_ID TLV中只能使用一个或两个TLV。第一个TLV始终指示必须在其上进行标签分配的下游数据信道的组件链路标识符。当存在时，第二个TLV始终指示必须在其上进行标签分配的上游数据信道的组件链路标识符。当仅存在一个TLV时，它指示下游和上游数据信道的组件链路标识符。
In the special case where the same label is to be valid across all component links, two TLVs SHOULD be used in an IF_ID RSVP_HOP object or IF_ID TLV. The first TLV indicates the TE link identifier of the bundle on which label allocation must be done. The second TLV indicates a bundle scope label. For TLV types 1 and 2, this is done by using the special bit value of all ones (1) (e.g., 0xFFFFFFFF for a type 1 TLV). Per [RFC3471], for TLV types 3, 4, and 5, this is done by setting the Interface ID field to the special value 0xFFFFFFFF. Note that this special case applies to both unidirectional and bidirectional LSPs.
在同一标签在所有组件链接中都有效的特殊情况下，在IF_ID RSVP_HOP对象或IF_ID TLV中应使用两个TLV。第一个TLV表示必须在其上进行标签分配的捆绑包的TE链路标识符。第二个TLV表示捆绑范围标签。对于TLV类型1和2，这是通过使用所有类型（1）的特殊位值来完成的（例如，类型1 TLV的0xFFFFFF）。根据[RFC3471]，对于TLV类型3、4和5，这是通过将接口ID字段设置为特殊值0xFFFFFF来完成的。注意，这种特殊情况同时适用于单向和双向LSP。
Although it SHOULD NOT be used, when used, the type 5 TLV MUST NOT be the first TLV in an IF_ID RSVP_HOP object or IF_ID TLV.
虽然不应使用，但使用时，类型5 TLV不得是IF_ID RSVP_HOP对象或IF_ID TLV中的第一个TLV。
This section modifies section 9.1.1. of [RFC3471]. The definition of the IP Address field of the TLV types 3, 4, and 5 is clarified.
本节修改了第9.1.1节。属于[RFC3471]。澄清了TLV类型3、4和5的IP地址字段的定义。
For types 3, 4, and 5, the Value field has an identical format to the contents of the C-Type 1 LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477]. Note that this results in the renaming of the IP Address field defined in [RFC3471].
对于类型3、4和5，值字段的格式与[RFC3477]中定义的C-Type 1 LSP_TUNNEL_INTERFACE_ID对象的内容相同。请注意，这将导致[RFC3471]中定义的IP地址字段重命名。
When Interface Identification TLVs are used, the TLVs are also used to indicate the specific components associated with an error. For RSVP, this means that any received TLVs SHOULD be copied into the IF_ID ERROR_SPEC object (see Section 8.2 in [RFC3473]). The Error Node Address field of the object SHOULD indicate the TE Link associated with the error. For CR-LDP, this means that any received TLVs SHOULD be copied into the IF_ID Status TLV (see Section 8.2 in [RFC3472]). The HOP Address field of the TLV SHOULD indicate the TE Link associated with the error.
当使用接口标识TLV时，TLV还用于指示与错误相关的特定组件。对于RSVP，这意味着任何接收到的TLV都应复制到IF_ID ERROR_SPEC对象中（参见[RFC3473]中的第8.2节）。对象的错误节点地址字段应指示与错误关联的TE链接。对于CR-LDP，这意味着任何接收到的TLV都应复制到IF_ID状态TLV中（参见[RFC3472]中的第8.2节）。TLV的跃点地址字段应指示与错误关联的TE链路。
In this section, we define the Traffic Engineering parameters to be advertised for a bundled link, based on the configuration of the component links and of the bundled link. The definition of these parameters for component links was undertaken in [RFC3784] and [RFC3630]; we use the terminology from [RFC3630].
在本节中，我们根据组件链路和捆绑链路的配置，定义要为捆绑链路发布的流量工程参数。[RFC3784]和[RFC3630]中对组件链接的这些参数进行了定义；我们使用[RFC3630]中的术语。
The Link Type of a bundled link is the (unique) Link Type of the component links. Note that this parameter is not present in IS-IS.
捆绑链接的链接类型是组件链接的（唯一）链接类型。请注意，is-is中不存在此参数。
For point-to-point links, the Link ID of a bundled link is the (unique) Router ID of the neighbor. For multi-access links, this is the interface address of the (unique) Designated Router. Note that this parameter is not present in IS-IS.
对于点到点链路，捆绑链路的链路ID是邻居的（唯一）路由器ID。对于多址链路，这是（唯一）指定路由器的接口地址。请注意，is-is中不存在此参数。
Note that in IS-IS, the Local Interface IP Address is known as the IPv4 Interface Address and the Remote Interface IP Address is known as the IPv4 Neighbor Address.
注意，在IS-IS中，本地接口IP地址称为IPv4接口地址，远程接口IP地址称为IPv4邻居地址。
If the bundled link is numbered, the Local Interface IP Address is the local address of the bundled link; similarly, the Remote Interface IP Address is the remote address of the bundled link.
如果捆绑链路已编号，则本地接口IP地址为捆绑链路的本地地址；类似地，远程接口IP地址是捆绑链路的远程地址。
If the bundled link is unnumbered, the link local identifier is set to the identifier chosen for the bundle by the advertising LSR. The link remote identifier is set to the identifier chosen by the neighboring LSR for the reverse link corresponding to this bundle, if known; otherwise, this is set to 0.
如果捆绑链接未编号，则链接本地标识符将设置为广告LSR为捆绑选择的标识符。链路远程标识符设置为相邻LSR为对应于该捆绑的反向链路选择的标识符（如果已知）；否则，该值设置为0。
The Traffic Engineering Metric for a bundled link is that of the component links.
捆绑链路的流量工程度量是组件链路的流量工程度量。
This parameter is not used. The maximum LSP Bandwidth (as described below) replaces the Maximum Bandwidth for bundled links.
不使用此参数。最大LSP带宽（如下所述）取代捆绑链路的最大带宽。
For a given bundled link, we assume that either each of its component links is configured with the Maximum Reservable Bandwidth, or the bundled link is configured with the Maximum Reservable Bandwidth. In the former case, the Maximum Reservable Bandwidth of the bundled link is set to the sum of the Maximum Reservable Bandwidths of all component links associated with the bundled link.
对于给定的捆绑链路，我们假设其每个组件链路配置有最大可保留带宽，或者捆绑链路配置有最大可保留带宽。在前一种情况下，捆绑链路的最大可保留带宽被设置为与捆绑链路相关联的所有组件链路的最大可保留带宽之和。
The unreserved bandwidth of a bundled link at priority p is the sum of the unreserved bandwidths at priority p of all the component links associated with the bundled link.
优先级为p的捆绑链路的未保留带宽是与捆绑链路相关联的所有组件链路的优先级为p的未保留带宽之和。
The Resource Classes for a bundled link are the same as those of the component links.
捆绑链接的资源类与组件链接的资源类相同。
The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. For an unbundled link, the Maximum Bandwidth is defined in [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled link at priority p is defined to be the maximum of the Maximum LSP Bandwidth at priority p of all of its component links.
最大LSP带宽将取代最大带宽。对于非绑定链路，最大带宽在[GMPLS-ROUTING]中定义。优先级为p的捆绑链路的最大LSP带宽定义为其所有组件链路的优先级为p的最大LSP带宽的最大值。
The details of how Maximum LSP Bandwidth is carried in IS-IS is given in [GMPLS-ISIS]. The details of how Maximum LSP Bandwidth is carried in OSPF is given in [GMPLS-OSPF].
[GMPLS-ISIS]中给出了is-is中如何携带最大LSP带宽的详细信息。[GMPLS-OSPF]中给出了OSPF中如何承载最大LSP带宽的详细信息。
The RSVP (or CR-LDP) Traffic Control module, or its equivalent, on an LSR with bundled links must apply admission control on a per-component link basis. An LSP with a bandwidth requirement b and setup priority p fits in a bundled link if at least one component link has a maximum LSP bandwidth >= b at priority p. If there are several such links, the implementation will choose which link to use for the LSP.
具有捆绑链路的LSR上的RSVP（或CR-LDP）流量控制模块或其等效模块必须基于每个组件链路应用准入控制。如果至少有一个组件链路在优先级p处具有大于等于b的最大LSP带宽，则具有带宽要求b和设置优先级p的LSP适合捆绑链路。如果存在多个这样的链接，则实现将选择用于LSP的链接。
In order to know the maximum LSP bandwidth (per priority) of each component link, the Traffic Control module must track the unreserved bandwidth (per priority) for each component link.
为了了解每个组件链路的最大LSP带宽（每个优先级），流量控制模块必须跟踪每个组件链路的未保留带宽（每个优先级）。
A change in the unreserved bandwidth of a component link results in a change in the unreserved bandwidth of the bundled link. It also potentially results in a change in the maximum LSP bandwidth of the bundle; thus, the maximum LSP bandwidth should be recomputed.
组件链路的非保留带宽的变化导致捆绑链路的非保留带宽的变化。它还可能导致捆绑包的最大LSP带宽发生变化；因此，应重新计算最大LSP带宽。
If one of the component links goes down, the associated bundled link remains up and continues to be advertised, provided that at least one component link associated with the bundled link is up. The unreserved bandwidth of the component link that is down is set to zero, and the unreserved bandwidth and maximum LSP bandwidth of the bundle must be recomputed. If all the component links associated with a given bundled link are down, the bundled link MUST not be advertised into OSPF/IS-IS.
如果其中一个组件链接断开，则相关联的捆绑链接保持向上并继续播发，前提是与捆绑链接相关联的至少一个组件链接断开。关闭的组件链路的未保留带宽设置为零，必须重新计算捆绑包的未保留带宽和最大LSP带宽。如果与给定捆绑链路关联的所有组件链路都已关闭，则不得将捆绑链路播发到OSPF/IS-IS中。
This document defines ways of utilizing procedures defined in other documents, referenced herein. Any security issues related to those procedures are addressed in the referenced documents. Thus, this document raises no new security issues for RSVP-TE [RFC3209] or CR-LDP [RFC3212].
本文件定义了使用本文引用的其他文件中定义的程序的方法。与这些程序相关的任何安全问题均在参考文件中予以解决。因此，本文件不会对RSVP-TE[RFC3209]或CR-LDP[RFC3212]提出新的安全问题。
This document changes the recommended usage of two of the Interface_ID Types defined in [RFC3471]. For this reason, the IANA registry of GMPLS Signaling Parameters has been updated to read:
本文件更改了[RFC3471]中定义的两种接口ID类型的建议用法。因此，GMPLS信令参数的IANA注册表已更新为：
4 12 COMPONENT_IF_DOWNSTREAM - DEPRECATED 5 12 COMPONENT_IF_UPSTREAM - DEPRECATED
4 12组件如果下游-弃用5 12组件如果上游-弃用
[GMPLS-ISIS] Kompella, K. Ed. and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
[GMPLS-ISIS]Kompella，K.Ed.和Y.Rekhter，Ed.“支持通用多协议标签交换（GMPLS）的中间系统到中间系统（IS-IS）扩展”，RFC 4205，2005年10月。
[GMPLS-OSPF] Kompella, K. Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[GMPLS-OSPF]Kompella，K.Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，2005年10月。
[GMPLS-ROUTING] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[GMPLS-ROUTING]Kompella，K.，Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的路由扩展”，RFC 4202，2005年10月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.
[RFC3472]Ashwood Smith，P.和L.Berger，“基于广义多协议标签交换（GMPLS）信令约束的路由标签分发协议（CR-LDP）扩展”，RFC 3472，2003年1月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784]Smit，H.和T.Li，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 37842004年6月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[RFC3480] Kompella, K., Rekhter, Y., and A. Kullberg, "Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)", RFC 3480, February 2003.
[RFC3480]Kompella，K.，Rekhter，Y.，和A.Kullberg，“CR-LDP（约束路由标签分发协议）中的无编号链路信令”，RFC 3480，2003年2月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477]Kompella，K.和Y.Rekhter，“资源预留协议中未编号链路的信令-流量工程（RSVP-TE）”，RFC 3477，2003年1月。
[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月。
[RFC3209] 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.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[RFC3212]Jamoussi，B.，Andersson，L.，Callon，R.，Dantu，R.，Wu，L.，Doolan，P.，Worster，T.，Feldman，N.，Fredette，A.，Girish，M.，Gray，E.，Heinanen，J.，Kilty，T.，和A.Malis，“使用LDP的基于约束的LSP设置”，RFC 3212，2002年1月。
[LMP] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[LMP]Lang，J.，Ed.，“链路管理协议（LMP）”，RFC 4204，2005年10月。
Authors' Addresses
作者地址
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Kireeti Kompella Juniper Networks，Inc.加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089
EMail: kireeti@juniper.net
EMail: kireeti@juniper.net
Yakov Rekhter Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Yakov Rekhter Juniper Networks，Inc.加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089
EMail: yakov@juniper.net
EMail: yakov@juniper.net
Lou Berger Movaz Networks, Inc.
Lou Berger Movaz网络公司。
Phone: +1 703-847-1801
EMail: lberger@movaz.com
Phone: +1 703-847-1801
EMail: lberger@movaz.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编辑功能的资金目前由互联网协会提供。