Internet Engineering Task Force (IETF) H. Gredler, Ed.
Request for Comments: 7752 Individual Contributor
Category: Standards Track J. Medved
ISSN: 2070-1721 S. Previdi
Cisco Systems, Inc.
A. Farrel
Juniper Networks, Inc.
S. Ray
March 2016
Internet Engineering Task Force (IETF) H. Gredler, Ed.
Request for Comments: 7752 Individual Contributor
Category: Standards Track J. Medved
ISSN: 2070-1721 S. Previdi
Cisco Systems, Inc.
A. Farrel
Juniper Networks, Inc.
S. Ray
March 2016
North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP
使用BGP的链路状态和流量工程（TE）信息的北向分布
Abstract
摘要
In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.
在许多环境中，网络外部的组件被要求基于网络拓扑和网络内连接的当前状态（包括流量工程（TE）信息）执行计算。这是通常由IGP路由协议在网络中分发的信息。
This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.
本文档描述了一种机制，通过该机制，可以从网络收集链路状态和TE信息，并使用BGP路由协议与外部组件共享。这是使用新的BGP网络层可达性信息（NLRI）编码格式实现的。该机制适用于物理和虚拟IGP链路。所描述的机制受策略控制。
Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).
该技术的应用包括应用层流量优化（ALTO）服务器和路径计算元素（PCE）。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7752.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7752.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Language ......................................5
2. Motivation and Applicability ....................................5
2.1. MPLS-TE with PCE ...........................................5
2.2. ALTO Server Network API ....................................6
3. Carrying Link-State Information in BGP ..........................7
3.1. TLV Format .................................................8
3.2. The Link-State NLRI ........................................8
3.2.1. Node Descriptors ...................................12
3.2.2. Link Descriptors ...................................16
3.2.3. Prefix Descriptors .................................18
3.3. The BGP-LS Attribute ......................................19
3.3.1. Node Attribute TLVs ................................20
3.3.2. Link Attribute TLVs ................................23
3.3.3. Prefix Attribute TLVs ..............................28
3.4. BGP Next-Hop Information ..................................31
3.5. Inter-AS Links ............................................32
3.6. Router-ID Anchoring Example: ISO Pseudonode ...............32
3.7. Router-ID Anchoring Example: OSPF Pseudonode ..............33
3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration ....34
4. Link to Path Aggregation .......................................34
4.1. Example: No Link Aggregation ..............................35
4.2. Example: ASBR to ASBR Path Aggregation ....................35
4.3. Example: Multi-AS Path Aggregation ........................36
5. IANA Considerations ............................................36
5.1. Guidance for Designated Experts ...........................37
6. Manageability Considerations ...................................38
6.1. Operational Considerations ................................38
6.1.1. Operations .........................................38
6.1.2. Installation and Initial Setup .....................38
6.1.3. Migration Path .....................................38
1. Introduction ....................................................3
1.1. Requirements Language ......................................5
2. Motivation and Applicability ....................................5
2.1. MPLS-TE with PCE ...........................................5
2.2. ALTO Server Network API ....................................6
3. Carrying Link-State Information in BGP ..........................7
3.1. TLV Format .................................................8
3.2. The Link-State NLRI ........................................8
3.2.1. Node Descriptors ...................................12
3.2.2. Link Descriptors ...................................16
3.2.3. Prefix Descriptors .................................18
3.3. The BGP-LS Attribute ......................................19
3.3.1. Node Attribute TLVs ................................20
3.3.2. Link Attribute TLVs ................................23
3.3.3. Prefix Attribute TLVs ..............................28
3.4. BGP Next-Hop Information ..................................31
3.5. Inter-AS Links ............................................32
3.6. Router-ID Anchoring Example: ISO Pseudonode ...............32
3.7. Router-ID Anchoring Example: OSPF Pseudonode ..............33
3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration ....34
4. Link to Path Aggregation .......................................34
4.1. Example: No Link Aggregation ..............................35
4.2. Example: ASBR to ASBR Path Aggregation ....................35
4.3. Example: Multi-AS Path Aggregation ........................36
5. IANA Considerations ............................................36
5.1. Guidance for Designated Experts ...........................37
6. Manageability Considerations ...................................38
6.1. Operational Considerations ................................38
6.1.1. Operations .........................................38
6.1.2. Installation and Initial Setup .....................38
6.1.3. Migration Path .....................................38
6.1.4. Requirements on Other Protocols and
Functional Components ..............................38
6.1.5. Impact on Network Operation ........................38
6.1.6. Verifying Correct Operation ........................39
6.2. Management Considerations .................................39
6.2.1. Management Information .............................39
6.2.2. Fault Management ...................................39
6.2.3. Configuration Management ...........................40
6.2.4. Accounting Management ..............................40
6.2.5. Performance Management .............................40
6.2.6. Security Management ................................41
7. TLV/Sub-TLV Code Points Summary ................................41
8. Security Considerations ........................................42
9. References .....................................................43
9.1. Normative References ......................................43
9.2. Informative References ....................................45
Acknowledgements ..................................................47
Contributors ......................................................47
Authors' Addresses ................................................48
6.1.4. Requirements on Other Protocols and
Functional Components ..............................38
6.1.5. Impact on Network Operation ........................38
6.1.6. Verifying Correct Operation ........................39
6.2. Management Considerations .................................39
6.2.1. Management Information .............................39
6.2.2. Fault Management ...................................39
6.2.3. Configuration Management ...........................40
6.2.4. Accounting Management ..............................40
6.2.5. Performance Management .............................40
6.2.6. Security Management ................................41
7. TLV/Sub-TLV Code Points Summary ................................41
8. Security Considerations ........................................42
9. References .....................................................43
9.1. Normative References ......................................43
9.2. Informative References ....................................45
Acknowledgements ..................................................47
Contributors ......................................................47
Authors' Addresses ................................................48
The contents of a Link-State Database (LSDB) or of an IGP's Traffic Engineering Database (TED) describe only the links and nodes within an IGP area. Some applications, such as end-to-end Traffic Engineering (TE), would benefit from visibility outside one area or Autonomous System (AS) in order to make better decisions.
链路状态数据库（LSDB）或IGP流量工程数据库（TED）的内容仅描述IGP区域内的链路和节点。一些应用程序，如端到端流量工程（TE），将受益于一个区域或自治系统（as）之外的可见性，以便做出更好的决策。
The IETF has defined the Path Computation Element (PCE) [RFC4655] as a mechanism for achieving the computation of end-to-end TE paths that cross the visibility of more than one TED or that require CPU-intensive or coordinated computations. The IETF has also defined the ALTO server [RFC5693] as an entity that generates an abstracted network topology and provides it to network-aware applications.
IETF已将路径计算元素（PCE）[RFC4655]定义为一种机制，用于实现跨多个TED可视性或需要CPU密集型或协调计算的端到端TE路径的计算。IETF还将ALTO服务器[RFC5693]定义为生成抽象网络拓扑并将其提供给网络感知应用程序的实体。
Both a PCE and an ALTO server need to gather information about the topologies and capabilities of the network in order to be able to fulfill their function.
PCE和ALTO服务器都需要收集有关网络拓扑和功能的信息，以便能够实现其功能。
This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol [RFC4271]. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual links. The mechanism described is subject to policy control.
本文档描述了一种机制，通过该机制，可以使用BGP路由协议[RFC4271]从网络收集链路状态和TE信息，并与外部组件共享。这是使用新的BGP网络层可达性信息（NLRI）编码格式实现的。该机制适用于物理链路和虚拟链路。所描述的机制受策略控制。
A router maintains one or more databases for storing link-state information about nodes and links in any given area. Link attributes stored in these databases include: local/remote IP addresses, local/ remote interface identifiers, link metric and TE metric, link bandwidth, reservable bandwidth, per Class-of-Service (CoS) class reservation state, preemption, and Shared Risk Link Groups (SRLGs). The router's BGP process can retrieve topology from these LSDBs and distribute it to a consumer, either directly or via a peer BGP speaker (typically a dedicated Route Reflector), using the encoding specified in this document.
路由器维护一个或多个数据库，用于存储任何给定区域中节点和链路的链路状态信息。存储在这些数据库中的链路属性包括：本地/远程IP地址、本地/远程接口标识符、链路度量和TE度量、链路带宽、可保留带宽、每类服务（CoS）类保留状态、抢占和共享风险链路组（SRLGs）。路由器的BGP进程可以使用本文档中指定的编码，直接或通过对等BGP扬声器（通常是专用路由反射器）从这些LSDB检索拓扑并将其分发给消费者。
The collection of link-state and TE information and its distribution to consumers is shown in the following figure.
链接状态和TE信息的收集及其对消费者的分布如下图所示。
+-----------+
| Consumer |
+-----------+
^
|
+-----------+
| BGP | +-----------+
| Speaker | | Consumer |
+-----------+ +-----------+
^ ^ ^ ^
| | | |
+---------------+ | +-------------------+ |
| | | |
+-----------+ +-----------+ +-----------+
| BGP | | BGP | | BGP |
| Speaker | | Speaker | . . . | Speaker |
+-----------+ +-----------+ +-----------+
^ ^ ^
| | |
IGP IGP IGP
+-----------+
| Consumer |
+-----------+
^
|
+-----------+
| BGP | +-----------+
| Speaker | | Consumer |
+-----------+ +-----------+
^ ^ ^ ^
| | | |
+---------------+ | +-------------------+ |
| | | |
+-----------+ +-----------+ +-----------+
| BGP | | BGP | | BGP |
| Speaker | | Speaker | . . . | Speaker |
+-----------+ +-----------+ +-----------+
^ ^ ^
| | |
IGP IGP IGP
Figure 1: Collection of Link-State and TE Information
图1：链接状态和TE信息的收集
A BGP speaker may apply configurable policy to the information that it distributes. Thus, it may distribute the real physical topology from the LSDB or the TED. Alternatively, it may create an abstracted topology, where virtual, aggregated nodes are connected by virtual paths. Aggregated nodes can be created, for example, out of multiple routers in a Point of Presence (POP). Abstracted topology can also be a mix of physical and virtual nodes and physical and virtual links. Furthermore, the BGP speaker can apply policy to determine when information is updated to the consumer so that there is a
BGP演讲者可以对其分发的信息应用可配置策略。因此，它可以分布来自LSDB或TED的真实物理拓扑。或者，它可以创建一个抽象拓扑，其中虚拟聚合节点通过虚拟路径连接。例如，可以使用存在点（POP）中的多个路由器创建聚合节点。抽象拓扑也可以是物理和虚拟节点以及物理和虚拟链接的混合体。此外，BGP扬声器可以应用策略来确定何时向消费者更新信息，以便存在错误
reduction of information flow from the network to the consumers. Mechanisms through which topologies can be aggregated or virtualized are outside the scope of this document
减少从网络到消费者的信息流。拓扑可以聚合或虚拟化的机制不在本文档的范围内
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]中所述进行解释。
This section describes use cases from which the requirements can be derived.
本节描述可从中派生需求的用例。
As described in [RFC4655], a PCE can be used to compute MPLS-TE paths within a "domain" (such as an IGP area) or across multiple domains (such as a multi-area AS or multiple ASes).
如[RFC4655]所述，PCE可用于计算“域”（如IGP区域）内或跨多个域（如多区域As或多个ASE）的MPLS-TE路径。
o Within a single area, the PCE offers enhanced computational power that may not be available on individual routers, sophisticated policy control and algorithms, and coordination of computation across the whole area.
o 在单个区域内，PCE提供了单个路由器可能无法提供的增强计算能力、复杂的策略控制和算法，以及整个区域内的计算协调。
o If a router wants to compute a MPLS-TE path across IGP areas, then its own TED lacks visibility of the complete topology. That means that the router cannot determine the end-to-end path and cannot even select the right exit router (Area Border Router (ABR)) for an optimal path. This is an issue for large-scale networks that need to segment their core networks into distinct areas but still want to take advantage of MPLS-TE.
o 如果路由器想要计算跨IGP区域的MPLS-TE路径，则其自身的TED缺乏完整拓扑的可见性。这意味着路由器无法确定端到端路径，甚至无法为最佳路径选择正确的出口路由器（区域边界路由器（ABR））。对于需要将其核心网络划分为不同区域但仍希望利用MPLS-TE的大型网络来说，这是一个问题。
Previous solutions used per-domain path computation [RFC5152]. The source router could only compute the path for the first area because the router only has full topological visibility for the first area along the path, but not for subsequent areas. Per-domain path computation uses a technique called "loose-hop-expansion" [RFC3209] and selects the exit ABR and other ABRs or AS Border Routers (ASBRs) using the IGP-computed shortest path topology for the remainder of the path. This may lead to sub-optimal paths, makes alternate/back-up path computation hard, and might result in no TE path being found when one really does exist.
以前每个域路径计算使用的解决方案[RFC5152]。源路由器只能计算第一个区域的路径，因为路由器仅对路径上的第一个区域具有完整的拓扑可见性，而对后续区域不具有完整的拓扑可见性。每域路径计算使用一种称为“松跳扩展”的技术[RFC3209]，并使用IGP计算的最短路径拓扑为剩余路径选择出口ABR和其他ABR或AS边界路由器（ASBR）。这可能导致次优路径，使备用/备用路径计算变得困难，并且可能导致在确实存在TE路径时找不到TE路径。
The PCE presents a computation server that may have visibility into more than one IGP area or AS, or may cooperate with other PCEs to perform distributed path computation. The PCE obviously needs access
PCE提供计算服务器，该计算服务器可以对多个IGP区域或AS具有可见性，或者可以与其他PCE协作以执行分布式路径计算。PCE显然需要接入
to the TED for the area(s) it serves, but [RFC4655] does not describe how this is achieved. Many implementations make the PCE a passive participant in the IGP so that it can learn the latest state of the network, but this may be sub-optimal when the network is subject to a high degree of churn or when the PCE is responsible for multiple areas.
向TED报告其服务的区域，但[RFC4655]未说明如何实现这一点。许多实现使PCE成为IGP中的被动参与者，以便它能够了解网络的最新状态，但当网络受到高度搅动或PCE负责多个区域时，这可能是次优的。
The following figure shows how a PCE can get its TED information using the mechanism described in this document.
下图显示了PCE如何使用本文档中描述的机制获取其TED信息。
+----------+ +---------+
| ----- | | BGP |
| | TED |<-+-------------------------->| Speaker |
| ----- | TED synchronization | |
| | | mechanism: +---------+
| | | BGP with Link-State NLRI
| v |
| ----- |
| | PCE | |
| ----- |
+----------+
^
| Request/
| Response
v
Service +----------+ Signaling +----------+
Request | Head-End | Protocol | Adjacent |
-------->| Node |<------------>| Node |
+----------+ +----------+
+----------+ +---------+
| ----- | | BGP |
| | TED |<-+-------------------------->| Speaker |
| ----- | TED synchronization | |
| | | mechanism: +---------+
| | | BGP with Link-State NLRI
| v |
| ----- |
| | PCE | |
| ----- |
+----------+
^
| Request/
| Response
v
Service +----------+ Signaling +----------+
Request | Head-End | Protocol | Adjacent |
-------->| Node |<------------>| Node |
+----------+ +----------+
Figure 2: External PCE Node Using a TED Synchronization Mechanism
图2：使用TED同步机制的外部PCE节点
The mechanism in this document allows the necessary TED information to be collected from the IGP within the network, filtered according to configurable policy, and distributed to the PCE as necessary.
本文件中的机制允许从网络内的IGP收集必要的TED信息，根据可配置策略进行过滤，并根据需要分发给PCE。
An ALTO server [RFC5693] is an entity that generates an abstracted network topology and provides it to network-aware applications over a web-service-based API. Example applications are peer-to-peer (P2P) clients or trackers, or Content Distribution Networks (CDNs). The abstracted network topology comes in the form of two maps: a Network Map that specifies allocation of prefixes to Partition Identifiers (PIDs), and a Cost Map that specifies the cost between PIDs listed in the Network Map. For more details, see [RFC7285].
ALTO服务器[RFC5693]是生成抽象网络拓扑并通过基于web服务的API将其提供给网络感知应用程序的实体。示例应用程序是对等（P2P）客户端或跟踪器，或内容分发网络（CDN）。抽象的网络拓扑以两种映射的形式出现：一种是网络映射，指定为分区标识符（PID）分配前缀；另一种是成本映射，指定网络映射中列出的PID之间的成本。有关更多详细信息，请参阅[RFC7285]。
ALTO abstract network topologies can be auto-generated from the physical topology of the underlying network. The generation would typically be based on policies and rules set by the operator. Both prefix and TE data are required: prefix data is required to generate ALTO Network Maps, and TE (topology) data is required to generate ALTO Cost Maps. Prefix data is carried and originated in BGP, and TE data is originated and carried in an IGP. The mechanism defined in this document provides a single interface through which an ALTO server can retrieve all the necessary prefix and network topology data from the underlying network. Note that an ALTO server can use other mechanisms to get network data, for example, peering with multiple IGP and BGP speakers.
ALTO abstract网络拓扑可以从底层网络的物理拓扑自动生成。生成通常基于操作员设置的策略和规则。前缀和TE数据都是必需的：生成ALTO网络图需要前缀数据，生成ALTO成本图需要TE（拓扑）数据。前缀数据在BGP中携带和携带，TE数据在IGP中携带和携带。本文档中定义的机制提供了一个接口，ALTO服务器可以通过该接口从底层网络检索所有必要的前缀和网络拓扑数据。请注意，ALTO服务器可以使用其他机制获取网络数据，例如，使用多个IGP和BGP扬声器进行对等。
The following figure shows how an ALTO server can get network topology information from the underlying network using the mechanism described in this document.
下图显示了ALTO服务器如何使用本文档中描述的机制从底层网络获取网络拓扑信息。
+--------+
| Client |<--+
+--------+ |
| ALTO +--------+ BGP with +---------+
+--------+ | Protocol | ALTO | Link-State NLRI | BGP |
| Client |<--+------------| Server |<----------------| Speaker |
+--------+ | | | | |
| +--------+ +---------+
+--------+ |
| Client |<--+
+--------+
+--------+
| Client |<--+
+--------+ |
| ALTO +--------+ BGP with +---------+
+--------+ | Protocol | ALTO | Link-State NLRI | BGP |
| Client |<--+------------| Server |<----------------| Speaker |
+--------+ | | | | |
| +--------+ +---------+
+--------+ |
| Client |<--+
+--------+
Figure 3: ALTO Server Using Network Topology Information
图3：使用网络拓扑信息的ALTO服务器
This specification contains two parts: definition of a new BGP NLRI that describes links, nodes, and prefixes comprising IGP link-state information and definition of a new BGP path attribute (BGP-LS attribute) that carries link, node, and prefix properties and attributes, such as the link and prefix metric or auxiliary Router-IDs of nodes, etc.
本规范包含两部分：描述包含IGP链路状态信息的链路、节点和前缀的新BGP NLRI的定义，以及承载链路、节点和前缀属性和属性（如链路和前缀度量或节点的辅助路由器ID等）的新BGP路径属性（BGP-LS属性）的定义。
It is desirable to keep the dependencies on the protocol source of this attribute to a minimum and represent any content in an IGP-neutral way, such that applications that want to learn about a link-state topology do not need to know about any OSPF or IS-IS protocol specifics.
希望将对该属性的协议源的依赖性保持在最小，并以IGP中立的方式表示任何内容，以便希望了解链路状态拓扑的应用程序不需要了解任何OSPF或is-is协议细节。
Information in the new Link-State NLRIs and attributes is encoded in Type/Length/Value triplets. The TLV format is shown in Figure 4.
新链接状态NLRIs和属性中的信息以类型/长度/值三元组进行编码。TLV格式如图4所示。
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 (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Value (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: TLV Format
图4:TLV格式
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 not padded to 4-octet alignment. Unrecognized types MUST be preserved and propagated. In order to compare NLRIs with unknown TLVs, all TLVs MUST be ordered in ascending order by TLV Type. If there are more TLVs of the same type, then the TLVs MUST be ordered in ascending order of the TLV value within the TLVs with the same type by treating the entire Value field as an opaque hexadecimal string and comparing leftmost octets first, regardless of the length of the string. All TLVs that are not specified as mandatory are considered optional.
长度字段以八位字节定义值部分的长度（因此，没有值部分的TLV的长度为零）。TLV未填充到4-八位组对齐。必须保留和传播无法识别的类型。为了将NLRI与未知TLV进行比较，所有TLV必须按TLV类型升序排列。如果有更多相同类型的TLV，则必须按照相同类型TLV中TLV值的升序对TLV进行排序，方法是将整个值字段视为不透明的十六进制字符串，并首先比较最左侧的八位字节，而不管字符串的长度如何。所有未指定为强制性的TLV均视为可选。
The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's containers for carrying opaque information. Each Link-State NLRI describes either a node, a link, or a prefix.
MP_REACH_NLRI和MP_UNREACH_NLRI属性是BGP用于承载不透明信息的容器。每个链路状态NLRI描述节点、链路或前缀。
All non-VPN link, node, and prefix information SHALL be encoded using AFI 16388 / SAFI 71. VPN link, node, and prefix information SHALL be encoded using AFI 16388 / SAFI 72.
所有非VPN链路、节点和前缀信息应使用AFI 16388/SAFI 71进行编码。VPN链路、节点和前缀信息应使用AFI 16388/SAFI 72进行编码。
In order for two BGP speakers to exchange Link-State NLRI, they MUST use BGP Capabilities Advertisement to ensure that they are both capable of properly processing such NLRI. This is done as specified in [RFC4760], by using capability code 1 (multi-protocol BGP), with AFI 16388 / SAFI 71 for BGP-LS, and AFI 16388 / SAFI 72 for BGP-LS-VPN.
为了让两个BGP扬声器交换链路状态NLRI，他们必须使用BGP播发功能，以确保他们都能够正确处理此类NLRI。这是按照[RFC4760]中的规定，通过使用功能代码1（多协议BGP）、BGP-LS的AFI 16388/SAFI 71和BGP-LS-VPN的AFI 16388/SAFI 72实现的。
The format of the Link-State NLRI is shown in the following figures.
链接状态NLRI的格式如下图所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Type | Total NLRI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Link-State NLRI (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Type | Total NLRI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Link-State NLRI (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Link-State AFI 16388 / SAFI 71 NLRI Format
图5：链接状态AFI 16388/SAFI 71 NLRI格式
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Type | Total NLRI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Route Distinguisher +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Link-State NLRI (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Type | Total NLRI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Route Distinguisher +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Link-State NLRI (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Link-State VPN AFI 16388 / SAFI 72 NLRI Format
图6：链路状态VPN AFI 16388/SAFI 72 NLRI格式
The Total NLRI Length field contains the cumulative length, in octets, of the rest of the NLRI, not including the NLRI Type field or itself. For VPN applications, it also includes the length of the Route Distinguisher.
“总NLRI长度”字段包含NLRI其余部分的累积长度（以八位字节为单位），不包括NLRI类型字段或其本身。对于VPN应用程序，它还包括路由识别器的长度。
+------+---------------------------+
| Type | NLRI Type |
+------+---------------------------+
| 1 | Node NLRI |
| 2 | Link NLRI |
| 3 | IPv4 Topology Prefix NLRI |
| 4 | IPv6 Topology Prefix NLRI |
+------+---------------------------+
+------+---------------------------+
| Type | NLRI Type |
+------+---------------------------+
| 1 | Node NLRI |
| 2 | Link NLRI |
| 3 | IPv4 Topology Prefix NLRI |
| 4 | IPv6 Topology Prefix NLRI |
+------+---------------------------+
Table 1: NLRI Types
表1：NLRI类型
Route Distinguishers are defined and discussed in [RFC4364].
[RFC4364]中定义并讨论了路线识别器。
The Node NLRI (NLRI Type = 1) is shown in the following figure.
节点NLRI（NLRI类型=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
+-+-+-+-+-+-+-+-+
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors (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
+-+-+-+-+-+-+-+-+
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: The Node NLRI Format
图7：节点NLRI格式
The Link NLRI (NLRI Type = 2) is shown in the following figure.
链接NLRI（NLRI类型=2）如下图所示。
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
+-+-+-+-+-+-+-+-+
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Link Descriptors (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
+-+-+-+-+-+-+-+-+
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Link Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: The Link NLRI Format
图8：链接NLRI格式
The IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the same format, as shown in the following figure.
IPv4和IPv6前缀NLRIs（NLRI类型=3和类型=4）使用相同的格式，如下图所示。
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
+-+-+-+-+-+-+-+-+
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Prefix Descriptors (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
+-+-+-+-+-+-+-+-+
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Prefix Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: The IPv4/IPv6 Topology Prefix NLRI Format
图9:IPv4/IPv6拓扑前缀NLRI格式
The Protocol-ID field can contain one of the following values:
协议ID字段可以包含以下值之一：
+-------------+----------------------------------+
| Protocol-ID | NLRI information source protocol |
+-------------+----------------------------------+
| 1 | IS-IS Level 1 |
| 2 | IS-IS Level 2 |
| 3 | OSPFv2 |
| 4 | Direct |
| 5 | Static configuration |
| 6 | OSPFv3 |
+-------------+----------------------------------+
+-------------+----------------------------------+
| Protocol-ID | NLRI information source protocol |
+-------------+----------------------------------+
| 1 | IS-IS Level 1 |
| 2 | IS-IS Level 2 |
| 3 | OSPFv2 |
| 4 | Direct |
| 5 | Static configuration |
| 6 | OSPFv3 |
+-------------+----------------------------------+
Table 2: Protocol Identifiers
表2：协议标识符
The 'Direct' and 'Static configuration' protocol types SHOULD be used when BGP-LS is sourcing local information. For all information derived from other protocols, the corresponding Protocol-ID MUST be used. If BGP-LS has direct access to interface information and wants to advertise a local link, then the Protocol-ID 'Direct' SHOULD be used. For modeling virtual links, such as described in Section 4, the Protocol-ID 'Static configuration' SHOULD be used.
BGP-LS获取本地信息时，应使用“直接”和“静态配置”协议类型。对于从其他协议派生的所有信息，必须使用相应的协议ID。如果BGP-LS可以直接访问接口信息，并希望公布本地链路，则应使用协议ID“direct”。对于虚拟链路建模，如第4节所述，应使用协议ID“静态配置”。
Both OSPF and IS-IS MAY run multiple routing protocol instances over the same link. See [RFC6822] and [RFC6549]. These instances define independent "routing universes". The 64-bit Identifier field is used to identify the routing universe where the NLRI belongs. The NLRIs representing link-state objects (nodes, links, or prefixes) from the same routing universe MUST have the same 'Identifier' value. NLRIs
OSPF和IS-IS都可以在同一链路上运行多个路由协议实例。参见[RFC6822]和[RFC6549]。这些实例定义了独立的“路由宇宙”。64位标识符字段用于标识NLRI所属的路由范围。表示来自同一路由范围的链接状态对象（节点、链接或前缀）的NLRI必须具有相同的“标识符”值。NLRIs
with different 'Identifier' values MUST be considered to be from different routing universes. Table 3 lists the 'Identifier' values that are defined as well-known in this document.
具有不同“标识符”的值必须被视为来自不同的路由范围。表3列出了本文档中定义为已知的“标识符”值。
+------------+----------------------------------+
| Identifier | Routing Universe |
+------------+----------------------------------+
| 0 | Default Layer 3 Routing topology |
+------------+----------------------------------+
+------------+----------------------------------+
| Identifier | Routing Universe |
+------------+----------------------------------+
| 0 | Default Layer 3 Routing topology |
+------------+----------------------------------+
Table 3: Well-Known Instance Identifiers
表3：众所周知的实例标识符
If a given protocol does not support multiple routing universes, then it SHOULD set the Identifier field according to Table 3. However, an implementation MAY make the 'Identifier' configurable for a given protocol.
如果给定的协议不支持多个路由通用，则应根据表3设置标识符字段。然而，一个实现可能会使“标识符”对于给定的协议是可配置的。
Each Node Descriptor and Link Descriptor consists of one or more TLVs, as described in the following sections.
每个节点描述符和链路描述符由一个或多个TLV组成，如以下各节所述。
Each link is anchored by a pair of Router-IDs that are used by the underlying IGP, namely, a 48-bit ISO System-ID for IS-IS and a 32-bit Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more additional auxiliary Router-IDs, mainly for Traffic Engineering purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE Router-IDs [RFC5305] [RFC6119]. These auxiliary Router-IDs MUST be included in the link attribute described in Section 3.3.2.
每个链路由底层IGP使用的一对路由器ID锚定，即is-is的48位ISO系统ID和OSPFv2和OSPFv3的32位路由器ID。IGP可以使用一个或多个附加的辅助路由器ID，主要用于流量工程目的。例如，IS-IS可能具有一个或多个IPv4和IPv6 TE路由器ID[RFC5305][RFC6119]。这些辅助路由器ID必须包含在第3.3.2节所述的链路属性中。
It is desirable that the Router-ID assignments inside the Node Descriptor are globally unique. However, there may be Router-ID spaces (e.g., ISO) where no global registry exists, or worse, Router-IDs have been allocated following the private-IP allocation described in RFC 1918 [RFC1918]. BGP-LS uses the Autonomous System (AS) Number and BGP-LS Identifier (see Section 3.2.1.4) to disambiguate the Router-IDs, as described in Section 3.2.1.1.
希望节点描述符内的路由器ID分配是全局唯一的。但是，可能存在不存在全局注册表的路由器ID空间（例如ISO），或者更糟糕的是，路由器ID已按照RFC 1918[RFC1918]中描述的专用IP分配进行分配。BGP-LS使用自治系统（AS）编号和BGP-LS标识符（见第3.2.1.4节）消除路由器ID的歧义，如第3.2.1.1节所述。
One problem that needs to be addressed is the ability to identify an IGP node globally (by "globally", we mean within the BGP-LS database collected by all BGP-LS speakers that talk to each other). This can be expressed through the following two requirements:
需要解决的一个问题是全局识别IGP节点的能力（我们所说的“全局”，是指在所有相互交谈的BGP-LS发言者收集的BGP-LS数据库中）。这可以通过以下两个要求来表达：
(A) The same node MUST NOT be represented by two keys (otherwise, one node will look like two nodes).
（A） 同一节点不能由两个键表示（否则，一个节点看起来像两个节点）。
(B) Two different nodes MUST NOT be represented by the same key (otherwise, two nodes will look like one node).
（B） 两个不同的节点不能由同一个键表示（否则，两个节点将看起来像一个节点）。
We define an "IGP domain" to be the set of nodes (hence, by extension links and prefixes) within which each node has a unique IGP representation by using the combination of Area-ID, Router-ID, Protocol-ID, Multi-Topology ID, and Instance-ID. The problem is that BGP may receive node/link/prefix information from multiple independent "IGP domains", and we need to distinguish between them. Moreover, we can't assume there is always one and only one IGP domain per AS. During IGP transitions, it may happen that two redundant IGPs are in place.
我们将“IGP域”定义为一组节点（因此，通过扩展链路和前缀），其中每个节点通过使用区域ID、路由器ID、协议ID、多拓扑ID和实例ID的组合具有唯一的IGP表示。问题是BGP可能从多个独立的“IGP域”接收节点/链路/前缀信息，我们需要区分它们。此外，我们不能假设每个AS都有且只有一个IGP域。在IGP转换期间，可能会发生两个冗余IGP就位的情况。
In Section 3.2.1.4, a set of sub-TLVs is described, which allows specification of a flexible key for any given node/link information such that global uniqueness of the NLRI is ensured.
在第3.2.1.4节中，描述了一组子TLV，其允许为任何给定节点/链路信息指定灵活密钥，从而确保NLRI的全局唯一性。
The Local Node Descriptors TLV contains Node Descriptors for the node anchoring the local end of the link. This is a mandatory TLV in all three types of NLRIs (node, link, and prefix). The length of this TLV is variable. The value contains one or more Node Descriptor Sub-TLVs defined in Section 3.2.1.4.
本地节点描述符TLV包含用于锚定链接本地端的节点的节点描述符。这是所有三种NLRI（节点、链接和前缀）中的强制TLV。此TLV的长度是可变的。该值包含第3.2.1.4节中定义的一个或多个节点描述符子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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Node Descriptor Sub-TLVs (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Node Descriptor Sub-TLVs (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Local Node Descriptors TLV Format
图10：本地节点描述符TLV格式
The Remote Node Descriptors TLV contains Node Descriptors for the node anchoring the remote end of the link. This is a mandatory TLV for Link NLRIs. The length of this TLV is variable. The value contains one or more Node Descriptor Sub-TLVs defined in Section 3.2.1.4.
远程节点描述符TLV包含用于锚定链路远程端的节点的节点描述符。这是链接NLRIs的强制TLV。此TLV的长度是可变的。该值包含第3.2.1.4节中定义的一个或多个节点描述符子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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Node Descriptor Sub-TLVs (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Node Descriptor Sub-TLVs (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Remote Node Descriptors TLV Format
图11：远程节点描述符TLV格式
The Node Descriptor Sub-TLV type code points and lengths are listed in the following table:
下表列出了节点描述符子TLV类型代码点和长度：
+--------------------+-------------------+----------+
| Sub-TLV Code Point | Description | Length |
+--------------------+-------------------+----------+
| 512 | Autonomous System | 4 |
| 513 | BGP-LS Identifier | 4 |
| 514 | OSPF Area-ID | 4 |
| 515 | IGP Router-ID | Variable |
+--------------------+-------------------+----------+
+--------------------+-------------------+----------+
| Sub-TLV Code Point | Description | Length |
+--------------------+-------------------+----------+
| 512 | Autonomous System | 4 |
| 513 | BGP-LS Identifier | 4 |
| 514 | OSPF Area-ID | 4 |
| 515 | IGP Router-ID | Variable |
+--------------------+-------------------+----------+
Table 4: Node Descriptor Sub-TLVs
表4：节点描述符子TLV
The sub-TLV values in Node Descriptor TLVs are defined as follows:
节点描述符TLV中的子TLV值定义如下：
Autonomous System: Opaque value (32-bit AS Number)
自治系统：不透明值（32位作为数字）
BGP-LS Identifier: Opaque value (32-bit ID). In conjunction with Autonomous System Number (ASN), uniquely identifies the BGP-LS domain. The combination of ASN and BGP-LS ID MUST be globally unique. All BGP-LS speakers within an IGP flooding-set (set of IGP nodes within which an LSP/LSA is flooded) MUST use the same ASN, BGP-LS ID tuple. If an IGP domain consists of multiple flooding-sets, then all BGP-LS speakers within the IGP domain SHOULD use the same ASN, BGP-LS ID tuple.
BGP-LS标识符：不透明值（32位ID）。与自治系统编号（ASN）一起，唯一标识BGP-LS域。ASN和BGP-LS ID的组合必须是全局唯一的。IGP泛洪集合（LSP/LSA泛洪的IGP节点集合）内的所有BGP-LS扬声器必须使用相同的ASN、BGP-LS ID元组。如果IGP域由多个泛洪集组成，则IGP域内的所有BGP-LS扬声器应使用相同的ASN、BGP-LS ID元组。
Area-ID: Used to identify the 32-bit area to which the NLRI belongs. The Area Identifier allows different NLRIs of the same router to be discriminated.
区域ID：用于标识NLRI所属的32位区域。区域标识符允许区分同一路由器的不同NLRI。
IGP Router-ID: Opaque value. This is a mandatory TLV. For an IS-IS non-pseudonode, this contains a 6-octet ISO Node-ID (ISO system-ID). For an IS-IS pseudonode corresponding to a LAN, this
IGP路由器ID：不透明值。这是一个强制性的TLV。对于IS-IS非伪节点，它包含6个八位组的ISO节点ID（ISO系统ID）。对于与LAN相对应的IS-IS伪节点
contains the 6-octet ISO Node-ID of the Designated Intermediate System (DIS) followed by a 1-octet, nonzero PSN identifier (7 octets in total). For an OSPFv2 or OSPFv3 non-pseudonode, this contains the 4-octet Router-ID. For an OSPFv2 pseudonode representing a LAN, this contains the 4-octet Router-ID of the Designated Router (DR) followed by the 4-octet IPv4 address of the DR's interface to the LAN (8 octets in total). Similarly, for an OSPFv3 pseudonode, this contains the 4-octet Router-ID of the DR followed by the 4-octet interface identifier of the DR's interface to the LAN (8 octets in total). The TLV size in combination with the protocol identifier enables the decoder to determine the type of the node.
包含指定中间系统（DIS）的6个八位组ISO节点ID，后跟1个八位组非零PSN标识符（总共7个八位组）。对于OSPFv2或OSPFv3非伪节点，它包含4-octet路由器ID。对于表示LAN的OSPFv2伪节点，它包含指定路由器（DR）的4-octet路由器ID，后跟DR与LAN接口的4-octet IPv4地址（总共8个八位字节）。类似地，对于OSPFv3伪节点，它包含DR的4-octet路由器ID，后跟DR与LAN接口的4-octet接口标识符（总共8个八位字节）。TLV大小与协议标识符相结合使得解码器能够确定节点的类型。
There can be at most one instance of each sub-TLV type present in any Node Descriptor. The sub-TLVs within a Node Descriptor MUST be arranged in ascending order by sub-TLV type. This needs to be done in order to compare NLRIs, even when an implementation encounters an unknown sub-TLV. Using stable sorting, an implementation can do binary comparison of NLRIs and hence allow incremental deployment of new key sub-TLVs.
在任何节点描述符中，每个子TLV类型最多只能有一个实例。节点描述符中的子TLV必须按子TLV类型按升序排列。为了比较NLRI，即使实现遇到未知的子TLV，也需要这样做。使用稳定排序，实现可以对NLRI进行二进制比较，从而允许增量部署新的关键子TLV。
The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF Multi-Topology IDs for a link, node, or prefix.
多拓扑ID（MT-ID）TLV为链路、节点或前缀携带一个或多个IS-IS或OSPF多拓扑ID。
Semantics of the IS-IS MT-ID are defined in Section 7.2 of RFC 5120 [RFC5120]. Semantics of the OSPF MT-ID are defined in Section 3.7 of RFC 4915 [RFC4915]. If the value in the MT-ID TLV is derived from OSPF, then the upper 9 bits MUST be set to 0. Bits R are reserved and SHOULD be set to 0 when originated and ignored on receipt.
IS-IS MT-ID的语义在RFC 5120[RFC5120]第7.2节中定义。OSPF MT-ID的语义在RFC 4915[RFC4915]第3.7节中定义。如果MT-ID TLV中的值来自OSPF，则高9位必须设置为0。位R是保留的，在发起时应设置为0，并在接收时忽略。
The format of the MT-ID TLV is shown in the following figure.
MT-ID 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=2*n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| Multi-Topology ID 1 | .... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// .... |R R R R| Multi-Topology ID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=2*n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| Multi-Topology ID 1 | .... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// .... |R R R R| Multi-Topology ID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Multi-Topology ID TLV Format
图12：多拓扑ID TLV格式
where Type is 263, Length is 2*n, and n is the number of MT-IDs carried in the TLV.
其中Type为263，长度为2*n，n为TLV中携带的MT ID数量。
The MT-ID TLV MAY be present in a Link Descriptor, a Prefix Descriptor, or the BGP-LS attribute of a Node NLRI. In a Link or Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of the topology where the link or the prefix is reachable is allowed. In case one wants to advertise multiple topologies for a given Link Descriptor or Prefix Descriptor, multiple NLRIs need to be generated where each NLRI contains an unique MT-ID. In the BGP-LS attribute of a Node NLRI, one MT-ID TLV containing the array of MT-IDs of all topologies where the node is reachable is allowed.
MT-ID TLV可以存在于节点NLRI的链路描述符、前缀描述符或BGP-LS属性中。在链路或前缀描述符中，仅允许包含链路或前缀可到达的拓扑的MT-ID的单个MT-ID TLV。如果要为给定的链路描述符或前缀描述符播发多个拓扑，则需要生成多个NLRI，其中每个NLRI包含唯一的MT-ID。在节点NLRI的BGP-LS属性中，允许一个MT-ID TLV，其中包含节点可访问的所有拓扑的MT ID数组。
The Link Descriptor field is a set of Type/Length/Value (TLV) triplets. The format of each TLV is shown in Section 3.1. The Link Descriptor TLVs uniquely identify a link among multiple parallel links between a pair of anchor routers. A link described by the Link Descriptor TLVs actually is a "half-link", a unidirectional representation of a logical link. In order to fully describe a single logical link, two originating routers advertise a half-link each, i.e., two Link NLRIs are advertised for a given point-to-point link.
链接描述符字段是一组类型/长度/值（TLV）三元组。各TLV的格式见第3.1节。链路描述符tlv唯一地标识一对锚路由器之间的多个并行链路中的链路。链路描述符TLV描述的链路实际上是“半链路”，是逻辑链路的单向表示。为了充分描述单个逻辑链路，两个发起路由器分别通告一个半链路，即，为给定的点到点链路通告两个链路nlri。
The format and semantics of the Value fields in most Link Descriptor TLVs correspond to the format and semantics of Value fields in IS-IS Extended IS Reachability sub-TLVs, defined in [RFC5305], [RFC5307], and [RFC6119]. Although the encodings for Link Descriptor TLVs were originally defined for IS-IS, the TLVs can carry data sourced by either IS-IS or OSPF.
大多数链路描述符TLV中值字段的格式和语义对应于IS-IS扩展IS可达性子TLV中值字段的格式和语义，定义见[RFC5305]、[RFC5307]和[RFC6119]。虽然链路描述符TLV的编码最初是为IS-IS定义的，但TLV可以携带IS-IS或OSPF来源的数据。
The following TLVs are valid as Link Descriptors in the Link NLRI:
以下TLV作为链接NLRI中的链接描述符有效：
+-----------+---------------------+--------------+------------------+
| TLV Code | Description | IS-IS TLV | Reference |
| Point | | /Sub-TLV | (RFC/Section) |
+-----------+---------------------+--------------+------------------+
| 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 |
| | Identifiers | | |
| 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 |
| | address | | |
| 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 |
| | address | | |
| 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 |
| | address | | |
| 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 |
| | address | | |
| 263 | Multi-Topology | --- | Section 3.2.1.5 |
| | Identifier | | |
+-----------+---------------------+--------------+------------------+
+-----------+---------------------+--------------+------------------+
| TLV Code | Description | IS-IS TLV | Reference |
| Point | | /Sub-TLV | (RFC/Section) |
+-----------+---------------------+--------------+------------------+
| 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 |
| | Identifiers | | |
| 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 |
| | address | | |
| 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 |
| | address | | |
| 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 |
| | address | | |
| 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 |
| | address | | |
| 263 | Multi-Topology | --- | Section 3.2.1.5 |
| | Identifier | | |
+-----------+---------------------+--------------+------------------+
Table 5: Link Descriptor TLVs
表5：链路描述符TLV
The information about a link present in the LSA/LSP originated by the local node of the link determines the set of TLVs in the Link Descriptor of the link.
由链路的本地节点发起的LSA/LSP中存在的链路的相关信息确定链路的链路描述符中的tlv集合。
If interface and neighbor addresses, either IPv4 or IPv6, are present, then the IP address TLVs are included in the Link Descriptor but not the link local/remote Identifier TLV. The link local/remote identifiers MAY be included in the link attribute.
如果存在接口和邻居地址（IPv4或IPv6），则IP地址TLV包括在链路描述符中，但不包括链路本地/远程标识符TLV。链路本地/远程标识符可以包括在链路属性中。
If interface and neighbor addresses are not present and the link local/remote identifiers are present, then the link local/remote Identifier TLV is included in the Link Descriptor.
如果接口和邻居地址不存在且链路本地/远程标识符存在，则链路本地/远程标识符TLV包括在链路描述符中。
The Multi-Topology Identifier TLV is included in Link Descriptor if that information is present.
多拓扑标识符TLV包含在链路描述符中（如果存在该信息）。
The Prefix Descriptor field is a set of Type/Length/Value (TLV) triplets. Prefix Descriptor TLVs uniquely identify an IPv4 or IPv6 prefix originated by a node. The following TLVs are valid as Prefix Descriptors in the IPv4/IPv6 Prefix NLRI:
前缀描述符字段是一组类型/长度/值（TLV）三元组。前缀描述符TLV唯一标识由节点发起的IPv4或IPv6前缀。以下TLV作为IPv4/IPv6前缀NLRI中的前缀描述符有效：
+-------------+---------------------+----------+--------------------+
| TLV Code | Description | Length | Reference |
| Point | | | (RFC/Section) |
+-------------+---------------------+----------+--------------------+
| 263 | Multi-Topology | variable | Section 3.2.1.5 |
| | Identifier | | |
| 264 | OSPF Route Type | 1 | Section 3.2.3.1 |
| 265 | IP Reachability | variable | Section 3.2.3.2 |
| | Information | | |
+-------------+---------------------+----------+--------------------+
+-------------+---------------------+----------+--------------------+
| TLV Code | Description | Length | Reference |
| Point | | | (RFC/Section) |
+-------------+---------------------+----------+--------------------+
| 263 | Multi-Topology | variable | Section 3.2.1.5 |
| | Identifier | | |
| 264 | OSPF Route Type | 1 | Section 3.2.3.1 |
| 265 | IP Reachability | variable | Section 3.2.3.2 |
| | Information | | |
+-------------+---------------------+----------+--------------------+
Table 6: Prefix Descriptor TLVs
表6：前缀描述符TLV
The OSPF Route Type TLV is an optional TLV that MAY be present in Prefix NLRIs. It is used to identify the OSPF route type of the prefix. It is used when an OSPF prefix is advertised in the OSPF domain with multiple route types. The Route Type TLV allows the discrimination of these advertisements. The format of the OSPF Route Type TLV is shown in the following figure.
OSPF路由类型TLV是可选的TLV，可能出现在前缀NLRIs中。它用于标识前缀的OSPF路由类型。在OSPF域中以多种路由类型播发OSPF前缀时使用。路由类型TLV允许区分这些广告。OSPF路由类型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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type |
+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type |
+-+-+-+-+-+-+-+-+
Figure 13: OSPF Route Type TLV Format
图13:OSPF路由类型TLV格式
where the Type and Length fields of the TLV are defined in Table 6. The OSPF Route Type field values are defined in the OSPF protocol and can be one of the following:
其中TLV的类型和长度字段在表6中定义。OSPF路由类型字段值在OSPF协议中定义，可以是以下值之一：
o Intra-Area (0x1)
o 内部区域（0x1）
o Inter-Area (0x2)
o 区域间（0x2）
o External 1 (0x3)
o 外部1（0x3）
o External 2 (0x4)
o 外部2（0x4）
o NSSA 1 (0x5)
o NSSA 1（0x5）
o NSSA 2 (0x6)
o NSSA 2（0x6）
The IP Reachability Information TLV is a mandatory TLV that contains one IP address prefix (IPv4 or IPv6) originally advertised in the IGP topology. Its purpose is to glue a particular BGP service NLRI by virtue of its BGP next hop to a given node in the LSDB. A router SHOULD advertise an IP Prefix NLRI for each of its BGP next hops. The format of the IP Reachability Information TLV is shown in the following figure:
IP可达性信息TLV是一个强制TLV，它包含一个最初在IGP拓扑中公布的IP地址前缀（IPv4或IPv6）。其目的是通过BGP下一跳将特定BGP服务NLRI粘附到LSDB中的给定节点。路由器应为其每个BGP下一跳播发IP前缀NLRI。IP可达性信息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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | IP Prefix (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: IP Reachability Information TLV Format
图14:IP可达性信息TLV格式
The Type and Length fields of the TLV are defined in Table 6. The following two fields determine the reachability information of the address family. The Prefix Length field contains the length of the prefix in bits. The IP Prefix field contains the most significant octets of the prefix, i.e., 1 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 16, 3 octets for prefix length 17 up to 24, 4 octets for prefix length 25 up to 32, etc.
表6中定义了TLV的类型和长度字段。以下两个字段确定地址族的可达性信息。前缀长度字段包含前缀的长度（以位为单位）。IP前缀字段包含前缀最重要的八位字节，即1个八位字节表示前缀长度1到8，2个八位字节表示前缀长度9到16，3个八位字节表示前缀长度17到24，4个八位字节表示前缀长度25到32，等等。
The BGP-LS attribute is an optional, non-transitive BGP attribute that is used to carry link, node, and prefix parameters and attributes. It is defined as a set of Type/Length/Value (TLV) triplets, described in the following section. This attribute SHOULD only be included with Link-State NLRIs. This attribute MUST be ignored for all other address families.
BGP-LS属性是可选的、不可传递的BGP属性，用于承载链接、节点和前缀参数和属性。它被定义为一组类型/长度/值（TLV）三元组，如下节所述。此属性应仅包含在链接状态NLRIs中。对于所有其他地址族，必须忽略此属性。
Node attribute TLVs are the TLVs that may be encoded in the BGP-LS attribute with a Node NLRI. The following Node Attribute TLVs are defined:
节点属性TLV是可以使用节点NLRI在BGP-LS属性中编码的TLV。定义了以下节点属性TLV：
+-------------+----------------------+----------+-------------------+
| TLV Code | Description | Length | Reference |
| Point | | | (RFC/Section) |
+-------------+----------------------+----------+-------------------+
| 263 | Multi-Topology | variable | Section 3.2.1.5 |
| | Identifier | | |
| 1024 | Node Flag Bits | 1 | Section 3.3.1.1 |
| 1025 | Opaque Node | variable | Section 3.3.1.5 |
| | Attribute | | |
| 1026 | Node Name | variable | Section 3.3.1.3 |
| 1027 | IS-IS Area | variable | Section 3.3.1.2 |
| | Identifier | | |
| 1028 | IPv4 Router-ID of | 4 | [RFC5305]/4.3 |
| | Local Node | | |
| 1029 | IPv6 Router-ID of | 16 | [RFC6119]/4.1 |
| | Local Node | | |
+-------------+----------------------+----------+-------------------+
+-------------+----------------------+----------+-------------------+
| TLV Code | Description | Length | Reference |
| Point | | | (RFC/Section) |
+-------------+----------------------+----------+-------------------+
| 263 | Multi-Topology | variable | Section 3.2.1.5 |
| | Identifier | | |
| 1024 | Node Flag Bits | 1 | Section 3.3.1.1 |
| 1025 | Opaque Node | variable | Section 3.3.1.5 |
| | Attribute | | |
| 1026 | Node Name | variable | Section 3.3.1.3 |
| 1027 | IS-IS Area | variable | Section 3.3.1.2 |
| | Identifier | | |
| 1028 | IPv4 Router-ID of | 4 | [RFC5305]/4.3 |
| | Local Node | | |
| 1029 | IPv6 Router-ID of | 16 | [RFC6119]/4.1 |
| | Local Node | | |
+-------------+----------------------+----------+-------------------+
Table 7: Node Attribute TLVs
表7：节点属性TLV
The Node Flag Bits TLV carries a bit mask describing node attributes. The value is a variable-length bit array of flags, where each bit represents a node capability.
节点标志位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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|T|E|B|R|V| Rsvd|
+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|T|E|B|R|V| Rsvd|
+-+-+-+-+-+-+-+-+-+
Figure 15: Node Flag Bits TLV Format
图15：节点标志位TLV格式
The bits are defined as follows:
这些位的定义如下：
+-----------------+-------------------------+------------+
| Bit | Description | Reference |
+-----------------+-------------------------+------------+
| 'O' | Overload Bit | [ISO10589] |
| 'T' | Attached Bit | [ISO10589] |
| 'E' | External Bit | [RFC2328] |
| 'B' | ABR Bit | [RFC2328] |
| 'R' | Router Bit | [RFC5340] |
| 'V' | V6 Bit | [RFC5340] |
| Reserved (Rsvd) | Reserved for future use | |
+-----------------+-------------------------+------------+
+-----------------+-------------------------+------------+
| Bit | Description | Reference |
+-----------------+-------------------------+------------+
| 'O' | Overload Bit | [ISO10589] |
| 'T' | Attached Bit | [ISO10589] |
| 'E' | External Bit | [RFC2328] |
| 'B' | ABR Bit | [RFC2328] |
| 'R' | Router Bit | [RFC5340] |
| 'V' | V6 Bit | [RFC5340] |
| Reserved (Rsvd) | Reserved for future use | |
+-----------------+-------------------------+------------+
Table 8: Node Flag Bits Definitions
表8：节点标志位定义
An IS-IS node can be part of one or more IS-IS areas. Each of these area addresses is carried in the IS-IS Area Identifier TLV. If multiple area addresses are present, multiple TLVs are used to encode them. The IS-IS Area Identifier TLV may be present in the BGP-LS attribute only when advertised in the Link-State Node NLRI.
IS-IS节点可以是一个或多个IS-IS区域的一部分。这些区域地址中的每一个都携带在is-is区域标识符TLV中。如果存在多个区域地址，则使用多个TLV对其进行编码。仅当在链路状态节点NLRI中通告时，IS-IS区域标识符TLV才可能出现在BGP-LS属性中。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Area Identifier (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Area Identifier (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: IS-IS Area Identifier TLV Format
图16:IS-IS区域标识符TLV格式
The Node Name TLV is optional. Its structure and encoding has been borrowed from [RFC5301]. The Value field identifies the symbolic name of the router node. This symbolic name can be the Fully Qualified Domain Name (FQDN) for the router, it can be a subset of the FQDN (e.g., a hostname), or it can be any string operators want to use for the router. The use of FQDN or a subset of it is strongly RECOMMENDED. The maximum length of the Node Name TLV is 255 octets.
节点名TLV是可选的。其结构和编码借鉴了[RFC5301]。值字段标识路由器节点的符号名称。此符号名可以是路由器的完全限定域名（FQDN），也可以是FQDN的子集（例如主机名），也可以是操作员希望用于路由器的任何字符串。强烈建议使用FQDN或其子集。节点名TLV的最大长度为255个八位字节。
The Value field is encoded in 7-bit ASCII. If a user interface for configuring or displaying this field permits Unicode characters, that user interface is responsible for applying the ToASCII and/or ToUnicode algorithm as described in [RFC5890] to achieve the correct format for transmission or display.
值字段以7位ASCII编码。如果用于配置或显示此字段的用户界面允许使用Unicode字符，则该用户界面负责应用[RFC5890]中所述的ToASCII和/或ToUnicode算法，以获得正确的传输或显示格式。
Although [RFC5301] describes an IS-IS-specific extension, usage of the Node Name TLV is possible for all protocols. How a router derives and injects node names, e.g., OSPF nodes, is outside of the scope of this document.
尽管[RFC5301]描述了特定于IS的扩展，但所有协议都可以使用节点名TLV。路由器如何派生和注入节点名称（例如OSPF节点）不在本文档范围内。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Node Name (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Node Name (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Node Name Format
图17：节点名称格式
The local IPv4/IPv6 Router-ID TLVs are used to describe auxiliary Router-IDs that the IGP might be using, e.g., for TE and migration purposes such as correlating a Node-ID between different protocols. If there is more than one auxiliary Router-ID of a given type, then each one is encoded in its own TLV.
本地IPv4/IPv6路由器ID TLV用于描述IGP可能使用的辅助路由器ID，例如，用于TE和迁移目的，例如在不同协议之间关联节点ID。如果给定类型有多个辅助路由器ID，则每个辅助路由器ID都在其自己的TLV中编码。
The Opaque Node Attribute TLV is an envelope that transparently carries optional Node Attribute TLVs advertised by a router. An originating router shall use this TLV for encoding information specific to the protocol advertised in the NLRI header Protocol-ID field or new protocol extensions to the protocol as advertised in the NLRI header Protocol-ID field for which there is no protocol-neutral representation in the BGP Link-State NLRI. The primary use of the Opaque Node Attribute TLV is to bridge the document lag between, e.g., a new IGP link-state attribute being defined and the protocol-neutral BGP-LS extensions being published. A router, for example, could use this extension in order to advertise the native protocol's Node Attribute TLVs, such as the OSPF Router Informational Capabilities TLV defined in [RFC7770] or the IGP TE Node Capability Descriptor TLV described in [RFC5073].
不透明节点属性TLV是一个信封，它透明地携带路由器公布的可选节点属性TLV。发起路由器应使用该TLV编码NLRI头协议ID字段中公布的协议的特定信息，或NLRI头协议ID字段中公布的协议的新协议扩展，BGP链路状态NLRI中没有协议中立表示。不透明节点属性TLV的主要用途是在定义新的IGP链路状态属性和发布协议中立的BGP-LS扩展之间桥接文档延迟。例如，路由器可以使用此扩展来公布本机协议的节点属性TLV，例如[RFC7770]中定义的OSPF路由器信息能力TLV或[RFC5073]中描述的IGP TE节点能力描述符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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque node attributes (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque node attributes (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Opaque Node Attribute Format
图18：不透明节点属性格式
Link Attribute TLVs are TLVs that may be encoded in the BGP-LS attribute with a Link NLRI. Each 'Link Attribute' is a Type/Length/ Value (TLV) triplet formatted as defined in Section 3.1. The format and semantics of the Value fields in some Link Attribute TLVs correspond to the format and semantics of the Value fields in IS-IS Extended IS Reachability sub-TLVs, defined in [RFC5305] and [RFC5307]. Other Link Attribute TLVs are defined in this document. Although the encodings for Link Attribute TLVs were originally defined for IS-IS, the TLVs can carry data sourced by either IS-IS or OSPF.
链路属性TLV是可以使用链路NLRI在BGP-LS属性中编码的TLV。每个“链接属性”都是一个类型/长度/值（TLV）三元组，格式如第3.1节所定义。某些链接属性TLV中的值字段的格式和语义与[RFC5305]和[RFC5307]中定义的IS-IS扩展IS可达性子TLV中的值字段的格式和语义相对应。本文档中定义了其他链接属性TLV。虽然链路属性TLV的编码最初是为IS-IS定义的，但TLV可以携带IS-IS或OSPF来源的数据。
The following Link Attribute TLVs are valid in the BGP-LS attribute with a Link NLRI:
以下链接属性TLV在具有链接NLRI的BGP-LS属性中有效：
+-----------+---------------------+--------------+------------------+
| TLV Code | Description | IS-IS TLV | Reference |
| Point | | /Sub-TLV | (RFC/Section) |
+-----------+---------------------+--------------+------------------+
| 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Local Node | | |
| 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Local Node | | |
| 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Remote Node | | |
| 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Remote Node | | |
| 1088 | Administrative | 22/3 | [RFC5305]/3.1 |
| | group (color) | | |
| 1089 | Maximum link | 22/9 | [RFC5305]/3.4 |
| | bandwidth | | |
| 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 |
| | link bandwidth | | |
| 1091 | Unreserved | 22/11 | [RFC5305]/3.6 |
| | bandwidth | | |
| 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 |
| 1093 | Link Protection | 22/20 | [RFC5307]/1.2 |
| | Type | | |
| 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 |
| 1095 | IGP Metric | --- | Section 3.3.2.4 |
| 1096 | Shared Risk Link | --- | Section 3.3.2.5 |
| | Group | | |
| 1097 | Opaque Link | --- | Section 3.3.2.6 |
| | Attribute | | |
| 1098 | Link Name | --- | Section 3.3.2.7 |
+-----------+---------------------+--------------+------------------+
+-----------+---------------------+--------------+------------------+
| TLV Code | Description | IS-IS TLV | Reference |
| Point | | /Sub-TLV | (RFC/Section) |
+-----------+---------------------+--------------+------------------+
| 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Local Node | | |
| 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Local Node | | |
| 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Remote Node | | |
| 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Remote Node | | |
| 1088 | Administrative | 22/3 | [RFC5305]/3.1 |
| | group (color) | | |
| 1089 | Maximum link | 22/9 | [RFC5305]/3.4 |
| | bandwidth | | |
| 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 |
| | link bandwidth | | |
| 1091 | Unreserved | 22/11 | [RFC5305]/3.6 |
| | bandwidth | | |
| 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 |
| 1093 | Link Protection | 22/20 | [RFC5307]/1.2 |
| | Type | | |
| 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 |
| 1095 | IGP Metric | --- | Section 3.3.2.4 |
| 1096 | Shared Risk Link | --- | Section 3.3.2.5 |
| | Group | | |
| 1097 | Opaque Link | --- | Section 3.3.2.6 |
| | Attribute | | |
| 1098 | Link Name | --- | Section 3.3.2.7 |
+-----------+---------------------+--------------+------------------+
Table 9: Link Attribute TLVs
表9：链接属性TLV
The local/remote IPv4/IPv6 Router-ID TLVs are used to describe auxiliary Router-IDs that the IGP might be using, e.g., for TE purposes. All auxiliary Router-IDs of both the local and the remote node MUST be included in the link attribute of each Link NLRI. If there is more than one auxiliary Router-ID of a given type, then multiple TLVs are used to encode them.
本地/远程IPv4/IPv6路由器ID TLV用于描述IGP可能使用的辅助路由器ID，例如用于TE目的。本地和远程节点的所有辅助路由器ID必须包含在每个链路NLRI的链路属性中。如果给定类型有多个辅助路由器ID，则使用多个TLV对其进行编码。
The MPLS Protocol Mask TLV carries a bit mask describing which MPLS signaling protocols are enabled. The length of this TLV is 1. The value is a bit array of 8 flags, where each bit represents an MPLS Protocol capability.
MPLS协议掩码TLV带有一个位掩码，描述启用了哪些MPLS信令协议。该TLV的长度为1。该值是由8个标志组成的位数组，其中每个位表示MPLS协议功能。
Generation of the MPLS Protocol Mask TLV is only valid for and SHOULD only be used with originators that have local link insight, for example, the Protocol-IDs 'Static configuration' or 'Direct' as per Table 2. The MPLS Protocol Mask TLV MUST NOT be included in NLRIs with the other Protocol-IDs listed in Table 2.
MPLS协议掩码TLV的生成仅对具有本地链路洞察的发起人有效，并且仅应与具有本地链路洞察的发起人一起使用，例如，如表2所示的协议ID“静态配置”或“直接”。MPLS协议掩码TLV不得与表2中列出的其他协议ID一起包含在NLRIs中。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|R| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|R| Reserved |
+-+-+-+-+-+-+-+-+
Figure 19: MPLS Protocol Mask TLV
图19:MPLS协议掩码TLV
The following bits are defined:
定义了以下位：
+------------+------------------------------------------+-----------+
| Bit | Description | Reference |
+------------+------------------------------------------+-----------+
| 'L' | Label Distribution Protocol (LDP) | [RFC5036] |
| 'R' | Extension to RSVP for LSP Tunnels | [RFC3209] |
| | (RSVP-TE) | |
| 'Reserved' | Reserved for future use | |
+------------+------------------------------------------+-----------+
+------------+------------------------------------------+-----------+
| Bit | Description | Reference |
+------------+------------------------------------------+-----------+
| 'L' | Label Distribution Protocol (LDP) | [RFC5036] |
| 'R' | Extension to RSVP for LSP Tunnels | [RFC3209] |
| | (RSVP-TE) | |
| 'Reserved' | Reserved for future use | |
+------------+------------------------------------------+-----------+
Table 10: MPLS Protocol Mask TLV Codes
表10:MPLS协议掩码TLV代码
The TE Default Metric TLV carries the Traffic Engineering metric for this link. The length of this TLV is fixed at 4 octets. If a source protocol uses a metric width of less than 32 bits, then the high-order bits of this field MUST be padded with zero.
TE默认度量TLV携带此链路的流量工程度量。该TLV的长度固定为4个八位字节。如果源协议使用的度量宽度小于32位，则此字段的高阶位必须用零填充。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Default Link Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Default Link Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: TE Default Metric TLV Format
图20:TE默认公制TLV格式
The IGP Metric TLV carries the metric for this link. The length of this TLV is variable, depending on the metric width of the underlying protocol. IS-IS small metrics have a length of 1 octet (the two most significant bits are ignored). OSPF link metrics have a length of 2 octets. IS-IS wide metrics have a length of 3 octets.
IGP度量TLV承载此链路的度量。此TLV的长度是可变的，这取决于基础协议的度量宽度。IS-IS小度量的长度为1个八位字节（忽略两个最高有效位）。OSPF链路度量的长度为2个八位字节。IS-IS宽度量的长度为3个八位字节。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IGP Link Metric (variable 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IGP Link Metric (variable length) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: IGP Metric TLV Format
图21:IGP公制TLV格式
The Shared Risk Link Group (SRLG) TLV carries the Shared Risk Link Group information (see Section 2.3 ("Shared Risk Link Group Information") of [RFC4202]). It contains a data structure consisting of a (variable) list of SRLG values, where each element in the list has 4 octets, as shown in Figure 22. The length of this TLV is 4 * (number of SRLG values).
共享风险链接组（SRLG）TLV携带共享风险链接组信息（见[RFC4202]第2.3节（“共享风险链接组信息”）。它包含一个由SRLG值（变量）列表组成的数据结构，列表中的每个元素有4个八位字节，如图22所示。该TLV的长度为4*（SRLG值的数量）。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ............ //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Shared Risk Link Group TLV Format
图22：共享风险链接组TLV格式
The SRLG TLV for OSPF-TE is defined in [RFC4203]. In IS-IS, the SRLG information is carried in two different TLVs: the IPv4 (SRLG) TLV (Type 138) defined in [RFC5307] and the IPv6 SRLG TLV (Type 139) defined in [RFC6119]. In Link-State NLRI, both IPv4 and IPv6 SRLG information are carried in a single TLV.
OSPF-TE的SRLG TLV在[RFC4203]中定义。在IS-IS中，SRLG信息在两种不同的TLV中传输：在[RFC5307]中定义的IPv4（SRLG）TLV（类型138）和在[RFC6119]中定义的IPv6 SRLG TLV（类型139）。在链路状态NLRI中，IPv4和IPv6 SRLG信息都在单个TLV中承载。
The Opaque Link Attribute TLV is an envelope that transparently carries optional Link Attribute TLVs advertised by a router. An originating router shall use this TLV for encoding information specific to the protocol advertised in the NLRI header Protocol-ID field or new protocol extensions to the protocol as advertised in the NLRI header Protocol-ID field for which there is no protocol-neutral representation in the BGP Link-State NLRI. The primary use of the Opaque Link Attribute TLV is to bridge the document lag between, e.g., a new IGP link-state attribute being defined and the 'protocol-neutral' BGP-LS extensions being published.
不透明链路属性TLV是一个信封，它透明地携带路由器公布的可选链路属性TLV。发起路由器应使用该TLV编码NLRI头协议ID字段中公布的协议的特定信息，或NLRI头协议ID字段中公布的协议的新协议扩展，BGP链路状态NLRI中没有协议中立表示。不透明链路属性TLV的主要用途是在定义新的IGP链路状态属性和发布“协议中立”BGP-LS扩展之间桥接文档延迟。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque link attributes (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque link attributes (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Opaque Link Attribute TLV Format
图23：不透明链接属性TLV格式
The Link Name TLV is optional. The Value field identifies the symbolic name of the router link. This symbolic name can be the FQDN for the link, it can be a subset of the FQDN, or it can be any string
链接名称TLV是可选的。值字段标识路由器链路的符号名称。此符号名可以是链接的FQDN，也可以是FQDN的子集，也可以是任何字符串
operators want to use for the link. The use of FQDN or a subset of it is strongly RECOMMENDED. The maximum length of the Link Name TLV is 255 octets.
操作员希望用于链接。强烈建议使用FQDN或其子集。链接名TLV的最大长度为255个八位字节。
The Value field is encoded in 7-bit ASCII. If a user interface for configuring or displaying this field permits Unicode characters, that user interface is responsible for applying the ToASCII and/or ToUnicode algorithm as described in [RFC5890] to achieve the correct format for transmission or display.
值字段以7位ASCII编码。如果用于配置或显示此字段的用户界面允许使用Unicode字符，则该用户界面负责应用[RFC5890]中所述的ToASCII和/或ToUnicode算法，以获得正确的传输或显示格式。
How a router derives and injects link names is outside of the scope of this document.
路由器如何派生和注入链接名称超出了本文档的范围。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Link Name (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Link Name (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Link Name TLV Format
图24：链接名称TLV格式
Prefixes are learned from the IGP topology (IS-IS or OSPF) with a set of IGP attributes (such as metric, route tags, etc.) that MUST be reflected into the BGP-LS attribute with a prefix NLRI. This section describes the different attributes related to the IPv4/IPv6 prefixes. Prefix Attribute TLVs SHOULD be used when advertising NLRI types 3 and 4 only. The following Prefix Attribute TLVs are defined:
前缀从IGP拓扑（IS-IS或OSPF）中学习，具有一组IGP属性（如度量、路由标记等），必须使用前缀NLRI反映到BGP-LS属性中。本节介绍与IPv4/IPv6前缀相关的不同属性。仅在宣传NLRI类型3和4时，应使用前缀属性TLV。定义了以下前缀属性TLV：
+---------------+----------------------+----------+-----------------+
| TLV Code | Description | Length | Reference |
| Point | | | |
+---------------+----------------------+----------+-----------------+
| 1152 | IGP Flags | 1 | Section 3.3.3.1 |
| 1153 | IGP Route Tag | 4*n | [RFC5130] |
| 1154 | IGP Extended Route | 8*n | [RFC5130] |
| | Tag | | |
| 1155 | Prefix Metric | 4 | [RFC5305] |
| 1156 | OSPF Forwarding | 4 | [RFC2328] |
| | Address | | |
| 1157 | Opaque Prefix | variable | Section 3.3.3.6 |
| | Attribute | | |
+---------------+----------------------+----------+-----------------+
+---------------+----------------------+----------+-----------------+
| TLV Code | Description | Length | Reference |
| Point | | | |
+---------------+----------------------+----------+-----------------+
| 1152 | IGP Flags | 1 | Section 3.3.3.1 |
| 1153 | IGP Route Tag | 4*n | [RFC5130] |
| 1154 | IGP Extended Route | 8*n | [RFC5130] |
| | Tag | | |
| 1155 | Prefix Metric | 4 | [RFC5305] |
| 1156 | OSPF Forwarding | 4 | [RFC2328] |
| | Address | | |
| 1157 | Opaque Prefix | variable | Section 3.3.3.6 |
| | Attribute | | |
+---------------+----------------------+----------+-----------------+
Table 11: Prefix Attribute TLVs
表11：前缀属性TLV
The IGP Flags TLV contains IS-IS and OSPF flags and bits originally assigned to the prefix. The IGP Flags TLV is encoded as follows:
IGP标志TLV包含IS-IS和OSPF标志以及最初分配给前缀的位。IGP标志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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|N|L|P| Resvd.|
+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|N|L|P| Resvd.|
+-+-+-+-+-+-+-+-+
Figure 25: IGP Flag TLV Format
图25:IGP标志TLV格式
The Value field contains bits defined according to the table below:
值字段包含根据下表定义的位：
+----------+---------------------------+-----------+
| Bit | Description | Reference |
+----------+---------------------------+-----------+
| 'D' | IS-IS Up/Down Bit | [RFC5305] |
| 'N' | OSPF "no unicast" Bit | [RFC5340] |
| 'L' | OSPF "local address" Bit | [RFC5340] |
| 'P' | OSPF "propagate NSSA" Bit | [RFC5340] |
| Reserved | Reserved for future use. | |
+----------+---------------------------+-----------+
+----------+---------------------------+-----------+
| Bit | Description | Reference |
+----------+---------------------------+-----------+
| 'D' | IS-IS Up/Down Bit | [RFC5305] |
| 'N' | OSPF "no unicast" Bit | [RFC5340] |
| 'L' | OSPF "local address" Bit | [RFC5340] |
| 'P' | OSPF "propagate NSSA" Bit | [RFC5340] |
| Reserved | Reserved for future use. | |
+----------+---------------------------+-----------+
Table 12: IGP Flag Bits Definitions
表12:IGP标志位定义
The IGP Route Tag TLV carries original IGP Tags (IS-IS [RFC5130] or OSPF) of the prefix and is encoded as follows:
IGP路由标签TLV携带前缀的原始IGP标签（IS-IS[RFC5130]或OSPF），并且编码如下：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Route Tags (one or more) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Route Tags (one or more) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: IGP Route Tag TLV Format
图26:IGP路线标签TLV格式
Length is a multiple of 4.
长度是4的倍数。
The Value field contains one or more Route Tags as learned in the IGP topology.
值字段包含在IGP拓扑中学习到的一个或多个路由标记。
The Extended IGP Route Tag TLV carries IS-IS Extended Route Tags of the prefix [RFC5130] and is encoded as follows:
扩展IGP路由标签TLV携带前缀为[RFC5130]的IS-IS扩展路由标签，并按如下方式编码：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Extended Route Tag (one or more) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Extended Route Tag (one or more) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: Extended IGP Route Tag TLV Format
图27：扩展IGP路线标签TLV格式
Length is a multiple of 8.
长度是8的倍数。
The Extended Route Tag field contains one or more Extended Route Tags as learned in the IGP topology.
扩展路由标签字段包含一个或多个在IGP拓扑中学习到的扩展路由标签。
The Prefix Metric TLV is an optional attribute and may only appear once. If present, it carries the metric of the prefix as known in the IGP topology as described in Section 4 of [RFC5305] (and therefore represents the reachability cost to the prefix). If not present, it means that the prefix is advertised without any reachability.
前缀度量TLV是一个可选属性，只能出现一次。如果存在，则其携带如[RFC5305]第4节所述的IGP拓扑中已知的前缀度量（因此表示前缀的可达性成本）。如果不存在，则表示该前缀在没有任何可达性的情况下被通告。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: Prefix Metric TLV Format
图28：前缀度量TLV格式
Length is 4.
长度是4。
The OSPF Forwarding Address TLV [RFC2328] [RFC5340] carries the OSPF forwarding address as known in the original OSPF advertisement. Forwarding address can be either IPv4 or IPv6.
OSPF转发地址TLV[RFC2328][RFC5340]携带原始OSPF广告中已知的OSPF转发地址。转发地址可以是IPv4或IPv6。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Forwarding Address (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Forwarding Address (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: OSPF Forwarding Address TLV Format
图29:OSPF转发地址TLV格式
Length is 4 for an IPv4 forwarding address, and 16 for an IPv6 forwarding address.
IPv4转发地址的长度为4，IPv6转发地址的长度为16。
The Opaque Prefix Attribute TLV is an envelope that transparently carries optional Prefix Attribute TLVs advertised by a router. An originating router shall use this TLV for encoding information specific to the protocol advertised in the NLRI header Protocol-ID field or new protocol extensions to the protocol as advertised in the NLRI header Protocol-ID field for which there is no protocol-neutral representation in the BGP Link-State NLRI. The primary use of the Opaque Prefix Attribute TLV is to bridge the document lag between, e.g., a new IGP link-state attribute being defined and the protocol-neutral BGP-LS extensions being published.
不透明前缀属性TLV是一个信封，它透明地携带路由器公布的可选前缀属性TLV。发起路由器应使用该TLV编码NLRI头协议ID字段中公布的协议的特定信息，或NLRI头协议ID字段中公布的协议的新协议扩展，BGP链路状态NLRI中没有协议中立表示。不透明前缀属性TLV的主要用途是在定义新的IGP链路状态属性和发布协议无关的BGP-LS扩展之间桥接文档延迟。
The format of the TLV is as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque Prefix Attributes (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque Prefix Attributes (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: Opaque Prefix Attribute TLV Format
图30：不透明前缀属性TLV格式
Type is as specified in Table 11. Length is variable.
类型如表11所示。长度是可变的。
BGP link-state information for both IPv4 and IPv6 networks can be carried over either an IPv4 BGP session or an IPv6 BGP session. If an IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI SHOULD be an IPv4 address. Similarly, if an IPv6 BGP session is used, then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 address. Usually, the next hop will be set to the local endpoint
IPv4和IPv6网络的BGP链路状态信息可以通过IPv4 BGP会话或IPv6 BGP会话进行传输。如果使用IPv4 BGP会话，则MP\u REACH\u NLRI中的下一个跃点应为IPv4地址。类似地，如果使用IPv6 BGP会话，则MP_REACH_NLRI中的下一个跃点应为IPv6地址。通常，下一跳将设置为本地端点
address of the BGP session. The next-hop address MUST be encoded as described in [RFC4760]. The Length field of the next-hop address will specify the next-hop address family. If the next-hop length is 4, then the next hop is an IPv4 address; if the next-hop length is 16, then it is a global IPv6 address; and if the next-hop length is 32, then there is one global IPv6 address followed by a link-local IPv6 address. The link-local IPv6 address should be used as described in [RFC2545]. For VPN Subsequent Address Family Identifier (SAFI), as per custom, an 8-byte Route Distinguisher set to all zero is prepended to the next hop.
BGP会话的地址。下一跳地址必须按照[RFC4760]中所述进行编码。下一个跃点地址的长度字段将指定下一个跃点地址族。如果下一跃点长度为4，则下一跃点为IPv4地址；如果下一跳长度为16，则为全局IPv6地址；如果下一个跃点长度为32，则有一个全局IPv6地址，后跟一个链路本地IPv6地址。链路本地IPv6地址应按照[RFC2545]中的说明使用。对于VPN后续地址族标识符（SAFI），根据自定义，将一个设置为全零的8字节路由识别器前置到下一跳。
The BGP Next Hop attribute is used by each BGP-LS speaker to validate the NLRI it receives. In case identical NLRIs are sourced by multiple originators, the BGP Next Hop attribute is used to tiebreak as per the standard BGP path decision process. This specification doesn't mandate any rule regarding the rewrite of the BGP Next Hop attribute.
每个BGP-LS扬声器使用BGP Next Hop属性来验证其接收的NLRI。如果相同的NLRI由多个发起者提供，则根据标准BGP路径决策流程，使用BGP下一跳属性进行分层。本规范不强制执行任何有关重写BGP下一跳属性的规则。
The main source of TE information is the IGP, which is not active on inter-AS links. In some cases, the IGP may have information of inter-AS links [RFC5392] [RFC5316]. In other cases, an implementation SHOULD provide a means to inject inter-AS links into BGP-LS. The exact mechanism used to provision the inter-AS links is outside the scope of this document
TE信息的主要来源是IGP，它在AS间链路上不活动。在某些情况下，IGP可能具有AS间链路的信息[RFC5392][RFC5316]。在其他情况下，实现应提供将AS间链路注入BGP-LS的方法。用于提供AS间链路的确切机制不在本文件范围内
Encoding of a broadcast LAN in IS-IS provides a good example of how Router-IDs are encoded. Consider Figure 31. This represents a Broadcast LAN between a pair of routers. The "real" (non-pseudonode) routers have both an IPv4 Router-ID and IS-IS Node-ID. The pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for the LAN. Two unidirectional links (Node1, Pseudonode1) and (Pseudonode1, Node2) are being generated.
IS-IS中广播LAN的编码为路由器ID的编码提供了一个很好的示例。请考虑图31。这表示一对路由器之间的广播LAN。“真实”（非伪节点）路由器同时具有IPv4路由器ID和IS-IS节点ID。伪节点没有IPv4路由器ID。Node1是LAN的DI。正在生成两个单向链路（Node1，Pseudonode1）和（Pseudonode1，Node2）。
The Link NLRI of (Node1, Pseudonode1) is encoded as follows. The IGP Router-ID TLV of the local Node Descriptor is 6 octets long and contains the ISO-ID of Node1, 1920.0000.2001. The IGP Router-ID TLV of the remote Node Descriptor is 7 octets long and contains the ISO-ID of Pseudonode1, 1920.0000.2001.02. The BGP-LS attribute of this link contains one local IPv4 Router-ID TLV (TLV type 1028) containing 192.0.2.1, the IPv4 Router-ID of Node1.
（Node1，Pseudonode1）的链路NLRI编码如下。本地节点描述符的IGP路由器ID TLV为6个八位字节长，包含节点1的ISO-ID，1920.0000.2001。远程节点描述符的IGP路由器ID TLV为7个八位字节长，包含伪节点1的ISO-ID，1920.0000.2001.02。此链路的BGP-LS属性包含一个本地IPv4路由器ID TLV（TLV类型1028），其中包含节点1的IPv4路由器ID 192.0.2.1。
The Link NLRI of (Pseudonode1, Node2) is encoded as follows. The IGP Router-ID TLV of the local Node Descriptor is 7 octets long and contains the ISO-ID of Pseudonode1, 1920.0000.2001.02. The IGP
（伪节点1，节点2）的链路NLRI编码如下。本地节点描述符的IGP路由器ID TLV为7个八位字节长，包含伪节点1的ISO-ID，1920.0000.2001.02。IGP
Router-ID TLV of the remote Node Descriptor is 6 octets long and contains the ISO-ID of Node2, 1920.0000.2002. The BGP-LS attribute of this link contains one remote IPv4 Router-ID TLV (TLV type 1030) containing 192.0.2.2, the IPv4 Router-ID of Node2.
远程节点描述符的路由器ID TLV为6个八位字节长，包含节点2的ISO-ID，1920.0000.2002。此链路的BGP-LS属性包含一个远程IPv4路由器ID TLV（TLV类型1030），其中包含节点2的IPv4路由器ID 192.0.2.2。
+-----------------+ +-----------------+ +-----------------+
| Node1 | | Pseudonode1 | | Node2 |
|1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00|
| 192.0.2.1 | | | | 192.0.2.2 |
+-----------------+ +-----------------+ +-----------------+
+-----------------+ +-----------------+ +-----------------+
| Node1 | | Pseudonode1 | | Node2 |
|1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00|
| 192.0.2.1 | | | | 192.0.2.2 |
+-----------------+ +-----------------+ +-----------------+
Figure 31: IS-IS Pseudonodes
图31:IS-IS伪节点
Encoding of a broadcast LAN in OSPF provides a good example of how Router-IDs and local Interface IPs are encoded. Consider Figure 32. This represents a Broadcast LAN between a pair of routers. The "real" (non-pseudonode) routers have both an IPv4 Router-ID and an Area Identifier. The pseudonode does have an IPv4 Router-ID, an IPv4 Interface Address (for disambiguation), and an OSPF Area. Node1 is the DR for the LAN; hence, its local IP address 10.1.1.1 is used as both the Router-ID and Interface IP for the pseudonode keys. Two unidirectional links, (Node1, Pseudonode1) and (Pseudonode1, Node2), are being generated.
OSPF中广播LAN的编码为路由器ID和本地接口IP的编码提供了一个很好的示例。请考虑图32。这表示一对路由器之间的广播LAN。“真实”（非伪节点）路由器具有IPv4路由器ID和区域标识符。伪节点具有IPv4路由器ID、IPv4接口地址（用于消除歧义）和OSPF区域。Node1是局域网的DR；因此，其本地IP地址10.1.1.1用作伪节点密钥的路由器ID和接口IP。正在生成两个单向链路（Node1，Pseudonode1）和（Pseudonode1，Node2）。
The Link NLRI of (Node1, Pseudonode1) is encoded as follows:
（Node1，Pseudonode1）的链路NLRI编码如下：
o Local Node Descriptor
o 局部节点描述符
TLV #515: IGP Router-ID: 11.11.11.11
TLV #515: IGP Router-ID: 11.11.11.11
TLV #514: OSPF Area-ID: ID:0.0.0.0
TLV #514: OSPF Area-ID: ID:0.0.0.0
o Remote Node Descriptor
o 远程节点描述符
TLV #515: IGP Router-ID: 11.11.11.11:10.1.1.1
TLV #515: IGP Router-ID: 11.11.11.11:10.1.1.1
TLV #514: OSPF Area-ID: ID:0.0.0.0
TLV #514: OSPF Area-ID: ID:0.0.0.0
The Link NLRI of (Pseudonode1, Node2) is encoded as follows:
（伪节点1，节点2）的链路NLRI编码如下：
o Local Node Descriptor
o 局部节点描述符
TLV #515: IGP Router-ID: 11.11.11.11:10.1.1.1
TLV #515: IGP Router-ID: 11.11.11.11:10.1.1.1
TLV #514: OSPF Area-ID: ID:0.0.0.0
TLV #514: OSPF Area-ID: ID:0.0.0.0
o Remote Node Descriptor
o 远程节点描述符
TLV #515: IGP Router-ID: 33.33.33.34
TLV #515: IGP Router-ID: 33.33.33.34
TLV #514: OSPF Area-ID: ID:0.0.0.0
TLV #514: OSPF Area-ID: ID:0.0.0.0
+-----------------+ +-----------------+ +-----------------+
| Node1 | | Pseudonode1 | | Node2 |
| 11.11.11.11 |--->| 11.11.11.11 |--->| 33.33.33.34 |
| | | 10.1.1.1 | | |
| Area 0 | | Area 0 | | Area 0 |
+-----------------+ +-----------------+ +-----------------+
+-----------------+ +-----------------+ +-----------------+
| Node1 | | Pseudonode1 | | Node2 |
| 11.11.11.11 |--->| 11.11.11.11 |--->| 33.33.33.34 |
| | | 10.1.1.1 | | |
| Area 0 | | Area 0 | | Area 0 |
+-----------------+ +-----------------+ +-----------------+
Figure 32: OSPF Pseudonodes
图32:OSPF伪节点
Graceful migration from one IGP to another requires coordinated operation of both protocols during the migration period. Such a coordination requires identifying a given physical link in both IGPs. The IPv4 Router-ID provides that "glue", which is present in the Node Descriptors of the OSPF Link NLRI and in the link attribute of the IS-IS Link NLRI.
从一个IGP到另一个IGP的优雅迁移需要在迁移期间协调两个协议的操作。这种协调需要在两个IGP中识别给定的物理链路。IPv4路由器ID提供了“胶水”，它存在于OSPF链路NLRI的节点描述符和is-is链路NLRI的链路属性中。
Consider a point-to-point link between two routers, A and B, that initially were OSPFv2-only routers and then IS-IS is enabled on them. Node A has IPv4 Router-ID and ISO-ID; node B has IPv4 Router-ID, IPv6 Router-ID, and ISO-ID. Each protocol generates one Link NLRI for the link (A, B), both of which are carried by BGP-LS. The OSPFv2 Link NLRI for the link is encoded with the IPv4 Router-ID of nodes A and B in the local and remote Node Descriptors, respectively. The IS-IS Link NLRI for the link is encoded with the ISO-ID of nodes A and B in the local and remote Node Descriptors, respectively. In addition, the BGP-LS attribute of the IS-IS Link NLRI contains the TLV type 1028 containing the IPv4 Router-ID of node A, TLV type 1030 containing the IPv4 Router-ID of node B, and TLV type 1031 containing the IPv6 Router-ID of node B. In this case, by using IPv4 Router-ID, the link (A, B) can be identified in both the IS-IS and OSPF protocol.
考虑两个路由器A和B之间的点对点链路，最初是OSPFv2路由器，然后在它们上启用IS-IS。节点A具有IPv4路由器ID和ISO-ID；节点B具有IPv4路由器ID、IPv6路由器ID和ISO-ID。每个协议为链路（A、B）生成一个链路NLRI，这两个NLRI都由BGP-LS承载。该链路的OSPFv2链路NLRI分别使用本地和远程节点描述符中节点A和B的IPv4路由器ID进行编码。该链路的IS-IS链路NLRI分别用本地和远程节点描述符中的节点A和B的ISO-ID编码。此外，IS-IS链路NLRI的BGP-LS属性包含TLV类型1028（包含节点A的IPv4路由器ID）、TLV类型1030（包含节点B的IPv4路由器ID）和TLV类型1031（包含节点B的IPv6路由器ID）。在这种情况下，通过使用IPv4路由器ID，可以在IS-IS和OSPF协议中标识链路（A、B）。
Distribution of all links available in the global Internet is certainly possible; however, it not desirable from a scaling and privacy point of view. Therefore, an implementation may support a link to path aggregation. Rather than advertising all specific links of a domain, an ASBR may advertise an "aggregate link" between a non-adjacent pair of nodes. The "aggregate link" represents the
全球互联网上所有可用链接的分发当然是可能的；然而，从可伸缩性和隐私性的角度来看，这是不可取的。因此，实现可以支持到路径聚合的链接。ASBR不公布域的所有特定链接，而是公布非相邻节点对之间的“聚合链接”。“聚合链接”表示
aggregated set of link properties between a pair of non-adjacent nodes. The actual methods to compute the path properties (of bandwidth, metric, etc.) are outside the scope of this document. The decision whether to advertise all specific links or aggregated links is an operator's policy choice. To highlight the varying levels of exposure, the following deployment examples are discussed.
一对非相邻节点之间链路属性的聚合集。计算路径属性（带宽、度量等）的实际方法超出了本文档的范围。是否公布所有特定链接或聚合链接是运营商的策略选择。为了突出显示不同的暴露级别，将讨论以下部署示例。
Consider Figure 33. Both AS1 and AS2 operators want to protect their inter-AS {R1, R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants to compute its link-protection LSP to R3, it needs to "see" an alternate path to R3. Therefore, the AS2 operator exposes its topology. All BGP-TE-enabled routers in AS1 "see" the full topology of AS2 and therefore can compute a backup path. Note that the computing router decides if the direct link between {R3, R4} or the {R4, R5, R3} path is used.
请考虑图33。AS1和AS2运营商都希望使用RSVP-FRR LSP保护其AS{R1，R3}，{R2，R4}间链路。如果R1想要计算到R3的链路保护LSP，它需要“查看”到R3的备用路径。因此，AS2操作符公开其拓扑。AS1中所有启用BGP TE的路由器“查看”AS2的完整拓扑，因此可以计算备份路径。注意，计算路由器决定是使用{R3，R4}之间的直接链路还是使用{R4，R5，R3}路径。
AS1 : AS2
:
R1-------R3
| : | \
| : | R5
| : | /
R2-------R4
:
:
AS1 : AS2
:
R1-------R3
| : | \
| : | R5
| : | /
R2-------R4
:
:
Figure 33: No Link Aggregation
图33：无链接聚合
The brief difference between the "no-link aggregation" example and this example is that no specific link gets exposed. Consider Figure 34. The only link that gets advertised by AS2 is an "aggregate" link between R3 and R4. This is enough to tell AS1 that there is a backup path. However, the actual links being used are hidden from the topology.
“无链接聚合”示例与本示例之间的简单区别在于没有特定的链接被公开。请考虑图34。AS2发布的唯一链接是R3和R4之间的“聚合”链接。这足以告诉AS1存在备份路径。但是，实际使用的链接对拓扑是隐藏的。
AS1 : AS2
:
R1-------R3
| : |
| : |
| : |
R2-------R4
:
:
AS1 : AS2
:
R1-------R3
| : |
| : |
| : |
R2-------R4
:
:
Figure 34: ASBR Link Aggregation
图34:ASBR链路聚合
Service providers in control of multiple ASes may even decide to not expose their internal inter-AS links. Consider Figure 35. AS3 is modeled as a single node that connects to the border routers of the aggregated domain.
控制多个AS的服务提供商甚至可能决定不公开其内部AS间链路。请考虑图35。AS3被建模为连接到聚合域的边界路由器的单个节点。
AS1 : AS2 : AS3
: :
R1-------R3-----
| : : \
| : : vR0
| : : /
R2-------R4-----
: :
: :
AS1 : AS2 : AS3
: :
R1-------R3-----
| : : \
| : : vR0
| : : /
R2-------R4-----
: :
: :
Figure 35: Multi-AS Aggregation
图35：多AS聚合
IANA has assigned address family number 16388 (BGP-LS) in the "Address Family Numbers" registry with this document as a reference.
IANA已在“地址系列号”注册表中分配了地址系列号16388（BGP-LS），并将本文件作为参考。
IANA has assigned SAFI values 71 (BGP-LS) and 72 (BGP-LS-VPN) in the "SAFI Values" sub-registry under the "Subsequent Address Family Identifiers (SAFI) Parameters" registry.
IANA在“后续地址系列标识符（SAFI）参数”注册表下的“SAFI值”子注册表中分配了SAFI值71（BGP-LS）和72（BGP-LS-VPN）。
IANA has assigned value 29 (BGP-LS Attribute) in the "BGP Path Attributes" sub-registry under the "Border Gateway Protocol (BGP) Parameters" registry.
IANA在“边界网关协议（BGP）参数”注册表下的“BGP路径属性”子注册表中分配了值29（BGP-LS属性）。
IANA has created a new "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry at <http://www.iana.org/assignments/bgp-ls-parameters>. All of the following registries are BGP-LS specific and are accessible under this registry:
IANA在以下位置创建了一个新的“边界网关协议-链路状态（BGP-LS）参数”注册表：<http://www.iana.org/assignments/bgp-ls-parameters>. 以下所有注册表都是特定于BGP-LS的，可在此注册表下访问：
o "BGP-LS NLRI-Types" registry
o “BGP-LS NLRI类型”注册表
Value 0 is reserved. The maximum value is 65535. The registry has been populated with the values shown in Table 1. Allocations within the registry require documentation of the proposed use of the allocated value (Specification Required) and approval by the Designated Expert assigned by the IESG (see [RFC5226]).
保留值0。最大值为65535。注册表已填充表1中所示的值。注册中心内的分配需要记录分配值的拟议用途（需要规范）并获得IESG指定专家的批准（见[RFC5226]）。
o "BGP-LS Protocol-IDs" registry
o “BGP-LS协议ID”注册表
Value 0 is reserved. The maximum value is 255. The registry has been populated with the values shown in Table 2. Allocations within the registry require documentation of the proposed use of the allocated value (Specification Required) and approval by the Designated Expert assigned by the IESG (see [RFC5226]).
保留值0。最大值为255。注册表已填充表2中所示的值。注册中心内的分配需要记录分配值的拟议用途（需要规范）并获得IESG指定专家的批准（见[RFC5226]）。
o "BGP-LS Well-Known Instance-IDs" registry
o “BGP-LS已知实例ID”注册表
The registry has been populated with the values shown in Table 3. New allocations from the range 1-31 use the IANA allocation policy "Specification Required" and require approval by the Designated Expert assigned by the IESG (see [RFC5226]). Values in the range 32 to 2^64-1 are for "Private Use" and are not recorded by IANA.
注册表已填充表3中所示的值。1-31范围内的新分配使用IANA分配政策“所需规范”，并需要获得IESG指定专家的批准（见[RFC5226]）。32到2^64-1范围内的值仅供“私人使用”，IANA不记录这些值。
o "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry
o “BGP-LS节点描述符、链接描述符、前缀描述符和属性TLV”注册表
Values 0-255 are reserved. Values 256-65535 will be used for code points. The registry has been populated with the values shown in Table 13. Allocations within the registry require documentation of the proposed use of the allocated value (Specification Required) and approval by the Designated Expert assigned by the IESG (see [RFC5226]).
保留值0-255。值256-65535将用于代码点。注册表已填充表13中所示的值。注册中心内的分配需要记录分配值的拟议用途（需要规范）并获得IESG指定专家的批准（见[RFC5226]）。
In all cases of review by the Designated Expert (DE) described here, the DE is expected to ascertain the existence of suitable documentation (a specification) as described in [RFC5226] and to verify that the document is permanently and publicly available. The DE is also expected to check the clarity of purpose and use of the requested code points. Last, the DE must verify that any specification produced in the IETF that requests one of these code points has been made available for review by the IDR working group and that any specification produced outside the IETF does not conflict with work that is active or already published within the IETF.
在此处所述指定专家（DE）审查的所有情况下，DE应确定是否存在[RFC5226]中所述的适当文件（规范），并验证文件是否永久公开。DE还应检查所请求代码点的用途和使用的清晰性。最后，DE必须验证IETF中产生的任何规范（要求这些代码点之一）是否已提供给IDR工作组审查，并且IETF之外产生的任何规范是否与IETF中正在进行或已经发布的工作相冲突。
This section is structured as recommended in [RFC5706].
本节的结构如[RFC5706]所建议。
Existing BGP operational procedures apply. No new operation procedures are defined in this document. It is noted that the NLRI information present in this document carries purely application-level data that has no immediate corresponding forwarding state impact. As such, any churn in reachability information has a different impact than regular BGP updates, which need to change the forwarding state for an entire router. Furthermore, it is anticipated that distribution of this NLRI will be handled by dedicated route reflectors providing a level of isolation and fault containment between different NLRI types.
现有BGP操作程序适用。本文件未定义新的操作程序。需要注意的是，本文档中的NLRI信息包含纯粹的应用程序级数据，没有直接对应的转发状态影响。因此，可达性信息中的任何搅动都会产生与常规BGP更新不同的影响，后者需要更改整个路由器的转发状态。此外，预计该NLRI的分布将由专用路线反射器处理，在不同NLRI类型之间提供一定程度的隔离和故障遏制。
Configuration parameters defined in Section 6.2.3 SHOULD be initialized to the following default values:
第6.2.3节中定义的配置参数应初始化为以下默认值：
o The Link-State NLRI capability is turned off for all neighbors.
o 所有邻居的链路状态NLRI功能均已关闭。
o The maximum rate at which Link-State NLRIs will be advertised/ withdrawn from neighbors is set to 200 updates per second.
o 链路状态NLRIs从邻居播发/撤回的最大速率设置为每秒200次更新。
The proposed extension is only activated between BGP peers after capability negotiation. Moreover, the extensions can be turned on/ off on an individual peer basis (see Section 6.2.3), so the extension can be gradually rolled out in the network.
建议的扩展仅在能力协商后在BGP对等方之间激活。此外，扩展可以在单个对等基础上打开/关闭（参见第6.2.3节），因此扩展可以在网络中逐步展开。
The protocol extension defined in this document does not put new requirements on other protocols or functional components.
本文件中定义的协议扩展不会对其他协议或功能组件提出新要求。
Frequency of Link-State NLRI updates could interfere with regular BGP prefix distribution. A network operator MAY use a dedicated Route-Reflector infrastructure to distribute Link-State NLRIs.
链路状态NLRI更新的频率可能会干扰常规BGP前缀分布。网络运营商可以使用专用的路由反射器基础设施来分发链路状态NLRI。
Distribution of Link-State NLRIs SHOULD be limited to a single admin domain, which can consist of multiple areas within an AS or multiple ASes.
链路状态NLRIs的分布应限于单个管理域，该域可以由AS或多个ASE中的多个区域组成。
Existing BGP procedures apply. In addition, an implementation SHOULD allow an operator to:
现有的BGP程序适用。此外，实施应允许操作员：
o List neighbors with whom the speaker is exchanging Link-State NLRIs.
o 列出演讲者正在与之交换链接状态NLRIs的邻居。
The IDR working group has documented and continues to document parts of the Management Information Base and YANG models for managing and monitoring BGP speakers and the sessions between them. It is currently believed that the BGP session running BGP-LS is not substantially different from any other BGP session and can be managed using the same data models.
IDR工作组已记录并将继续记录管理信息库的部分内容，以及管理和监控BGP发言人和他们之间会议的模型。目前认为，运行BGP-LS的BGP会话与任何其他BGP会话没有实质性区别，可以使用相同的数据模型进行管理。
If an implementation of BGP-LS detects a malformed attribute, then it MUST use the 'Attribute Discard' action as per [RFC7606], Section 2.
如果BGP-LS的实现检测到格式错误的属性，则必须按照[RFC7606]第2节使用“属性丢弃”操作。
An implementation of BGP-LS MUST perform the following syntactic checks for determining if a message is malformed.
BGP-LS的实现必须执行以下语法检查，以确定消息是否格式错误。
o Does the sum of all TLVs found in the BGP-LS attribute correspond to the BGP-LS path attribute length?
o 在BGP-LS属性中找到的所有TLV的总和是否对应于BGP-LS路径属性长度？
o Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute correspond to the BGP MP_REACH_NLRI length?
o 在BGP MP_REACH_NLRI属性中找到的所有TLV的总和是否对应于BGP MP_REACH_NLRI长度？
o Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI attribute correspond to the BGP MP_UNREACH_NLRI length?
o 在BGP MP_UNREACH_NLRI属性中找到的所有TLV的总和是否对应于BGP MP_UNREACH_NLRI长度？
o Does the sum of all TLVs found in a Node, Link or Prefix Descriptor NLRI attribute correspond to the Total NLRI Length field of the Node, Link, or Prefix Descriptors?
o 在节点、链接或前缀描述符NLRI属性中找到的所有TLV的总和是否对应于节点、链接或前缀描述符的总NLRI长度字段？
o Does any fixed-length TLV correspond to the TLV Length field in this document?
o 是否有固定长度的TLV与本文档中的TLV长度字段相对应？
An implementation SHOULD allow the operator to specify neighbors to which Link-State NLRIs will be advertised and from which Link-State NLRIs will be accepted.
实现应允许操作员指定将向哪个链路状态NLRIs播发以及从哪个链路状态NLRIs接受的邻居。
An implementation SHOULD allow the operator to specify the maximum rate at which Link-State NLRIs will be advertised/withdrawn from neighbors.
实现应允许操作员指定从邻居通告/撤回链路状态NLRI的最大速率。
An implementation SHOULD allow the operator to specify the maximum number of Link-State NLRIs stored in a router's Routing Information Base (RIB).
实现应允许操作员指定路由器路由信息库（RIB）中存储的链路状态NLRI的最大数量。
An implementation SHOULD allow the operator to create abstracted topologies that are advertised to neighbors and create different abstractions for different neighbors.
实现应该允许操作员创建向邻居公布的抽象拓扑，并为不同的邻居创建不同的抽象。
An implementation SHOULD allow the operator to configure a 64-bit Instance-ID.
实现应允许操作员配置64位实例ID。
An implementation SHOULD allow the operator to configure a pair of ASN and BGP-LS identifiers (Section 3.2.1.4) per flooding set in which the node participates.
实现应允许运营商为节点参与的每个泛洪集配置一对ASN和BGP-LS标识符（第3.2.1.4节）。
Not Applicable.
不适用。
An implementation SHOULD provide the following statistics:
实施应提供以下统计信息：
o Total number of Link-State NLRI updates sent/received
o 发送/接收的链路状态NLRI更新总数
o Number of Link-State NLRI updates sent/received, per neighbor
o 每个邻居发送/接收的链路状态NLRI更新数
o Number of errored received Link-State NLRI updates, per neighbor
o 每个邻居收到的错误链路状态NLRI更新数
o Total number of locally originated Link-State NLRIs
o 本地发起的链路状态NLRI的总数
These statistics should be recorded as absolute counts since system or session start time. An implementation MAY also enhance this information by recording peak per-second counts in each case.
这些统计数据应记录为自系统或会话开始时间起的绝对计数。实现还可以通过在每种情况下记录每秒峰值计数来增强该信息。
An operator SHOULD define an import policy to limit inbound updates as follows:
操作员应定义导入策略以限制入站更新，如下所示：
o Drop all updates from consumer peers.
o 删除消费者同行的所有更新。
An implementation MUST have the means to limit inbound updates.
实现必须具有限制入站更新的方法。
This section contains the global table of all TLVs/sub-TLVs defined in this document.
本节包含本文件中定义的所有TLV/子TLV的全局表。
+-----------+---------------------+--------------+------------------+
| TLV Code | Description | IS-IS TLV/ | Reference |
| Point | | Sub-TLV | (RFC/Section) |
+-----------+---------------------+--------------+------------------+
| 256 | Local Node | --- | Section 3.2.1.2 |
| | Descriptors | | |
| 257 | Remote Node | --- | Section 3.2.1.3 |
| | Descriptors | | |
| 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 |
| | Identifiers | | |
| 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 |
| | address | | |
| 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 |
| | address | | |
| 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 |
| | address | | |
| 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 |
| | address | | |
| 263 | Multi-Topology ID | --- | Section 3.2.1.5 |
| 264 | OSPF Route Type | --- | Section 3.2.3 |
| 265 | IP Reachability | --- | Section 3.2.3 |
| | Information | | |
| 512 | Autonomous System | --- | Section 3.2.1.4 |
| 513 | BGP-LS Identifier | --- | Section 3.2.1.4 |
| 514 | OSPF Area-ID | --- | Section 3.2.1.4 |
| 515 | IGP Router-ID | --- | Section 3.2.1.4 |
| 1024 | Node Flag Bits | --- | Section 3.3.1.1 |
| 1025 | Opaque Node | --- | Section 3.3.1.5 |
| | Attribute | | |
| 1026 | Node Name | variable | Section 3.3.1.3 |
| 1027 | IS-IS Area | variable | Section 3.3.1.2 |
| | Identifier | | |
| 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Local Node | | |
+-----------+---------------------+--------------+------------------+
| TLV Code | Description | IS-IS TLV/ | Reference |
| Point | | Sub-TLV | (RFC/Section) |
+-----------+---------------------+--------------+------------------+
| 256 | Local Node | --- | Section 3.2.1.2 |
| | Descriptors | | |
| 257 | Remote Node | --- | Section 3.2.1.3 |
| | Descriptors | | |
| 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 |
| | Identifiers | | |
| 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 |
| | address | | |
| 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 |
| | address | | |
| 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 |
| | address | | |
| 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 |
| | address | | |
| 263 | Multi-Topology ID | --- | Section 3.2.1.5 |
| 264 | OSPF Route Type | --- | Section 3.2.3 |
| 265 | IP Reachability | --- | Section 3.2.3 |
| | Information | | |
| 512 | Autonomous System | --- | Section 3.2.1.4 |
| 513 | BGP-LS Identifier | --- | Section 3.2.1.4 |
| 514 | OSPF Area-ID | --- | Section 3.2.1.4 |
| 515 | IGP Router-ID | --- | Section 3.2.1.4 |
| 1024 | Node Flag Bits | --- | Section 3.3.1.1 |
| 1025 | Opaque Node | --- | Section 3.3.1.5 |
| | Attribute | | |
| 1026 | Node Name | variable | Section 3.3.1.3 |
| 1027 | IS-IS Area | variable | Section 3.3.1.2 |
| | Identifier | | |
| 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Local Node | | |
| 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Local Node | | |
| 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Remote Node | | |
| 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Remote Node | | |
| 1088 | Administrative | 22/3 | [RFC5305]/3.1 |
| | group (color) | | |
| 1089 | Maximum link | 22/9 | [RFC5305]/3.4 |
| | bandwidth | | |
| 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 |
| | link bandwidth | | |
| 1091 | Unreserved | 22/11 | [RFC5305]/3.6 |
| | bandwidth | | |
| 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 |
| 1093 | Link Protection | 22/20 | [RFC5307]/1.2 |
| | Type | | |
| 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 |
| 1095 | IGP Metric | --- | Section 3.3.2.4 |
| 1096 | Shared Risk Link | --- | Section 3.3.2.5 |
| | Group | | |
| 1097 | Opaque Link | --- | Section 3.3.2.6 |
| | Attribute | | |
| 1098 | Link Name | --- | Section 3.3.2.7 |
| 1152 | IGP Flags | --- | Section 3.3.3.1 |
| 1153 | IGP Route Tag | --- | [RFC5130] |
| 1154 | IGP Extended Route | --- | [RFC5130] |
| | Tag | | |
| 1155 | Prefix Metric | --- | [RFC5305] |
| 1156 | OSPF Forwarding | --- | [RFC2328] |
| | Address | | |
| 1157 | Opaque Prefix | --- | Section 3.3.3.6 |
| | Attribute | | |
+-----------+---------------------+--------------+------------------+
| 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Local Node | | |
| 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Remote Node | | |
| 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Remote Node | | |
| 1088 | Administrative | 22/3 | [RFC5305]/3.1 |
| | group (color) | | |
| 1089 | Maximum link | 22/9 | [RFC5305]/3.4 |
| | bandwidth | | |
| 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 |
| | link bandwidth | | |
| 1091 | Unreserved | 22/11 | [RFC5305]/3.6 |
| | bandwidth | | |
| 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 |
| 1093 | Link Protection | 22/20 | [RFC5307]/1.2 |
| | Type | | |
| 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 |
| 1095 | IGP Metric | --- | Section 3.3.2.4 |
| 1096 | Shared Risk Link | --- | Section 3.3.2.5 |
| | Group | | |
| 1097 | Opaque Link | --- | Section 3.3.2.6 |
| | Attribute | | |
| 1098 | Link Name | --- | Section 3.3.2.7 |
| 1152 | IGP Flags | --- | Section 3.3.3.1 |
| 1153 | IGP Route Tag | --- | [RFC5130] |
| 1154 | IGP Extended Route | --- | [RFC5130] |
| | Tag | | |
| 1155 | Prefix Metric | --- | [RFC5305] |
| 1156 | OSPF Forwarding | --- | [RFC2328] |
| | Address | | |
| 1157 | Opaque Prefix | --- | Section 3.3.3.6 |
| | Attribute | | |
+-----------+---------------------+--------------+------------------+
Table 13: Summary Table of TLV/Sub-TLV Code Points
表13：TLV/子TLV代码点汇总表
Procedures and protocol extensions defined in this document do not affect the BGP security model. See the Security Considerations section of [RFC4271] for a discussion of BGP security. Also refer to [RFC4272] and [RFC6952] for analysis of security issues for BGP.
本文档中定义的过程和协议扩展不影响BGP安全模型。有关BGP安全性的讨论，请参阅[RFC4271]的安全注意事项部分。有关BGP安全问题的分析，请参阅[RFC4272]和[RFC6952]。
In the context of the BGP peerings associated with this document, a BGP speaker MUST NOT accept updates from a consumer peer. That is, a participating BGP speaker should be aware of the nature of its relationships for link-state relationships and should protect itself
在与本文档关联的BGP对等环境中，BGP扬声器不得接受来自消费者对等的更新。也就是说，参与的BGP演讲者应了解其链路状态关系的性质，并应保护自己
from peers sending updates that either represent erroneous information feedback loops or are false input. Such protection can be achieved by manual configuration of consumer peers at the BGP speaker.
来自发送表示错误信息反馈循环或错误输入的更新的对等方。这种保护可以通过在BGP扬声器上手动配置消费者对等点来实现。
An operator SHOULD employ a mechanism to protect a BGP speaker against DDoS attacks from consumers. The principal attack a consumer may apply is to attempt to start multiple sessions either sequentially or simultaneously. Protection can be applied by imposing rate limits.
运营商应采用一种机制来保护BGP扬声器免受消费者的DDoS攻击。使用者可能应用的主要攻击是试图顺序或同时启动多个会话。可以通过施加利率限制来实施保护。
Additionally, it may be considered that the export of link-state and TE information as described in this document constitutes a risk to confidentiality of mission-critical or commercially sensitive information about the network. BGP peerings are not automatic and require configuration; thus, it is the responsibility of the network operator to ensure that only trusted consumers are configured to receive such information.
此外，可以认为，如本文件所述，链路状态和TE信息的导出构成了对网络关键任务或商业敏感信息保密的风险。BGP对等不是自动的，需要配置；因此，网络运营商有责任确保仅将受信任的消费者配置为接收此类信息。
[ISO10589] International Organization for Standardization, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/ IEC 10589, November 2002.
[ISO10589]国际标准化组织，“与提供无连接模式网络服务协议一起使用的中间系统到中间系统域内路由信息交换协议（ISO 8473）”，ISO/IEC 10589，2002年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，DOI 10.17487/RFC2328，1998年4月<http://www.rfc-editor.org/info/rfc2328>.
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, DOI 10.17487/RFC2545, March 1999, <http://www.rfc-editor.org/info/rfc2545>.
[RFC2545]Marques，P.和F.Dupont，“将BGP-4多协议扩展用于IPv6域间路由”，RFC 2545，DOI 10.17487/RFC2545，1999年3月<http://www.rfc-editor.org/info/rfc2545>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<http://www.rfc-editor.org/info/rfc3209>.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, <http://www.rfc-editor.org/info/rfc4202>.
[RFC4202]Kompella，K.，Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的路由扩展”，RFC 4202，DOI 10.17487/RFC4202，2005年10月<http://www.rfc-editor.org/info/rfc4202>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <http://www.rfc-editor.org/info/rfc4203>.
[RFC4203]Kompella，K.，Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，DOI 10.17487/RFC4203，2005年10月<http://www.rfc-editor.org/info/rfc4203>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 4271，DOI 10.17487/RFC4271，2006年1月<http://www.rfc-editor.org/info/rfc4271>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <http://www.rfc-editor.org/info/rfc4760>.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，DOI 10.17487/RFC4760，2007年1月<http://www.rfc-editor.org/info/rfc4760>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, <http://www.rfc-editor.org/info/rfc4915>.
[RFC4915]Psenak，P.，Mirtorabi，S.，Roy，A.，Nguyen，L.，和P.Pillay Esnault，“OSPF中的多拓扑（MT）路由”，RFC 4915，DOI 10.17487/RFC4915，2007年6月<http://www.rfc-editor.org/info/rfc4915>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.“LDP规范”，RFC 5036，DOI 10.17487/RFC5036，2007年10月<http://www.rfc-editor.org/info/rfc5036>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <http://www.rfc-editor.org/info/rfc5120>.
[RFC5120]Przygienda，T.，Shen，N.，和N.Sheth，“M-ISIS：中间系统到中间系统（IS-ISs）的多拓扑（MT）路由”，RFC 5120，DOI 10.17487/RFC5120，2008年2月<http://www.rfc-editor.org/info/rfc5120>.
[RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy Control Mechanism in IS-IS Using Administrative Tags", RFC 5130, DOI 10.17487/RFC5130, February 2008, <http://www.rfc-editor.org/info/rfc5130>.
[RFC5130]Previdi，S.，Shand，M.，Ed.，和C.Martin，“IS-IS中使用管理标签的策略控制机制”，RFC 5130，DOI 10.17487/RFC5130，2008年2月<http://www.rfc-editor.org/info/rfc5130>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, October 2008, <http://www.rfc-editor.org/info/rfc5301>.
[RFC5301]McPherson，D.和N.Shen，“IS-IS的动态主机名交换机制”，RFC 5301，DOI 10.17487/RFC5301，2008年10月<http://www.rfc-editor.org/info/rfc5301>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，DOI 10.17487/RFC5305，2008年10月<http://www.rfc-editor.org/info/rfc5305>.
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, <http://www.rfc-editor.org/info/rfc5307>.
[RFC5307]Kompella，K.，Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的IS-IS扩展”，RFC 5307，DOI 10.17487/RFC5307，2008年10月<http://www.rfc-editor.org/info/rfc5307>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 5340，DOI 10.17487/RFC5340，2008年7月<http://www.rfc-editor.org/info/rfc5340>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 5890，DOI 10.17487/RFC5890，2010年8月<http://www.rfc-editor.org/info/rfc5890>.
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, February 2011, <http://www.rfc-editor.org/info/rfc6119>.
[RFC6119]Harrison，J.，Berger，J.，和M.Bartlett，“IS-IS中的IPv6流量工程”，RFC 6119，DOI 10.17487/RFC6119，2011年2月<http://www.rfc-editor.org/info/rfc6119>.
[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, March 2012, <http://www.rfc-editor.org/info/rfc6549>.
[RFC6549]Lindem，A.，Roy，A.，和S.Mirtorabi，“OSPFv2多实例扩展”，RFC 6549，DOI 10.17487/RFC65492012年3月<http://www.rfc-editor.org/info/rfc6549>.
[RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. Ward, "IS-IS Multi-Instance", RFC 6822, DOI 10.17487/RFC6822, December 2012, <http://www.rfc-editor.org/info/rfc6822>.
[RFC6822]Previdi，S.，Ed.，Ginsberg，L.，Shand，M.，Roy，A.，和D.Ward，“IS-IS多实例”，RFC 6822，DOI 10.17487/RFC6822，2012年12月<http://www.rfc-editor.org/info/rfc6822>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <http://www.rfc-editor.org/info/rfc7606>.
[RFC7606]Chen，E.，Ed.，Scudder，J.，Ed.，Mohapatra，P.，和K.Patel，“BGP更新消息的修订错误处理”，RFC 7606，DOI 10.17487/RFC7606，2015年8月<http://www.rfc-editor.org/info/rfc7606>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，DOI 10.17487/RFC1918，1996年2月<http://www.rfc-editor.org/info/rfc1918>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <http://www.rfc-editor.org/info/rfc4272>.
[RFC4272]Murphy，S.，“BGP安全漏洞分析”，RFC 4272，DOI 10.17487/RFC4272，2006年1月<http://www.rfc-editor.org/info/rfc4272>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，DOI 10.17487/RFC4364，2006年2月<http://www.rfc-editor.org/info/rfc4364>.
[RFC4655] Farrel, A., Vasseur, JP., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4655]Farrel，A.，Vasseur，JP.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 4655，DOI 10.17487/RFC4655，2006年8月<http://www.rfc-editor.org/info/rfc4655>.
[RFC5073] Vasseur, JP., Ed. and JL. Le Roux, Ed., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", RFC 5073, DOI 10.17487/RFC5073, December 2007, <http://www.rfc-editor.org/info/rfc5073>.
[RFC5073]Vasseur，JP.，Ed.和JL。Le Roux，Ed.，“发现流量工程节点能力的IGP路由协议扩展”，RFC 5073，DOI 10.17487/RFC5073，2007年12月<http://www.rfc-editor.org/info/rfc5073>.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, <http://www.rfc-editor.org/info/rfc5152>.
[RFC5152]Vasseur，JP.，Ed.，Ayyangar，A.，Ed.，和R.Zhang，“建立域间流量工程（TE）标签交换路径（LSP）的每域路径计算方法”，RFC 5152，DOI 10.17487/RFC5152，2008年2月<http://www.rfc-editor.org/info/rfc5152>.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, December 2008, <http://www.rfc-editor.org/info/rfc5316>.
[RFC5316]Chen，M.，Zhang，R.，和X.Duan，“支持自治系统间MPLS和GMPLS流量工程的ISIS扩展”，RFC 5316，DOI 10.17487/RFC5316，2008年12月<http://www.rfc-editor.org/info/rfc5316>.
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, January 2009, <http://www.rfc-editor.org/info/rfc5392>.
[RFC5392]Chen，M.，Zhang，R.，和X.Duan，“支持跨自治系统（AS）MPLS和GMPLS流量工程的OSPF扩展”，RFC 5392，DOI 10.17487/RFC5392，2009年1月<http://www.rfc-editor.org/info/rfc5392>.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, DOI 10.17487/RFC5693, October 2009, <http://www.rfc-editor.org/info/rfc5693>.
[RFC5693]Seedorf，J.和E.Burger，“应用层流量优化（ALTO）问题陈述”，RFC 5693，DOI 10.17487/RFC5693，2009年10月<http://www.rfc-editor.org/info/rfc5693>.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <http://www.rfc-editor.org/info/rfc5706>.
[RFC5706]Harrington，D.，“考虑新协议和协议扩展的操作和管理指南”，RFC 5706，DOI 10.17487/RFC5706，2009年11月<http://www.rfc-editor.org/info/rfc5706>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, <http://www.rfc-editor.org/info/rfc6952>.
[RFC6952]Jethanandani，M.，Patel，K.，和L.Zheng，“根据路由协议键控和认证（KARP）设计指南分析BGP，LDP，PCEP和MSDP问题”，RFC 6952，DOI 10.17487/RFC6952，2013年5月<http://www.rfc-editor.org/info/rfc6952>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, <http://www.rfc-editor.org/info/rfc7285>.
[RFC7285]Alimi，R.，Ed.，Penno，R.，Ed.，Yang，Y.，Ed.，Kiesel，S.，Previdi，S.，Room，W.，Shalunov，S.，和R.Woundy，“应用层流量优化（ALTO）协议”，RFC 7285，DOI 10.17487/RFC7285，2014年9月<http://www.rfc-editor.org/info/rfc7285>.
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, <http://www.rfc-editor.org/info/rfc7770>.
[RFC7770]Lindem，A.，Ed.，Shen，N.，Vasseur，JP.，Aggarwal，R.，和S.Shaffer，“用于宣传可选路由器功能的OSPF扩展”，RFC 7770，DOI 10.17487/RFC7770，2016年2月<http://www.rfc-editor.org/info/rfc7770>.
Acknowledgements
致谢
We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les Ginsberg, Liem Nguyen, Manish Bhardwaj, Matt Miller, Mike Shand, Peter Psenak, Rex Fernando, Richard Woundy, Steven Luong, Tamas Mondal, Waqas Alam, Vipin Kumar, Naiming Shen, Carlos Pignataro, Balaji Rajagopalan, Yakov Rekhter, Alvaro Retana, Barry Leiba, and Ben Campbell for their comments.
我们要感谢Nischal Sheth，Alia Atlas，David Ward，Derek Yaung，Murtuza Lightwala，John Scudder，Kaliraj Vairavakkalai，Les Ginsberg，Liem Nguyen，Manish Bhardwaj，Matt Miller，Mike Shand，Peter Psenak，Rex Fernando，Richard Woundy，Steven Luong，Tamas Mondal，Waqas Alam，Vipin Kumar，Naiming Shen，Carlos Pignataro，Balaji Rajagopalan，亚科夫·雷克特、阿尔瓦罗·雷塔纳、巴里·莱巴和本·坎贝尔感谢他们的评论。
Contributors
贡献者
We would like to thank Robert Varga for the significant contribution he gave to this document.
我们要感谢罗伯特·瓦尔加对本文件作出的重大贡献。
Authors' Addresses
作者地址
Hannes Gredler (editor) Individual Contributor
汉内斯·格雷德勒（编辑）个人撰稿人
Email: hannes@gredler.at
Email: hannes@gredler.at
Jan Medved Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 United States
Jan Medved Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
Email: jmedved@cisco.com
Email: jmedved@cisco.com
Stefano Previdi Cisco Systems, Inc. Via Del Serafico, 200 Rome 00142 Italy
Stefano Previdi Cisco Systems，Inc.Via Del Serafico，200罗马00142意大利
Email: sprevidi@cisco.com
Email: sprevidi@cisco.com
Adrian Farrel Juniper Networks, Inc.
阿德里安·法雷尔·朱尼珀网络公司。
Email: adrian@olddog.co.uk
Email: adrian@olddog.co.uk
Saikat Ray
赛卡特射线
Email: raysaikat@gmail.com
Email: raysaikat@gmail.com