Network Working Group K. Kompella, Ed.
Request for Comments: 4203 Y. Rekhter, Ed.
Updates: 3630 Juniper Networks
Category: Standards Track October 2005
Network Working Group K. Kompella, Ed.
Request for Comments: 4203 Y. Rekhter, Ed.
Updates: 3630 Juniper Networks
Category: Standards Track October 2005
OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
支持通用多协议标签交换（GMPLS）的OSPF扩展
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 encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS).
本文件规定了OSPF路由协议扩展的编码，以支持通用多协议标签交换（GMPLS）。
This document specifies extensions to the OSPF routing protocol [OSPF] in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). The set of required enhancements to OSPF are outlined in [GMPLS-ROUTING].
本文件规定了OSPF路由协议[OSPF]的扩展，以支持承载通用多协议标签交换（GMPLS）的链路状态信息。[GMPLS-ROUTING]中概述了OSPF所需的一系列增强功能。
In this section, we define the enhancements to the Traffic Engineering (TE) properties of GMPLS TE links that can be announced in OSPF TE LSAs. The TE LSA, which is an opaque LSA with area flooding scope [OSPF-TE], has only one top-level Type/Length/Value (TLV) triplet and has one or more nested sub-TLVs for extensibility. The top-level TLV can take one of two values (1) Router Address or (2) Link. In this document, we enhance the sub-TLVs for the Link TLV in support of GMPLS. Specifically, we add the following sub-TLVs to the Link TLV:
在本节中，我们定义了可以在OSPF TE LSA中宣布的GMPLS TE链路的流量工程（TE）特性的增强。TE LSA是具有区域泛洪作用域[OSPF-TE]的不透明LSA，只有一个顶级类型/长度/值（TLV）三元组，并且具有一个或多个嵌套子TLV以实现扩展性。顶级TLV可以采用两个值之一（1）路由器地址或（2）链路。在本文中，我们增强了链路TLV的子TLV，以支持GMPLS。具体而言，我们将以下子TLV添加到链路TLV：
Sub-TLV Type Length Name 11 8 Link Local/Remote Identifiers 14 4 Link Protection Type 15 variable Interface Switching Capability Descriptor 16 variable Shared Risk Link Group
子TLV类型长度名称11 8链路本地/远程标识符14 4链路保护类型15可变接口交换能力描述符16可变共享风险链路组
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
Link Local/Remote Identifiers is a sub-TLV of the Link TLV. The type of this sub-TLV is 11, and length is eight octets. The value field of this sub-TLV contains four octets of Link Local Identifier followed by four octets of Link Remote Identifier (see Section "Support for unnumbered links" of [GMPLS-ROUTING]). If the Link Remote Identifier is unknown, it is set to 0.
链路本地/远程标识符是链路TLV的子TLV。该子TLV的类型为11，长度为8个八位字节。此子TLV的值字段包含链路本地标识符的四个八位字节，后跟链路远程标识符的四个八位字节（请参阅[GMPLS-ROUTING]的“支持未编号链路”一节）。如果链接远程标识符未知，则将其设置为0。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Remote Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Remote Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A node can communicate its Link Local Identifier to its neighbor using a link local Opaque LSA, as described in Section "Exchanging Link Local TE Information".
节点可以使用链路本地不透明LSA将其链路本地标识符传送给其邻居，如“交换链路本地TE信息”部分所述。
The Link Protection Type is a sub-TLV of the Link TLV. The type of this sub-TLV is 14, and length is four octets.
链路保护类型是链路TLV的子TLV。该子TLV的类型为14，长度为四个八位字节。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protection Cap | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protection Cap | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first octet is a bit vector describing the protection capabilities of the link (see Section "Link Protection Type" of [GMPLS-ROUTING]). They are:
第一个八位组是描述链路保护能力的位向量（参见[GMPLS-ROUTING]的“链路保护类型”一节）。他们是：
0x01 Extra Traffic
0x01额外流量
0x02 Unprotected
0x02未受保护
0x04 Shared
0x04共享
0x08 Dedicated 1:1
0x08专用1:1
0x10 Dedicated 1+1
0x10专用1+1
0x20 Enhanced
0x20增强型
0x40 Reserved
0x40保留
0x80 Reserved
0x80保留
The remaining three octets SHOULD be set to zero by the sender, and SHOULD be ignored by the receiver.
其余三个八位字节应由发送方设置为零，接收方应忽略。
The Link Protection Type sub-TLV may occur at most once within the Link TLV.
链路保护类型子TLV在链路TLV内最多出现一次。
The SRLG is a sub-TLV (of type 16) of the Link TLV. The length is the length of the list in octets. The value is an unordered list of 32 bit numbers that are the SRLGs that the link belongs to. The format of the value field is as shown below:
SRLG是链路TLV的子TLV（类型16）。长度是列表的长度（以八位字节为单位）。该值是32位数字的无序列表，这些数字是链接所属的SRLGs。值字段的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This sub-TLV carries the Shared Risk Link Group information (see Section "Shared Risk Link Group Information" of [GMPLS-ROUTING]).
该子TLV携带共享风险链路组信息（参见[GMPLS-ROUTING]的“共享风险链路组信息”一节）。
The SRLG sub-TLV may occur at most once within the Link TLV.
SRLG子TLV在链路TLV内最多出现一次。
The Interface Switching Capability Descriptor is a sub-TLV (of type 15) of the Link TLV. The length is the length of value field in octets. The format of the value field is as shown below:
接口交换能力描述符是链路TLV的子TLV（类型15）。长度是值字段的长度（以八位字节为单位）。值字段的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Capability-specific information |
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Capability-specific information |
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Switching Capability (Switching Cap) field contains one of the following values:
切换能力（切换上限）字段包含以下值之一：
1 Packet-Switch Capable-1 (PSC-1) 2 Packet-Switch Capable-2 (PSC-2) 3 Packet-Switch Capable-3 (PSC-3) 4 Packet-Switch Capable-4 (PSC-4) 51 Layer-2 Switch Capable (L2SC) 100 Time-Division-Multiplex Capable (TDM) 150 Lambda-Switch Capable (LSC) 200 Fiber-Switch Capable (FSC)
1个支持分组交换机-1（PSC-1）2个支持分组交换机-2（PSC-2）3个支持分组交换机-3（PSC-3）4个支持分组交换机-4（PSC-4）51个支持第二层交换机（L2SC）100个支持时分多路复用（TDM）150个支持Lambda交换机（LSC）200个支持光纤交换机（FSC）
The Encoding field contains one of the values specified in Section 3.1.1 of [GMPLS-SIG].
编码字段包含[GMPLS-SIG]第3.1.1节中规定的值之一。
Maximum LSP Bandwidth is encoded as a list of eight 4 octet fields in the IEEE floating point format [IEEE], with priority 0 first and priority 7 last. The units are bytes (not bits!) per second.
最大LSP带宽以IEEE浮点格式[IEEE]编码为八个4个八位字段的列表，优先级为0，优先级为7。单位为每秒字节（不是位！）。
The content of the Switching Capability specific information field depends on the value of the Switching Capability field.
交换能力特定信息字段的内容取决于交换能力字段的值。
When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4, the Switching Capability specific information field includes Minimum LSP Bandwidth, Interface MTU, and padding.
当交换能力字段为PSC-1、PSC-2、PSC-3或PSC-4时，交换能力特定信息字段包括最小LSP带宽、接口MTU和填充。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum LSP Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum LSP Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Minimum LSP Bandwidth is encoded in a 4 octets field in the IEEE floating point format. The units are bytes (not bits!) per second. The Interface MTU is encoded as a 2 octets integer. The padding is 2 octets, and is used to make the Interface Switching Capability Descriptor sub-TLV 32-bits aligned. It SHOULD be set to zero by the sender and SHOULD be ignored by the receiver.
最小LSP带宽以IEEE浮点格式编码在4个八位字节字段中。单位为每秒字节（不是位！）。接口MTU编码为2个八位整数。填充为2个八位字节，用于使接口交换能力描述符子TLV 32位对齐。发送方应将其设置为零，接收方应将其忽略。
When the Switching Capability field is L2SC, there is no Switching Capability specific information field present.
当切换能力字段为L2SC时，不存在特定于切换能力的信息字段。
When the Switching Capability field is TDM, the Switching Capability specific information field includes Minimum LSP Bandwidth, an indication whether the interface supports Standard or Arbitrary SONET/SDH, and padding.
当交换能力字段为TDM时，交换能力特定信息字段包括最小LSP带宽、接口是否支持标准或任意SONET/SDH的指示以及填充。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum LSP Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Indication | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum LSP Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Indication | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Minimum LSP Bandwidth is encoded in a 4 octets field in the IEEE floating point format. The units are bytes (not bits!) per second. The indication whether the interface supports Standard or Arbitrary SONET/SDH is encoded as 1 octet. The value of this octet is 0 if the interface supports Standard SONET/SDH, and 1 if the interface supports Arbitrary SONET/SDH. The padding is 3 octets, and is used to make the Interface Switching Capability Descriptor sub-TLV 32-bits aligned. It SHOULD be set to zero by the sender and SHOULD be ignored by the receiver.
最小LSP带宽以IEEE浮点格式编码在4个八位字节字段中。单位为每秒字节（不是位！）。接口是否支持标准或任意SONET/SDH的指示编码为1个八位字节。如果接口支持标准SONET/SDH，则此八位字节的值为0；如果接口支持任意SONET/SDH，则此八位字节的值为1。填充为3个八位字节，用于使接口交换能力描述符子TLV 32位对齐。发送方应将其设置为零，接收方应将其忽略。
When the Switching Capability field is LSC, there is no Switching Capability specific information field present.
当切换能力字段为LSC时，不存在特定于切换能力的信息字段。
To support interfaces that have more than one Interface Switching Capability Descriptor (see Section "Interface Switching Capability Descriptor" of [GMPLS-ROUTING]) the Interface Switching Capability Descriptor sub-TLV may occur more than once within the Link TLV.
为了支持具有多个接口交换能力描述符的接口（参见[GMPLS-ROUTING]的“接口交换能力描述符”一节），接口交换能力描述符子TLV可能在链路TLV中出现不止一次。
The restarting node should follow the OSPF restart procedures [OSPF-RESTART], and the RSVP-TE restart procedures [GMPLS-RSVP].
重启节点应遵循OSPF重启程序[OSPF-restart]和RSVP-TE重启程序[GMPLS-RSVP]。
When a restarting node is going to originate its TE LSAs, the TE LSAs containing Link TLV should be originated with 0 unreserved bandwidth, Traffic Engineering metric set to 0xffffffff, and if the Link has LSC or FSC as its Switching Capability then also with 0 as Max LSP Bandwidth, until the node is able to determine the amount of unreserved resources taking into account the resources reserved by the already established LSPs that have been preserved across the restart. Once the restarting node determines the amount of unreserved resources, taking into account the resources reserved by the already established LSPs that have been preserved across the restart, the node should advertise these resources in its TE LSAs.
当重新启动的节点将要发起其TE LSA时，包含链路TLV的TE LSA应以0未保留带宽发起，流量工程度量设置为0xFFFFFF，如果链路具有LSC或FSC作为其交换能力，则也应以0作为最大LSP带宽，直到节点能够确定未保留的资源量，同时考虑已建立的LSP保留的资源，这些LSP已在重启过程中保留。在重新启动节点确定未保留资源的数量后，考虑到已建立的LSP保留的资源，这些LSP在重新启动期间被保留，节点应在其TE LSA中公布这些资源。
In addition in the case of a planned restart prior to restarting, the restarting node SHOULD originate the TE LSAs containing Link TLV with 0 as unreserved bandwidth, and if the Link has LSC or FSC as its Switching Capability then also with 0 as Max LSP Bandwidth. This would discourage new LSP establishment through the restarting router.
此外，在重新启动之前计划重新启动的情况下，重新启动节点应发起包含链路TLV的TE LSA，0为非保留带宽，如果链路具有LSC或FSC作为其交换能力，则也应具有0为最大LSP带宽。这将阻止通过重新启动路由器建立新的LSP。
Neighbors of the restarting node should continue advertise the actual unreserved bandwidth on the TE links from the neighbors to that node.
重新启动节点的邻居应继续公布从邻居到该节点的TE链路上的实际未保留带宽。
Regular graceful restart should not be aborted if a TE LSA or TE topology changes. TE graceful restart need not be aborted if a TE LSA or TE topology changes.
如果TE LSA或TE拓扑发生更改，则不应中止常规正常重启。如果TE LSA或TE拓扑发生更改，则无需中止TE优雅重启。
It is often useful for a node to communicate some Traffic Engineering information for a given interface to its neighbors on that interface. One example of this is a Link Local Identifier. If nodes X and Y are connected by an unnumbered point-to-point interface I, then X's Link Local Identifier for I is Y's Link Remote Identifier for I. X can communicate its Link Local Identifier for I by exchanging with Y a TE link local opaque LSA described below. Note that this information need only be exchanged over interface I, hence the use of a link local Opaque LSA.
节点将给定接口的某些流量工程信息传递给该接口上的邻居通常很有用。这方面的一个示例是链路本地标识符。如果节点X和Y通过未编号的点对点接口I连接，则I的X的链路本地标识符是I的Y的链路远程标识符。X可以通过与Y交换下面描述的TE链路本地不透明LSA来通信I的链路本地标识符。请注意，此信息只需通过接口I交换，因此使用链路本地不透明LSA。
A TE Link Local LSA is an opaque LSA of type 9 (link-local flooding scope) with Opaque Type 1 (TE LSA) and Opaque ID of 0.
TE链路本地LSA是类型为9（链路本地泛洪范围）的不透明LSA，不透明类型为1（TE LSA），不透明ID为0。
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 | 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
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 | 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
The format of the TLVs that make up the body of the TE Link Local LSA is the same as that of the TE TLVs: a 2-octet Type field followed by a 2-octet Length field which indicates the length of the Value field in octets. The Top Level Type for the Link Local TLV is 4. The Value field is zero-padded at the end to a four octet boundary.
构成TE链路本地LSA主体的TLV的格式与TE TLV的格式相同：一个2个八位组类型的字段，后跟一个2个八位组长度字段，该字段以八位组表示值字段的长度。链路本地TLV的顶级类型为4。值字段在四个八位组边界的末端填充为零。
The only TLV defined here is the Link Local Identifier TLV, with Type 1, Length 4 and Value the 32 bit Link Local Identifier for the link over which the TE Link Local LSA is exchanged.
此处定义的唯一TLV是链路本地标识符TLV，类型为1，长度为4，值为交换TE链路本地LSA的链路的32位链路本地标识符。
Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose, CA 95138
加利福尼亚州圣何塞法拉利街5853号阿扬·班纳吉·卡里昂网络公司，邮编95138
Phone: +1.408.972.3645
EMail: abanerjee@calient.net
Phone: +1.408.972.3645
EMail: abanerjee@calient.net
John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138
约翰·德雷克·卡林特网络公司，加利福尼亚州圣何塞法拉利路5853号，邮编95138
Phone: +1.408.972.3720
EMail: jdrake@calient.net
Phone: +1.408.972.3720
EMail: jdrake@calient.net
Greg Bernstein Ciena Corporation 10480 Ridgeview Court Cupertino, CA 94014
格雷格·伯恩斯坦·西纳公司10480加利福尼亚州库比蒂诺里奇维尤法院，邮编94014
Phone: +1.408.366.4713
EMail: greg@ciena.com
Phone: +1.408.366.4713
EMail: greg@ciena.com
Don Fedyk Nortel Networks Corp. 600 Technology Park Drive Billerica, MA 01821
唐·费迪克北电网络公司，地址：马萨诸塞州比尔里卡科技园大道600号，邮编：01821
Phone: +1.978.288.4506
EMail: dwfedyk@nortelnetworks.com
Phone: +1.978.288.4506
EMail: dwfedyk@nortelnetworks.com
Eric Mannie Independent Consultant
埃里克·曼尼独立顾问
EMail: eric_mannie@hotmail.com
EMail: eric_mannie@hotmail.com
Debanjan Saha Tellium Optical Systems 2 Crescent Place P.O. Box 901 Ocean Port, NJ 07757
新泽西州海港901号新月广场2号德班詹萨哈碲光学系统邮政信箱07757
Phone: +1.732.923.4264
EMail: dsaha@tellium.com
Phone: +1.732.923.4264
EMail: dsaha@tellium.com
Vishal Sharma Metanoia, Inc. 335 Elan Village Lane, Unit 203 San Jose, CA 95134-2539
Vishal Sharma Metanoia，Inc.加利福尼亚州圣何塞市Elan村巷335号203单元，邮编95134-2539
Phone: +1.408.943.1794
EMail: v.sharma@ieee.org
Phone: +1.408.943.1794
EMail: v.sharma@ieee.org
The authors would like to thank Suresh Katukam, Jonathan Lang, Quaizar Vohra, and Alex Zinin for their comments on the document.
作者要感谢Suresh Katukam、Jonathan Lang、Quaizar Vohra和Alex Zinin对该文件的评论。
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 direct effect on IP routing. Tampering with GMPLS TE LSAs may have an effect on the underlying transport (optical and/or SONET-SDH) network. [OSPF-TE] suggests mechanisms such as [OSPF-SIG] to protect the transmission of this information, and those or other mechanisms should be used to secure and/or authenticate the information carried in the Opaque LSAs.
本文件规定了OSPFv2中不透明LSA的内容。由于不透明LSA不用于SPF计算或正常路由，因此此处指定的扩展对IP路由没有直接影响。篡改GMPLS TE LSA可能会对底层传输（光学和/或SONET-SDH）网络产生影响。[OSPF-TE]建议使用[OSPF-SIG]等机制来保护此信息的传输，并且应使用这些或其他机制来保护和/或验证不透明LSA中携带的信息。
The memo introduces four new sub-TLVs of the TE Link TLV in the TE Opaque LSA for OSPF v2; [OSPF-TE] says that the sub-TLVs of the TE Link TLV in the range 10-32767 must be assigned by Expert Review, and must be registered with IANA.
备忘录介绍了OSPF v2 TE不透明LSA中TE链路TLV的四个子TLV；[OSPF-TE]表示，范围为10-32767的TE链路TLV的子TLV必须通过专家评审分配，并且必须在IANA注册。
The memo has four suggested values for the four sub-TLVs of the TE Link TLV; it is strongly recommended that the suggested values be granted, as there are interoperable implementations using these values.
备忘录对TE-Link TLV的四个子TLV有四个建议值；强烈建议授予建议的值，因为存在使用这些值的可互操作实现。
Finally, a new Top Level Type for OSPF TE LSAs for the Link Local TLV has been allocated from the Standards Action space.
最后，从标准操作空间为链路本地TLV分配了一个新的OSPF TE LSA顶级类型。
[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月。
[GMPLS-RSVP] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[GMPLS-RSVP]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[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月。
[IEEE] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593- 7653-8).
[IEEE]IEEE，“二进制浮点运算的IEEE标准”，标准754-19851985（ISBN 1-5593-7653-8）。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF]Moy，J.，“OSPF版本2”，STD 54，RFC 23281998年4月。
[OSPF-RESTART] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[OSPF-RESTART]Moy，J.，Pillay Esnault，P.，和A.Lindem，“优雅的OSPF重启”，RFC 36232003年11月。
[OSPF-SIG] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[OSPF-SIG]Murphy，S.，Badger，M.，和B.Wellington，“具有数字签名的OSPF”，RFC 2154，1997年6月。
[OSPF-TE] Katz, D., Kompella, K., and Yeung, D., "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[OSPF-TE]Katz，D.，Kompella，K.，和Yeung，D.，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[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月。
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
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编辑功能的资金目前由互联网协会提供。