Network Working Group D. Katz
Request for Comments: 3630 K. Kompella
Updates: 2370 Juniper Networks
Category: Standards Track D. Yeung
Procket Networks
September 2003
Network Working Group D. Katz
Request for Comments: 3630 K. Kompella
Updates: 2370 Juniper Networks
Category: Standards Track D. Yeung
Procket Networks
September 2003
Traffic Engineering (TE) Extensions to OSPF Version 2
OSPF版本2的流量工程（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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.
本文档描述了OSPF协议版本2的扩展，以支持使用不透明链路状态播发的区域内流量工程（TE）。
This document specifies a method of adding traffic engineering capabilities to OSPF Version 2 [1]. The architecture of traffic engineering is described in [5]. The semantic content of the extensions is essentially identical to the corresponding extensions to IS-IS [6]. It is expected that the traffic engineering extensions to OSPF will continue to mirror those in IS-IS.
本文件规定了向OSPF版本2[1]添加流量工程功能的方法。交通工程的体系结构如[5]所述。扩展的语义内容基本上与is-is的相应扩展相同[6]。预计OSPF的流量工程扩展将继续反映is-is中的扩展。
The extensions provide a way of describing the traffic engineering topology (including bandwidth and administrative constraints) and distributing this information within a given OSPF area. This topology does not necessarily match the regular routed topology, though this proposal depends on Network LSAs to describe multi-access links. This document purposely does not say how the mechanisms described here can be used for traffic engineering across multiple OSPF areas; that task is left to future documents. Furthermore, no changes have been made to the operation of OSPFv2 flooding; in
这些扩展提供了一种描述流量工程拓扑（包括带宽和管理约束）的方法，并在给定的OSPF区域内分发这些信息。此拓扑不一定与常规路由拓扑匹配，尽管此方案依赖于网络LSA来描述多址链路。本文件无意说明如何将此处描述的机制用于跨多个OSPF区域的流量工程；这项任务留给今后的文件处理。此外，OSPFv2注水系统的运行没有任何变化；在里面
particular, if non-TE capable nodes exist in the topology, they MUST flood TE LSAs as any other type 10 (area-local scope) Opaque LSAs (see [3]).
特别是，如果拓扑中存在不支持TE的节点，则它们必须像任何其他类型10（区域局部范围）不透明LSA一样使用TE LSA（请参见[3]）。
Many of the extensions specified in this document are in response to the requirements stated in [5], and thus are referred to as "traffic engineering extensions", and are also commonly associated with MPLS Traffic Engineering. A more accurate (albeit bland) designation is "extended link attributes", as the proposal is to simply add more attributes to links in OSPF advertisements.
本文件中规定的许多扩展是对[5]中所述要求的响应，因此被称为“流量工程扩展”，通常也与MPLS流量工程相关。一个更准确（尽管平淡无奇）的名称是“扩展链接属性”，因为该建议只是在OSPF广告中为链接添加更多属性。
The information made available by these extensions can be used to build an extended link state database just as router LSAs are used to build a "regular" link state database; the difference is that the extended link state database (referred to below as the traffic engineering database) has additional link attributes. Uses of the traffic engineering database include:
这些扩展提供的信息可用于构建扩展链路状态数据库，就像路由器LSA用于构建“常规”链路状态数据库一样；不同之处在于，扩展链路状态数据库（以下称为流量工程数据库）具有额外的链路属性。交通工程数据库的用途包括：
o monitoring the extended link attributes; o local constraint-based source routing; and o global traffic engineering.
o 监控扩展链路属性；o基于局部约束的源路由；o全球交通工程。
For example, an OSPF-speaking device can participate in an OSPF area, build a traffic engineering database, and thereby report on the reservation state of links in that area.
例如，说OSPF的设备可以参与OSPF区域，建立流量工程数据库，从而报告该区域中链路的保留状态。
In "local constraint-based source routing", a router R can compute a path from a source node A to a destination node B; typically, A is R itself, and B is specified by a "router address" (see below). This path may be subject to various constraints on the attributes of the links and nodes that the path traverses, e.g., use green links that have unreserved bandwidth of at least 10Mbps. This path could then be used to carry some subset of the traffic from A to B, forming a simple but effective means of traffic engineering. How the subset of traffic is determined, and how the path is instantiated, is beyond the scope of this document; suffice it to say that one means of defining the subset of traffic is "those packets whose IP destinations were learned from B", and one means of instantiating paths is using MPLS tunnels. As an aside, note that constraint-based routing can be NP-hard, or even unsolvable, depending on the nature of the attributes and constraints, and thus many implementations will use heuristics. Consequently, we don't attempt to sketch an algorithm here.
在“基于局部约束的源路由”中，路由器R可以计算从源节点a到目的节点B的路径；通常，A是R本身，B由“路由器地址”指定（见下文）。该路径可能受到路径所穿越的链路和节点属性的各种约束，例如，使用具有至少10Mbps的无保留带宽的绿色链路。然后，可以使用该路径将某些流量子集从A传送到B，从而形成一种简单但有效的流量工程方法。如何确定流量子集以及如何实例化路径超出了本文档的范围；可以这样说，定义流量子集的一种方法是“从B学习其IP目的地的那些分组”，实例化路径的一种方法是使用MPLS隧道。另外，请注意，基于约束的路由可能是NP难的，甚至是无法解决的，这取决于属性和约束的性质，因此许多实现将使用启发式。因此，我们不尝试在这里绘制算法。
Finally, for "global traffic engineering", a device can build a traffic engineering database, input a traffic matrix and an optimization function, crunch on the information, and thus compute optimal or near-optimal routing for the entire network. The device can subsequently monitor the traffic engineering topology and react to changes by recomputing the optimal routes.
最后，对于“全局流量工程”，设备可以建立流量工程数据库，输入流量矩阵和优化函数，处理信息，从而计算整个网络的最优或接近最优路由。该设备随后可以监控交通工程拓扑，并通过重新计算最佳路线对变化作出反应。
As mentioned above, this document specifies extensions and procedures for intra-area distribution of Traffic Engineering information. Methods for inter-area and inter-AS (Autonomous System) distribution are not discussed here.
如上所述，本文件规定了交通工程信息区域内分发的扩展和程序。这里不讨论区域间和区域间AS（自治系统）分布的方法。
The extensions specified in this document capture the reservation state of point-to-point links. The reservation state of multi-access links may not be accurately reflected, except in the special case in which there are only two devices in the multi-access subnetwork. Operation over multi-access networks with more than two devices is not specifically prohibited. A more accurate description of the reservation state of multi-access networks is for further study.
本文档中指定的扩展捕获点到点链接的保留状态。多址链路的保留状态可能无法准确反映，除非在多址子网中只有两个设备的特殊情况下。没有明确禁止在具有两个以上设备的多址网络上进行操作。更准确地描述多址网络的预约状态还有待进一步研究。
This document also does not support unnumbered links. This deficiency will be addressed in future documents; see also [7] and [8].
本文档也不支持未编号的链接。这一缺陷将在今后的文件中予以解决；另见[7]和[8]。
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 BCP 14, RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。
This extension makes use of the Opaque LSA [3].
此扩展使用不透明LSA[3]。
Three types of Opaque LSAs exist, each of which has a different flooding scope. This proposal uses only Type 10 LSAs, which have an area flooding scope.
存在三种不透明LSA，每种LSA具有不同的泛洪范围。本提案仅使用10型LSA，其具有区域泛洪范围。
One new LSA is defined, the Traffic Engineering LSA. This LSA describes routers, point-to-point links, and connections to multi-access networks (similar to a Router LSA). For traffic engineering purposes, the existing Network LSA is sufficient for describing multi-access links, so no additional LSA is defined for this purpose.
定义了一种新的LSA，即流量工程LSA。此LSA描述路由器、点对点链路和到多址网络的连接（类似于路由器LSA）。出于流量工程的目的，现有的网络LSA足以描述多接入链路，因此没有为此目的定义额外的LSA。
The LSA ID of an Opaque LSA is defined as having eight bits of type data and 24 bits of type-specific data. The Traffic Engineering LSA uses type 1. The remaining 24 bits are the Instance field, as follows:
不透明LSA的LSA ID定义为具有8位类型数据和24位类型特定数据。交通工程LSA使用类型1。剩余的24位是实例字段，如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Instance field is an arbitrary value used to maintain multiple Traffic Engineering LSAs. A maximum of 16777216 Traffic Engineering LSAs may be sourced by a single system. The LSA ID has no topological significance.
实例字段是用于维护多个流量工程LSA的任意值。单个系统最多可提供16777216个流量工程LSA。LSA ID没有拓扑意义。
The Traffic Engineering LSA starts with the standard LSA header:
流量工程LSA从标准LSA标头开始：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LSA payload consists of one or more nested Type/Length/Value (TLV) triplets for extensibility. The format of each TLV is:
LSA有效负载由一个或多个嵌套类型/长度/值（TLV）三元组组成，以实现可扩展性。每个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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of zero). The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value would have a length of three, but the total size of the TLV would be eight octets). Nested TLVs are also 32-bit aligned. Unrecognized types are ignored.
长度字段以八位字节定义值部分的长度（因此，没有值部分的TLV的长度为零）。TLV填充为四个八位组对齐；长度字段中不包括填充（因此三个八位字节的值的长度为三，但TLV的总大小为八个八位字节）。嵌套TLV也是32位对齐的。将忽略无法识别的类型。
This memo defines Types 1 and 2. See the IANA Considerations section for allocation of new Types.
本备忘录定义了类型1和类型2。有关新类型的分配，请参见IANA注意事项部分。
An LSA contains one top-level TLV.
LSA包含一个顶级TLV。
There are two top-level TLVs defined:
定义了两个顶级TLV：
1 - Router Address 2 - Link
1-路由器地址2-链路
The Router Address TLV specifies a stable IP address of the advertising router that is always reachable if there is any connectivity to it; this is typically implemented as a "loopback address". The key attribute is that the address does not become unusable if an interface is down. In other protocols, this is known as the "router ID," but for obvious reasons this nomenclature is avoided here. If a router advertises BGP routes with the BGP next hop attribute set to the BGP router ID, then the Router Address SHOULD be the same as the BGP router ID.
路由器地址TLV指定广告路由器的稳定IP地址，如果有任何连接，则该地址始终可访问；这通常实现为“环回地址”。关键属性是，如果接口关闭，地址不会变得不可用。在其他协议中，这被称为“路由器ID”，但出于显而易见的原因，这里避免使用这种命名法。如果路由器播发BGP路由时将BGP下一跳属性设置为BGP路由器ID，则路由器地址应与BGP路由器ID相同。
If IS-IS is also active in the domain, this address can also be used to compute the mapping between the OSPF and IS-IS topologies. For example, suppose a router R is advertising both IS-IS and OSPF Traffic Engineering LSAs, and suppose further that some router S is building a single Traffic Engineering Database (TED) based on both IS-IS and OSPF TE information. R may then appear as two separate nodes in S's TED. However, if both the IS-IS and OSPF LSAs generated by R contain the same Router Address, then S can determine that the IS-IS TE LSA and the OSPF TE LSA from R are indeed from a single router.
如果IS-IS在域中也处于活动状态，则此地址也可用于计算OSPF和IS-IS拓扑之间的映射。例如，假设路由器R正在宣传is-is和OSPF流量工程lsa，并且进一步假设一些路由器S正在基于is-is和OSPF-TE信息构建单个流量工程数据库（TED）。然后，R可能会在S的TED中显示为两个单独的节点。然而，如果由R生成的IS-IS和OSPF LSA都包含相同的路由器地址，则S可以确定来自R的IS-IS TE LSA和OSPF TE LSA确实来自单个路由器。
The router address TLV is type 1, has a length of 4, and a value that is the four octet IP address. It must appear in exactly one Traffic Engineering LSA originated by a router.
路由器地址TLV为类型1，长度为4，值为四个八位字节的IP地址。它必须出现在路由器发起的一个流量工程LSA中。
The Link TLV describes a single link. It is constructed of a set of sub-TLVs. There are no ordering requirements for the sub-TLVs.
链路TLV描述单个链路。它由一组子TLV构成。子TLV没有订购要求。
Only one Link TLV shall be carried in each LSA, allowing for fine granularity changes in topology.
每个LSA中仅应携带一个链路TLV，允许拓扑中的细粒度变化。
The Link TLV is type 2, and the length is variable.
链路TLV为类型2，长度可变。
The following sub-TLVs of the Link TLV are defined:
定义了链路TLV的以下子TLV：
1 - Link type (1 octet) 2 - Link ID (4 octets) 3 - Local interface IP address (4 octets) 4 - Remote interface IP address (4 octets) 5 - Traffic engineering metric (4 octets) 6 - Maximum bandwidth (4 octets) 7 - Maximum reservable bandwidth (4 octets) 8 - Unreserved bandwidth (32 octets) 9 - Administrative group (4 octets)
1-链路类型（1个八位字节）2-链路ID（4个八位字节）3-本地接口IP地址（4个八位字节）4-远程接口IP地址（4个八位字节）5-流量工程度量（4个八位字节）6-最大带宽（4个八位字节）7-最大可保留带宽（4个八位字节）8-无保留带宽（32个八位字节）9-管理组（4个八位字节）
This memo defines sub-Types 1 through 9. See the IANA Considerations section for allocation of new sub-Types.
本备忘录定义了子类型1至9。有关新子类型的分配，请参见IANA注意事项部分。
The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear exactly once. All other sub-TLVs defined here may occur at most once. These restrictions need not apply to future sub-TLVs. Unrecognized sub-TLVs are ignored.
链接类型和链接ID子TLV是必需的，即必须只出现一次。此处定义的所有其他子TLV最多只能出现一次。这些限制不必适用于未来的子TLV。忽略未识别的子TLV。
Various values below use the (32 bit) IEEE Floating Point format. For quick reference, this format is as follows:
下面的各种值使用（32位）IEEE浮点格式。为便于快速参考，此格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Exponent | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Exponent | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S is the sign, Exponent is the exponent base 2 in "excess 127" notation, and Fraction is the mantissa - 1, with an implied binary point in front of it. Thus, the above represents the value:
S是符号，指数是以“超额127”表示法为基数的指数2，分数是尾数-1，前面有一个隐含的二进制点。因此，上述值表示：
(-1)**(S) * 2**(Exponent-127) * (1 + Fraction)
(-1)**(S) * 2**(Exponent-127) * (1 + Fraction)
For more details, refer to [4].
有关更多详细信息，请参阅[4]。
The Link Type sub-TLV defines the type of the link:
链路类型子TLV定义链路的类型：
1 - Point-to-point 2 - Multi-access
1-点对点2-多址
The Link Type sub-TLV is TLV type 1, and is one octet in length.
链路类型子TLV为TLV类型1，长度为一个八位组。
The Link ID sub-TLV identifies the other end of the link. For point-to-point links, this is the Router ID of the neighbor. For multi-access links, this is the interface address of the designated router. The Link ID is identical to the contents of the Link ID field in the Router LSA for these link types.
链路ID子TLV标识链路的另一端。对于点到点链路，这是邻居的路由器ID。对于多址链路，这是指定路由器的接口地址。对于这些链路类型，链路ID与路由器LSA中链路ID字段的内容相同。
The Link ID sub-TLV is TLV type 2, and is four octets in length.
链路ID子TLV为TLV类型2，长度为四个八位字节。
The Local Interface IP Address sub-TLV specifies the IP address(es) of the interface corresponding to this link. If there are multiple local addresses on the link, they are all listed in this sub-TLV.
本地接口IP地址子TLV指定与此链接对应的接口的IP地址。如果链路上有多个本地地址，则它们都列在此子TLV中。
The Local Interface IP Address sub-TLV is TLV type 3, and is 4N octets in length, where N is the number of local addresses.
本地接口IP地址子TLV为TLV类型3，长度为4N个八位字节，其中N为本地地址数。
The Remote Interface IP Address sub-TLV specifies the IP address(es) of the neighbor's interface corresponding to this link. This and the local address are used to discern multiple parallel links between systems. If the Link Type of the link is Multi-access, the Remote Interface IP Address is set to 0.0.0.0; alternatively, an implementation MAY choose not to send this sub-TLV.
远程接口IP地址子TLV指定与此链接对应的邻居接口的IP地址。此地址和本地地址用于识别系统之间的多个并行链路。如果链路的链路类型为多址，则远程接口IP地址设置为0.0.0.0；或者，实现可以选择不发送该子TLV。
The Remote Interface IP Address sub-TLV is TLV type 4, and is 4N octets in length, where N is the number of neighbor addresses.
远程接口IP地址子TLV为TLV类型4，长度为4N个八位字节，其中N是邻居地址的数量。
The Traffic Engineering Metric sub-TLV specifies the link metric for traffic engineering purposes. This metric may be different than the standard OSPF link metric. Typically, this metric is assigned by a network administrator.
交通工程度量sub-TLV指定用于交通工程目的的链路度量。此度量可能不同于标准OSPF链路度量。通常，此指标由网络管理员指定。
The Traffic Engineering Metric sub-TLV is TLV type 5, and is four octets in length.
子TLV的流量工程度量为TLV类型5，长度为四个八位字节。
The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that can be used on this link, in this direction (from the system originating the LSA to its neighbor), in IEEE floating point format. This is the true link capacity. The units are bytes per second.
Maximum Bandwidth sub TLV以IEEE浮点格式指定此链路在该方向（从发起LSA的系统到其邻居）上可使用的最大带宽。这是真正的链路容量。单位为每秒字节数。
The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in length.
子TLV的最大带宽为TLV类型6，长度为四个八位字节。
The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link, in this direction, in IEEE floating point format. Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). This SHOULD be user-configurable; the default value should be the Maximum Bandwidth. The units are bytes per second.
Maximum Reservable Bandwidth sub TLV以IEEE浮点格式指定此链路上沿此方向可保留的最大带宽。请注意，这可能大于最大带宽（在这种情况下，链路可能被超额订阅）。这应该是用户可配置的；默认值应为最大带宽。单位为每秒字节数。
The Maximum Reservable Bandwidth sub-TLV is TLV type 7, and is four octets in length.
子TLV的最大可保留带宽为TLV类型7，长度为四个八位字节。
The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved at each of the eight priority levels in IEEE floating point format. The values correspond to the bandwidth that can be reserved with a setup priority of 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub-TLV, and priority 7 at the end of the sub-TLV. The initial values (before any bandwidth is reserved) are all set to the Maximum Reservable Bandwidth. Each value will be less than or equal to the Maximum Reservable Bandwidth. The units are bytes per second.
Unreserved Bandwidth sub TLV指定在IEEE浮点格式的八个优先级中的每个优先级上尚未保留的带宽量。这些值对应于可保留的带宽，设置优先级为0到7，按递增顺序排列，优先级0出现在子TLV的开始处，优先级7出现在子TLV的结束处。初始值（保留任何带宽之前）均设置为最大可保留带宽。每个值都将小于或等于最大可保留带宽。单位为每秒字节数。
The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets in length.
无保留带宽子TLV为TLV类型8，长度为32个八位字节。
The Administrative Group sub-TLV contains a 4-octet bit mask assigned by the network administrator. Each set bit corresponds to one administrative group assigned to the interface. A link may belong to multiple groups.
管理组子TLV包含由网络管理员分配的4位八位元掩码。每个设置位对应于分配给接口的一个管理组。链接可能属于多个组。
By convention, the least significant bit is referred to as 'group 0', and the most significant bit is referred to as 'group 31'.
按照惯例，最低有效位称为“组0”，最高有效位称为“组31”。
The Administrative Group is also called Resource Class/Color [5].
管理组也称为资源类/颜色[5]。
The Administrative Group sub-TLV is TLV type 9, and is four octets in length.
管理组子TLV为TLV类型9，长度为四个八位字节。
Routers shall originate Traffic Engineering LSAs whenever the LSA contents change, and whenever otherwise required by OSPF (an LSA refresh, for example). Note that this does not mean that every change must be flooded immediately; an implementation MAY set thresholds (for example, a bandwidth change threshold) that trigger immediate flooding, and initiate flooding of other changes after a short time interval. In any case, the origination of Traffic Engineering LSAs SHOULD be rate-limited to at most one every MinLSInterval [1].
当LSA内容发生变化时，以及OSPF要求时（例如LSA刷新），路由器应发起流量工程LSA。注意，这并不意味着每一个变更都必须立即被淹没；实现可以设置触发立即泛洪的阈值（例如，带宽更改阈值），并在短时间间隔后启动其他更改的泛洪。在任何情况下，流量工程LSA的发起速率应限制为每分钟间隔最多一次[1]。
Upon receipt of a changed Traffic Engineering LSA or Network LSA (since these are used in traffic engineering calculations), the router should update its traffic engineering database. No Shortest Path First (SPF) or other route calculations are necessary.
在收到更改的流量工程LSA或网络LSA（因为它们用于流量工程计算）后，路由器应更新其流量工程数据库。无需进行最短路径优先（SPF）或其他路线计算。
There should be no interoperability issues with routers that do not implement these extensions, as the Opaque LSAs will be silently ignored.
不实现这些扩展的路由器不应该存在互操作性问题，因为不透明的LSA将被默默地忽略。
The result of having routers that do not implement these extensions is that the traffic engineering topology will be missing pieces. However, if the topology is connected, TE paths can still be calculated and ought to work.
如果路由器没有实现这些扩展，那么流量工程拓扑就会丢失。但是，如果拓扑是连接的，则仍然可以计算TE路径，并且应该可以工作。
This document specifies the contents of Opaque LSAs in OSPFv2. As Opaque LSAs are not used for SPF computation or normal routing, the extensions specified here have no affect on IP routing. However, tampering with TE LSAs may have an effect on traffic engineering computations, and it is suggested that any mechanisms used for securing the transmission of normal OSPF LSAs be applied equally to all Opaque LSAs, including the TE LSAs specified here.
本文件规定了OSPFv2中不透明LSA的内容。由于不透明LSA不用于SPF计算或正常路由，因此此处指定的扩展对IP路由没有影响。然而，篡改TE LSA可能会对流量工程计算产生影响，并且建议用于确保正常OSPF LSA传输的任何机制应平等地应用于所有不透明LSA，包括此处规定的TE LSA。
Note that the mechanisms in [1] and [9] apply to Opaque LSAs. It is suggested that any future mechanisms proposed to secure/authenticate OSPFv2 LSA exchanges be made general enough to be used with Opaque LSAs.
注意，[1]和[9]中的机制适用于不透明LSA。建议将来提出的任何保护/认证OSPFv2 LSA交换的机制应足够通用，以便与不透明LSA一起使用。
The top level Types in a TE LSA, as well as Types for sub-TLVs for each top level Type, have been registered with IANA, except as noted.
TE LSA中的顶级类型以及每个顶级类型的子TLV类型已向IANA注册，除非另有说明。
Here are the guidelines (using terms defined in [10]) for the assignment of top level Types in TE LSAs:
以下是在TE LSA中分配顶级类型的指南（使用[10]中定义的术语）：
o Types in the range 3-32767 are to be assigned via Standards Action.
o 3-32767范围内的类型将通过标准行动进行分配。
o Types in the range 32768-32777 are for experimental use; these will not be registered with IANA, and MUST NOT be mentioned by RFCs.
o 32768-32777范围内的类型用于实验用途；这些将不会在IANA注册，RFC不得提及。
o Types in the range 32778-65535 are not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations that covers the range being assigned.
o 此时不分配32778-65535范围内的类型。在此范围内进行任何分配之前，必须有一个标准跟踪RFC，指定涵盖所分配范围的IANA注意事项。
The guidelines for the assignment of types for sub-TLVs in a TE LSA are as follows:
TE LSA子TLV类型分配指南如下：
o Types in the range 10-32767 are to be assigned via Standards Action.
o 范围为10-32767的类型将通过标准行动进行分配。
o Types in the range 32768-32777 are for experimental use; these will not be registered with IANA, and MUST NOT be mentioned by RFCs.
o 32768-32777范围内的类型用于实验用途；这些将不会在IANA注册，RFC不得提及。
o Types in the range 32778-65535 are not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations that covers the range being assigned.
o 此时不分配32778-65535范围内的类型。在此范围内进行任何分配之前，必须有一个标准跟踪RFC，指定涵盖所分配范围的IANA注意事项。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
[1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[1] Moy，J.，“OSPF版本2”，STD 54，RFC 23281998年4月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.
[3] Coltun，R.，“OSPF不透明LSA选项”，RFC 23701998年7月。
[4] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593-7653-8).
[4] IEEE，“二进制浮点运算的IEEE标准”，标准754-1985，1985（ISBN 1-5593-7653-8）。
[5] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[5] Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[6] Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering", work in progress.
[6] Smit，H.和T.Li，“ISIS交通工程扩展”，正在进行中。
[7] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[7] Kompella，K.和Y.Rekhter，“资源预留协议中未编号链路的信令-流量工程（RSVP-TE）”，RFC 3477，2003年1月。
[8] Kompella, K., Rekhter, Y. and A. Kullberg, "Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)", RFC 3480, February 2003.
[8] Kompella，K.，Rekhter，Y.和A.Kullberg，“CR-LDP（约束路由标签分发协议）中的无编号链路信令”，RFC 3480，2003年2月。
[9] Murphy, S., Badger, M. and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[9] Murphy，S.，Badger，M.和B.Wellington，“具有数字签名的OSPF”，RFC 2154，1997年6月。
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[10] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
Dave Katz Juniper Networks美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089
Phone: +1 408 745 2000
EMail: dkatz@juniper.net
Phone: +1 408 745 2000
EMail: dkatz@juniper.net
Derek M. Yeung Procket Networks, Inc. 1100 Cadillac Court Milpitas, CA 95035 USA
Derek M.Yeung Procket Networks，Inc.美国加利福尼亚州米尔皮塔斯市凯迪拉克球场1100号，邮编95035
Phone: +1 408 635-7900
EMail: myeung@procket.com
Phone: +1 408 635-7900
EMail: myeung@procket.com
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
Kireeti Kompella Juniper Networks 1194 N.Mathilda Ave.Sunnyvale，加利福尼亚州94089
Phone: +1 408 745 2000
EMail: kireeti@juniper.net
Phone: +1 408 745 2000
EMail: kireeti@juniper.net
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。